:: Re: [DNG] Multiple resignations fro…
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Rick Moen
Fecha:  
A: dng
Asunto: Re: [DNG] Multiple resignations from Freenode's staff ??? New drama shake the opensource
Quoting Dimitris via Dng (dng@???):

> there are lawyers-threats involved and he took infra too. so it's
> not that simple/light as you're presenting it.
> announced here as well : https://twitter.com/freenodestaff


As always, persons involve will need to judge for themselves whether
legal inevitable blustering must be paid any attention at all, and what
attention if any. It is extremely common to threaten vaguely described
tort action against software and project forks, by the way.

You have not bothered to state what your point is. So, I provisionally
conclude that you don't have one beyond "the person is making vague
legal threats against departed staff", which is of course exactly what
one expects in this situation. And? (Actually, no. I'd rather you not
tell me. Yes, I know that computer geeks throw their handkerchiefs and
have a fainting spell when someone issues bushwah tort threats, even
when those threats aren't against them. I just don't think this mental
aberration warrants my time.)

> what's most troublesome is that thousands of user data passed
> control without any info/consent.. to the crown prince - mt gox
> scammer(!)


If you don't wish to have the association between your IRC nick and your
e-mail address, which ISTR is the entirety of what this term "thousands
of user data" refers to, then go tell Freenode's NickServ to "DROP" your
nick. (Personally, I think that's pretty feeble 'user data'.)

Anyway, the above has no obvious connection to the prior discussion, but
you do you.

> p.s. most of the "spelling" paradigms you wrote, are not like that..
> but probably OT..


(1) It's a metaphor.  Obviously.
(2) In every case I cited, the core concept I spoke of applied, that
    in essence the project continued but left the old name behind.


The point is that this is a frequent and somewhat normal pattern in
software, and part of the grand tradition to fork if necessary in order
to get away from something that stands in the way of the project.

My point should be self-evident, so I don't intend to waste time arguing
with you just because you wish to debate the self-evidently true.