copyleft-next patent commons?
by Gervase Markham
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
10 years, 7 months
Section 4 and 7 - permissive license contenand development process
by Luis R. Rodriguez
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
10 years, 8 months
Inbound-outbound clause and licensor promise
by Engel Nyst
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
10 years, 8 months