linux-kernel - Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

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: <orfy4qffyj.fsf@oliva.athome.lsd.ic.unicamp.br>
Date:	Sun, 17 Jun 2007 18:07:00 -0300
From:	Alexandre Oliva <aoliva@...hat.com>
To:	Bernd Petrovitsch <bernd@...mix.at>
Cc:	Gabor Czigola <czigola@...il.com>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

On Jun 17, 2007, Bernd Petrovitsch <bernd@...mix.at> wrote:

> On Sun, 2007-06-17 at 15:55 -0300, Alexandre Oliva wrote:
>> On Jun 17, 2007, "Gabor Czigola" <czigola@...il.com> wrote:
>> 
>> > I wonder why the linux kernel development community couldn't propose
>> > an own GPL draft (say v2.2) that is "as free as v2" and that includes
>> > some ideas (from v3) that are considered as good (free, innovative, in
>> > the spirit of whatever etc.) by the majority of the kernel developers.
>> 
>> For one, because the text of the GPL is copyrighted by the FSF, and
>> licensed without permission for modification.  And that's as it should
>> be, you don't want others to modify the terms of the license you chose
>> for your code, do you?

> That's probably precisely the reason for removing the "or later" so that
> others (even if it's "only" the FSF) can't modify the terms of the
> license chosen for the code.

Yes, if you don't trust the organization entitled to publish revised
versions to abide by its commitment to abide by a similar spirit, or
if that spirit does not reflect your intent as a copyright holder,
this are all rational reasons to remove the "or later", indeed (at
least as much as distrust can be regarded as rational, that is ;-)

However, as Ingo argued, not being able to patch holes, fix bugs and
add new features is a very bad idea.  He was talking about the
software, but this is as true when it comes to the license.

There are smarter ways of retaining control over licensing terms that
don't paint yourself into a corner that's nearly impossible to get out
of.

For example, the license provisions could state "or any later version
that CONDITION", where CONDITION reflects your intent as a copyright
holder, or it could state "or any other license that CONDITION."

They could also appoint a committee, or rules for formation of a
committee, to make this sort of decisions on behalf of all the
copyright holders involved.

Of course, since these are in fact all additional permissions, anyone
could take them out, or rather elect not to offer this option for
their own contributions (and then you might end up refraining from
merging them).

The mechanics are no different from "or any later version" provisions,
really, except that then you establish what the goals of your
community are without blocking upgrades that wouldn't conflict, but
that would rather further the interests of your own community.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@...dhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@...d.ic.unicamp.br, gnu.org}
-
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/