RE: [beck@bofh.cns.ualberta.ca: I respect the GPL immensely,really I do - but I believe this type of action weakens us all.]

["David Schwartz" <davids@webmaster.com>]

> You miss the whole point of dual licencing:
> 
> Sam has stated in the licence that the code can be distributed under the 
> terms of the BSD licence, or alternatively it can be distributed under 
> the terms of the GPLv2.
> 
> Noone removed Sam's licence.
> 
> Sam has offered a choice, and if you choose one of the two offered 
> licences when distributing his code that complies with what he stated
> in his copyright notice.
> 
> IANAL, but if reyk contributed to dual licenced code keeping the file 
> dual licenced it's hard to argue that he did not make the changes he 
> made available dual licenced.

I think that there needs to be some general understanding about what the policy has to be when dual-licensed or BSD-licensed code is incorporated into the Linux kernel. Unfortunately, I don't think it's practical keep dual-licensed or BSD-licensed code in the Linux kernel because it prevents GPLv2 code from being incorporated into that file.

For example, if I make a file 'foo.c' available under a dual license, and it winds up in the Linux kernel, what happens? Suppose someone decides my locking is not optimal, and they cut/paste a few lines of code from another file, GPLv2 only, into 'foo.c'. Did they just put someone's GPLv2 code under a dual license? Of course not.

I think the policy should be:

1) If BSD-only code is incorporated into the Linux kernel, the BSD license must not be removed, as this is prohibited by the BSD license. However, a note should be included that only the original work is offered under the BSD license and that the license does not apply to the new elements that may have been added to that file. The file, as it presently sits, is likely only offered under the GPLv2.

2) If dual-licensed code is added to the Linux kernel, one of two things has to happen.

 A) If the code is relatively self-contained, it should stay dual-licensed. A warning should be placed in the file (with a pointer to a more detailed explanation) that GPLv2-only code cannot be spliced into this file without removing the dual-license.

 B) If the code is not relatively self-contained, or can no longer stay as A above due to the desire to splice in code from other modules are add GPLv2-only code, the GPL license should be removed.

I honestly wish that it would be possible to offer more code back to the BSD-licensed versions. If you know who I am, you know I'm a strong critic of the GPL license and much prefer the BSD license. However, I think Linux as a project suffers if it includes files available under different licenses. It's much harder to work with the code, modify it, and contribute to it.

Almost any consistent license is better than different files being under different licenses such that you are burdened with compliance issues when you try to move improvements from one file into another.

Imagine if every file system were under a different license and someon adds a new file system hook that every filesystem benefits from implementing. Suppose the original author submits an implementation for ext2 and it's under GPLv2. Think about the burdens if you then tried to implement that hook for three other filesystems, each with their own license, and you can't cut/paste the ext2 hook in.

DS


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