copyleft-next March 2013

copyleft-next@lists.fedorahosted.org

4 participants
4 discussions

copyleft-next patent commons?
by Gervase Markham 10 Apr '13

10 Apr '13

Again, forgive me if this has been discussed before... Has the group considered the pros and cons of changing section 10), para b), to cover all copyleft-nexted works? So: 10. Termination Your license grants under section 1 are automatically terminated if You ... b) initiate a patent infringement litigation claim (excluding declaratory judgment actions, counterclaims, and cross-claims) alleging that any work under this License directly or indirectly infringes any patent. In other words, if you sue someone over a patent in a copyleft-nexted work, you lose rights to use all copyleft-nexted works. As copyleft-nexted works become more common and more useful (say e.g. a copyleft-nexted work was incorporated into Android) it would become more and more of a bad idea to sue anyone for patent infringement relating to such work. After all, in that case, the first thing you'd have to do is replace all the company Android phones with iPhones... The potential disadvantage of this, presumably, is the risk that organizations will be less interested in writing or using copyleft-nexted works. Gerv

8 30

copyleft-next 0.2.1 released
by Richard Fontana 12 Mar '13

12 Mar '13

Good news, everyone! copyleft-next 0.2.1 has now been released. https://gitorious.org/copyleft-next/copyleft-next/blobs/raw/master/Releases… - RF

2 1

Section 4 and 7 - permissive license contenand development process
by Luis R. Rodriguez 09 Mar '13

09 Mar '13

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

5 11

Inbound-outbound clause and licensor promise
by Engel Nyst 09 Mar '13

09 Mar '13

Hello copyleft-next, I'd submit for discussion the (re)introduction of an inbound-outbound clause for contributions, and the possibility to use it as the place where the upstream licensor makes an explicit promise: to keep the software under copyleft. A clause in the style of Apache License 2.0 section 5[1] has been in the text of copyleft-next at some point[2], however it has been removed later. I'd suggest to re-add it (and thereby make CLAs more clearly unnecessary), and also, to consider addition of a second part. Part #1: "Unless You explicitly state otherwise when making it, any Contribution intentionally submitted for inclusion in a Covered Work by You to Us shall be under the terms and conditions of this License, without any additional terms or conditions." Part #2: "By accepting the Contribution, We promise to only distribute it under copyleft-next, or future versions." Or, "By accepting your Contribution, We acknowledge your intention to be distributed by Us under copyleft-next only, unless You make a public express statement of your agreement to different terms." Or, "By accepting your Contribution, We acknowledge your intention that We distribute it solely under copyleft-next or future versions, and We promise to offer any work we prepare based on it under these terms (or of a future version)." I assume these attempts are quite unworkable (please shut them down), but consider the point itself. As far as I can tell, this will not, and can not, make the licensor legally bound, because Licensor (in AL 2.0 sense) can always receive a different license, like the CLA grant. The CLA, IMO, will apply unrestricted anyway. IANAL though. OTOH, this opinion is not widely shared[3]: it seems the respective AL 2.0 paragraph can be read as precisely making room for Apache itself to not follow the conditions of the AL 2.0 grant, but instead license on the basis of the CLA grant. Please see the thread: the potential that AL 2.0 submissions clause *could limit* the CLA holding entity in some way is quite interesting. But is legally binding of the promise the only issue worth pursuing? The expression of intention of contributors, or the creation of an expectation from the community in regard to the behavior of a CLA-holding entity, could have more positive effects. Added up to part #1. Some of the issues with CLAs are that they might be signed with many unwritten expectations, and they may grant much more rights, than they were originally intended for. A clause like this is a place to have those expectations written. Other issues with CLAs are simply that they're separate documents, which give licensing rights, are deemed necessary for some reason, and are written as an agreement (not as a license) typically in legalese. Personally, I see a concerning potential for proprietary relicensing to affect community contributions which were not intended to be proprietary by contributors. (as far as I understand, Richard Fontana disagrees with this. I admit I am not objective on the matter.) In any case, I wonder if this proposal can reduce the potential, creating a better environment *before* proprietary relicensing has occasion, agreements, interests, to happen. [1] http://apache.org/licenses/LICENSE-2.0 [2] http://ur1.ca/crp2u [3] http://thread.gmane.org/gmane.comp.apache.legal.discuss/2708

2 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

copyleft-next March 2013