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]
Date:	Sun, 19 May 2013 09:45:48 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Jonas Gorski <jonas.gorski+gpl@...il.com>
Cc:	"luke.leighton" <luke.leighton@...il.com>,
	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 03:28:28PM +0200, Jonas Gorski wrote:
> Because Linus /is/ the highest authority regarding Linux. He holds the
> copyright to the most crucial parts, and without his cooperation, you
> will never get the GPLv2 parts to be re-licensed to GPLv2+, unless you
> remove everything from him and replace it with your own
> implementations. And do the same with every other contributors' code
> who doesn't agree to switch to GPLv2+.

It's not just Linus; many senior Linux kernel developers have spoken
very clearly that the anti-Tivoization clause in GPLv3 is totally
unacceptable, and so many of us have stated unequivocally that our
code will be released under a GPLv2-only license.  This means that
GPLv3-only code is always going to be incompatible with code released
as part of the Linux kernel, because substantial parts of the kernel
have and will be available only under a GPLv2 only license.

If anyone wants to release their code under a dual-license, it's
easist if that's how you submitted the code originally.  For example,
drivers/char/random.c is released under a BSD/GPLv2 dual license
(because I wanted to encourage its use in other operating systems,
since to me high quality crypto is more important that free software
wankery/idealism).

If you have only contributed a few lines or partially to a particular
single file, specifying that "these 15 linues of the function
I_worship_at_the_altar_of_rms() are under the GPLv2/v3, even through
the rest of the file is GPLv2-only" is not something that we generally
do.  Speaking as a subsystem maintainer, for the portions of the code
that I maintain, if someone insisted on line-level copyright
statements, I'd just simply reject the patch rather than dealing with
the accounting nightmare.

If you want to add a GPLv2/GPLv3 dual license to a file which you
originally contributed to, but then later on other peoeple have
contributed lines of code, you'll need to get the consent of everyone
who have contributed changes to that file.

Finally, as Jonas has stated, if you are trying to impose the
anti-Tivoization clause through the back door, it's not going to have
that effect, since people can always choose either license for
dual-licensed code, and for the kernel GPLv2 always has to be one of
the choices.  The only reason why you might want to dual-license the
code is if you want to allow said code to be used in other contexts,
either in BSD-licensed code in the case of a GPLv2/BSD dual license,
or GPLv3-only licensed code in the case of a GPLv2/GPLv3 dual license.

Regards,

						- Ted
--
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