lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPweEDyMx7zEzt=g+12vUdeGEwmuvR85QaZB8-vKRP-oRtN5jw@mail.gmail.com>
Date:	Sun, 19 May 2013 13:24:32 +0100
From:	"luke.leighton" <luke.leighton@...il.com>
To:	Ralph Corderoy <ralph@...utplus.co.uk>
Cc:	Cole Johnson <coleharrisjohnson@...il.com>,
	legal@...ts.gpl-violations.org, linux-kernel@...r.kernel.org
Subject: Re: Would like to form a pool of Linux copyright holders for faster
 GPL enforcement against Anthrax Kernels

On Sun, May 19, 2013 at 12:04 PM, Ralph Corderoy <ralph@...utplus.co.uk> wrote:
> Hi Luke,
>
>> if i choose to release all copyright code under dual licenses then
>> THAT IS MY RIGHT
>
> Sssh!  It's a Sunday morning;  hangover time for many.

 :)  *sotto voice* sorry.

> Does the LICENSING section in
> http://lxr.free-electrons.com/source/Documentation/development-process/1.Intro#L237
> help?

 it does in some ways.  it doesn't answer the specific question, "how
do i formally get my copyright announcement updated in the linux
kernel source code" yet though but it does provide some opportunity to
point out some errors and mis-... mis-somethings, i can't think of the
exact word.


252 One implication of this ownership structure is that any attempt to change
253 the licensing of the kernel is doomed to almost certain failure.

 interesting.  this statement completely and utterly misses the point.
 it assumes that "the kernel" and "the license" are directly and
irrevocably linked.  which they most certainly are not.

 the statement *should* read as follows:

 "any attempt to change the licensing on the files which make up the
linux kernel"

which, again is mis-leading - in this case very very badly - because
it implies that somehow just because *most* of the files are under one
license, therefore automatically people should not make their *own*
mind - their own free and conscious choice - to release their
contributions under alternative licenses.

 i could give half a dozen examples, here, including many books and
films, documentaries, sports achievement stories and so on, all of
which are along the lines of, "person decides to break
mould/boundaries/tradition, gets told by priests/politicians/peers
it's not possible, distance/time/resources are too far/long/small
therefore you will fail/die/get-strung-up-for-heresy, they do it
anyway, and everyone goes hurrah at the end".

 let's make another attempt:

 "we the major linux copyright holders, who wrote this documentation,
respect your decision to choose an additional license as well as the
GPLv2 to release your code under, and it is important to make it clear
that we do not seek to influence your right to choose an additional
license or licenses, one way or the other.  the key to remember is
that any files released under licenses *not* compatible with the GPLv2
*CANNOT* legally be used.   as the kernel is an aggregated work, over
time the accumulation of files under alternative licenses (those that
are compatible with the current GPLv2 license) *may* result in a
useful and useable subset of the linux kernel source files coming
about.  so our personal opinion here - which should in no way
influence your own decisions - is that you are pissing in the wind if
you think that's going to come about any time soon, and as a result of
that, we (the major linux copyright holders who wrote this
documentation) decided not to bother releasing our contributions under
any license other than the GPLv2."


253          There are
254 few practical scenarios where the agreement of all copyright holders could
255 be obtained

 one such scenario would be to have a pool of individuals and entities
that maintain a subscription to a list such that their permission -
collectively - could be sought.  if there are some individuals or
entities that have begun the process, others may be more inclined to
follow.

 but even there, it's still not the point:

255                   (or their code removed from the kernel).

 i'm intrigued that there has been no mention of rewrites.  at some
point in the future, if there happens to be all but a critical but
tiny subset under an alternative license, surely someone would step up
and do a rewrite, yes?


255
       So, in particular,
256 there is no prospect of a migration to version 3 of the GPL in the
257 foreseeable future.

 "forseeable future".  is that a good reason to not take action??
"we're stuck here therefore we should not move" - how many
civilisations have died out exactly because of that kind of thinking??

 assuming we don't blow up the planet within 50-100 years, is it
reasonable to assume that in 50-100 years - and this is a sincere
question absolutely no dis-integrity here - is it reasonable to start
the process now such that linux in 50 to 100 years time is useable
under an alternative license?

 overall i see this entire paragraph as deeply flawed, full of
assumptions, and thoroughly defeatist.  i'm surprised that the
attention to detail normally inherent in linux kernel programming
hasn't been applied across the board.

l.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ