[copyleft-next] Section 4 and 7 - permissive license contenand development process

Luis R. Rodriguez mcgrof at do-not-panic.com
Tue Feb 26 22:24:51 UTC 2013


Kudos on the copyleft-next-0.2.0 release!

A few questions regarding section 4 and 7. For clarity I'll paste both
sections and then post my questions after.

4. Conditions for Distributing Derived Works; Outbound GPL Compatibility

   If You distribute a Derived Work, You must license the entire Derived
   Work as a whole under this License, with prominent notice of such
   licensing. This condition may not be avoided through such means as
   separate distribution of portions of the Derived Work.

   You may additionally license the Derived Work under any version of the
   GNU General Public License published by the Free Software Foundation
   ("GPL"), so that the recipient may further distribute the Derived Work

7. Symmetrical Licensing Condition for Upstream Contributions

   If You distribute a work to Me specifically for inclusion in or
   modification of a Covered Work (Your "Patch"), then, unless Your Patch
   explicitly states otherwise, You license it to Me under this License, to
   the extent of Your copyright in Your Patch. This condition does not
   negate the other conditions of this License, if applicable to Your
   Patch.

As it is today the GPL allows for permissive license contributions and
for example you are entitled to extract these permissive license
contributions (them having a license statement on the top of the
header file) and use these permissive license components in permissive
licensed / proprietary new or existing projects. We discovered this
for a big project with the help of SFLC during the ath5k wars, for
example, and we used this to help share code between BSD and Linux [0]
and today I try to exploit this on my question on killing proprietary
drivers. I'll note that there are some interpretations on intent on
this on certain projects, like for example in a big GPL project the
intent behind developers is that although we allow for this we do not
intend to enable extracting permissive licensed components from the
GPL larger project for you to go and make non-GPL compatible
modifications of that extracted content to the same GPL larger project
given that the license at run time of the individual components are
all GPL [1]. My questions then:

1) Does copyleft-next allow for the same type of extraction of
permissive licensed components if they are declared as such for
sharing in a permissive license / proprietary project?

2) I argue that perhaps the last part that I describe in the above
paragraph be actually clarified as intent and by design of the
license, if not already.

3) The last question has to do with development process and licensing.
Section 7 has language that asserts that if patches are submitted that
it will be assumed the contribution is being made under the same
license unless otherwise stated. This is good, however I invite you to
please review and consider the effort behind the signed-off-by fork
[2] by W. Trevor King that was spawned after discussions of the
potential of forking the Signed-off-by Developer Certificate of Origin
on the Linux kernel [3]. What I wonder is if a merge of such / similar
language onto copyleft-next may help with development process
therefore making an understanding and respect of development process
through licensing, thereby making the requirement of a Signed-off-by
tag perhaps not required.

Thoughts?

[0] https://lkml.org/lkml/2012/4/6/371
[1] https://lkml.org/lkml/2012/4/7/119
[2] https://github.com/wking/signed-off-by
[3] https://lkml.org/lkml/2012/11/20/636

  Luis


More information about the copyleft-next mailing list