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