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, 7 months
[OT] tips/tricks/best practices for non-programmers using git for plain text documents?
by Luis Villa
Apologies for the slightly OT post:
Does anyone here know of a document/documents that give non-programmers
tips/tricks/best practices on using git for plain text documents?
Obviously to some extent this is just "git for non-programmers" but I'm
guessing that there are other non-obvious best practices that
non-programmers could stand to learn, and that I'm hoping someone has
written up somewhere.
For example, since non-programmers tend to pass around entire word docs
instead of patches, they're likely to do all edits to a document and then
submit a single gigantic change, instead of breaking it up into small
functional changes (as is probably best practice). Compounding this (for
me) is that I've often found it difficult to figure out how to cleanly
break up patches into small bits in git. (I think there are some records of
this in gitorious :)
Thoughts? Suggestions?
Thanks ahead of time-
Luis
10 years, 9 months
Disclosing two bugs filed
by Stephen Michael Kellat
It is best to note that I have filed two bugs seeking support for copyleft-next in various places.
Stephen Michael Kellat
Begin forwarded message:
Date: Sun, 19 May 2013 17:52:15 -0000
From: Stephen Michael Kellat <skellat(a)fastmail.net>
To: skellat(a)fastmail.net
Subject: [Bug 1181818] [NEW] Launchpad does not support copyleft-next as a license choice for projects
Public bug reported:
For projects being hosted on Launchpad, Launchpad does not support the
selection of copyleft-next as a usable license. The license is
available via copyleft-next.org and the current version is available at
https://gitorious.org/copyleft-next/copyleft-
next/blobs/raw/master/Releases/copyleft-next-0.3.0 for review.
** Affects: launchpad
Importance: Undecided
Status: New
--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1181818
Title:
Launchpad does not support copyleft-next as a license choice for
projects
Status in Launchpad itself:
New
Bug description:
For projects being hosted on Launchpad, Launchpad does not support the
selection of copyleft-next as a usable license. The license is
available via copyleft-next.org and the current version is available
at https://gitorious.org/copyleft-next/copyleft-
next/blobs/raw/master/Releases/copyleft-next-0.3.0 for review.
To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad/+bug/1181818/+subscriptions
Begin forwarded message:
Date: Sun, 19 May 2013 17:44:40 -0000
From: Stephen Michael Kellat <skellat(a)fastmail.net>
To: skellat(a)fastmail.net
Subject: [Bug 1181811] [NEW] Packaging tool does not support copyleft-next license
Public bug reported:
Description: Ubuntu 13.04
Release: 13.04
Installed: 3.1.1-2ubuntu6
Candidate: 3.1.1-2ubuntu6
Version table:
*** 3.1.1-2ubuntu6 0
500 http://ca.archive.ubuntu.com/ubuntu/ raring/universe i386 Packages
100 /var/lib/dpkg/status
The packaging tool does not support the copyleft-next license as an
option. The latest version as of bug filing is available here:
https://gitorious.org/copyleft-next/copyleft-
next/blobs/raw/master/Releases/copyleft-next-0.3.0
Attempt to create a package. Select "Other license(s)". The wizard
does not let you specify directly the license which requires post-wizard
tampering.
** Affects: gambas
Importance: Unknown
Status: Unknown
** Affects: gambas3 (Ubuntu)
Importance: Undecided
Status: New
** Bug watch added: code.google.com/p/gambas/issues #431
http://code.google.com/p/gambas/issues/detail?id=431
** Also affects: gambas via
http://code.google.com/p/gambas/issues/detail?id=431
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1181811
Title:
Packaging tool does not support copyleft-next license
Status in Gambas:
Unknown
Status in “gambas3” package in Ubuntu:
New
Bug description:
Description: Ubuntu 13.04
Release: 13.04
Installed: 3.1.1-2ubuntu6
Candidate: 3.1.1-2ubuntu6
Version table:
*** 3.1.1-2ubuntu6 0
500 http://ca.archive.ubuntu.com/ubuntu/ raring/universe i386 Packages
100 /var/lib/dpkg/status
The packaging tool does not support the copyleft-next license as an
option. The latest version as of bug filing is available here:
https://gitorious.org/copyleft-next/copyleft-
next/blobs/raw/master/Releases/copyleft-next-0.3.0
Attempt to create a package. Select "Other license(s)". The wizard
does not let you specify directly the license which requires post-
wizard tampering.
To manage notifications about this bug go to:
https://bugs.launchpad.net/gambas/+bug/1181811/+subscriptions
10 years, 10 months
Developer Certificate of Origin - Signed-off-by standalone project followup
by Luis R. Rodriguez
At the 2013 San Francisco Linux Collaboration talk I gave a talk [0]
as a followup on the discussions I initiated a while ago on lkml [1]
on the possibility of taking the Linux kernel's Developer Certificate
of Origin and streamlining it by making it a stand alone project for
other projects to benefit from it. This is a follow up to that talk.
W. Trevor King did some handy work by doing taking the Linux kernel's
DCO and making it a standalone project on github [2] and keeping its
history already. He's also made it project agnostic. To make a
standalone DCO project agnostic and useful for any type of project it
would help if any licensed project could use it. One question that we
had over this idea was whether or not the DCO is licensed under the
GPLv2 or not. Its arguable whether or not its copyrightable, perhaps
not but just the idea of contributions to it might make it so.
Although we could try to get a Creative Commons licensed DCO (and at
least for the standard body text, not the rest of SubmittingPatches
I'll go poke) King has made it possible for any licensed project to
use the DCO standalone project by making a Creative Commons licensed
file that simply refers to the public URL of the project.
As per discussions at LF collab it was acknowledged that the DCO could
indeed be a benefit to other projects but we'd need to ensure that the
body of the text is maintained as a very conservative document. I also
wanted to address volunteering a real life attorney to help with
reviews / maintenance so I volunteered Richard Fontana given Richard's
public work on copyleft-next and the copyleft-next mailing list
availability and his public work as an attorney for the community
there [3]. Richard seems to have accepted.
What's next? Please join the copyleft-next mailing list if you are
interested in evolving the DCO and helping with streamlining this
effort.
[0] https://docs.google.com/presentation/d/1J4VTSTuiJ88xcvOrYg7HRvwUoxOW9qvnB...
[1] https://lkml.org/lkml/2012/11/20/636
[2] git://github.com/wking/signed-off-by.git
[3] http://lists.fedorahosted.org/mailman/listinfo/copyleft-next
Luis
10 years, 10 months
copyleft-next commit b2f0c69e - combining permissive license content
by Luis R. Rodriguez
I got a question regarding this commit:
commit b2f0c69e5fc1ec37cb787a9981154630b09e8e0d
Author: Richard Fontana <fontana2012(a)gmail.com>
Date: Tue Nov 20 10:52:53 2012 -0500
Clarify language of section 5 (Distributing Derived Works)
diff --git a/Drafts/copyleft-next b/Drafts/copyleft-next
index 88addc2..e10119f 100644
--- a/Drafts/copyleft-next
+++ b/Drafts/copyleft-next
@@ -90,10 +90,10 @@ THIS IS A DRAFT. DO NOT USE AS A LICENSE.
5. Distributing Derived Works.
- You may Distribute a Derived Work, provided that you license the
- entire Derived Work under this License, and include prominent
- notice of such licensing. This condition may not be avoided through
- such means as separate Distribution.
+ 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.
6. Direct Licensing.
Today's v0.3.0 added the GPL option too, so today's paragraph 3 reads:
3. 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 the GPL, so that the
recipient may further Distribute the Derived Work under either this
License or the GPL.
The GPL allows for GPL-compatible work to be integrated into it. In a
larger GPL project this allows for example say a group that wants to
share code with the BSD family to license code under a permissive
GPL-compatible license, and then through usage of things like the DCO
maintain it under a permissive license. Then portions that are
copyleft could be extracted by the BSD folks and they could go live
happy in their permissive license world.
Does the above paragraph prevent this type of sharing ? If so does the
option to re-license to GPL allow for it?
Luis
10 years, 10 months
HBR cure (2013-04-17)
by Richard Fontana
This is a Harvey Birdman Rule violation cure.
On or about Wednesday, 17 April 2013, in San Francisco, in the late
afternoon, I had a short conversation with Mike Linksvayer concerning
copyleft-next that I believe triggered HBR.
As I recall: Mike asked me if I was still planning on drafting an
Affero-ish variant of copyleft-next. I said I was, and that I had
recently wondered whether my previous assumption (start with a
non-Affero copyleft-next and work on the Affero variant afterwards)
may have had things backwards.
The substantive obstacle I have been facing with copyleft-next (as I
think I explained on this list a couple of weeks ago) relates to the
'rule vs. standard' dichotomy; I believe a simpler alternative to the
GPL ought to (ideally) require greater ease of application and
interpretation. I do not know how to achieve this, and perhaps it is
not achievable. That is to say, the best we can hope for wrt making
copyleft-next "easier" (beyond the kind of structural and textual
clarity and simplicity already present in existing versions) is to
improve in small ways on some of the basic definitions in
copyleft-next and rely on the development of useful authoritative
interpretation. However, I'm still not ready to concede that.
Anyway, as I recall, I said to Mike that perhaps drafting an
Affero-ish variant of copyleft-next might produce insights into how to
draft what I've previously been thinking of as the vanilla version. I
have also previously and separately wondered whether an Affero-ish
copyleft-next ought to be MPL-like in its approach to the copyleft
boundary issue. This is all related to suggestions, made at times by
Michael Meeks and by Bradley Kuhn, that a "Lesser AGPL" may be useful.
- RF
10 years, 10 months