Here's an update of what's been going on with the copyleft-next draft.
Deletion of dl-supp ===================
The biggest change of the past week was my deletion of "dl-supp". In an earlier commit, I moved the "anti-Tivoization" provisions derived from the second part of GPLv3 section 6 into a supplementary document which an initial licensor could place on a new program. I now see no point in even having it as a supplement.
Thus, copyleft-next has no anti-Tivoization provisions, and so the patch originally proposed by mcgrof (see https://lkml.org/lkml/2012/7/12/401 ) has now effectively been applied.
A lot of careful thought and discussion went into the corresponding provisions of GPLv3. They represent the result of a difficult compromise, and are motivated by policy goals for which I have deep personal sympathy. I contend that they are among the best-drafted parts of that license. The policy concern about locked-down consumer devices with effectively nonmodifiable GPL-licensed software has become more relevant in the years since those provisions were drafted.
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. 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. To the contrary, it appears if anything to have motivated risk-averse companies to avoid use of GPLv3-licensed software. That is not dispositive but it is relevant. (There may be evidence to the contrary that I am unaware of.)
I'm open to being convinced that this deletion should be reverted, but if no one successfully convinces me, it is likely to stay deleted.
Part of what influences me is the availability of outbound (A)GPLv3 compatibility. As with the more obscure 'contractor' provision of GPLv3 section 2, those who care strongly about these provisions will be able to incorporate copyleft-next code in GPLv3-licensed works.
Deletion of first part of anti-anti-circumvention provision ===========================================================
While I currently continue to feel it is worthwhile for copyleft-next to explicitly address anti-circumvention law, I no longer consider the first paragraph of what was GPLv3 section 3 to be desirable.
The basic idea here was the hope that courts would be influenced by a general declaration by the licensor that covered works are, in some sense fundamental to the license, not 'effective technological protection measures'. There is no known history of use of this provision by those defending against invocation of anti-circumvention law.
This strikes me as being an inherently weak provision, but, the less weak one assumes it is, the more problematic it becomes from a free software perspective, since it approaches something like a field of use restriction. That certainly is not what the FSF intended, but that lack of intent does not make the discomfort go away.
The reason for effectively two (or three, depending on how you look at it) anti-anti-circumvention provisions had to do with concerns about differences between US and EU approaches to anti-circumvention law. I consider it better to come up with one provision suitable for major jurisdictions in which the license is likely to be granted. A modification of the second part of what was GPLv3 section 3 is a better basis for such a provision.
Further changes to termination ==============================
In response to discussion on the mailing list, I have changed the EPL-inspired "reasonable time period" cure to a 30-day cure.
I have also eliminated the relatively complex "automatic termination -> provisional automatic reinstatement -> permanent automatic reinstatement' feature which was originally added to GPLv3 section 8 in the final draft. I have explained this in a posting to this list made earlier today.
Deletion of liberty-or-death example ====================================
This is a noteworthy change. If people think that we need the example given in GPLv3 section 12, let me know.
- Richard
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 nevertheless think this is a terrible mistake. This change is effectively abandoning the idea that copyleft should defend users' freedoms to install modified versions.
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.
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. This is akin to George W. Bush saying that he made key policy decisions based on "his gut". Intuition is useful to generate serendipity, but making a policy decision based on empty intuition is a disaster. Generally, this decision is a disaster for copyleft if copyleft-next is ever adopted.
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, (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. 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? 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.
I'm open to being convinced that this deletion should be reverted, but if no one successfully convinces me, it is likely to stay deleted.
I've proposed this merge request below to put it in a *stronger* version of the GPLv3 anti-lock-down provision that I drafted last night. I propose a stricter one because (a) GPLv3's version was probably a compromise that wasn't worth making, because the people who insisted on the compromise avoid GPLv3'd software anyway, and (b) I think copyleft-next should start from something extremely strong on this issue and decide to compromise, rather than compromise away users' rights to install modified versions from the start.
Indeed, I'm not going to issue an ultimatum like Fontana's above (i.e., "you must convince me otherwise that the provision shouldn't be so strong"). What I'm saying is we should *start* with the strictest possible anti-lock-down provision for copyleft-next, *then* see if there is sufficient consensus under the rule formerly know as the Harvey Birdman Rule to see if that clause should be watered down.
IMO, anything that is called copyleft in the modern climate of lock-down must defend users' freedom to install modified versions of software.
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.
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). I'm aghast that you now argue this is akin to the contractors thing!
Would you have preferred the OpenWRT and SamyGo communities to just "not exist"? Without requirements to ensure installation of modified versions, they wouldn't.
Anyway, the merge request is: https://gitorious.org/copyleft-next/copyleft-next/merge_requests/10
Patch from that merge request is also attached.
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
Richard Fontana wrote at 12:50 (EDT) on Friday:
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.
You should definitely talk to some users of electronic devices who are trying to modify the software for them.
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.
I've been diposed about this matter in a court case [0]. What I said on the record is that we are "stuck with an interpretation that GPLv2 doesn't cover crypto-lock-down" in large part because of public statements about GPLv2 that Eben Moglen made as FSF's attorney. I disagree with those statements, but what can I do? I wasn't on FSF's Board nor an FSF employee when Eben made those statements. I think it's a horrible outcome, because I agree with Alan Cox, but I'm one voice facing estoppel that FSF's law firm generated for it. I've given up tilting at that particular windmill: even though I think Alan is right, estoppel has been generated and we're stuck with it.
*However*, note that's narrowed to *crypto* lock-down. I do think any other means of lock-down relate to GPLv2's "scripts to control compilation and installation of the executable" -- distributor of binary works have to give instructions to install. Eben never commented on this on behalf of FSF to my knowledge, so I believe that GPLv2 as is stands requires disclosure of all installation information up to but not including crypto keys.
This is precisely why all future copylefts MUST have explicit clause defending on this issue of cypto-lock-down, due the estoppel generated against GPLv2 by public statements by otherwise knowledgeable folks saying that GPLv2 allows crypto-lock-down. To be abundantly clear what I mean: I believe GPLv3 merely *clarifies* the existing requirements with GPLv2 *except* for the disclosure of authorization keys, which I think *would* be required by GPLv2 too, but for the aformentioned estoppel.
Anyway, as for your direct question "what I'm doing on this myself", you personally know I spend 8-10 hours every week working to enforce the GPL, both GPLv2 and GPLv3 (although I just started doing GPLv3 enforcement when Samba handed their enforcement work to Conservancy a month or two ago). Thus, it'd be slightly disingenuous for anyone to suggest I'm not doing everything I possibly can on this issue. I really hope your comment wasn't intended to suggest that I wasn't so doing.
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.
I think we have no clear evidence either way. Even in the Linux project, there is disagreement, and the Linux project probably is the most opposed to anti-lockdown provisions of any project.
If I start to see GPLv3 having some real-world effect on the lockdown issue, maybe I'll change my mind.
This takes time. You've given GPLv2 a full 20 years to establish itself, and you therefore say it's a valid, useful license. But you've only given the clarified and improved terms of GPLv3 a mere 5 years, and now you're saying: "I've decided its terms don't matter and I give up on its key provisions now".
If you want to be fair, you'd stay neutral on the question for another 15 years, right? Shouldn't copyleft-next include any provision we agree is good policy?
Where is all the GPLv3 software on these gadgets?
Samba appears in some.
The similarity lies in the "no one should get too upset by this" factor:
I get upset when copyleft becomes de-facto permissive licensing, which is what lock-down yields. I know plenty of users are upset in this way.
Richard Fontana wrote at 23:49 (EDT) on Friday:
Much as I believe I said of the anti-Tivoization provisions: if we knew that these provisions were being used to discourage or render ineffective lockdown of consumer devices, the argument for deleting them might be a lot weaker.
This is argument seems akin to perfection theory of GPLv2.
You're basically saying here that copyleft-next will include no provision that hasn't been previously directly enforced on. That will limit the policy positions of copyleft-next to only that narrow work that Conservancy, FSF and Harald Welte have done. I believe great work has been done there, but we're limited by our meager resources. It's somewhat unfair for you to hang all that on us alone.
In other words, you *don't* argue that anti-lock-down provisions are immoral nor bad policy. Ted does argue that, and I respect his position on that because it's his belief and he believes that people have a moral right to lock down users from ever upgrading or improving their technology. I disagree with him, but it's a disagreement of morality.
You're arguing that certain license terms aren't "popular" or "enforced yet" as reasons to have or not have certain things in the license. What's the point of writing a copyleft license with no morality? Copyleft *is* a moral position. If you want an amoral license, why not go make DWTFYW-next instead?
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?
Those products didn't have crypto-lock down, but crypto-lock down is slowly but surely becoming more common. UEFI even requires it on ARM now.
Anyway, it sounds like you're rejecting my patch vehemently. Since copyleft-next is a dictatorship, is there any point in continuing to advocate for my patch? What would be the necessary requirements those us who oppose cryto-lock-down to get it added?
Would you at least consider my patch if I rewrite it but leave out "authorization keys" for now, while we continue this discussion? I've posted a merge request on this (see elsewhere in the thread).
In my view, that would at least make it equivalent to GPLv2's more terse version. You do want to make sure it's not a *weaker* copyleft than GPLv2, right?
[0] I'm seeking to release that deposition of mine, as I think it'd be useful, but sadly the defendant insisted on a protective order during discovery, and I need to burn some of Conservancy's outside counsel's time to figure out if it covers my deposition and what we'd need to redact if it does. Sadly, again, this is a resource-constraint problem. Most people don't realize that their local pizza parlor has more staffing that nearly any given non-profit org in the Free Software community.
On 08/05/2012 10:12 AM, Bradley M. Kuhn wrote:
Richard Fontana wrote at 12:50 (EDT) on Friday:
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.
You should definitely talk to some users of electronic devices who are trying to modify the software for them.
I know that such users exist; I'm just not aware of them being GPLv3 advocates. Maybe they are.
I've been diposed about this matter in a court case [0]. What I said on the record is that we are "stuck with an interpretation that GPLv2 doesn't cover crypto-lock-down" in large part because of public statements about GPLv2 that Eben Moglen made as FSF's attorney. I disagree with those statements, but what can I do? I wasn't on FSF's Board nor an FSF employee when Eben made those statements. I think it's a horrible outcome, because I agree with Alan Cox, but I'm one voice facing estoppel that FSF's law firm generated for it. I've given up tilting at that particular windmill: even though I think Alan is right, estoppel has been generated and we're stuck with it.
*However*, note that's narrowed to *crypto* lock-down. I do think any other means of lock-down relate to GPLv2's "scripts to control compilation and installation of the executable" -- distributor of binary works have to give instructions to install. Eben never commented on this on behalf of FSF to my knowledge, so I believe that GPLv2 as is stands requires disclosure of all installation information up to but not including crypto keys.
This is precisely why all future copylefts MUST have explicit clause defending on this issue of cypto-lock-down, due the estoppel generated against GPLv2 by public statements by otherwise knowledgeable folks saying that GPLv2 allows crypto-lock-down.
If I understand everything you're saying here correctly, you are effectively asserting that if Alan Cox sues someone for a GPLv2 violation, the defendant can successfully get the lawsuit thrown out by saying that Alan Cox is bound by statements made by an unaffiliated third party (the FSF) about its own interpretation of GPLv2? To be sure, the FSF has had great influence over community interpretation of GPLv2, and I consider this to be something that courts absolutely should take into account, but a theory that this influence can have estoppel-like effects on third parties seems a stretch to me. Interesting, though.
Anyway, as for your direct question "what I'm doing on this myself",
Well, you've already answered that in your posting, by stating your views on this issue very clearly.
If I start to see GPLv3 having some real-world effect on the lockdown issue, maybe I'll change my mind.
This takes time. You've given GPLv2 a full 20 years to establish itself, and you therefore say it's a valid, useful license.
Actually I think GPLv2 was valid and useful the moment it was released in 1991 .
But you've only given the clarified and improved terms of GPLv3 a mere 5 years, and now you're saying: "I've decided its terms don't matter and I give up on its key provisions now".
That isn't what I'm saying. It may be fair to accuse me of impatience at the 5-year mark. I certainly think the terms in GPLv3, including the terms we're talking about here, *do* matter, if only because there's quite a lot of software licensed under it. I'm not so sure these terms are "key provisions" of GPLv3, though, for reasons I've already suggested.
Shouldn't copyleft-next include any provision we agree is good policy?
Not necessarily. I don't want it to be hundreds of pages (or hundreds of thousands of words) long. It can't address every policy.
Much as I believe I said of the anti-Tivoization provisions: if we knew that these provisions were being used to discourage or render ineffective lockdown of consumer devices, the argument for deleting them might be a lot weaker.
This is argument seems akin to perfection theory of GPLv2.
You're basically saying here that copyleft-next will include no provision that hasn't been previously directly enforced on.
No, that would be an unreasonably conservative view, particularly given how little enforcement there appears to be, as you note. I'm saying rather that while there are good reasons to take these provisions out, I might be convinced otherwise if I were seeing them work effectively in the post-2007 world. Maybe some of your enforcement work will establish that.
You're arguing that certain license terms aren't "popular" or "enforced yet" as reasons to have or not have certain things in the license.
That's not quite what I'm saying, but let's say you're close enough. Space is limited, so we have to make some tradeoffs. If my perception that few people who otherwise like GPLv3 actually care about these provisions is correct (I realize you think I'm wrong), they are an obvious candidate for deletion.
You (probably) won't like this comparison, but think of GPLv2 section 8 -- legitimizing territorial restrictions. This is (in retrospect, I realize) a bad, strange and also almost entirely unused provision. The FSF rightly deleted it from GPLv3, after first asking whether anyone in the GPL-using community felt it ought to stay in. No one came forward. And one of the main arguments for deleting it was that no one used it.
What's the point of writing a copyleft license with no morality? Copyleft *is* a moral position. If you want an amoral license, why not go make DWTFYW-next instead?
That's just as much about, and not about, morality. I don't think it is correct to imply that permissive non-copyleft licenses are 'more amoral' than copyleft (and would this make weak copyleft licenses 'semi-amoral'?)
Anyway, it sounds like you're rejecting my patch vehemently.
Not vehemently. I still have an free/open mind on this entire issue. But your patch is actually asking me to not only restore the GPLv3 policy but actually to expand it further than any free software license has ever done, other than possibly drafts of GPLv3.
Since copyleft-next is a dictatorship,
You seemed to dislike my suggestion that we apply for Apache incubator which would presumably require abolition of benevolent dictatorship governance. :-)
is there any point in continuing to advocate for my patch? What would be the necessary requirements those us who oppose cryto-lock-down to get it added?
I welcome continued discussion of the policy issue.
Would you at least consider my patch if I rewrite it but leave out "authorization keys" for now, while we continue this discussion? I've posted a merge request on this (see elsewhere in the thread).
I'll take a look at it.
Most people don't realize that their local pizza parlor has more staffing that nearly any given non-profit org in the Free Software community.
Agreed. I encourage everyone in the world reading this to consider donating to the Software Freedom Conservancy and the Free Software Foundation.
- Richard
On Sun, Aug 05, 2012 at 10:12:08AM -0400, Bradley M. Kuhn wrote:
This is precisely why all future copylefts MUST have explicit clause defending on this issue of cypto-lock-down, due the estoppel generated against GPLv2 by public statements by otherwise knowledgeable folks saying that GPLv2 allows crypto-lock-down.
This is only true if you believe that someone who attempts crypto-lockdown must forced to disgorge the keys.
However, if three is language (such as you have proposed) which protects someone who tries to circumvent lockdown measures from DMCA or DMCA-like laws, that might be something that everyone can get behind.
But let's be clear --- these two issues do not have to be linked, as far as I can tell. Whether or not we should "protect" against crypto lockdown, or indeed any kind of lockdown, is a separable issue from trying to defend someone who is trying to circumvent such a lockdown...
- Ted
On 08/03/2012 09:09 AM, Bradley M. Kuhn wrote:
Anyway, the merge request is: https://gitorious.org/copyleft-next/copyleft-next/merge_requests/10
I have rejected this patch, though I've adapted some of your general modifications to the 'Corresponding Source' definition.
https://gitorious.org/copyleft-next/copyleft-next/commit/2457a57bda65bc42ae1...
- Richard
On Fri, Aug 3, 2012 at 7:15 PM, Richard Fontana fontana@sharpeleven.orgwrote:
On 08/03/2012 09:09 AM, Bradley M. Kuhn wrote:
Anyway, the merge request is: https://gitorious.org/copyleft-next/copyleft-next/merge_requests/10
I have rejected this patch, though I've adapted some of your general modifications to the 'Corresponding Source' definition.
https://gitorious.org/copyleft-next/copyleft-next/commit/2457a57bda65bc42ae1...
That should be "any scripts..." not just "scripts", no?
Also, I've never been sure what "control" means in this context. Given that "perform" is probably broad enough to completely encompass "control," and given how comprehensive the list of tasks is now (it's arguably impossible to "perform" a build without some form of control) I'd be inclined to replace "control and perform" with simply "perform," or else give a more specific definition of "control" (e.g, by reference to configuration files.)
Luis
On 08/03/2012 10:57 PM, Luis Villa wrote:
On Fri, Aug 3, 2012 at 7:15 PM, Richard Fontana <fontana@sharpeleven.org mailto:fontana@sharpeleven.org> wrote:
On 08/03/2012 09:09 AM, Bradley M. Kuhn wrote: > Anyway, the merge request is: > https://gitorious.org/copyleft-next/copyleft-next/merge_requests/10 I have rejected this patch, though I've adapted some of your general modifications to the 'Corresponding Source' definition. https://gitorious.org/copyleft-next/copyleft-next/commit/2457a57bda65bc42ae16faea50fe6a72a7ccb25f
That should be "any scripts..." not just "scripts", no?
Also, I've never been sure what "control" means in this context. Given that "perform" is probably broad enough to completely encompass "control," and given how comprehensive the list of tasks is now (it's arguably impossible to "perform" a build without some form of control) I'd be inclined to replace "control and perform" with simply "perform," or else give a more specific definition of "control" (e.g, by reference to configuration files.)
Thanks: suggestion applied but with "any" bracketed. https://gitorious.org/copyleft-next/copyleft-next/commit/df546cda853a72c71ab...
- Richard
Luis Villa wrote at 22:57 (EDT) on Friday:
That should be "any scripts..." not just "scripts", no?
What is the point of adding 'any'? Why do you advocate for it, and who do you advocate on behalf of on this point?
Richard Fontana wrote at 00:03 (EDT) on Saturday:
Thanks: suggestion applied but with "any" bracketed. https://gitorious.org/copyleft-next/copyleft-next/commit/df546cda853a72c71ab...
Why do you believe "any" is correct there?
I've proposed another patch (attached), removing the [any] and bringing in other parts of my original patch that Fontana removed. As mentioned elsewhere in the thread, I suggest that we make this just a clarification of GPLv2 (sans authorization-keys issue), and I believe we'll be well on the way to that with the attached patch, which is also in this merge request:
https://gitorious.org/copyleft-next/copyleft-next/merge_requests/14
I've never been sure what "control" means in this context. Given that "perform" is probably broad enough to completely encompass "control," and given how comprehensive the list of tasks is now (it's arguably impossible to "perform" a build without some form of control) I'd be inclined to replace "control and perform" with simply "perform," or else give a more specific definition of "control" (e.g, by reference to configuration files.)
I actually think "scripts used to control compilation and installation of the executable" is effectively the same as what I wrote in my original patch, but I've seen weasely lawyers argue otherwise to defend their GPL-violating clients, so I think we need as much text in there as possible. We should keep adding verbs until we can't think of any more. The sharks on the other side will keep coming up with new verbs to tell us they're *so* different, just to help their client get away with violating the GPL.
On 08/05/2012 10:30 AM, Bradley M. Kuhn wrote:
I've proposed another patch (attached), removing the [any] and bringing in other parts of my original patch that Fontana removed. As mentioned elsewhere in the thread, I suggest that we make this just a clarification of GPLv2 (sans authorization-keys issue), and I believe we'll be well on the way to that with the attached patch, which is also in this merge request:
https://gitorious.org/copyleft-next/copyleft-next/merge_requests/14
[Luis Villa:]
I've never been sure what "control" means in this context. Given that "perform" is probably broad enough to completely encompass "control," and given how comprehensive the list of tasks is now (it's arguably impossible to "perform" a build without some form of control) I'd be inclined to replace "control and perform" with simply "perform," or else give a more specific definition of "control" (e.g, by reference to configuration files.)
I actually think "scripts used to control compilation and installation of the executable" is effectively the same as what I wrote in my original patch, but I've seen weasely lawyers argue otherwise to defend their GPL-violating clients, so I think we need as much text in there as possible. We should keep adding verbs until we can't think of any more. The sharks on the other side will keep coming up with new verbs to tell us they're *so* different, just to help their client get away with violating the GPL.
I have accepted most of *this* patch except for Bradley's introduction of the term "know-how", which I want to do some more research on, as it is commonly used in technology license agreements (where it seems it typically is a defined term). Of course I welcome any discussion about it or the rest of this patch here
Note that I do not necessarily endorse the characterization of any persons as "weasels" or "sharks".
- Richard
Richard Fontana wrote on 6 August:
I have accepted most of *this* patch except for Bradley's introduction of the term "know-how", which I want to do some more research on, as it is commonly used in technology license agreements (where it seems it typically is a defined term).
I notice that this thread died here in August. How is your research about "know-how" going?
I see copyleft-next now says: "known to you (even if previously unrecorded)". Why is that preferable to "know-how"?
On 10/11/2012 07:19 AM, Bradley M. Kuhn wrote:
I see copyleft-next now says: "known to you (even if previously unrecorded)". Why is that preferable to "know-how"?
Well, it was a way of avoiding the issue of whether "know-how" is okay to use undefined. I think it captures what you (at least primarily) seem to have in mind when you speak of "know-how" in Corresponding Source.
- RF
Richard Fontana wrote on 2 August:
Deletion of dl-supp
..
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. 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. To the contrary, it appears if anything to have motivated risk-averse companies to avoid use of GPLv3-licensed software.
I find this argument specious and it has a "history repeating itself" quality. I can imagine a BSD developer, in the early 1990s, saying that "risk-averse companies" are "avoiding GCC" because this copyleft thing is too dangerous, and there is less freedom because some people who would use GCC if it weren't copyleft would be doing so.
I think nearly everyone agrees (except, perhaps, for the person who is most directly responsible for the error) that the communication between the GPLv3 drafting committee and the Linux developers was completely botched. I regularly deliver an apology directly from RMS to every Linux developer I meet. RMS told me explicitly: "Please tell the Linux developers I'm sorry and that my intent was to take very seriously their feedback in a friendly way and if we failed to do that, we made an error".
That error being made, we now live with the consequences. But to allow that error to propagate into a decision that no anti-lock-down provision should even be *available* to copyleft-next users is completely unreasonable in my view.
I believe we're going to continue to fight about the question of whether anti-lock-down is a primary feature of copyleft-next. However, it seems to me a needlessly contentious act to delete the *supplement*. If the supplement structure of copyleft-next exists, then the two supplements that must be officially recommended are the (a) network services clause and (b) anti-lock-down clause.
I therefore insist that the anti-lock-down supplement be reverted. Please accept this merge request: https://gitorious.org/copyleft-next/copyleft-next/merge_requests/21
On Fri, Oct 12, 2012 at 6:25 AM, Bradley M. Kuhn bkuhn@ebb.org wrote:
If the supplement structure of copyleft-next exists
Does it? There's just a document (or two, with your restoration) that claim to not be further restrictions, with no support in the license draft. Am I missing something obvious? It seems like such a structural thing being unclear is good reason to not call a draft 0.01 or whatever, if there was a point of a small-version-number-but-do-not-use-this-version otherwise.
My wild guess of what such a structure would look like:
- No further restriction section enumerates ws-supp [and dl-supp if reinstated] as acceptable restrictions. - Outbound compatibility says only AGPLv3+ [or, if only dl-supp GPLv3+]
I don't know that I'm really sold on those supplements at all; maybe people who want them should just use [A]GPLv3+. But, to illustrate my wild guess above and make a fool of myself:
https://gitorious.org/copyleft-next/copyleft-next/merge_requests/22
I'm not sure the supplements are unambiguously identified (including them in the main license as optional provisions would be most unambiguous, I guess) or if the complexity is worth it.
I hope to be wholly off base.
Mike
On 10/13/2012 03:29 AM, Mike Linksvayer wrote:
I'm not sure the supplements are unambiguously identified (including them in the main license as optional provisions would be most unambiguous, I guess) or if the complexity is worth it.
Maybe having license variants with the supplement(s) included would be better, easier to understand (this is somewhat related to the relatively recent thread started by Luis Villa on the idea of a noncopyleft version of copyleft-next).
Since neither I nor anyone else has yet devoted any real attention to the drafting of the supplement(s), it may not matter too much at this stage.
- RF
On 10/13/2012 03:29 AM, Mike Linksvayer wrote:
On Fri, Oct 12, 2012 at 6:25 AM, Bradley M. Kuhn bkuhn@ebb.org wrote:
If the supplement structure of copyleft-next exists
Does it? There's just a document (or two, with your restoration) that claim to not be further restrictions, with no support in the license draft. Am I missing something obvious? It seems like such a structural thing being unclear is good reason to not call a draft 0.01 or whatever, if there was a point of a small-version-number-but-do-not-use-this-version otherwise.
My wild guess of what such a structure would look like:
- No further restriction section enumerates ws-supp [and dl-supp if
reinstated] as acceptable restrictions.
- Outbound compatibility says only AGPLv3+ [or, if only dl-supp
GPLv3+]
Now that I've looked at your merge request, I think you may have misunderstood what I was intending. The idea was that the initial copyleft-next licensor could include the supplement, in which case it would normally govern the initial work and all downstream Derived Works. Cf. GPLv2 section 8. It's not like a GPLv3 section 7 allowed "addtional requirement".
I don't know that I'm really sold on those supplements at all; maybe people who want them should just use [A]GPLv3+. But, to illustrate my wild guess above and make a fool of myself:
https://gitorious.org/copyleft-next/copyleft-next/merge_requests/22
I'm not sure the supplements are unambiguously identified (including them in the main license as optional provisions would be most unambiguous, I guess) or if the complexity is worth it.
I hope to be wholly off base.
I'm thinking of deleting "ws-supp" (and not accepting bkuhn's merge request to restore "dl-supp"). I still very much want there to be a separate/supplementary "AGPL-ish" version of copyleft-next, but I think we need to start from scratch with the language, so there isn't much to be gained by using AGPLv3 section 13 language as a placeholder for the time being.
- RF
On Sun, Oct 14, 2012 at 6:17 PM, Richard Fontana fontana@sharpeleven.org wrote:
On 10/13/2012 03:29 AM, Mike Linksvayer wrote:
My wild guess of what such a structure would look like:
- No further restriction section enumerates ws-supp [and dl-supp if
reinstated] as acceptable restrictions.
- Outbound compatibility says only AGPLv3+ [or, if only dl-supp
GPLv3+]
Now that I've looked at your merge request, I think you may have misunderstood what I was intending. The idea was that the initial copyleft-next licensor could include the supplement, in which case it would normally govern the initial work and all downstream Derived Works. Cf. GPLv2 section 8. It's not like a GPLv3 section 7 allowed "addtional requirement".
I'm probably missing some important nuance, but I don't see a difference. Obviously any additional condition would govern downstream works. But would need to be accounted for in the license somehow (stating these supplements aren't additional restrictions and may therefore be added, or just that these supplements may be added) and would seem to necessarily impact outbound compatibility based on the nature of the supplements. I guess the nuance is that the part of the license accounting for supplements could limit application to the "original copyright holder who places the Program under this License", though that'd be a bit at dissonance with outbound [A]GPLv3+ compatibility.
I'm thinking of deleting "ws-supp" (and not accepting bkuhn's merge request to restore "dl-supp"). I still very much want there to be a separate/supplementary "AGPL-ish" version of copyleft-next, but I think we need to start from scratch with the language, so there isn't much to be gained by using AGPLv3 section 13 language as a placeholder for the time being.
and
On Sun, Oct 14, 2012 at 12:32 AM, Richard Fontana fontana@sharpeleven.org wrote:
On 10/13/2012 03:29 AM, Mike Linksvayer wrote:
I'm not sure the supplements are unambiguously identified (including them in the main license as optional provisions would be most unambiguous, I guess) or if the complexity is worth it.
Maybe having license variants with the supplement(s) included would be better, easier to understand (this is somewhat related to the relatively recent thread started by Luis Villa on the idea of a noncopyleft version of copyleft-next).
I very much agree with this, that's why I somewhat jokingly suggested "arch-copyleft-next" awhile back.
Since neither I nor anyone else has yet devoted any real attention to the drafting of the supplement(s), it may not matter too much at this stage.
I guess it matters if one considers something calling itself copyleft-next that does not incorporate all known freedom enforcement mechanisms to be an abomination. ;-)
Mike
On Fri, Oct 12, 2012 at 03:25:18PM +0200, Bradley M. Kuhn wrote:
I think nearly everyone agrees (except, perhaps, for the person who is most directly responsible for the error) that the communication between the GPLv3 drafting committee and the Linux developers was completely botched. I regularly deliver an apology directly from RMS to every Linux developer I meet. RMS told me explicitly: "Please tell the Linux developers I'm sorry and that my intent was to take very seriously their feedback in a friendly way and if we failed to do that, we made an error".
Botched how? Anti-lock-down was clearly non-negotiable, on both sides. It's a fundamental philosophical divide. Whether or not the GPLv3 drafting committee could have been more "friendly", I don't see how it could have changed the outcome.
The question is whether increasing the developer community (by inviting companies like Tivo to use and enhance, and contribute their changes back to Linux), versus how important is it that consumer electronic devices should be considered not general purpose computers but more as disposable devices where the desireability of allow users to be able to hack and replace the firmware of said devices was not so critically important a priority that it's worth it to dissuade companies like Tivo from using Linux, and have them use BSD instead.
RMS has one view on this question, and Linus Torvalds and many other Linux kernel developers, who arguably collectively hold copyright on a very large majority of the Linux kernel, have a different view.
So whether the GPLv3 drafting committee was "friendly" or not, and had told the Linux community "no" versus "hell, no", it wouldn't have made much of a difference as to the Linux community rejecting a copyright which would have caused us to turn away from our development community many companies who are comfortable with the "stone soup" model of software development (i.e., one where sharing code is more important than mandating that the code always be installable on some arbitrary consumer electronic device), but where said company which might have strong business/legal/contractual reasons why an anti-lockdown clause would be a show-stopper for them.
Regards,
- Ted
On 10/13/2012 07:48 AM, Theodore Ts'o wrote:
[...] told the Linux community "no" versus "hell, no", it wouldn't have made much of a difference as to the Linux community rejecting a copyright which would have caused us to turn away from our development community many companies who are comfortable with the "stone soup" model of software development[...]
Given that Apple's BSD based devices alone are responsible for 65% of revenue [0] representing over $100 billion in annual hardware sales [1] it seems that a significant portion of the "stone soup" developer community is already relying upon permissively licensed kernels.
And yet Linux seems to be thriving. Even if some of the currently Linux based "stone soup" developers were to depart due to an anti-lockdown provision how bad could it be for Linux? Is there any reason to believe that the party would stop?
If we take the integral under the curve over all time for Linux commits and put the Tivo (and friends) commits in to a "stone soup" category how big a percentage is that? How big a percentage is it likely to to be in the future?
Respectfully,
--Tom
[0] http://www.asymco.com/2011/01/21/65-of-apples-sales-from-ios-powered-devices... [1] http://www.tuaw.com/2012/01/25/lesser-known-facts-from-apples-earnings-state...
On Sat, Oct 13, 2012 at 10:04:04AM -0500, Tom Marble wrote:
Given that Apple's BSD based devices alone are responsible for 65% of revenue [0] representing over $100 billion in annual hardware sales [1] it seems that a significant portion of the "stone soup" developer community is already relying upon permissively licensed kernels.
There is only one developer contributing to Apple's MacOS X --- which is, of course, Apple. The economic size and success of the application development community used by iOS is not really what is at issue here.
The big question is how many kernel contributers --- especially by the ARM community, the embeddeded and handset community, etc., might have been deterred by anti-Lock-down clauses. And note that number of Android devices alone is four times the size of iOS by some estimates. Furthermore, there are some significant network effects, where some new company might decide to use Linux because of how many other companies have been using Linux, and hence the device driver support is present where it might not be with FreeBSD. (Or Hurd --- have you checked to see what the device driver support is like for Hurd? It's either very amusing or very sad, depending on your point of view....)
And yet Linux seems to be thriving.
There are may who believe it is because we are active friendly and encourage contributions by everyone, and we don't turn people away.....
If we take the integral under the curve over all time for Linux commits and put the Tivo (and friends) commits in to a "stone soup" category how big a percentage is that? How big a percentage is it likely to to be in the future?
Quite large, I suspect. Linux is used in every single Samsung and Sony TV, in many Samsung home appliances (dishwashers, washing machines, etc.), and so on. Linux is used in a *very* large number of places, and the contributions made by one of these company to support one particular hardware or wireless chipset, can help ensure the continued rich availability of device drivers in the Laptop and PC world. Contributions to improve power efficiency for handsets is helping to improve the environmental impact of cloud servers. The model right now is *working*. Why the heck should we make changes that we *know* would cause some people to move away. (Hint: there is a *reason* Android devices use their own libc, instead of using the GPL'ed glibc.....)
Best regards,
- Ted
Theodore Ts'o wrote on 13 October:
Botched how? Anti-lock-down was clearly non-negotiable, on both sides. It's a fundamental philosophical divide.
I realize the anti-lock down provision was presented by the FSF to the Linux developers as non-negotiable. However, I've since, many years later, learned that FSF leadership was never even communicated the position of the Linux developers adequately by FSF's representatives at the time. Last year, RMS specifically asked me to apologize on his behalf to every single Linux developer to tell them that he wished he'd talked with you directly about your concerns at the time, rather than going through legal counsel. I think I've so-issued that apology to you, Ted, when I saw you in person at some point, but if I didn't, I do so now. :)
Meanwhile, I don't know what would have happened if there had been real communication on this issue between FSF and the Linux Developers, rather than the blustering that occurred on that fateful conference call and other such occurrences. Perhaps we'd have still ended up at the same impasse that we reached. We can't go back in time and run the experiment again, so we'll never know.
But, I think FSF's leadership recognizes that the Linux developers weren't negotiated with as equals during GPLv3, and that they should have been. Speaking briefly as a member of FSF's Board (although I wasn't on FSF's Board at the time), I certainly think that's true and feel bad about it, and I am sorry I wasn't on the Board at the time to do something about it.
On Tue, Dec 04, 2012 at 08:38:38AM -0500, Bradley M. Kuhn wrote:
I realize the anti-lock down provision was presented by the FSF to the Linux developers as non-negotiable. However, I've since, many years later, learned that FSF leadership was never even communicated the position of the Linux developers adequately by FSF's representatives at the time. Last year, RMS specifically asked me to apologize on his behalf to every single Linux developer to tell them that he wished he'd talked with you directly about your concerns at the time, rather than going through legal counsel. I think I've so-issued that apology to you, Ted, when I saw you in person at some point, but if I didn't, I do so now. :)
I don't recall hearing this, but I certainly accept the apology --- although I'm still not clear what RMS would have concessions (if any) he would have been willing to make if (as you say) negotiations had happened "has equals".
I'll note that the typical consumer electronic device has a sales lifetime of 6-12 months, and perhaps a useful lifetime of 2-5 years. For cell phones, it's more like 2-3 years, tops. I'm pretty sure that we've had code contributed by Tivo, and certainly by other mobile handset manufacturers, that have gotten far more reuse and usefulness outside of the original reason why they were written. So if you take the long view, you can make the credible argument that there is more _Open_ _Source_ code that is made available by allowing lock-down than if you take the purely _Free_ _Software_ (by which I mean anti-lockdown uber alles) approach.
At a pretty fundamental level, that's why I'm pretty hostile to the "you must be able to install modified software" freedom as being one that should be enforced.
On the flip side, what sort of softening would you propose? Why is it OK if the ability to restrict the ability to install and run modified code is enforced via cryptographic signing, where the key is kept carefully separate from the source code needed to install the damned thing, but it's not OK if the key was careless mixed into the source code. The GPLv2 approach allows for the ability to restrict this freedom, but if the manufacturer makes a mistake, then suddenly it's lawsuit territory, or getting caught between obligations of conflicting contractual/licensing obligations.
If we're going to allow manufacturers to lock down their devices, as they surely can do using the GPLv2 even if they need to jump through the hoops correctly, what is the value of having the license require the hoops? Hope that they screw up so we can play "gotcha" and demand sources or hit them with a lawsuit?
- Ted
On Tue, Dec 04, 2012 at 09:20:19AM -0500, Theodore Ts'o wrote:
If we're going to allow manufacturers to lock down their devices, as they surely can do using the GPLv2 even if they need to jump through the hoops correctly, what is the value of having the license require the hoops? Hope that they screw up so we can play "gotcha" and demand sources or hit them with a lawsuit?
By the way, this is why I respected Eben Moglin's hard line position on the anti-lockdown clause. Either the copyright license should have it, or shouldn't. Whether you want to call the people who have managed to use the GPLv2's to achieve various business objections via locking down the ability to install modified code "using a loophole", or "a defect in GPLv2", or (as some would say) "a flawed interpretation of the GPLv2 language", if you're going to lock it down, you should lock it down all the way.
On the flip side, if we're going to allow manufacturers of dedicated consumer electronic devices to lock down the device, we shouldn't require that they jump through flaming hoops and do things exactly right, or otherwise leave legal traps which we hope that they fall into. To do otherwise would be, in my mind, somewhat dishonest.
So the only place where I could envision some compromise would perhaps be in trying to define what we mean by a "dedicated consumer device", versus a "general purpose computer". There is precedence in this; witness GPLv3's exemption of medical devices and voting machines.
The problem is that the line between "consumer devices" and "general purpose computers" gets fuzzier and fuzzier. While most people wouldn't care whether or not they could update the software on a watch, what happens when the watch has more computing power than a microVax II did back in the day, and you can download applications to the watch?
If we try to do it by device function, i.e., "medical devices" and "voting machines", what happens when someone comes up with some additional device family where there might be legitimate public policy reasons why allowing manufacturers to be able to lock down the software is OK? So I'm not actually a big fan of the GPLv3 approach of discriminating against specific fields of endeavor for exemption is such a great idea.
So how would you propose to split the baby in a way where anti-lockdown versus not isn't a stark philosophical choice? I don't see how it could be anything other than a either 100% yes or 100% no choice in a license.
Regards,
- Ted
On 12/04/2012 09:20 AM, Theodore Ts'o wrote:
On Tue, Dec 04, 2012 at 08:38:38AM -0500, Bradley M. Kuhn wrote:
I realize the anti-lock down provision was presented by the FSF to the Linux developers as non-negotiable. However, I've since, many years later, learned that FSF leadership was never even communicated the position of the Linux developers adequately by FSF's representatives at the time. Last year, RMS specifically asked me to apologize on his behalf to every single Linux developer to tell them that he wished he'd talked with you directly about your concerns at the time, rather than going through legal counsel. I think I've so-issued that apology to you, Ted, when I saw you in person at some point, but if I didn't, I do so now. :)
I don't recall hearing this, but I certainly accept the apology --- although I'm still not clear what RMS would have concessions (if any) he would have been willing to make if (as you say) negotiations had happened "has equals".
My own recollection (bearing in mind this was 6 years ago and the unreliability of human memory, etc.) was that Diane Peters and, separately, James Bottomley (specifically on that conference call that Bradley referenced) proposed making the anti-lockdown requirement (this was before the 'User Products' approach was taken) opt-in. I am certain that RMS knew about the proposal to make the anti-lockdown requirement opt-in or opt-out (it was the obvious 'compromise' solution at the time). I'm not sure that contradicts anything Bradley is saying, but I just want the historical record to be clear.
The idea of making anti-lockdown opt-in (or perpetual opt-out) was a response to the argument that the FSF was making at the time, which is that GPLv3's "additional permissions" mechanism provided the solution for any licensor who objected to anti-lockdown. The counter-objection was that this would not address the case where the licensor wished to ensure that no downstream licensee could re-impose the anti-lockdown requirement on *their* distributees.
Linus Torvalds may have said something publicly about this during that time period as well (that is, about use of 'additional permissions' being unsatisfactory for those who might otherwise be able to live with GPLv3 but objected to the anti-lockdown requirement). I seem to remember that, but again it was several years ago.
One reason I remember this (in general) was that, on my own initiative, and probably following that conference call Bradley referenced, I proceeded one evening to draft what I called (IIRC) "The Linux Kernel License", a proof of concept which was something like the existing draft of GPLv3 except the initial licensor would have to opt in to the anti-lockdown provisions, or could opt out of them (I can't recall which).
- RF
On 12/04/2012 10:35 AM, Richard Fontana wrote:
Linus Torvalds may have said something publicly about this during that time period as well (that is, about use of 'additional permissions' being unsatisfactory for those who might otherwise be able to live with GPLv3 but objected to the anti-lockdown requirement).
Much later on he did: http://lkml.indiana.edu/hypermail/linux/kernel/0706.1/2700.html
So I might be remembering that, or perhaps he said something to the same effect several months earlier.
Incidentally, re-reading this now after several years, I think Linus is basically correct in saying "The whole notion of 'additional permissions' in the GPLv3 is totally pointless". I mean, "totally pointless" maybe going a bit far, but I came to a similar conclusion in deleting the section 7 additional permissions scheme early on in the drafting of copyleft-next.
However, Linus was not correct when he said "The reason for the "additional permissions" is just to make the LGPL go away, and become a sub-clause of the GPLv3." That was the reverse of what happened: the FSF decided [very early on in the conceptualization of GPLv3] to add a provision to GPLv3 explicitly addressing additional permissions, and only when the matter of drafting an LGPLv3 was considered, RMS realized that instead of drafting an entirely new license, LGPLv3 could just be structured as GPLv3 plus additional permissions.
- RF
On Tue, Dec 04, 2012 at 02:09:26PM -0500, Richard Fontana wrote:
On 12/04/2012 10:35 AM, Richard Fontana wrote:
Linus Torvalds may have said something publicly about this during that time period as well (that is, about use of 'additional permissions' being unsatisfactory for those who might otherwise be able to live with GPLv3 but objected to the anti-lockdown requirement).
Much later on he did: http://lkml.indiana.edu/hypermail/linux/kernel/0706.1/2700.html
So I might be remembering that, or perhaps he said something to the same effect several months earlier.
In addition the reasoning he gave (which is that someone could take code that you wrote, and strip off the additional permissions), which you might be morally against, one of the other objections to this approach is that for an issue such as anti-lockdown, which has many passionate supporters (including Bradley, Alaxandre Oliver, et. al), this would essentially encourage forks, which would be rather disastrous from a community point of view --- i.e., we could easily end up with a FreeBSD/NetBSD/OpenBSD/DragonflyBSD situation, without the ability to be able to share code between the various BSD forks in a bilateral way.
Regards,
- Ted
On 10/12/2012 09:25 AM, Bradley M. Kuhn wrote:
the communication between the GPLv3 drafting committee and the Linux developers was completely botched.
Just in the interest of historical accuracy, there was no "GPLv3 drafting committee". There were four "Discussion Committees". The actual drafting of the license was the work of RMS, Eben, and me, with certain significant contributions by David Turner and, later, by Brett Smith. I wouldn't call that group a "committee" (it didn't function in any sense as a committee). Some of the members of some of the Discussion Committees did have some influence on some parts of the license.
(There was a fifth committee of sorts called the "International Committee", but it had no influence whatsoever on the drafting of GPLv3.)
That error being made, we now live with the consequences. But to allow that error to propagate into a decision that no anti-lock-down provision should even be *available* to copyleft-next users is completely unreasonable in my view.
It's available in the sense that copyleft-next is one-way GPLv3-compatible.
I believe we're going to continue to fight about the question of whether anti-lock-down is a primary feature of copyleft-next. However, it seems to me a needlessly contentious act to delete the *supplement*. If the supplement structure of copyleft-next exists, then the two supplements that must be officially recommended are the (a) network services clause and (b) anti-lock-down clause.
Anyone who cares strongly about the inclusion of the anti-lockdown clause, at this stage, is someone largely content with GPLv3 (or, say, someone who believes that GPLv2 already effectively implements anti-lockdown). By contrast, I think there are some who are supportive or potentially supportive of the policy behind the network services clause who are *not* entirely content with AGPLv3. That's my intuition, at any rate; I may be wrong about both statements.
- RF
On Sun, Oct 14, 2012 at 12:22 AM, Richard Fontana fontana@sharpeleven.org wrote:
On 10/12/2012 09:25 AM, Bradley M. Kuhn wrote:
I believe we're going to continue to fight about the question of whether anti-lock-down is a primary feature of copyleft-next. However, it seems to me a needlessly contentious act to delete the *supplement*. If the supplement structure of copyleft-next exists, then the two supplements that must be officially recommended are the (a) network services clause and (b) anti-lock-down clause.
Anyone who cares strongly about the inclusion of the anti-lockdown clause, at this stage, is someone largely content with GPLv3 (or, say, someone who believes that GPLv2 already effectively implements anti-lockdown). By contrast, I think there are some who are supportive or potentially supportive of the policy behind the network services clause who are *not* entirely content with AGPLv3. That's my intuition, at any rate; I may be wrong about both statements.
<mode philosophy> I've been giving software freedoms a lot of thought over the last few months and while at first I could not understand why claims of new discovered freedoms (device re-OSing, network services) should be inherently associated with older software under the older copyleft licenses which did not make mention to these freedoms, I've now come to grips with this as on ongoing philosophical journey and position one can have. The founders of GNU and the original copyleft license did have the intent all along to protect one's software freedoms, the extent to which that could be done could only be expressed in terms of what outlets we had at that time in terms of respecting these freedoms. Technically though new freedoms and rights have been described more tangibly over time and while the original authors of GNU and copyleft have always wish to ensure such new freedoms and rights are respected retroactively as they are discovered one cannot assume everyone else will want to follow, although they should. The inception of certain business models with at least a well understood set of freedoms and rights thrived way before new freedoms were found. These business models need their own set of licenses to also be updated over time to remain effective and relevant to any new changes. I see a lot of effort on the GPLv3 campaign and then AGPL to include a lot of these new found freedoms but I consider it a mistake to discard any older copyleft licenses as stale due to the fact that they do not include new found freedoms. The GNU position to jump on the latest copyleft licenses and make them apply to a lot of older projects is fine given the spirit of the project but the tensions we have seen over time is assumptions that everyone should do the same.
As I see it copyleft-next should evolve slowly and consider branching out every time a new found set of freedoms are found and each branch can move forward with updates / corrections / language taken from the tip so long as it does not add new freedoms (kind of how we require sha1sums from tip prior to applying a relevant patch back to stable releases of the kernel). The tip however can and should always stay focused on the latest freedoms.
Unfortunately though as we have it today GPLv2 was left abandoned after GPLv3 came out. I believe a lot of language from GPLv3 could be put into GPLv2 and I see no reason why we never did that. Short cutting and taking copyleft-next way ahead of where GPLv2 left off IMHO would do disservice to the community. I'm not saying it should not happen, just saying perhaps it should not happen until we have a nice update upgrade path from GPLv2 to a respective copyleft-next that allows all users of GPLv2 and businesses using it to move forward with it without any concerns or issues. Moving forward with another iteration of copyleft-next should IMHO be reviewed carefully with all newly discovered freedoms well described, and even business implications taken into consideration given that we have huge stakeholders now using these licenses. </mode philosophy>
Luis
On 10/12/2012 09:25 AM, Bradley M. Kuhn wrote:
the communication between the GPLv3 drafting committee and the Linux developers was completely botched.
Richard Fontana wrote on 14 October:
Just in the interest of historical accuracy, there was no "GPLv3 drafting committee".
Said by someone who was *on* the drafting committee. :)
The actual drafting of the license was the work of RMS, Eben, and me, with certain significant contributions by David Turner and, later, by Brett Smith. I wouldn't call that group a "committee" (it didn't function in any sense as a committee).
Right, that's sort of my point: that committee was likely dysfunctional and therefore communications were not handled properly.
Anyone who cares strongly about the inclusion of the anti-lockdown clause, at this stage, is someone largely content with GPLv3 (or, say, someone who believes that GPLv2 already effectively implements anti-lockdown).
I believe GPLv2 does but since prominent figures in the community don't agree with me and Alan Cox on that, there's a lot of estoppel generated.
I don't think GPLv3 is good on this issue. It's been over-influenced by lawyers. We need anti-lock-down provision in copyleft-next that's more tenable. And we shouldn't start from "no right to 'install and run' modified versions whatsoever" which is where the master branch stands at this moment.
Also, my point remains: current master branch of copyleft-next does *less* to defend the freedom of installing modified versions than even GPLv2 does on its *weakest* possible reading!
By contrast, I think there are some who are supportive or potentially supportive of the policy behind the network services clause who are *not* entirely content with AGPLv3.
Agreed. But what if one supports both? What license is there for them? It's not copyleft-next in its current form, that's for sure.
On 12/04/2012 08:45 AM, Bradley M. Kuhn wrote:
Richard Fontana wrote on 14 October:
Anyone who cares strongly about the inclusion of the anti-lockdown clause, at this stage, is someone largely content with GPLv3 (or, say, someone who believes that GPLv2 already effectively implements anti-lockdown).
[...]
I don't think GPLv3 is good on this issue. It's been over-influenced by lawyers. We need anti-lock-down provision in copyleft-next that's more tenable. And we shouldn't start from "no right to 'install and run' modified versions whatsoever" which is where the master branch stands at this moment.
Not true. There is a legal right to install and run (in fact, copyleft-next goes further than GPLv2 or GPLv3 with respect to this, arguably). The question is, what should the definition of Corresponding Source be, and should there additionally be a requirement to provide 'Installation Information' if that is thought of as something separate from 'Corresponding Source' (as in the GPLv3 model).
Also, my point remains: current master branch of copyleft-next does *less* to defend the freedom of installing modified versions than even GPLv2 does on its *weakest* possible reading!
That is not intentional. There may be some value in adapting part of the GPLv2 'corresponding source code' definition. I will look into that.
By contrast, I think there are some who are supportive or potentially supportive of the policy behind the network services clause who are *not* entirely content with AGPLv3.
Agreed. But what if one supports both? What license is there for them?
Is there really any developer out there, in a position to use GPLv3 or AGPLv3 as a license, who really cares about both? That's not a rhetorical question; I'd be curious to ask someone like Chris Webber, say.
- RF
On 10/12/2012 09:25 AM, Bradley M. Kuhn wrote:
I believe we're going to continue to fight about the question of whether anti-lock-down is a primary feature of copyleft-next. However, it seems to me a needlessly contentious act to delete the *supplement*. If the supplement structure of copyleft-next exists, then the two supplements that must be officially recommended are the (a) network services clause and (b) anti-lock-down clause.
I therefore insist that the anti-lock-down supplement be reverted. Please accept this merge request: https://gitorious.org/copyleft-next/copyleft-next/merge_requests/21
I recently decided to delete the other 'supplement', the one that incorporates language from AGPLv3 section 13. Ironically, perhaps, this deletion reflects my belief that there must be an AGPL-ish flavor of copyleft-next. In order to achieve that successfully we have to start over from scratch rather than be influenced by the existing language of AGPLv3 section 13. (It's not impossible that we'll end up with very similar language.)
That being so, it stands to reason that the anti-lockdown supplement should also stay deleted, without even getting into the policy issue being raised by bkuhn. I'd rather focus on further refinement of base copyleft-next, beginning to think about what an AGPL-ish version of copyleft-next would look like, and only then considering the issue of whether there ought to be an anti-lockdown variant.
Therefore I have rejected bkuhn's merge request. It is so ordered!
- RF
Richard Fontana wrote on 7 November:
That being so, it stands to reason that the anti-lockdown supplement should also stay deleted,
I was convinced by Mike Linksvayer's message that the supplement structure is confusing and needs reworking. I'm ok with all supplements staying out, provided we get the policy issues sorted out in the main text of the license for both issues: network services and lock-down.
Sadly, things haven't gone in a good direction on that regard, as I've mentioned in other threads.
copyleft-next@lists.fedorahosted.org