linux-kernel - RE: how about mutual compatibility between Linux's GPLv2 and GPLv3?

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: <MDEHLPKNGKAHNMBLJOLKOEJBEMAC.davids@webmaster.com>
Date:	Thu, 21 Jun 2007 14:13:36 -0700
From:	"David Schwartz" <davids@...master.com>
To:	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: RE: how about mutual compatibility between Linux's GPLv2 and GPLv3?

Alexandre Oliva wrote:

> With a mere permission to combine, I can only enforce these provisions
> over my own code.

What does "my own code" mean when we're talking about derivative works and
code in the codebase influencing the design of later code? Code from one
module gets copied into another. Code in one module influences the design of
code in the kernel. New files are added with pieces from multiple other
files.

Are you seriously suggesting that the Linux kernel source contain code with
various different licenses with an obligation for those who work on the
source too keep track of which licenses apply to bits of code when they work
on them? That seems impossible as a practical matter.

All the kernel code not being available under the same license is a short
term problem. Over time, the code will get so combined and interwoven that
the intersection of all permitted licenses would soon apply to effectively
the entire kernel.

This would be no different from adopting GPLv3. Unless, that is, GPLv3 makes
itself compatible with GPlv2. In which case it would be no different from
doing nothing at all. (Except for all the pain it would cause as people
diligently try to figure out what licenses apply to their code and try not
to borrow code from parts of the kernel that have a different license from
the parts they are working on.)

DS

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