"Based on the new guidelines posted by the SFLC on 'Maintaining Permissive-Licensed Files in a GPL-Licensed Project: Guidelines for Developers', specifically section 5, we are introducing a new tag for use with patches which deal with files licensed under permissive licenses (BSD, ISC) on Linux wireless in our larger GPL project, the Linux kernel," explained Luis Rodriguez in an email titled, "new 'Changes-licensed-under' tag introduced for Linux-wireless". The web pages linked in the email appear to be an official response by the SFLC regarding the recent BSD vs. GPL licensing controversy surrounding the Atheros wireless device driver. Luis continued:
"Although some developers have a practice of implying their patches for a permissive licensed file abides by the respective permissive license of the file being patched, and although some changes are obviously not copyrightable, we would like to 'err on the side of caution', take the advice from SFLC, and introduce Changes-licensed-under in order to help the BSD family reap benefits of our contributions to permissive licensed files."
There were only a few brief replies to Luis' email. Stephen Hemminger suggested a simpler solution, "no, please don't [go] down this legal rat hole. It would cause bullshit like people submitting dual licensed patches to the scheduler or GPL only patches to the ath5k or ACPI code. Instead, add a section to Documentation/SubmittingPatches that clearly states that all changes to a file are licensed under the same license as the original file." Krzysztof Halasa pointed out that this was already the case, quoting a line from the Developer's Certificate of Origin contained in the SubmittingPatches file which says, "the contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file".
From: Luis R. Rodriguez
Subject: New 'Changes-licensed-under' tag introduced for Linux-wireless
Date: Sep 27, 11:00 am 2007
Our guidelines for patches [1] for Linux-wireless has been updated.
One section asks Linux-wireless developers to subscribe to the patch
guideline wiki page (section 2) and another which introduces the new
'Changes-licensed-under' (section 10).
Here I'll cover the new 'Changes-licensed-under' tag but please refer
to the link and subscribe to the page for the complete details and for
further changes.
--
Based on the new guidelines posted by the SFLC on ''Maintaining
Permissive-Licensed Files in a GPL-Licensed Project: Guidelines for
Developers'' [2], specifically section 5, we are introducing a new tag
for use with patches which deal with files licensed under permissive
licenses (BSD, ISC) on Linux wireless in our larger GPL project, the
Linux kernel. The tag is Changes-licensed-under and can be used by
developers to clarify the intended license for their patch on
permissive licensed files. It is clear that not all changes qualify a
patch author for Copyright but a lot of patches do qualify an author
for copyright. If you want crystal clear details of what constitutes
as a copyrightable change, at least within the US and the EU, you can
refer to SFLC's ''Originality Requirements under U.S. and E.U.
Copyright Law'' [3].
Although some developers have a practice of implying their patches for
a permissive licensed file abides by the respective permissive license
of the file being patched, and although some changes are obviously not
copyrightable, we would like to ''err on the side of caution'', take
the advice from SFLC, and introduce Changes-licensed-under in order to
help the BSD family reap benefits of our contributions to permissive
licensed files.
The Changes-licensed-under tag should be put before the Signed-off-by
tag. Since this tag is used to cover changes under permissive licenses
example of possible licenses are 3-Clause-BSD, and ISC. If you are
making changes to multiple permissive licensed files then please
specify which license covers what files.
--
For examples of using this tag please refer to the guidelines.
[1] http://linuxwireless.org/en/developers/SubmittingPatches
[2] http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
[3] http://www.softwarefreedom.org/resources/2007/originality-requirements.html
Luis
-
From: Stephen Hemminger
Subject: Re: New 'Changes-licensed-under' tag introduced for Linux-wireless
Date: Sep 27, 11:09 am 2007
On Thu, 27 Sep 2007 14:00:09 -0400
"Luis R. Rodriguez" <mcgrof@gmail.com> wrote:
> Our guidelines for patches [1] for Linux-wireless has been updated.
> One section asks Linux-wireless developers to subscribe to the patch
> guideline wiki page (section 2) and another which introduces the new
> 'Changes-licensed-under' (section 10).
>
> Here I'll cover the new 'Changes-licensed-under' tag but please refer
> to the link and subscribe to the page for the complete details and for
> further changes.
>
No, please don't down this legal rat hole. It would cause bullshit like
people submitting dual licensed patches to the scheduler or GPL only
patches to the ath5k or ACPI code.
Instead, add a section to Documentation/SubmittingPatches that clearly
states that all changes to a file are licensed under the same license
as the original file. I don't feel legally qualified to write the correct
wording.
--
Stephen Hemminger <shemminger@linux-foundation.org>
-
From: Krzysztof Halasa
Subject: Re: New 'Changes-licensed-under' tag introduced for Linux-wireless
Date: Sep 27, 1:17 pm 2007
Stephen Hemminger <shemminger@linux-foundation.org> writes:
> No, please don't down this legal rat hole. It would cause bullshit like
> people submitting dual licensed patches to the scheduler or GPL only
> patches to the ath5k or ACPI code.
Precisely. Signed-off-by means the patch author already authorized
the patch to be applied. With the patch merged the conditions still
in the file (project etc) apply and not some obscure email tags.
If someone really wants to change licencing conditions then the
licence conditions in the source code must be changed.
> Instead, add a section to Documentation/SubmittingPatches that clearly
> states that all changes to a file are licensed under the same license
> as the original file. I don't feel legally qualified to write the correct
> wording.
Current Documentation/SubmittingPatches:
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
indicated in the file; or
^^^^^^^^^^^^^^^^^^^^^
--
Krzysztof Halasa
-
Confusing and complex?
Doesn't this just make it confusing and complex?
Will people know what is licensed under what?
License proliferation sucks.
confusing
Yes, this will be very confusing. You will need to keep the original completely separate and patches also separately, then apply all patches before configuring and compiling. I agree that the original permissive license should be all that governs the file. BSD/ISC is more permissive than GPL, so there are absolutely no (legal) problems having BSD/ISC code in the Linux source. I have no idea what the coders themselves think about this - some don't like BSD/ISC because they believe the rights of the end user aren't protected, so they might object to BSD/ISC code in the tree.
On the other hand, the SFLC's advice on "dual-licensed" code is:
"If such a developer is using a license like the modified BSD license or the ISC license, where there is an established and widespread community understanding that the terms permit incorporation into larger programs covered by the GPL, the developer should simply use the permissive license without any further reference to the GPL."
In reality, BSD and Linux developers would both benefit by working on a particular piece of code. If a third party takes this code for it's proprietary work, who cares? It is in all likelihood a very minor part of the kernel and besides, the kernel would already have received benefit from the original code. I don't think small inclusions of more permissive licensed code really poses a significant threat of code being modified without contributions back to the original.
Using BSD code in Linux would...
But now the Linux kernel is under the GPL.
If BSD code would be added to Linux kernel, then it would be under the GPL with some BSD. That would make it more complex.
License proliferation sucks.
I wish BSD and Linux, used the same license. :(
Well, they still have convienently not addressed authorship
While these press releases include a vast amount of background, nothing has actually addressed the issue of authorship and copyright claimed on the files.
I believe we need to get reyk's opinion on this, as he is the original author, but
looking at:
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-dev.git;a=bl...
This file appears to be reyk's original work, then run through linux indent, with a few
stylistic changes, comments, and variable renames. The issue is does running code through
indent and renaming the variables constitute enough to add your name as an author right
up there with the original authors - is this a significant contribution?
I certainly don't think so. and I'm pretty sure reyk doesn't. I'm sure he can
comment further. Will this code go into the main linux kernel with the authorship
under question?
Keeping attribution is essential not the list of author
The list of author doesn't matter: what matters is attribution ie who did what: as long as the history is kept and it is known who did what it doesn't matter how many authors are listed.
You could add your name in the list of author if you removed a whitespace, if there is the patch history then it doesn't matter as it's possible to look at who did what..
Yes and no
Yes and no. The list of contributors does not matter as you say, however the list of copyright holders does. Removing trailing whitespaces or changing indention will make you a contributor, but not a copyright holder. This issue is addressed by the SFLC's Originality Requirements under U.S. and E.U. Copyright Law document.
Addressing authorship
Actually I think it was addressed here:
http://www.softwarefreedom.org/resources/2007/ath5k-code-analysis.html
Whether one agrees with the conclusions or not is a different matter but they do appear to have addressed the issue.
Clean room implementation
Just do a clean room implementation instead.
* Team 1 reads the original BSD code, and documents the code.
* Team 2 reads the documentation that Team 1 wrote, and then writes an implementation.
Then we can have it under GPL license.
Exactly, why waste precious
Exactly, why waste precious assets like dev time for spurious activities like bug-checking or functionality improvements, or for that matter reverse-engineering closed blobs, when we can constructively use double the devs for clean-room implementations of each others' code?
Don't be an asshole. You
Don't be an asshole. You GPL users can have all the BSD-licensed code you want. The point is that, when you unthinkingly apply the GPL all over a project created and largely maintained by BSD people, you screw them out of accepting any work back -- and then put them in a bad spot when they have to beg for less restrictive licensing on patches to their own code.
It really would cut down the drama to use per-file licensing; then if anyone wants to add specifically GPL'd components (the rate-control code that the madwifi? guys wanted to protect under the GPL), they just have to stick it in a separate file and add a #include. Equivalent to, but much less messy than, maintaining dozens of differently licensed .patch files, and it makes it much easier to turn the BSD portions into a working piece of BSD software.
Really, you have no idea how incensed I am that you would construe the argument backwards. What's worse is that I think you really were that confused and don't realize you were being a troll. (Unfortunately, these misunderstandings tend to snowball, and then /. gets involved...)
What's wrong?
What's wrong with that? The licence permits it, after all. If they don't like people doing that, why do they allow it in the licence terms?