EPL 2.0
by Richard Fontana
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:
https://dev.eclipse.org/mailman/listinfo/epl-discuss
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
discussed here.
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.
- RF
8 years, 5 months
An interesting take on license compatibility
by Theodore Ts'o
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
_either_ source.
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....
- Ted
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
> doesn't.
>
> 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.
>
> Rob
>
> * 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
> complicated...
10 years, 1 month
An idea
by Richard Fontana
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
EPL 1.0.
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
T.
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
received).
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?
- RF
10 years, 2 months
Non-update on copyleft-next
by Richard Fontana
Hi,
Not really much of an update:
Of late I've been trying to do something I believe I talked about
before, re-implement copyleft-next as a 'file-based' copyleft that is
less minimalist than MPL. As of yet I have not figured out how to do
this in a way I consider satisfactory, particularly one which is
(adequately) programming-language-agnostic and would have
normally-sane results, but I feel that it is important to attempt. I
am coming to appreciate certain qualities in the MPL approach that I
had previously overlooked, or been in some denial about.
If some satisfactory result is produced by this effort, it will be a
significant change to previous drafts of copyleft-next. It *might*
mean enough of a loss of structural elegance as to make it preferable
to stick with the existing approach (which I thought was coming along
okay), but that is not clear to me yet.
- RF
10 years, 2 months
Expanding the scope of OSI to be an "open source best practices" clearinghouse
by Alison Chaiken
Thanks to Luis, Simon and Richard for sharing their thoughts about the
Certificate of Origin. Codes of Conduct is perhaps another area
where OSI could usefully have a compliance specification or approval
process similar to its role with open-source licenses:
http://www.h-online.com/open/news/item/Python-Software-Foundation-publish...
Codes of Conduct and Certificates of Origin, like software licenses,
are areas where larger open-source projects want to adopt accepted
best practices, and smaller communities want to expend minimal effort.
Perhaps OSI could serve as a central source of all the policies
that such communities need to consider, not just software licenses.
Best wishes,
Alison
--
Alison Chaiken
(650) 279-5600 (cell) {she-devel.com,
exerciseforthereader.org}
Your body is governed by ancillary concerns like “stopping the
intolerable pain” and “not dying”. Those types of concerns have no
place in cycling.
-- Velominati, www.velominati.com/look-pro/look-pro-part-vi-move-sur-la-plaque/
10 years, 3 months
Re: [copyleft-next] LibreOffice Follow Up
by Luis R. Rodriguez
Putting the DCO / OSI talk onto copyleft-next public lists as that is
where we should be talking about DCO evolution. Getting the DCO
formalized through the OSI might be appealing to some so throwing it
out there as Alison brought this up. Not sure if we need any
additional resources at this point, most of the legwork to get it as a
standalone document is thankfully already done by W. King but what we
do need though is just more visibility, and perhaps address together
with the community an FAQ. I believe its best we evolve it openly
through copyleft-next and as it stands I believe we last left with the
conclusion Fontana would be volunteered to oversee final edits.
Curious if anyone has other opinions?
Simon, what if we don't need resources other than to declare it as OSI
sane or something? Perhaps we could just start off with the existing
standalone DCO text that W. King wrote, see if Fontana can help review
when the stars align and later see if the board can bless and publish
it? If we need an FAQ I can likely hack that up together based on the
slides. If this path is desirable I guess I need to join OSI ?
Luis
On Tue, Jun 4, 2013 at 1:39 PM, Alison Chaiken <alchaiken(a)gmail.com> wrote:
> ---------- Forwarded message ----------
> From: "Simon Phipps" <simon(a)webmink.com>
> Date: Jun 4, 2013 4:31 AM
> Subject: Re: LibreOffice Follow Up
> To: "Alison Chaiken" <alchaiken(a)gmail.com>
> Cc:
>
> DCO: Best plan is to form a Member Working Group around it to make a
> proposal for adoption. We're still testing the Working Group process but it
> involves:
>
> * A group of OSI Members who
> * Write a Charter proposal for the Board stating nwhat they plan to achieve,
> starting and ending when, using what resources
> * Meet to create a deliverable for OSI that has clearly defined processes
> for implementation and maintenance (keeping in mind the Board will not
> itself maintain anything - there either has to be a member team or a
> staffing proposal)
> * Deliver to the Board for adoption
>
> Does that sound interesting? You could be a test case...
>
> S.
>
>
> On Tue, Jun 4, 2013 at 6:39 AM, Alison Chaiken <alchaiken(a)gmail.com> wrote:
>>
>> Simon, I hope that you will consider adopting the Developer Certificate of Origin as
>> an OSI-endorsed and maintained document, as there is no other more
>> logical party.
>>
>> Luis Rodriguez' slides:
>>
>> https://events.linuxfoundation.org/images/stories/slides/lfcs2013_rodrigu...
10 years, 3 months