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:
Your license grants under section 1 are automatically terminated if
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
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
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 
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 . 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
 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 . 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.
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
A clause in the style of Apache License 2.0 section 5 has been in
the text of copyleft-next at some point, 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.
"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."
"By accepting the Contribution, We promise to only distribute it
under copyleft-next, or future versions."
"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."
"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: 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
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.
Dear Mr. Castro:
Greetings from Ashtabula. After asking Richard Fontana, our project
leader, on Identica I write to inquire about having a session during UDS
March 2013 where the copyleft-next team can talk about the license we
have been developing and how it may be used by projects within the
Ubuntu ecosystem. I caught Mr. Bacon's note earlier today that we're
experimenting with having virtual summits in lieu of in-person ones and
I would like to spread the word about this license development effort
with our community during UDS March.
The license project has a website here: http://copyleft-next.org/
The current working release of the license is available here:
In attempting to comply with the spirit of the project's Harvey Birdman
Rule, I am copying the project's e-mail list so that this inquiry is
disclosed to other project participants. I urge you to join us on the
list via the mailman form here so as to further discuss the matter:
Thank you for your time and consideration.
Stephen Michael Kellat
An Ubuntu Member
Does anyone think the idea of a limited-term copyleft -- particularly
given that copyleft-next is a software-oriented license -- is a
We're now a few years from the point where there could be 30-year-old
code under GPL-like licenses. I have found from $DAYJOB experience
that one occasionally has to deal with legal issues concerning
*really* old code (in a situation I dealt with today, from 1979;
admittedly that's unusual).
The idea would be to have the copyleft terms disappear after some
limited period far short of the statutory copyright term.
This is of course conceptually similar to the Creative Commons
'Founder's Copyright' idea and is related to general criticisms of
present-day copyright term duration.
If anyone thinks it's a good idea, what would be a good copyleft
duration? 15, 20, 25 years?
Please do not hesitate to shoot this down.
This is a HBR cure.
First, for those of you not following the official draft closely, as
of a recent commit, I have audaciously and iconoclastically added this
sentence to the (now single) section on object code disribution:
Each recipient of the Covered Work from You is an intended
third-party beneficiary of this License solely as to this section 
with the right to enforce its terms.
If any of the lawyers on this list have any comments of a strictly
insider-professional-knowledge *legal* nature on this sentence,
including arguments for its deletion or modification, feel free to
speak up (in a HBR-compliant manner of course).
If anyone (non-lawyer or otherwise) thinks it would be bad *policy* to
live in a world where a GPL-like license could be enforced through the
legal system by the obvious immediate beneficiaries of the source code
requirement, feel free to speak up (in a HBR-compliant manner of
That said, on to the HBR cure: I had a conversation with Bradley Kuhn
in which we very briefly discussed this issue, as Bradley was long
under the impression that the GPL could not *possibly* support an
argument that mere licensees have some standing to enforce the source
code requirement (despite the fact, of which Bradley might not be
aware, that over the years some legal academics have at last taken the
question seriously, if skeptically, and some private practice lawyers
[admittedly seeking to profit from the erstwhile open source boom, the
SCO crisis, etc.] purported to take this qite seriously too).
I noted the obvious point that copyleft-next and GPLv2/GPLv3 are not
worded identically, so his comment was partially irrelevant.
Bradley mentioned some interesting work that Australian lawyer Brendan
Scott had done attempting, AIUI, to use Australian consumer protection
law to give a basis for GPL licensees to sue upstream distributors for
failure to provide source code. It is not clear whether such efforts
have been successful.
Yesterday on IRC a handle of substantive topics were discussed.
While it's not clear that any decisions have been taken, the issues
raised seem worthy of HBR disclosure.
tmarble discussed the "transitive grace period" mail from Zooko
- noted Zooko brought this up before on debian-legal
- expressed uncertainty of downstream licensors could
"take advantage" of §2 to effectively withhold CCS to
derived works for up to a year.
- §2 does apply to downstream licensors
- there is potential for confusion between various grace periods
(and maybe even a potential for hucksterism)
The group discussed the problematic nature of defining "proprietary" software
as not meeting the OSD (too much room for interpretation, lobbying).
Fontana considers going back to "OSI Approved".
tmarble expressed concern that TPL or TGPPL like terms may introduce
vulnerabilities to copyleft-next. Perhaps a permissive license is
better suited to that audience?
The group was discussing EPL compatibility when mlinksva mentioned
another Rich Hickey license. The license in question is the
"Datomic Free Edition License"
Despite the title this is a virally non-free license.
Interestingly mlinksva points out that large sections of that
license are copied verbatim from CC-by-nd 3.0.
tmarble brought up the issue of *Sui Generis* database rights
and mlinksva stated that he has some pending comments on this topic
which are apropos to copyleft-next (for use with licensing data).
mlinksva commented on how long and complex the new OSM ODbL license is:
warp mentions that coverage of database rights for Europe would be welcome.
I'm interested in the possibility of using (a future version of)
copyleft-next for Tahoe-LAFS ¹. One possible way to do that would be
to define "version 2 of the Transitive Grace Period Public Licence" to
be some future version of copyleft-next, or a derivative of
copyleft-next. Since Tahoe-LAFS is licensed ³ under "Transitive Grace
Period Public Licence, version 1 or, at your option, any later
version", then I think this would allow everyone to start using
Tahoe-LAFS under the terms of copyleft-next. Another possibility could
be that the rights-holders (the Tahoe-LAFS Software Foundation) could
re-license it under copyleft-next.
My main motivation for considering copyleft-next is that I value
concision, simplicity, and readability-to-the-layman. So the pitch for
copyleft-next as published in LWN ⁴ appeals to me.
There are other things that appeal to me about it, such as the patent
lawsuit termination clause.
Now, I'm writing to ask: what would it take for me to offer a
*transitive* grace period for proprietary derived works? If I
understand correctly, §2 prevents a copyright holder from granting
only copyleft (not permissive) rights to some people under
copyleft-next while granting time-unlimited permissive works to other
However, consider this scenario, which is actually real life and not
1. Copyright to the Tahoe-LAFS source code is held by The Tahoe-LAFS
2. LeastAuthority.com (that's my company) has written extensions to
Tahoe-LAFS, which constitute a derived work of Tahoe-LAFS source code.
LeastAuthority.com has no special permissions to use the Tahoe-LAFS
source code other than the publicly available open source licensing
3. LeastAuthority.com would like to keep our derived work proprietary
for a limited time — 12 months from when we start redistributing or
4. LeastAuthority.com would like to *not have the option* of changing
our minds and keeping the derived work proprietary for longer than
that. This may be surprising to you, but it is a form of safety for
our customers. We're hoping to get more customers because they know
that we *don't have that option*, even if we were to get bought out by
a larger company with very different plans than ours.
5. LeastAuthority.com would like, at that future time when we grant
open source rights to use our derived work, if other people are able
to make derived works of our derived work, and if they are able to
keep their derived work proprietary for a limited time, but it is
important to us that they are *not* able to keep their derived work
proprietary for longer than that.
All of the above is actually true, except of course that the parts
about what we desire and intend may change with the weather.
Now if I understand correctly, if the Tahoe-LAFS Software Foundation
were to license the Tahoe-LAFS source code under copyleft-next v0.2,
then the Tahoe-LAFS Software Foundation would be able to make
proprietary derived works, or to license others to do so, in a
time-limited way, but LeastAuthority.com would not. Is that correct?
Do you see why that doesn't satisfy our (current) desires?
Founder, CEO, and Customer Support Rep
I know this has been discussed several times and quite cosmetic, but still
think that emphasizing Sections 10 & 11 by enclosing hash symbols "##" is
(slightly, I admit) confusing. I have to confess that I wondered for some
time why those very important clauses are commented-out...maybe I'm too
used to some scripting langages ;-)
The issue ticket  claims that it followed the MPL 2.0 convention, but
they actually use asterisks instead. Well, asterisks also remind me of
old C-style comments, but I guess * is better than #...
Assistant Professor of Economics, Surugadai University, Japan
mhatta(a)gnu.org / mhatta(a)debian.org / mhatta(a)mhatta.org /