It came to my attention earlier this week that the Eclipse Foundation
had begun public discussion of the drafting of a new version of the EPL.
So far little has been said on the relevant mailing list:
This caught my attention though:
http://dev.eclipse.org/mhonarc/lists/epl-discuss/msg00013.html as it
relates closely to the 'rule vs standard' issue that in the past was
The suggestion made by Jim Wright is interesting as at a high level it
bears some relationship to what I have been thinking about lately for
copyleft-next. It starts out with MPL-style copyleft as a conceptual
basis and tries to define something more extensive, but (unlike EPL
1.0) attempts to do so by articulating something bright line instead
of relying on some legal notion of derivative works.
Recent Canadian law school graduate here. I like simple open source
licenses, hence my interest in copyleft-next.
Are you still taking pull requests on the GitHub repository? I
understand that the Gitorious repository is the official one for the
project, but it seems to me that both repos are kept in sync, and I
don't have a Gitorious account (yet).
If not, I'd be happy to get a Gitorious account to make my pull request
Althought I don't always agree with all of Rob Landley's positions, I
think he had a very interesting take copyleft compatibility issues,
and it makes a very interesting counterpoint to the "the state of
copyleft is fine" talks that I've been listening to lately.
In particular I was taken by Rob's comment:
But there's no "the GPL" anymore. Linux and Samba can't share code,
even though they implement two ends of the same protocol. And
making your project "GPLv2 or later" means you can't take code from
Since many people don't have the time (or patience) to wade through
the admittedly rather low signal-to-noise ratio of LKML, and I think
folks on this list might find it interesting, I thought I'd take the
liberty of forwarding it here.
So the question with respect to copyleft-next is whether the diagnosis
that the reason for the decline in copyleft's popuarity is because the
license is too complicated, or for the reasons which Rob has
articulated. If the answer is a little of both, is there anything we
can do to make sure that copyleft-next doesn't make the problem of
splitting the copyleft community worse? (i.e., by introducing a new
license which is both GPLv2 and GPLv3 incompatible)
The other thing that's worth thinking revisiting is the whole
"friendly to app store" question. I do believe that if more and more
users get their applications via application stores (insert the
standard story of the rise of mobile devices and the decline of PC's),
the fact that code can't be used by people who intend to publish their
products via app stores is going to significantly decrease their
desire to want to use a copyleft license.
Is there some way we could introduce some kind of DMCA passthrough
like arrangement? I can easily imagine Amazon not being thrilled
about the possibility, if someone uploads sources which do not
correspond to the binary, and a Rabid Copyleft Enforcement
organization (which is hypothetical; I am not positing that any of the
existing copyleft efforts fall is this category) sues Amazon to be in
compliance, it could very easily be the case that Amazon does not have
the power to force the organization which uploaded the the binary to
cure the noncompliance. And if said copylefted source code was
something Amazon was using in other contexts (for example, the Linux
Kernel or glibc), the fact that some cad uploaded a non-compliant
binary package should not be grounds for forcing Amazon from not using
said package forever. And the obvious solution here is for Amazon to
simply have a rule "no GPL in packages you upload to our app store".
I understand that in the case where it is a embedded handset
manufacturer, you want to be able to hold their feet to the fire, but
if the goal is to promote the use of the copyleft license, it's not
clear that the threat of holding an app store owner to the file is
neither just nor wise. Especially since you could substitute "Debian"
for "Amazon" in the above scenario, and realize that a malicious
Debian maintainer, colluding with someone who owned copyright on some
or all of some package which is critical to Debian's operations, could
conduct a very nasty, legal Denial of Service attack on Debian....
On Tue, May 21, 2013 at 05:11:47AM -0500, Rob Landley wrote:
> On 05/18/2013 01:27:21 PM, luke.leighton wrote:
> > actually, that's a good point. please can it be specifically noted,
> >from this moment onwards, that all contributions that i have made to
> >the linux kernel are dual-licensed under both the GPLv2 and also the
> >GPLv3+ license?
> I have a git repository that goes back to 0.0.1. The word "leighton"
> (case insensitive) occurs in the full log exactly once, in a single
> 2004 commit that wasn't even done by you but was apparently inspired
> by a patch you did.
> >someone has to start somewhere on this. it doesn't matter if it takes
> >20 years for all GPLv2-exlusive contributions to be made obselete,
> >deleted or replaced: a start has to be made.
> You're aware that copyleft in general is declining, right?
> "The GPL" was synonymous with copyleft. It was a terminal node in a
> directed graph of license convertability, and the only thing
> programmers had to know is whether or not some other license was
> GPL-compatible. If it was: treat it as GPL. If it wasn't: ignore it.
> But there's no "the GPL" anymore. Linux and Samba can't share code,
> even though they implement two ends of the same protocol. And making
> your project "GPLv2 or later" means you can't take code from
> _either_ source. These days the GPL largely serves to _prevent_ code
> re-use, and people have responded to the percieved problems with
> "GPL-next" initiatives where they fragment copyleft further with
> Affero variants, by using creative commons on code, and so on. But
> copyleft only ever worked as one big universal license, and now it
> In the absence of a universal receiver, most developers have
> switched to universal donor licenses: MIT/BSD or even public domain.
> Yes, "most": the most common license on Github is "no license
> specified", and that's not just ignorance, that's napster-style
> civil disobedience from a generation of coders who lump copyright in
> with software patents and consider it all "too dumb to live". (You
> think GPL enforcement suits are viewed any differently than DMCA
> takedown notices on youtube, both coming from clueless old people?)
> Now add in Android's official "no GPL in userspace" policy, which
> means that if you preinstall GPL (or LGPL) software in your install
> image, you can't use the Android trademark to describe your product.
> (Did I mention that smartphones are replacing the PC? Mainframe,
> minicomputer, microcomputer, smartphone:
> http://www.youtube.com/watch?v=SGmtP5Lg_t0#t=30s and that's why
> Android matters; it can get preinstalled on that class of hardware.
> Linux has been trying for 20 years and still has less than 2%
> marketshare on any device an end-user interacts directly with.)
> I'm sorry, but Richard Stallman _screwed_up_. GPLv3 suceeded where
> Sun's CDDL failed: it split copyleft into incompatible warring
> factions which are collectively shrinking in market share because
> none of them are as useful a "The GPL" was.
> I miss "the GPL". But it's gone. It seems to be being replaced by a
> gradual shift to public domain code on the part of younger coders.
> (Part of this may just be that proprietary software ran its course.
> The ability to sell binary-only software was invented by the Apple
> vs Franklin decision in 1983 extending copyright to binaries, and
> over the next 20 years the market proved that just leads to
> abandonware and monopoly exclusion. That's about when Microsoft
> peaked and started stagnating, a dozen years ago. Making a killing
> selling shrinkwrapped software isn't nearly as attractive as it used
> to be.*)
> Advocating for GPLv2 to go away is sad, but understandable.
> Expecting GPLv2 to be replaced by GPLv3 is just delusional.
> * Except for terminal nodes like games where there can't be any
> lock-in because users don't derive work product from the software.
> Users seem to have developed a resistance to "you can hold my thesis
> for ransom because I wrote it with your software and your gatekeeper
> program can revoke my access to my own work", presumably because so
> many tools have gone away over the years. Of course the lesson has
> to be learned all over again with web services, and some things like
> photoshop are grandfathered in. As always, reality is
A few comments on the experimental branch.
1) Section 4, copyleft conditions, 3rd paragraph, says that you could
distribute "a Modification under this License even if it incorporates
third-party material governed by a license that is both OSI-Approved and
FSF-Free". It seems to amount to distribution of code under two
licenses, in the sense of juxtaposing code under different licenses in
the same file, which sounds very confusing. I suppose this reading is
incorrect, or there is some reason for this?
2) I'd think the licensing condition on a patch (section 6) should be
licensing by default under the free and open license of the file as
applicable, like the DCO language, or I'm not sure how it'd work
3) Trivial stylistic comment
The definition of Modified Code doesn't sound as nice as the previous
definition of Derived Work :-) (sorry!)
I wonder if it is necessary to entirely replace the use of the verbs
(i.e. adapt, transform) with addition and deletion operations?
I think to me, it'd seem natural if some of these verbs would be
expressly applied to source code in files.
4) Copyleft conditions
To summarize (please correct me if this is wrong), as long as a file has
copyrightable code under copyleft-next, the file is licensed under
Neighboring code, code using the copyleft-next-ed code, is free and open
source. (within some limits)
One reason why I support this experiment, is that to me, there isn't a
clear difference between the neighboring code in
copyleft-next-experimental and the code incorporated as open licensed in
copyleft-next-master (under section 4).
I mean this in the sense that code incorporated as open licensed (under
section 4 master) can lead to neighboring code easily during
development, without necessarily realizing it. But any recipient should
be able to trust it has the open license under which it's distributed.
Accepting neighboring code as open licensed in the license, makes that
5) A remark
MPL copyleft is IMHO the closest match for the 'strongest layer'. I mean
I think it's a very understandable definition of the first layer for the
copyleft-next scope. And I think the reason is indeed as noted by
Fontana in another thread: because MPL boundary is the same with almost
all other licenses (MIT, BSD) boundary: the copyrightable code, the
source of licensing conditions on the code.
An open source developer will know when there's MIT code in a file to
respect its attribution conditions accordingly; or BSD code, or AL2.0
code. The criteria for MPL are no different. The file headers reflect
copyright and any license under which there is copyrightable code in
this file. (AFAIK, it's much more common to write headers with copyright
and license information in files; even if this information is of course
also per package.)
I'd say it's routine in an open source project, and I'd say it's simple.
I'll add here some thoughts I've been having, not in an organized
manner, I will only note them down, for the list.
Richard Fontana reminded in a previous email thread on this experiment,
of GPLv2 section 2, the 2nd and 3rd paragraphs. I remember reading these
paragraphs years ago, and finding the concept *fair*.
I'm not sure GPL really does that, though. Or the way it does it,
through relicensing every open license, or reject combination with it if
it can't (calling it incompatible), is arguably not ideal.
(which is not necessarily to say there is another objectively better
way, but other ways with different trade-offs.)
When there's no copyrightable code in a file, it's work written entirely
by someone else. Taken in itself.
It applies to a package, a library, an application. It doesn't matter if
individual developers may happen to be the same, because the *license*
matters more in many ways. And the license on that file can be BSD. Or
MIT, AL2.0, or MPL. It might be more obvious for web applications in
some interpreted languages, with open repositories. (or for permissive
OTOH, when there's no copyrightable code in a file/package, the code
_written entirely by someone else_ might interact with copylefted code,
add behavior or change behavior, such that the result of their
combination will be a work of authorship standing on its own too. Or, it
might not; it can be very loosely related, a package with an
implementation which has nothing to do with another, except there's a
call to tie the two. (such as 'import' and use some method, as it's been
noted lately on this list)
In copyleft-next-experimental, as long as work "written by you" is
combined with "my" code to form a new work, then I will ask you
explicitly only to offer users the same freedoms as any open licensed
software does: your code can be BSD, MIT, MPL licensed. Only that it
will be as software should be: free and open software. Not copyleft-next.
Experimental branch copyleft-next-ed code accepts around it any free and
open license as it is. It doesn't (re)license neighboring code to
copyleft-next, and it doesn't disallow code/data sharing if they're not
relicensable to it.
If I include a BSD file, in a copyleft-next-experimental project, it's
unambiguously BSD. Whether it uses the copyleft-next code or not.
If I take away a BSD file, from the copyleft-next-experimental project,
it's BSD. It can be licensed proprietary separately (*its* downstream).
But *not* as long as it's part of a work that incorporates the
copyleft-next-ed code: the copyleft-next license guarantees that.
Copyleft-next-ed code is incompatible with *proprietary* licensed code.
Not as much open licensed.
It can't be incorporated in proprietary software. This is an
essential goal of strong copyleft, and it never changed.
Its intention is to be incorporated in open source software.
The concept is "weaker" than practically relicensing any part of the
derivative/collective work. It doesn't do that.
But, its scope extends beyond "weak" copyleft. It enables an ecosystem
of free and open source software around it.
To me, this license and its *clarity* would be very valuable, if it's
possible. I should say I am biased, though, and I surely can miss
otherwise very obvious issues.
I think perhaps copyleft doesn't have to be a "license of all licenses,
which converts everything to it, or rejects sharing". Copyleft is the
guarantee of freedom. A guarantee to downstream users, in a way that
enables free and open software to build upon it.
I wonder if the concept is contradictory in some way I don't entirely see?
Or unenforceable. It unambiguously allows every open license to set its
own conditions only, when the software, source or binary, is distributed
*separately*. (as Fontana mentioned in the idea thread).
What would the worse scenario?
 cf GPLv2 and v3 last paragraph.
Here's an idea, or rather half or so of an idea, I have.
Suppose all there is is source code (more precisely the preferred form
for making modifications); we live in a universe where there is no
object code or where object code is beyond the scope of copyright
(this is just for simplicity). A work is necessarily something digital
and presented as a set of one or more files. This is of course the
explicit basis for the weak approach to copyleft in the MPL and its
ancestors and progeny.
Although one might argue it is not so obvious from the language of any
version of the MPL (or ancestral or derivative licenses -- I'll just
say "MPL"), I think the common understanding, and certainly what makes
MPL a 'rule-based' (and possibly-necessarily) weak copyleft, is that
copyleft extends only to source files that are verbatim copies or new
downstream files which copy sufficiently from upstream ones. To try to
go further than this is what Jim was proposing in the epl-discuss
posting I noted in my previous post. The implicit, and sometimes
explicit, critique of MPL-family licenses by advocates for
orthodox-discourse GPL strong copyleft interpretation, is that this
leaves some possibility for circumvention of copyleft that is avoided
either by the actual language of the GPL or by some consensus around
its proper interpretation. The problem with the latter is the "legal
angst" that was referred to in the epl-discuss thread, which kind of
implies an absence of consensus, even in the weak copyleft context of
Suppose I create a set of source files, S1. Someone downstream creates
S2 by copying some files in S1 verbatim, modifying some S1 files (such
that those files contain what is indisputably nontrivial literal
copying from S1), and adding some new files that indisputably do *not*
contain nontrivial literal copying from S1 (let us call that set of
new files N). Regardless of the source code programming language, in
the general case there will be dependency relationships among some of
the files in S1, and, independently, among some of the files in S2.
S2 might contain copyrightable code from third parties (as might S1)
but ignore that complication.
If I apply the MPL 'rule', I can easily figure out what files in S2
are in the scope of the copyleft coming from S1; I'll call that subset
T. It will not include anything in N.
There is a subset of the files in N, I'll call it N', that have direct
or indirect programmatic dependency relationships (according to the
nature of the particular programming language at issue) with files in
Suppose the copyleft rule is this: as in MPL, files T must be licensed
under copyleft-next. Files N' can be, but need not be, licensed under
copyleft-next, and instead can be licensed under some sort of
acceptable FLOSS license, copyleft or noncopyleft. GPL, MIT, whatever.
Suppose further that the rule allows anyone to avoid the condition for
the licensing of files N' by distributing them separately. If you want
to distribute N' under a proprietary license, do it
separately. (Ignore the possibility of some definitional problem
here.) Otherwise those files have to be FLOSS, but the precise license
doesn't matter (within some defined limits).
Suppose further that copyleft-next has a clause (as some early
versions did) clarifying that no lawful uses under copyright law are
limited or excluded.
Also suppose that copyleft-next has some kind of safe harbor for
package-oriented operating system distros, app store vendors, and
similar things (such that the separate distribution circumvention is
something that the distro or app store vendor or whatever can engage
in without having to worry too much about it until notice is
This is a strange idea, but it is a kind of stronger copyleft than
exists under MPL-like licenses. (Depending on the situation, and how
one interprets the LGPL, it might be weaker or stronger than the
LGPL.) It resolves the 'legal angst' in a number of ways: reducing
copyleft analysis to something like a simple static analysis problem;
making separate distribution an excuse (explicitly not so in GPLv3),
potentially avoiding a lot of the perceived problems of license
incompatibility across source file boundaries, ensuring closely
related code (distributed together) is FLOSS (even if noncopyleft in
isolation -- this is no different from what we see in some GPL works
today, and cf. GPLv2 section 2, antepenultimate paragraph). It
certainly allows modes of circumvention that are assumed to be absent
under interpretive-orthodoxy GPL (which itself is understood to allow
some modes of circumvention).
But apart from that, is this a bad idea, or a nonsensical idea?