On 08/03/2012 09:09 AM, Bradley M. Kuhn wrote:
Richard Fontana wrote at 00:44 (EDT) yesterday:
> Thus, copyleft-next has no anti-Tivoization provisions
While I disagree with the term "anti-Tiviozation" (I use the term
"anti-lock-down"),
I've generally done so too, having picked up the habit from Eben, and
probably for similar reasons, but earlier in this list's existence Ted
Ts'o said:
I know [anti-Tivoization] is not a politically correct way of
referring to these clauses. It's the one that most people
understand, and I haven't seen a good replacement yet.[1]
I've decided I agree with that.
I nevertheless think this is a terrible mistake.
This change is effectively abandoning the idea that copyleft should
defend users' freedoms to install modified versions.
No. It's abandoning (subject to compelling arguments to the contrary)
the idea that *this* copyleft license should have the anti-Tivoization
provisions of GPLv3 section 6 in it.
We've entered an era where lock-down is common. Android device
users
must check lists to verify they can install a modified firmware: some
allow it, some don't, because the Apache License doesn't defend their
freedom to install modified versions, and GPLv2 on Linux has been
(perhaps incorrectly) read to not defend it (although prominent members
of the Linux community such as Alan Cox strongly disagree). Indeed, if
Alan is right, you're making copyleft-next even weaker than defending
this essential right of users than GPLv2 does.
How so? copyleft-next has the same provision as GPLv2: you may not
impose further restrictions. Alan Cox isn't coming up with some theory
out of thin air: he believes, as I understand it, that the
no-further-restrictions clause implies anti-Tivoization.
You can argue if you want that in this respect I am making
copyleft-next as "weak" as GPLv2, but it is certainly not *weaker*. So
if you condemn copyleft-next for this change, you must also condemn
GPLv2 for consistency.
> Yet, with respect to GPLv3, it has been my own intuition that
few
> projects consciously choosing that license do so because of the
> anti-Tivoization provisions.
You say you have this intuition, but you've given no evidence.
I have some insight into why GPLv3 appeals to some developers, based
on my professional work. I believe where such appeal is most carefully
thought out, it has to do with some sense that GPLv3 offers more
"patent protection" than GPLv2 (or most, and perhaps all, other FLOSS
licenses). I have not met one person in the past 5 years not closely
affiliated with the FSF who argues that the anti-Tivoization
provisions are a major feature giving GPLv3 an advantage over GPLv2.
I don't know how to provide evidence of this, though.
Generally, this decision is a disaster for copyleft if copyleft-next
is ever adopted.
No it isn't. The anti-Tivoization provisions have been effectively a
no-op, so far as I've been aware. Thus their preservation adds
unnecessary complexity to the license.
> I do not have the sense that the inclusion of these provisions
in
> GPLv3 has had the effect of increasing users' freedom to modify
> software in consumer devices they own.
Lock-down is now common, and is accomplished in four ways: (a) the
reading of GPLv2 to say that it doesn't defend users' freedoms to
install modified versions if cryptography is used for lock-down,
What, incidentally, have you been doing to encourage an alternative
reading? You are one of the most influential people in the world on
what GPLv2 means.
(b)
blatant GPLv2 violations, ignoring the requirement to include "scripts
to control compilation and installation of the executable", and (c)
avoiding copyleft software altogether, (d) a concerted campaign to
change industry practices to make lock-down mandatory on ARM, and very
difficult to avoid on x86.
In this climate, it's clearer than ever that all copyleft should cover
this issue.
This does not seem to me to be the prevailing viewpoint in the
GPL-using community.
Consider this: would you make an argument that because many
companies contribute to Apache-licensed software that the need for the
"share and share alike" clause of copyleft should be abandoned?
No. Clearly there are people who take that view, including some who
were formerly more supportive of the GPL, but that's not my view.
The
situation is at least analogous here, but is in fact, much worse,
because *most* electronic devices today are locked down and the number
grows every year.
What has GPLv3 *done* about this? Indulge me in the fantasy that
copyleft-next actually gets used by a fair number of developers some
day. I want copyleft-next to be simple and elegant and understandable
(to the extent possible). Therefore I'm discinclined to put in
detailed provisions that are never going to have any practical
application.
The "share-alike" aspect of the GPL has real effect in the world,
despite the existence of noncompliance.
If I start to see GPLv3 having some real-world effect on the lockdown
issue, maybe I'll change my mind.
> Part of what influences me is the availability of outbound
(A)GPLv3
> compatibility.
I think I can get away with saying this to Fontana because he's my
friend: IMO, your thinking on this is wrong-headed. Copyleft-next, if
it matters, should be the right type of copyleft for the next
generation. The next generation is all about installing modified
versions of software on electronic gadgets.
Where is all the GPLv3 software on these gadgets?
> those who care strongly about these provisions will be able to
> incorporate copyleft-next code in GPLv3-licensed works.
I'm sorry to hear that you believe so few people care about the right to
install modified versions. Even in the Linux community, there is huge
disagreement on this issue (Ted on one side, Alan on the other).
That assertion is best addressed to, and by, the Linux kernel
developer community.
I'm aghast that you now argue this is akin to the contractors
thing!
It's obviously of categorically different significance. The similarity
lies in the "no one should get too upset by this" factor: if you care
so much about the contractor provision, use A/L/GPLv3 or use take
copyleft-next code and "relicense" it under A/GPLv3. (BTW I sense that
some have taken the contractor provision to have some sort of
retroactive interpretive effect on GPLv2.) That assumes that the
outbound compatibility provision stays in (and the more I use such
reasoning the harder it will be for me to contemplate deletion of that
policy).
Would you have preferred the OpenWRT and SamyGo communities to just
"not
exist"? Without requirements to ensure installation of modified
versions, they wouldn't.
I don't understand what you're saying here. The license that allowed
those communities to flourish was not GPLv3; it was GPLv2, which has
no (explicit) anti-Tivoization provisions. Are you now agreeing with
Alan Cox (if I am representing his view correctly) that GPLv2 has an
implied anti-Tivoization requirement?
- Richard
[1]
https://lists.fedorahosted.org/pipermail/copyleft-next/2012-July/000005.html