10:39 a.m.
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:54 a.m.
Le mardi 21 mai 2013 à 11:39 -0400, Theodore Ts'o a écrit :
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)
IMHO, copyleft-next should be forward-compatible, not only with GPLv2
and GPLv3, but also LGPL and perhaps MPL.
This implies to have a "weak" copyleft model, and I think that's the way
to go, as noted in the previous discussion, given the increasing
importance of libraries and dynamic languages in free software
ecosystems.
Regards
Antoine.
1:04 p.m.
On Tue, May 21, 2013 at 05:54:44PM +0200, Antoine Pitrou wrote:
IMHO, copyleft-next should be forward-compatible, not only with GPLv2
and GPLv3, but also LGPL and perhaps MPL.
Is copyleft-next forward compatible at this point? I didn't think it
was at the moment, but it's been a while since I've done a close look
at the terms, and of course, I'm not a lawyer. :-) At the very least
I'd be surprised if copyleft-next was forward compatible with LGPL at
the moment.
If it's not, how far away are we from it being forward compatible, and
what would the tradeoffs be?
- Ted
1:18 p.m.
On 21/05/13 19:04, Theodore Ts'o wrote:
On Tue, May 21, 2013 at 05:54:44PM +0200, Antoine Pitrou wrote:
>
> IMHO, copyleft-next should be forward-compatible, not only with GPLv2
> and GPLv3, but also LGPL and perhaps MPL.
Is copyleft-next forward compatible at this point? I didn't think it
was at the moment, but it's been a while since I've done a close look
at the terms, and of course, I'm not a lawyer. :-) At the very least
I'd be surprised if copyleft-next was forward compatible with LGPL at
the moment.
If it's not, how far away are we from it being forward compatible, and
what would the tradeoffs be?
Which direction is "forward compatible"?
My understanding was that one of copyleft-next's founding principles was
that it was a GPL-style strong copyleft. (Am I right in that
understanding?) Allowing relicensing of c-n code under LGPL or MPL would
rather scupper that.
Gerv
1:23 p.m.
Le mardi 21 mai 2013 à 19:18 +0100, Gervase Markham a écrit :
On 21/05/13 19:04, Theodore Ts'o wrote:
> On Tue, May 21, 2013 at 05:54:44PM +0200, Antoine Pitrou wrote:
>>
>> IMHO, copyleft-next should be forward-compatible, not only with GPLv2
>> and GPLv3, but also LGPL and perhaps MPL.
>
> Is copyleft-next forward compatible at this point? I didn't think it
> was at the moment, but it's been a while since I've done a close look
> at the terms, and of course, I'm not a lawyer. :-) At the very least
> I'd be surprised if copyleft-next was forward compatible with LGPL at
> the moment.
>
> If it's not, how far away are we from it being forward compatible, and
> what would the tradeoffs be?
Which direction is "forward compatible"?
For me, it is from copylext-next to GPL and friends.
It would certainly be great to get the FSF to grant compatibility in the
other direction, but that sounds like a rather uncertain possibility.
My understanding was that one of copyleft-next's founding
principles was
that it was a GPL-style strong copyleft. (Am I right in that
understanding?) Allowing relicensing of c-n code under LGPL or MPL would
rather scupper that.
It would be nice to get a clarification on that.
Regards
Antoine.
1:49 p.m.
On Tue, May 21, 2013 at 07:18:16PM +0100, Gervase Markham wrote:
Which direction is "forward compatible"?
My understanding was that one of copyleft-next's founding principles was
that it was a GPL-style strong copyleft. (Am I right in that
understanding?) Allowing relicensing of c-n code under LGPL or MPL would
rather scupper that.
If you want to allow the relicensing of copyleft-next code to GPLv2 or
GPLv3, it needs to be more permissive than either one. This is what
allows BSD code to be relicensed under GPLv2/v3. If it is stronger
than GPLv2 or GPLv3, in that it has more restrictions than GPLv2 or v3
(for example, such as adding the Affero restriction) then that code
can be relicensed to either GPLv2 or GPLv3.
One of the other problems that has been noted before is that "weaker"
and "stronger" assumes that the copyright licenses can be strictly
ordered, and GPLv2-only and GPLv3-only are the perfect
counter-example. Code licensed under a GPLv2-only license (such as
the Linux Kernel) can not be suared with code licensed under a
GPLv3-only license (such as Samba). Code sharing doesn't work in
*either* direction.
- Ted
12:49 a.m.
On Tue, May 21, 2013 at 07:18:16PM +0100, Gervase Markham wrote:
My understanding was that one of copyleft-next's founding
principles was
that it was a GPL-style strong copyleft. (Am I right in that
understanding?)
Yes, but (in my own mind) what that means has recently been
changing, or weakening if you will.
copyleft-next is partly motivated by a desire to reduce complexity
associated with the GPL. It is also motivated by a desire to create a
new GPL-ish strong copyleft license. What I'm now starting to think is
that that problem of complexity may be inherent to how strong copyleft
is conceived by those who have tried to express what it means.
That is, there is no way to have a strong copyleft license without
either (a) incorporating existing strong copyleft lore about the GPL
which carries with it the complexity problem -- no matter how much
simpler the license is in language or structure -- or (b) ending up
with something which those who are most authoritative in saying what
'strong copyleft' means would not classify as a strong copyleft
license.
This kind of implies a repeat of history (of early non-GPL 'open
source' copyleft licenses), which is quite bothersome.
I don't think copyleft-next should be *forward* compatible with MPL,
however. That would clearly be admitting total defeat. :)
3:34 a.m.
On 22/05/13 06:49, Richard Fontana wrote:
Yes, but (in my own mind) what that means has recently been
changing, or weakening if you will.
Courage, brother! ;-)
copyleft-next is partly motivated by a desire to reduce complexity
associated with the GPL. It is also motivated by a desire to create a
new GPL-ish strong copyleft license. What I'm now starting to think is
that that problem of complexity may be inherent to how strong copyleft
is conceived by those who have tried to express what it means.
Where is the nexus of that complexity? Is it in the boundary definition
of what is covered and what is not? Or elsewhere?
I don't think copyleft-next should be *forward* compatible with
MPL,
however. That would clearly be admitting total defeat. :)
Well, indeed :-)
Gerv
12:17 a.m.
On Tue, May 21, 2013 at 02:04:14PM -0400, Theodore Ts'o wrote:
On Tue, May 21, 2013 at 05:54:44PM +0200, Antoine Pitrou wrote:
>
> IMHO, copyleft-next should be forward-compatible, not only with GPLv2
> and GPLv3, but also LGPL and perhaps MPL.
Is copyleft-next forward compatible at this point? I didn't think it
was at the moment, but it's been a while since I've done a close look
at the terms, and of course, I'm not a lawyer. :-) At the very least
I'd be surprised if copyleft-next was forward compatible with LGPL at
the moment.
If it's not, how far away are we from it being forward compatible, and
what would the tradeoffs be?
As of 0.3.0 it is (ignoring the situations Gerv was talking about)
forward-compatible with any version of the GPL (or the GNU AGPL).
It is not intended to be forward compatible with LGPL, but it is
arguably laterally compatible with LGPL, depending on how you
interpret LGPL. It is also in a sense compatible with LGPL to the
extent that LGPL is forward compatible with GPL (i.e. at the very
least copyleft-next and LGPL can be forward compatible together).
- RF
12:05 a.m.
On Tue, May 21, 2013 at 05:54:44PM +0200, Antoine Pitrou wrote:
IMHO, copyleft-next should be forward-compatible, not only with
GPLv2
and GPLv3, but also LGPL and perhaps MPL.
Originally I dismissed the idea of forward compatibility with LGPL
(though I naturally thought about it) because of the assumption that
copyleft-next would be a strong copyleft license in some very GPL-like
sense, plus (maybe this was more important) LGPL is itself
forward-compatible with GPL.
This implies to have a "weak" copyleft model, and I think
that's the way
to go, as noted in the previous discussion, given the increasing
importance of libraries and dynamic languages in free software
ecosystems.
It is clear that without intending this to have happened,
copyleft-next is showing signs of evolving into something 'weaker'
than I had originally conceived. This is somewhat disturbing (not in a
bad way necessarily) for various reasons. For one, I believe I
originally assumed that weak copyleft was actually the dead
category. For another, I thought Mozilla did a decent job with MPL
2.0. :)
As for forward compatibility with LGPL, though... this is easy to fix
but I am not sure it is really necessary. It is possible to interpret
LGPL as what I've now inaccurately described as inbound-compatible --
that is it is arguably compatible in the same sense that EPL is
arguably compatible. That may rest on a 'weak' interpretation of
LGPL. And as a policy matter it doesn't seem as compelling -- I take
your point about libraries and dynamic languages, indeed this has been
influencing a lot of my recent thinking, but LGPL is presumably
declining in use in that sphere.
- RF
11:07 a.m.
On 2013-05-21 23:39, Theodore Ts'o wrote:
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)
This analysis is where copyleft-next shines, IMHO. Explicit upward
compatibility with the GPLs and other licenses plus the permissive-next
mechanism are what will make copyleft-next not split the copyleft
community, but rather save it from becoming irrelevant.
--
/c
12:26 p.m.
On Tue, May 21, 2013 at 8:39 AM, Theodore Ts'o <tytso(a)mit.edu> wrote:
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)
I couldn't agree anymore. The digital revolution and changes in the
market pushed the FSF to come up with a license that although it does
protect freedoms it left behind evolving older copyleft with the
assumption of wider adoption on the new copyleft. So while I do
understand the ideas of evolving copyleft to a point perhaps we've
never been at I think it is important to not evolve it too fast, or if
we do at least allow for advancing the older licenses. So for example
as with Linux with stable releases in which we have on linux-stable:
* linux-3.8.y
* linux-3.9.y
* linux-3.10.y
And then we have Linus chugging along forward on mainline I think it
would be good to split the *new* attributes that copyleft-next
introduces and treat them as branches:
* copyleft-0.1.y
* copyleft-0.2.y
* copyleft-0.3.y
Using the GPL and AGPL as a references, if we could go back in time, I
feel there was a gap between GPLv2 and GPLv3, in terms of attributes
and implications, not only compatibility. This also applies to the
stark differences between GPL and AGPL evolution so in theory I'd see
room for:
* GPL-2.y
* GPL-3.y
* AGPL-2.y
* AGPL-3.y
And in between GPL-2.y and GPL-3.y I see a huge change, and in between
GPL and AGPL I also see a huge change. The evolutions between them and
the changes within should be considered gradually. We are at a point
today where for example the economics simply don't even exist to
enable AGPL to fruition in the market due to the lack of an
appreciation for such licenses. This is why I'm concerned with the
rapid evolution and expectations of embracing advances in copyleft.
Luis
1:45 p.m.
On Tue, May 21, 2013 at 10:26:37AM -0700, Luis R. Rodriguez wrote:
So while I do
understand the ideas of evolving copyleft to a point perhaps we've
never been at I think it is important to not evolve it too fast, or if
we do at least allow for advancing the older licenses. So for example
as with Linux with stable releases in which we have on linux-stable:
* linux-3.8.y
* linux-3.9.y
* linux-3.10.y
I'm not sure how this model can be carried forward to licenses, since
there are plenty of projects (not to mention core code in the Linux
kernel) which is two decades old at this point.
With the Linux kernel, after 5-10 years, we can be pretty certain that
older kernels simply won't boot on modern hardware, and the old
hardware has probably been decomissioned already. But that's not true
with specific lines of code. So even if we were to migrate forward as
you propose:
* copyleft-0.1.y
* copyleft-0.2.y
* copyleft-0.3.y
The cycle time is probably not going to be measured in months, as it
is in with software releases, but more like decades. Put another
away, eventually at some point the Linux Kernel will be replaced
whole-sale by some new OS --- I will be (pleasantly) surprised if we
are still using Linux 50 years from now --- but so maybe then, if we
assume that whatever new OS comes around doesn't use a single line of
code from Linux or any other GPLv2 project, maybe we could forsee some
point, half a century from now or later, when GPLv2-only code finally
"dies".
Also, with linux 3.8.y, 3.9.y, 3.10.y, etc., it's possible to forward
port and backwards port patches between the various different kernel
versions. One of the problems with assuming different license
versions is that you may only be able to port code in one direction,
or in the case of GPLv2-only and GPLv3-only code, the code can't be
ported in either direction.
And in between GPL-2.y and GPL-3.y I see a huge change, and in
between
GPL and AGPL I also see a huge change. The evolutions between them and
the changes within should be considered gradually. We are at a point
today where for example the economics simply don't even exist to
enable AGPL to fruition in the market due to the lack of an
appreciation for such licenses. This is why I'm concerned with the
rapid evolution and expectations of embracing advances in copyleft.
It's not obvious to me what the business model would be that would
allow startups or companies to use the AGPL without negatively
impacting their businesses (to be at least neutral, let alone actually
being a net positive for them). Regardless, the big problem is how do
we square the desire for code sharing between projects with the desire
for "rapid evolution" of licenses.
- Ted
2:15 p.m.
On Tue, May 21, 2013 at 11:45 AM, Theodore Ts'o <tytso(a)mit.edu> wrote:
On Tue, May 21, 2013 at 10:26:37AM -0700, Luis R. Rodriguez wrote:
> So while I do
> understand the ideas of evolving copyleft to a point perhaps we've
> never been at I think it is important to not evolve it too fast, or if
> we do at least allow for advancing the older licenses. So for example
> as with Linux with stable releases in which we have on linux-stable:
>
> * linux-3.8.y
> * linux-3.9.y
> * linux-3.10.y
I'm not sure how this model can be carried forward to licenses, since
there are plenty of projects (not to mention core code in the Linux
kernel) which is two decades old at this point.
With the Linux kernel, after 5-10 years, we can be pretty certain that
older kernels simply won't boot on modern hardware, and the old
hardware has probably been decomissioned already. But that's not true
with specific lines of code. So even if we were to migrate forward as
you propose:
> * copyleft-0.1.y
> * copyleft-0.2.y
> * copyleft-0.3.y
The cycle time is probably not going to be measured in months, as it
is in with software releases, but more like decades.
Agreed.
Put another
away, eventually at some point the Linux Kernel will be replaced
whole-sale by some new OS --- I will be (pleasantly) surprised if we
are still using Linux 50 years from now --- but so maybe then, if we
assume that whatever new OS comes around doesn't use a single line of
code from Linux or any other GPLv2 project, maybe we could forsee some
point, half a century from now or later, when GPLv2-only code finally
"dies".
Sure. I suppose I should clarify a bit more what I meant by using
inspiration of using the linux-stable branches. While software evolves
and embraces new evolved copyleft the market has not yet evolved as
fast to enable such to thrive software to thrive in the marketplace,
as such the marketplace still needs silly random fixes to what we deem
today a bit antiquated copyleft. So I welcome copyleft evolution but
am postulate and wonder if we could benefit from some real fixes to
copyleft backported to older copyleft -- that is changes that help
provide clarity / language but that do not bring new freedom
attributes to older copyleft.
Also, with linux 3.8.y, 3.9.y, 3.10.y, etc., it's possible to
forward
port and backwards port patches between the various different kernel
versions. One of the problems with assuming different license
versions is that you may only be able to port code in one direction,
or in the case of GPLv2-only and GPLv3-only code, the code can't be
ported in either direction.
Agreed.
> And in between GPL-2.y and GPL-3.y I see a huge change, and in
between
> GPL and AGPL I also see a huge change. The evolutions between them and
> the changes within should be considered gradually. We are at a point
> today where for example the economics simply don't even exist to
> enable AGPL to fruition in the market due to the lack of an
> appreciation for such licenses. This is why I'm concerned with the
> rapid evolution and expectations of embracing advances in copyleft.
It's not obvious to me what the business model would be that would
allow startups or companies to use the AGPL without negatively
impacting their businesses (to be at least neutral, let alone actually
being a net positive for them). Regardless, the big problem is how do
we square the desire for code sharing between projects with the desire
for "rapid evolution" of licenses.
This requires a bit of a write up which I am working on.
Luis
4:11 p.m.
On Tue, May 21, 2013 at 12:15 PM, Luis R. Rodriguez
<mcgrof(a)do-not-panic.com> wrote:
> It's not obvious to me what the business model would be that
would
> allow startups or companies to use the AGPL without negatively
> impacting their businesses (to be at least neutral, let alone actually
> being a net positive for them). Regardless, the big problem is how do
> we square the desire for code sharing between projects with the desire
> for "rapid evolution" of licenses.
This requires a bit of a write up which I am working on.
Finally I write about it:
http://www.do-not-panic.com/2013/08/evolving-capitalism-with-ethical.html
Luis
11:45 p.m.
On Tue, May 21, 2013 at 11:39:31AM -0400, Theodore Ts'o wrote:
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)
So is the concern is about future versions of copyleft-next and the
default 'or later' approach (in existing versions of copyleft-next)? I
have an idea of how to solve that but I have to think about it some
more to make sure it makes sense.
Rob is probably right that 'seems to prevent code reuse' is *one*
reason for the (putative) decline of copyleft, but I think he may be
taking it too far.
[quote from Rob Landley:]
> 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.
Wait, I think he's unfairly lumping copyleft-next in with other things
(maybe some of the discussions around CC 4.0?). :)
> In the absence of a universal receiver, most developers have
> switched to universal donor licenses: MIT/BSD or even public domain.
[...]
> 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 don't buy this really, if he's suggesting that there's a tendency to
use universal donor licenses because of the absence of a universal
receiver. I will note that by 2009 it was clear to me that (at least
in the mainstream Linux world I was dealing with a lot) "GPLv2 or
later" was being consciously chosen -- or maintained instead of
Samba-style relicensing -- over GPLv3, by copyleft-ecosystem projects,
because developers seemed to see "GPLv2 or later" as a
most-of-the-time universal receiver. This is undoubtedly one of the
reasons why adoption of GPLv3 specifically was more limited than some
thought it might have been. But I don't think it explains why, say, so
many GitHub projects use the MIT license or the like.
When Rob says RMS 'screwed up' ... well, the FSF *could* have
developed mechanisms in GPLv3 to address this matter of real/perceived
conflict between GPLv2 and GPLv3 (or LGPLv3, where the issue attracted
the most attention when the licenses were being drafted), but chose
not to. However I think he (Rob) has an exaggerated view of the
problem, even though I've dealt with such matters from time to time --
maybe a few times over 5 or so years.
> Expecting GPLv2 to be replaced by GPLv3 is just delusional.
Nearly 6 years from the release of GPLv3, *this* is clearly correct,
barring some sort of bizarre future nostalgia movement that for some
reason favors GPLv3 but not GPLv2. That is about as likely as a
revival of advertising clauses. :)
- RF
3908
days inactive
3994
days old
copyleft-next@lists.fedorahosted.org
15 comments
6 participants
participants (6)
-
Antoine Pitrou -
Claes Wallin (韋嘉誠) -
Gervase Markham -
Luis R. Rodriguez -
Richard Fontana -
Theodore Ts'o