Hi,
During the past two weeks I've been working on modifying a document that started out as the text of the GNU GPLv3 but which is now quite different. I've had gracious help from several other people, but so far it's fair to say that most of the *policy* decisions underlying the various changes have come from me (IOW you can blame me for almost anything in the draft thus far if you disagree with it). I thought I'd provide a summary description of the more interesting aspects of what's been done.
I deleted the following elements: * The Preamble and the 'How to Apply' appendix * The patent-related provisions that were introduced to GNU GPLv3 in the wake of the Microsoft/Novell deal of late 2006 * The old requirement to preserve legal notices in user interfaces * The acceptance provision (proposed by James Vasile)
I removed the so-called 'anti-Tivoization' provisions of GNU GPLv3 section 6 out of vanilla copyleft-next and into a separate document currently called "dl-supp". I also added a separate document called "ws-supp" containing substantially similar text to the first half of the GNU AGPLv3 section 13. I don't think I really explained this in the commit logs so I'll go into that a bit here. The idea is that the vanilla version of copyleft-next won't have an 'Affero clause' (much as GNU GPLv3 doesn't) and, unlike GNU GPLv3, it won't have 'anti-Tivoization' provisions. Only the *initial* licensor (someone who's starting a new work from scratch) can choose to supplement copyleft-next with one of those "supp" documents. Currently, vanilla copyleft-next is incompatible with {copyleft-next + dl-supp} and {copyleft-next + ws-supp} (much like "GNU GPLv2-only" is incompatible with GNU GPL3) (i.e. there's nothing corresponding to GPLv3/AGPLv3 cross-compatibility), though this is just because I deferred thinking about whether there should be compatibility or not.
I added a provision similar to Apache License 2.0 section 5 which is something like a built-in "inbound=outbound" contributor agreement for projects. (While I like this Apache feature very much it is a bit awkward in copyleft-next in its current form.)
I added a provision to the basic copyleft clause that is designed to remove the copyleft requirement if the licensor separately offers a proprietary commercial version of essentially the same software. Maybe this isn't worthwhile, but it was something I'd wanted to experiment with trying to implement for a long time.
I added a provision making copyleft-next relicensable under GNU GPLvn/AGPLv (the importance of this was impressed on me by Mike Linksvayer and it also addresses the FSF's reasonable concerns about GNU GPL derivatives).
I added a "no trademark rights granted" clause (similar to what's in MPL and the Apache License 2.0).
The old additional terms section has been drastically simplified and combined into the 'no-further-restrictions' section.
I won't go into detail about the remainder of the changes in this message but I'd describe them generally as aimed at substantial simplification and normalization of language and structure. To take one example, the patent license grant of GNU GPLv3 is essentially the same but it is presented very differently: it now accompanies the basic copyright license grant in the 'basic permissions' section early in the license (this is more like how other free software/open source licenses with patent license grants are structured, and I think it may be easier to understand).
I consider nothing of what I've done to be necessary or above criticism, but I think it gives you a sense of the direction I'm generally going in.
This might be the most lightly trafficked mailing list in the entire legal history of free and open source software, but I'd be happy if it could serve as a forum for discussing, suggesting or criticizing ideas, and also as one way of submitting patches against the license draft.
For those who don't know, currently I've been hosting the repository at https://gitorious.org/copyleft-next and mirroring at github https://github.com/richardfontana/copyleft-next
There's an IRC channel #copyleft-next on Freenode though so far the only discussion there has been bcotton and I talking about today's weather in Massachusetts. :-)
- Richard
On Wed, Jul 18, 2012 at 10:40:38PM -0400, Richard Fontana wrote:
I removed the so-called 'anti-Tivoization' provisions of GNU GPLv3 section 6 out of vanilla copyleft-next and into a separate document currently called "dl-supp". I also added a separate document called "ws-supp" containing substantially similar text to the first half of the GNU AGPLv3 section 13. I don't think I really explained this in the commit logs so I'll go into that a bit here. The idea is that the vanilla version of copyleft-next won't have an 'Affero clause' (much as GNU GPLv3 doesn't) and, unlike GNU GPLv3, it won't have 'anti-Tivoization' provisions. Only the *initial* licensor (someone who's starting a new work from scratch) can choose to supplement copyleft-next with one of those "supp" documents. Currently, vanilla copyleft-next is incompatible with {copyleft-next + dl-supp} and {copyleft-next + ws-supp} (much like "GNU GPLv2-only" is incompatible with GNU GPL3) (i.e. there's nothing corresponding to GPLv3/AGPLv3 cross-compatibility), though this is just because I deferred thinking about whether there should be compatibility or not.
In this last sentence, are you referring to the question of whether vanilla copyleft-next could or should be compatible with GPLv2-only, and/or what the compatibility of copyleft-next + dl-supp could or should be with respect to GPLv3?
I wasn't sure whether I was parsing it correctly, since this was something I immediately started thinking about when I started reading this paragraph, and I wasn't sure whether I was projecting my thinking onto yours.
In any case, the question of compatibility as a goal with GPLv2 or GPLv3 is a very interesting one. On the one hand, the ability to take code from one project and reuse it somewhere else without being unnecessarily limited by licensing compatibility issues is obviously, highly desirable. (For example, since e2fsprogs has two files which are lifted straight out from the kernel, there's no way I could ever take e2fsprogs GPLv3 due to its anti-Tivo clauases, regardless of whether I wanted to or not.) On the other hand, licensing compatibility of necessity constraints what you can put in the new copyleft-next license.
Regards,
- Ted
On 07/18/2012 11:53 PM, Ted Ts'o wrote:
On Wed, Jul 18, 2012 at 10:40:38PM -0400, Richard Fontana wrote:
Currently, vanilla copyleft-next is incompatible with {copyleft-next + dl-supp} and {copyleft-next + ws-supp} (much like "GNU GPLv2-only" is incompatible with GNU GPL3) (i.e. there's nothing corresponding to GPLv3/AGPLv3 cross-compatibility), though this is just because I deferred thinking about whether there should be compatibility or not.
In this last sentence, are you referring to the question of whether vanilla copyleft-next could or should be compatible with GPLv2-only, and/or what the compatibility of copyleft-next + dl-supp could or should be with respect to GPLv3?
I was probably conflating two thoughts there. In part, I was thinking of compatibility between vanilla copyleft-next and copyleft-next + dl-supp (or ws-supp), as though GNU GPLv2/v3 had never existed. For example, A starts a project using vanilla copyleft-next as the license. Should it be possible for B to license out a derivative work under copyleft-next + dl-supp or should that be disallowed? There are decent arguments on both sides.
It relates to the issues of GPLv2-only / GPLv3 compatibility in the GPL universe, however. In fact, what was going through my mind was the reaction (back in ~2007) some had to the argument, coming from FSF/FSF counsel/FSF advocates, that those who objected to the anti-Tivoization provisions could always use the "additional permissions" scheme explicitly laid out in GPLv3 (note btw that I've deleted all that as unnecessary obvious stuff and possibly even something that shouldn't be encouraged). Since, in the additional permissions scheme, additional permissions are explicitly removable downstream, anyone could transform a GPLv3 + "additional permission to ignore anti-Tivoization clauses" into standard GPLv3, and some found this objectionable on policy grounds, because they didn't like the idea that a downstream licensee could impose a more restrictive license than they themselves had chosen upstream.
For the moment, I've conveniently avoided the related problems of compatibility between copyleft-next and the GNU GPL license universe by putting in the clause that magically allows any copyleft-next flavor to be relicensed under GPLv2 or GPLv3 or AGPLv3 or later. But they raise the same policy issues, or seem to.
I wonder in fact if dl-supp serves any purpose if one can relicense under GPLv3. I deleted the more obscure contractor/outsourcing clause (see http://www.gnu.org/copyleft/gpl.html#section2 second paragraph) with the justification being that any company that cares so much about clarity on this issue can always avail themselves of relicensing under GPLv3 (of course this argument disappears if one removes the relicensing clause). I feel somewhat differently about ws-supp but that's another topic.
- Richard
Richard Fontana wrote:
some found this objectionable on policy grounds, because they didn't like the idea that a downstream licensee could impose a more restrictive license than they themselves had chosen upstream.
So, this is an interesting point on this issue. Is that really why those who objected had issue? After all, any weaker copyleft license can allow for such restrictions by downstream.
Does your point here relate to what has been called the "copyleft perfection theory of GPLv2"?
I think most people who generally like copyleft have a Platonic ideal in their minds of what their preferred copyleft license is, and then selectively read a given copyleft license to have those properties.
Having lived myself mostly in the reality of seeking compliance for GPLv2, but preferring GPLv3, I've had to dissuade myself of my Platonic ideals of copyleft and just focus on what the license actually says.
I wonder if copyleft-next can actually address this issue at all. Is its goal to be the Platonic ideal of copyleft for everyone? If so, how?
(Sorry, I hope in advance philosophical debate is appropriate on this list.)
-- bkuhn
On 07/30/2012 07:26 PM, Bradley M. Kuhn wrote:
Richard Fontana wrote:
some found this objectionable on policy grounds, because they didn't like the idea that a downstream licensee could impose a more restrictive license than they themselves had chosen upstream.
So, this is an interesting point on this issue. Is that really why those who objected had issue? After all, any weaker copyleft license can allow for such restrictions by downstream.
Does your point here relate to what has been called the "copyleft perfection theory of GPLv2"?
I think most people who generally like copyleft have a Platonic ideal in their minds of what their preferred copyleft license is, and then selectively read a given copyleft license to have those properties.
Having lived myself mostly in the reality of seeking compliance for GPLv2, but preferring GPLv3, I've had to dissuade myself of my Platonic ideals of copyleft and just focus on what the license actually says.
I wonder if copyleft-next can actually address this issue at all. Is its goal to be the Platonic ideal of copyleft for everyone?
Assuming I understand what you mean here, no, that is not a goal. I don't see how it is achievable, because we know that there are multiple, clashing ideals of copyleft -- at least if we mean strong copyleft.
At most, in allowing for outbound compatibility with GPLv2+/AGPLv3+, I believe copyleft-next accommodates the views of those who believe that one or more of those licenses more closely approximates their own ideal of what copyleft should mean.
(Sorry, I hope in advance philosophical debate is appropriate on this list.)
I certainly consider such debate appropriate.
- Richard
Richard Fontana wrote at 21:35 (EDT) on Monday:
I don't see how it is achievable, because we know that there are multiple, clashing ideals of copyleft -- at least if we mean strong copyleft.
I would agree with you, but then the question becomes: won't copyleft-next be "just another" copyleft, somewhere on the weak/strong spectrum, and ...
At most, in allowing for outbound compatibility with GPLv2+/AGPLv3+,
... if you have pure outbound compatibility to the FSF license suite, I have to wonder what the point is of copyleft-next. Who are the potential license users who *wouldn't* just use some existing copyleft license?
You talked in some of your interviews about copyleft-next as a way of experimenting with new ideas in copyleft. Perhaps we have to look at it that way, philosophically.
In other words, maybe we SHOULD pursue the Platonic ideal of copyleft, knowing full well that we can't live in the land of True Forms, but we should strive to it and see what happens.
We're rounding about 20 years out from the genius idea of copyleft. Some people don't like RMS or his ideas, but I think no one denies that copyleft was an invention of great genius.
Here we are, the next generation, rearranging little ornaments on the tree of the genius idea of copyleft. I long ago made my peace with the idea that my life's work is to merely rearrange ornaments on the tree of software freedom. In that vein, I suggest that copyleft-next is perhaps, a licensing drafting placeholder, that keeps trying to rearrange these ornaments until someone among us looks at it and has an epiphany. Those only come along once every generation or two on any given topic.
There's value in doing this exercise, but we should be realistic about what we're doing. Copyleft-next, in my estimation, is looking for the Theory of Everything for copyleft licensing. It's slow work and there may not be a breakthrough in our time. And, it may not exist at all. But we should look anyway and see what we find in the meantime.
On 07/31/2012 08:12 PM, Bradley M. Kuhn wrote:
Richard Fontana wrote at 21:35 (EDT) on Monday:
I don't see how it is achievable, because we know that there are multiple, clashing ideals of copyleft -- at least if we mean strong copyleft.
I would agree with you, but then the question becomes: won't copyleft-next be "just another" copyleft, somewhere on the weak/strong spectrum, and ...
It is intended to be strong copyleft. This is a fixed goal.
At most, in allowing for outbound compatibility with GPLv2+/AGPLv3+,
... if you have pure outbound compatibility to the FSF license suite, I have to wonder what the point is of copyleft-next. Who are the potential license users who *wouldn't* just use some existing copyleft license?
Well, I'm not absolutely convinced there should be outbound GPLv2+/AGPLv3+ compatibility. A few people, such as Mike Linksvayer and James Vasile, have made convincing arguments for why this is a good idea. It's partly a political thing. Remember, one of the things that makes copyleft-next different from past non-FSF GPL-alternative licenses is that I started with the GPLv3 text (granted, there is now almost no textual similarity between GPLv3 and copyleft-next). The FSF has discouraged making derivative works of the GNU GPL, and one of the FSF's arguments has been that this will tend to produce licenses that are GPL-incompatible. So I want to limit the degree to which the FSF is unhappy about copyleft-next. But Mike and James made additional arguments for having GNU strong copyleft compatibility. For example, I think it was James who said that this would make people more inclined to experiment with using the license. I believe it may have been Mike who emphasized the policy importance of minimizing commons fragmentation. The compatibility provision also goes (or should go) some way towards satisfying those who are concerned about license proliferation.
The existence of the outbound compatibility provision has, in any case, had an influence on how I've been drafting copyleft-next. I have partially justified some of the most dramatic changes from GPLv3 by saying that if people care so much about the loss of certain provisions they can always use copyleft-next code in a GPLv3-licensed work.
There's value in doing this exercise, but we should be realistic about what we're doing. Copyleft-next, in my estimation, is looking for the Theory of Everything for copyleft licensing.
That is not my goal at all. If I had to sum it up, I'd say this: I want to create a simpler, legally robust, more understandable, more aesthetically pleasing, noncorruptible strong copyleft license.
- Richard
On Tue, Jul 31, 2012 at 10:40:41PM -0400, Richard Fontana wrote:
It is intended to be strong copyleft. This is a fixed goal.
Just to clarify, when you say strong copyleft, you mean in the GPL vs LGPL sense, right?
People have been using "stronger" and "weaker" in other senses (i.e., whether there are more restrictions, such as the anti-Tivo clause) --- i.e., GPLv3 is "stronger" than GPLv2, or GPLv2 is "stronger" than BSD.
Personally, I don't really like "strong" and "weak" because it's rather imprecise, and it doesn't take into account the multidemensional nature of things; that is, it's not a single continuum of where certain licenses are "stronger" than others, and where someone might try to say that the "strongest" copyleft is best; licenses can't be strictly ordered!
- Ted
On 07/31/2012 11:25 PM, Theodore Ts'o wrote:
On Tue, Jul 31, 2012 at 10:40:41PM -0400, Richard Fontana wrote:
It is intended to be strong copyleft. This is a fixed goal.
Just to clarify, when you say strong copyleft, you mean in the GPL vs LGPL sense, right?
Yes. That's the only sense I mean.
People have been using "stronger" and "weaker" in other senses (i.e., whether there are more restrictions, such as the anti-Tivo clause) --- i.e., GPLv3 is "stronger" than GPLv2, or GPLv2 is "stronger" than BSD.
Right. I myself have only become aware of this usage recently (in the past month), and it surprises me. I don't think this is what the FSF, or RMS, ever meant by "strong" vs. "weak". For example, I don't recall the FSF ever saying that GPLv3 is "stronger" than GPLv2, or that AGPLv3 is "stronger" than GPLv3.
- Richard
Richard Fontana wrote at 08:19 (EDT):
I don't recall the FSF ever saying that GPLv3 is "stronger" than GPLv2, or that AGPLv3 is "stronger" than GPLv3.
I'd readily agree that my calling AGPLv3 a "stronger" copyleft than GPLv3 is somewhat about marketing AGPLv3. I don't know if you believe I'm the only promulgator of that usage, but I agree I've promulgated it.
OTOH, it's certainly true that I believe the freedom of users of network-hosted software to copy, share, modify, redistribute, and use modified versions of the software their using *is* an important right they should have. Thus, when I say "stronger copyleft", I simply means "more of the user population are guaranteed rights to copy, share, modify, redistribute and use modified versions of the software".
On 08/01/2012 06:06 PM, Bradley M. Kuhn wrote:
Richard Fontana wrote at 08:19 (EDT):
I don't recall the FSF ever saying that GPLv3 is "stronger" than GPLv2, or that AGPLv3 is "stronger" than GPLv3.
I'd readily agree that my calling AGPLv3 a "stronger" copyleft than GPLv3 is somewhat about marketing AGPLv3. I don't know if you believe I'm the only promulgator of that usage, but I agree I've promulgated it.
I either wasn't aware of it or had forgotten it.
OTOH, it's certainly true that I believe the freedom of users of network-hosted software to copy, share, modify, redistribute, and use modified versions of the software their using *is* an important right they should have. Thus, when I say "stronger copyleft", I simply means "more of the user population are guaranteed rights to copy, share, modify, redistribute and use modified versions of the software".
Okay. That is not what I mean by "strong" copyleft. I just mean it in the "GPL as opposed to LGPL" sense. I'll make some modification to the 'ABOUT' file to clarify that.
It occurs to me that one of the ways ws-supp should improve upon AGPLv3 is to provide more clarity on the scope of the source code requirement. Depending on how that's done and how a particular person interprets AGPLv3 today, that might be seen by that person as a weakening effect. Right now, however, I don't think of my goal for ws-supp as being to make it Michael Meeks' proposed ALGPL.
- Richard
On Tue, Jul 31, 2012 at 8:25 PM, Theodore Ts'o tytso@mit.edu wrote:
On Tue, Jul 31, 2012 at 10:40:41PM -0400, Richard Fontana wrote:
It is intended to be strong copyleft. This is a fixed goal.
Just to clarify, when you say strong copyleft, you mean in the GPL vs LGPL sense, right?
People have been using "stronger" and "weaker" in other senses (i.e., whether there are more restrictions, such as the anti-Tivo clause) --- i.e., GPLv3 is "stronger" than GPLv2, or GPLv2 is "stronger" than BSD.
Personally, I don't really like "strong" and "weak" because it's rather imprecise, and it doesn't take into account the multidemensional nature of things; that is, it's not a single continuum of where certain licenses are "stronger" than others, and where someone might try to say that the "strongest" copyleft is best; licenses can't be strictly ordered!
Historically, that has been the case, but given the convergence in patent termination clauses, notification requirements, and compatibility, the most recent versions of the major licenses (Apache, MPL 2, LGPL 3, GPL 3, AGPL 3, but excluding eclipse) actually can be basically strictly ordered on a copyleft-only basis.
Luis
On Wed, Aug 1, 2012 at 8:02 AM, Luis Villa luis@tieguy.org wrote:
On Tue, Jul 31, 2012 at 8:25 PM, Theodore Ts'o tytso@mit.edu wrote:
On Tue, Jul 31, 2012 at 10:40:41PM -0400, Richard Fontana wrote:
It is intended to be strong copyleft. This is a fixed goal.
Just to clarify, when you say strong copyleft, you mean in the GPL vs LGPL sense, right?
People have been using "stronger" and "weaker" in other senses (i.e., whether there are more restrictions, such as the anti-Tivo clause) --- i.e., GPLv3 is "stronger" than GPLv2, or GPLv2 is "stronger" than BSD.
Personally, I don't really like "strong" and "weak" because it's rather imprecise, and it doesn't take into account the multidemensional nature of things; that is, it's not a single continuum of where certain licenses are "stronger" than others, and where someone might try to say that the "strongest" copyleft is best; licenses can't be strictly ordered!
Historically, that has been the case, but given the convergence in patent termination clauses, notification requirements, and compatibility, the most recent versions of the major licenses (Apache, MPL 2, LGPL 3, GPL 3, AGPL 3, but excluding eclipse) actually can be basically strictly ordered on a copyleft-only basis.
I should add that:
1) It's obviously not a perfectly strict ordering - there are exceptions. But the basic principles and big concepts are now aligned. You can choose a recent-generation license based on level of copyleft, which wasn't the case in the recent past, when, e.g., you might have wanted the patent protections of MPL 1.1 but the copyleft of GPL. There was no way to get those in one package. Now that we're all agreed on the basics of the patent protection issues you can focus on your level of copyleft.
2) I think this is a very good thing - the convergence is the result of experiments by one license being accepted by others (e.g., MPL's defensive patent clause; GPL's termination/restoration clause, etc.). It may make sense to accept copyleft.next changes that would break the weak ordering we currently have only if they are an experiment that would stand a reasonable chance of being adopted by MPL 3, GPL 4, etc.
Luis
On 08/01/2012 11:10 AM, Luis Villa wrote:
Now that we're all agreed on the basics of the patent protection issues you can focus on your level of copyleft.
Not sure I agree on that. I see plenty of contemporary interest in use of licenses without explicit patent provisions of any sort (the MIT license seems at least as popular as it ever was). I would even say that the continued interest in GPLv2 even for post-2007 projects shows that explicit patent protection is not the highest priority for many developers, even those who generally favor GPL-style licensing.
As for licenses with explicit patent provisions, I don't think they reveal collectively any common agreement on what patent protection in a FLOSS license ought to be (even at a minimum - except that perhaps the Apache License 2.0 represents the acceptable minimum today.
- I think this is a very good thing - the convergence is the result
of experiments by one license being accepted by others (e.g., MPL's defensive patent clause; GPL's termination/restoration clause, etc.). It may make sense to accept copyleft.next changes that would break the weak ordering we currently have only if they are an experiment that would stand a reasonable chance of being adopted by MPL 3, GPL 4, etc.
Here of course I must disagree, and raise an issue you've given me an opportunity to raise, which is the great danger we are facing as a result of entrenched political 'winners' having effective control over the future of FLOSS licensing. This was an aspect of my concern about the abandoned effort to get OSI approval for CC0, although I don't think I was the one to state it so explicitly. To put it another way, we are entering an era where experimentation in licensing seems to be actively discouraged for what appear to be political reasons rather than reasons grounded in principle. Zooko's TGPPL, discussed earlier on this list, was an earlier casualty of this development.
- Richard
Richard Fontana wrote at 11:35 (EDT):
we are entering an era where experimentation in licensing seems to be actively discouraged for what appear to be political reasons rather than reasons grounded in principle.
I agree with you, but I see two reasons to approach new copyleft licensing experimentation with skepticism. Neither applies to copyleft-next much now, but could in the future.
The first reason is a simple one: license incompatibility hurts cross-project codesharing. The question really is, at least for me regarding this project's goal : does copyleft-next *only* have a AGPLv3 compatibility provision to avoid the political fallout of not having one, or is it indeed the real goal of copyleft-next to rise above license proliferation by making a copyleft true "cross-copyleft compatible", but simpler, more elegant copyleft? This is what I ask myself when I look at your AGPLv3 compatibility clause.
The second reason I'm skeptical is admittedly a bit more conspiratorial-sounding, but please hear me out before judging.
Because I'm one of the very few people on this planet who enforce copyleft, I *know* and *see* every day that there are companies out there -- including some big, wealthy ones -- who constantly seek to eviscerate copyleft. They hire expensive law firm lawyers, and use those lawyers to fight and erode copyleft. They fight proxy wars by backing violators in their defenses. There's a whole bag of dirty tricks out there that I face regularly in trying to make sure copyleft isn't effectively the same as the Apache Software license.
Now, I *don't* think Red Hat is such a company (by contrast, it's probably the friendliest for-profit company to copyleft out there). Nor do I even suspect Fontana's efforts are secretly on behalf of Red Hat; he's made it clear that copyleft-next is a personal project, and I believe him. *But* that's because I know Fontana very well, we're friends, and I also know what kind of culture Red Hat has.
However, when I look at something like copyleft-next, I still have to worry about hidden agendas of future contributors. GPLv3 process, of course, was *full* of such hidden agendas and manipulations. The whole damned thing was like a high-stakes, licensing version of the board game, Diplomacy. The only reason we got a good license out the other end of that process was because RMS *ignored* the game, and instead *personally* vetted every last clause and change uninfluenced by any lobbyists. Indeed, I frequently raise with him things I discover in GPLv3 -- now years later -- and I say "crap, why is that in there! That can't be right." and he invariably had already considered the situation and had a reason and a plan for why that's there. He has -- in every such case -- convinced me it was the right decision, but, from my point of view it's all post-hoc because the real important and correct policy-making was all in RMS' brain [0].
But, as I said earlier in this thread, there aren't many RMS' in the world, so when I see someone or a group of someones drafting a new copyleft license or attempting to influence the drafting of such, I end up having to follow the money and figure out what's really going on, because copyleft has more enemies than friends. And its enemies are well-funded and have good, expensive lawyers.
Zooko's TGPPL, discussed earlier on this list, was an earlier casualty of this development.
As one of the critics of TGPPL, I was very clear throughout that non-compatibility with FSF's license suite was my only complaint. Would there be use to copyleft-next for Zooko and I to finally sit down and *write* the AGPLv3 additional permission that makes TGPPL? Would that help inform the copyleft-next project?
[0] And note that I don't believe in papal infallibility here or anything like that. RMS is human and can make mistakes. It's just that he's really good at copyleft policy -- genius-level good -- but that's IMO the only reason GPLv3 wasn't a disaster. Some might say it's why GPLv3 *was* a disaster, but that's a separate debate, and you all can guess what side of that debate I'm on. :)
On 08/01/2012 06:06 PM, Bradley M. Kuhn wrote:
The question really is, at least for me regarding this project's goal : does copyleft-next *only* have a AGPLv3 compatibility provision to avoid the political fallout of not having one, or is it indeed the real goal of copyleft-next to rise above license proliferation by making a copyleft true "cross-copyleft compatible", but simpler, more elegant copyleft? This is what I ask myself when I look at your AGPLv3 compatibility clause.
You also have to look at "ws-supp". Right now that's just basically AGPLv3 section 13 paragraph 1 because I haven't dealt with it, but I intend for it to be a substantial improvement on AGPLv3 (section 13) (while of course inheriting all the improvements in vanilla copyleft-next).
The AGPLv3+/GPLv2+ compatibility clause is partly in vanilla copyleft-next for political reasons, and partly for policy reasons (which are political in a different sense).
But there is no general goal to make copyleft-next "cross-copyleft compatible". I don't think that's necessary. Making it a "simpler, more elegant copyleft" *is* one of the main goals of copyleft-next. I could achieve more elegance without that compatibility provision.
But, as I said earlier in this thread, there aren't many RMS' in the world, so when I see someone or a group of someones drafting a new copyleft license or attempting to influence the drafting of such, I end up having to follow the money and figure out what's really going on, because copyleft has more enemies than friends. And its enemies are well-funded and have good, expensive lawyers.
I hear you. Keep in mind the significance of the ex-Harvey Birdman Rule, imperfect as it is. I've thought about the idea of having a "disclose potential conflicts of interest" rule.
Zooko's TGPPL, discussed earlier on this list, was an earlier casualty of this development.
As one of the critics of TGPPL, I was very clear throughout that non-compatibility with FSF's license suite was my only complaint.
Would there be use to copyleft-next for Zooko and I to finally sit down and *write* the AGPLv3 additional permission that makes TGPPL? Would that help inform the copyleft-next project?
Well, any additional permission on AGPLv3 that makes TGPPL is likely to be easily adaptable to copyleft-next.
- Richard
Richard Fontana wrote at 22:12 (EDT) on Wednesday:
I intend for it to be a substantial improvement on AGPLv3 (section 13) (while of course inheriting all the improvements in vanilla copyleft-next).
While I know of no show-stopper bugs in AGPLv3§13, there are probably minor improvements worth making.
Making it a "simpler, more elegant copyleft" *is* one of the main goals of copyleft-next. I could achieve more elegance without that compatibility provision.
I think compatibility with at least the FSF suite is essential, if copyleft-next is intended to be a license used in the wild.
I hear you. Keep in mind the significance of the ex-Harvey Birdman Rule, imperfect as it is. I've thought about the idea of having a "disclose potential conflicts of interest" rule.
Yes, I like the rule formerly known as the Harvey Birdman Rule [0] as well. It's a rule that, if followed, can prevent the entire process from being a giant Diplomacy game. OTOH, how is the rule formerly known as Harvey Birdman rule enforced?
Well, any additional permission on AGPLv3 that makes TGPPL is likely to be easily adaptable to copyleft-next.
Ok, it's up to Zooko, then, if he wants to do this work with me. Fontana, is it on-topic for this list to the work here?
[0] BTW, I think I'm going to make a merge request to just call this darned thing Harvey Birdman again. this "ex-Harvey Birdman" or my preferred "The rule formerly known as Harvey Birdman Rule" is just annoying.
On 08/02/2012 05:49 PM, Bradley M. Kuhn wrote:
OTOH, how is the rule formerly known as Harvey Birdman rule enforced?
I guess it is ultimately an honor system, as with such things as the Chatham House Rule.
Well, any additional permission on AGPLv3 that makes TGPPL is likely to be easily adaptable to copyleft-next.
Ok, it's up to Zooko, then, if he wants to do this work with me. Fontana, is it on-topic for this list to the work here?
Sure. I am skeptical right now about whether it's worthwhile to include a TGPPL-like provision or supplement for copyleft-next, but Ben Cotton has already done a merge request (still open) aiming to implement the TPL/TGPPL idea. Standardization of categories of additional permissions may independently be a good idea.
[0] BTW, I think I'm going to make a merge request to just call this darned thing Harvey Birdman again. this "ex-Harvey Birdman" or my preferred "The rule formerly known as Harvey Birdman Rule" is just annoying.
I'm inclined to agree with this.
- RF
On Wed, Aug 1, 2012 at 9:35 AM, Richard Fontana fontana@sharpeleven.org wrote:
To put it another way, we are entering an era where experimentation in licensing seems to be actively discouraged for what appear to be political reasons rather than reasons grounded in principle. Zooko's TGPPL, discussed earlier on this list, was an earlier casualty of this development.
It is a great relief to hear you speak sympathetically about that episode. I'm sorry to say it, but I'm still angry and hurt about my experiences in that process.
However, I must say that those who opposed TGPPL at that time probably had principled reasons to do so, including their concern about "licence proliferation" and other legitimate concerns. (Mike Linksva has raised some objections to the TGPPL idea on this list.) What was not principled was their *method* of opposing it, which was to use OSI's power of denying "Open Source Definition" certification even though they did not appear to disbelieve that TGPPL was compliant with the Open Source Definition. Certain people also used the technique of being personally abusive toward me until I was no longer willing to continue to argue.
Here are all the entries on my blog about that:
https://lafsgateway.zooko.com/uri/URI:DIR2-RO:d73ap7mtjvv7y6qsmmwqwai4ii:tq5...]]
I would like to help draft a "TGPPLv2" which is expressed as an additional permission on AGPLv3. I am also very interested in a transitive grace period patch to copyleft-next that I've read about on this thread but have not yet seen.
I'm thinking about the license-compatibility issues that have been recently discussed on this list. I value licence-compatibility and I value being able to practically use a licence in the near term for real value.
Disclosure: I'm the founder and CEO of a tiny startup -- https://leastauthority.com -- that is selling a service based on the Tahoe-LAFS software, which is dual-licensed under GPLv2+|TGPPLv1+. Our company is producing a lot of new source code, funded by a research grant from DARPA, which we are contributing to the Tahoe-LAFS project under those same dual-licensing terms.
Regards,
Zooko
On Tue, Jul 31, 2012 at 5:12 PM, Bradley M. Kuhn bkuhn@ebb.org wrote:
We're rounding about 20 years out from the genius idea of copyleft. Some people don't like RMS or his ideas, but I think no one denies that copyleft was an invention of great genius.
Agreed.
Here we are, the next generation,
Speak for yourself, -- or two generations ;)
rearranging little ornaments on the tree of the genius idea of copyleft. I long ago made my peace with the idea that my life's work is to merely rearrange ornaments on the tree of software freedom. In that vein, I suggest that copyleft-next is perhaps, a licensing drafting placeholder, that keeps trying to rearrange these ornaments until someone among us looks at it and has an epiphany. Those only come along once every generation or two on any given topic.
There's value in doing this exercise, but we should be realistic about what we're doing. Copyleft-next, in my estimation, is looking for the Theory of Everything for copyleft licensing. It's slow work and there may not be a breakthrough in our time. And, it may not exist at all. But we should look anyway and see what we find in the meantime.
Agreed but I'd like to raise another point which you seem to have missed.
There is no denying @rms' genius in not only dreaming up copyleft but also architecting it and spread-heading other philosophical breakthroughs on software freedom. Software freedoms need to be understood, debated, educated, and written about as such: as software freedom philosophy. I have much to say in this regard but first I want to get straight to the point I want to make here: licensing strategies are instruments available at our disposal to allow us to implement in the real world protection for software freedoms we dream up as technology advances.
There is philosophy, there is licensing and lastly there are strategies on how to introduce these software freedoms into our worlds. In capitalist societies the way we get introduced to software freedoms are through the markets so that users can actually use these software freedoms with real products. Surely we in the community can make our own hardware, but to mass produce -- you need some sort of markets *today*. As I see it anti-tivoization (live with it) and afferoness (I realize its latin but this is short and sweet and I think we all get this is from the AGPL) are and should be considered as *evolutions* in software freedoms. To some, the lack of such freedoms were actually considered as loopholes in the good 'ol GPLv2. Weather or not anti-tivoization or afferoness were implicit in the GPLv2 and making them explicit in future licenses were necessary or not may something worthy of debate -- but to me it does not matter, in the long term the actual use case will only be validated in court. There is another oversight here: as free software philosophers its selfish to believe that developers themselves or companies (we live in a capitalist world, live with it) could not have their own practical interpretation downstream of the GPLv2. For better or worse, the GPLv2 is understood in the market as having only certain requirements. Its this last part that I believe creates the tension between church, industry and the community. Free software philosophers tend to be purists while the industry / market / random developers / support engineers / etc may not *care* much or at all and simply want to comply to the minimum requirements. There is plenty of evidence to support this.
While it may somewhat true that we are just re-arranging ornaments in a tree of the genius idea of copyleft that @rms dreamt up a long time ago in a galaxy far far away -- there are real life strategical challenges that we engineers in the industry face in pursuing large markets to learn how to play properly in the tree and also *move along in the tree* and maybe even *help with the tree*. There are strategical ways to place ornaments. @rms may want the tree up yesterday and for everyone to appreciate all the shiny ornaments on it, but even just the education alone could use some strategical and tactful placement. First get folks to understand software freedoms. Consumers still do not understand they have such freedoms, that alone is one problem, its no wonder why its hard to convince the entire *industry* of valuing then other evolutions on the idea of software freedoms such as anti-tivoization and affernoness. If our modern day engineers *barely* get the first set of software freedoms, and if we still even have the BSD hackers diehards hacking away blissfully ignoring their own software freedoms it shows a few things:
1) Education on software freedom could use some love 2) Even after understanding software freedoms, some may be happy in giving some freedoms up
I can tell you as someone growing up as a second generation geek with software freedoms being readily available to you -- the actual philosophical effort to educate properly on the importance of software freedoms simply sucks. We all do our part on trying to educate on this but this is not getting us closer on education as fast as we need it, as fast as technology is advancing. And even if people are educated -- some may still want to rot away without software freedoms. That's choice, and that's fine. The value of freedom must needs to be appreciated eventually by end users.
Whether we like it or not embracement of evolutions on software philosophy are slow and this slow pace is really only a reflection of the markets in which software freedoms would thrive in. Software is nothing but a very small instrument as part of a larger Technology Industrial Complex -- software, as well as the freedoms therein will evolve as the technology evolves. Whether we like it or not there's an implicit symbiotic relationship between software freedoms and technology as part of a larger Technology Industrial Complex. My point here is we can be more tactful to ensure that software freedoms are not only well understood but also well *respected*, *predicted*, and eventually highly *prioritized* as a *huge market attribute*. I have an idea on the later aspects of this but this idea is still being socially brewed.
Luis
mcgrof, I agree with most of points. In fact, I agree that it's important we make a contribution. I'd like us to think hard about the philosophy of software freedom and what policies should be implemented to ensure it.
I think you may have missed part of my point. The key point I was trying to make was that revolutionary ideas are hard to come up with. If we rely in the idea that we can come up with such, we may be waiting a long time. That's what I was getting at with rearranging ornaments.
On Sun, Aug 5, 2012 at 7:31 AM, Bradley M. Kuhn bkuhn@ebb.org wrote:
mcgrof, I agree with most of points. In fact, I agree that it's important we make a contribution. I'd like us to think hard about the philosophy of software freedom and what policies should be implemented to ensure it.
*As* we argue over what is best philosophically, licensing needs to move one. Whether we like it or not some folks / markets already depend on assumptions of certain projects to have only embraced certain software freedoms. We need to be respectful of that to create predictability. If there is any ambiguity over licensing terms over the GPLv2 we have no one but *ourselves* to blame.
Ultimately what I am arguing for is that in order for us to advance licensing with further freedom clarifications / requirements we must first widely review the philosophy publicly as we are right now. Trying to piggy back on the older licenses new concrete freedoms is simply a dirty trick even if the intention was to cover these 'loopholes' after the market already embraced a different set of freedoms for it.
I think you may have missed part of my point. The key point I was trying to make was that revolutionary ideas are hard to come up with. If we rely in the idea that we can come up with such, we may be waiting a long time. That's what I was getting at with rearranging ornaments.
Ah great point...
Luis
On Tue, Jul 31, 2012 at 5:12 PM, Bradley M. Kuhn bkuhn@ebb.org wrote:
In other words, maybe we SHOULD pursue the Platonic ideal of copyleft, knowing full well that we can't live in the land of True Forms, but we should strive to it and see what happens.
Platonic ideal of copyleft strikes me as absurd, but it is also a malleable term, so I don't know what you mean. The particulars of copyleft are deeply shaped by the regulatory environment it evolves in, including already used copylefts. The "ideal" copyleft(s) in any given environment is the most effective mechanism for neutralizing threats to and for promoting software freedom starting from that environment; this we should strive for.
We're rounding about 20 years out from the genius idea of copyleft. Some people don't like RMS or his ideas, but I think no one denies that copyleft was an invention of great genius.
I must deny it. Perhaps in service of supporting it. Any important claim must be attacked, lest it die from the unremitting bludgeoning of obscurity and triviality.
"Genius idea" and "invention of great genius" are vague, but a few of the things that could be implied, along with an uncharitable interpretation of RMS-copyleft:
* The invention was not only clever, but also useful and good. It is hard to evaluate the net effect of copyleft on software freedom, and it seems nobody has really tried. Furthermore, it is easy to argue that software freedom is unimportant or even negative, such that if copyleft works, it is evil. Some software freedom advocates have admitted that software freedom is less important than say climate change or ending slavery. It is possible that advances in computing help those causes and software freedom is not optimal for advancing computing unless one defines unfree computing as not-computing, which is silly -- in any case this makes software freedom, thus effective copyleft, evil, and if it is genius at all, it is evil genius, and that's not the kind of genius we want to praise as "genius".
* The invention wouldn't have occurred anyway. This is impossible to know, but dubious. Reciprocity mechanisms and forced sharing are endemic. We know that even unambiguously "genius" inventions occur multiple times independently. Software freedom lost and attempts to "hack" things other than software were "in the air".
* The invention required genius. I don't see why. Copyleft is not in an intellectually challenging concept (I take widespread non-malicious incomprehension as damning for the non-comprehenders and/or the concept, not an indication that the concept is genius).
* The inventor was a genius. RMS surely has far above "genius level" IQ, but that narrow interpretation of "genius" should be rejected as euromale-capitalist-technocrat-hegemonic, and it is not clear that RMS would evaluate to "genius level" on a more democratic basis, if we even allow for such evaluation to exist.
* Ideas and invention matter. No they don't, only implementation and adoption by the masses matter. "Genius idea" is merely a mythologization of implementation and impact, which are greatly aided by many geniuses. Software freedom has at best ambiguous and tenuous success, copyleft's contriubtion to same even moreso, providing no evidence for the kernel of truth to be found in non-pernicious mythologizations.
* The invention has withstood serious criticism. Subterfuge by rent-seeking high-paid law-firm lawyers doesn't count, except in the sense that winners write history. Deafening silence from philosophers, social scientists, and activists on this matter and instrument purported by a few people to be of great moral importance.
Doubtless many more exist. Yes, I'm being a little bit silly with some of the above, but I'm completely serious about the need for criticism.
Here we are, the next generation, rearranging little ornaments on the tree of the genius idea of copyleft. I long ago made my peace with the idea that my life's work is to merely rearrange ornaments on the tree of software freedom. In that vein, I suggest that copyleft-next is perhaps, a licensing drafting placeholder, that keeps trying to rearrange these ornaments until someone among us looks at it and has an epiphany. Those only come along once every generation or two on any given topic.
All important progress may be characterized pejoratively as rearranging little ornaments, but I see no reason to. Instead I would characterize having an "idea" pejoratively, and assign all credit to implementation and painstaking improvement and diffusion.
Put another way, the tree of software freedom is a mere sapling.
Richard Fontana wrote at 11:35 (EDT):
we are entering an era where experimentation in licensing seems to be actively discouraged for what appear to be political reasons rather than reasons grounded in principle.
I am all for experimentation and ignoring any "establishment"-political reasons against same, but I also think introduction of further incompatibility is harmful for reasons grounded in principle. There is much room for experiment that does not introduce new incompatibility, and even that agitates for increased compatibility. In these respects I think copyleft-next is at least promising.
On Wed, Aug 1, 2012 at 3:06 PM, Bradley M. Kuhn bkuhn@ebb.org wrote:
Because I'm one of the very few people on this planet who enforce copyleft,
This should weigh heavily on considerations of future copyleft policy, copyleft-next or elsewhere. A mechanism that depends on a very few non-superheros (though I'm much more willing to grant that your efforts are heroic than I am to put any idea on a pedestal) is a sad one. This may only indicate problems in software freedom beyond the scope of the mechanism itself, but if there's anything future mechanisms can do about it, they probably should. But it is easy to imagine both putting every conceivable enforcement tool in, and increasing readability, and other things, all as being helpful, and somewhat at odds with each other.
As one of the critics of TGPPL, I was very clear throughout that non-compatibility with FSF's license suite was my only complaint. Would there be use to copyleft-next for Zooko and I to finally sit down and *write* the AGPLv3 additional permission that makes TGPPL? Would that help inform the copyleft-next project?
It'd be neat regardless of copyleft-next! (Though I have a list of reasons TPL/TGPPL like mechanisms probably aren't important, if incompatibility is taken care of they are well worth trying out much more than present.)
Mike
On Wed, Jul 18, 2012 at 7:40 PM, Richard Fontana fontana@sharpeleven.org wrote:
I removed the so-called 'anti-Tivoization' provisions of GNU GPLv3 section 6 out of vanilla copyleft-next and into a separate document currently called "dl-supp". I also added a separate document called "ws-supp" containing substantially similar text to the first half of the GNU AGPLv3 section 13. I don't think I really explained this in the commit logs so I'll go into that a bit here. The idea is that the vanilla version of copyleft-next won't have an 'Affero clause' (much as GNU GPLv3 doesn't) and, unlike GNU GPLv3, it won't have 'anti-Tivoization' provisions. Only the *initial* licensor (someone who's starting a new work from scratch) can choose to supplement copyleft-next with one of those "supp" documents. Currently, vanilla copyleft-next is incompatible with {copyleft-next + dl-supp} and {copyleft-next + ws-supp} (much like "GNU GPLv2-only" is incompatible with GNU GPL3) (i.e. there's nothing corresponding to GPLv3/AGPLv3 cross-compatibility), though this is just because I deferred thinking about whether there should be compatibility or not.
If the supplements remain, I'd hope for as much compatibility as possible; something like the GPLv3/AGPLv3 mechanism seems fine.
I don't see any notion of additional conditions via supplements in the main license draft. If they remain, will the license explicitly only allow certain supplements? I'm somewhat skeptical of switches that turn on significant further restrictions in any case. The FDL is the nearest example of this I can think of (switches built in rather than as supplements) which produces ugly notices, independent of the non-freeness of those switches. I suppose MPL2's compatibility opt-out is another example, but I haven't seen it used yet.
It is also not clear how the two draft supplements would work with GPLvn compatibility (which of course I think maintaining is a good and necessary thing). I'm not sure the affero clause implemented as a permissible restriction in GPLv3, rather than as a separate license with a compatibility mechanism, would have been better; I suspect it would be more confusing. In any case, copyleft-next+ws-supp relicensing under anything other than AGPLv3[+] doesn't make much sense.
It'd be boring and relatively inflexible, but one way to go would be copyleft-next without lockdown and service features, compatible with all FSF strong copylefts, and arch-copyleft-next, compatible only with AGPLv3+.
Above is just rambling. I realize that the supp mechanism might be experimental and I may not understand.
I added a provision similar to Apache License 2.0 section 5 which is something like a built-in "inbound=outbound" contributor agreement for projects. (While I like this Apache feature very much it is a bit awkward in copyleft-next in its current form.)
I love the section name. I don't understand (purely because I'm ignorant) how this works -- specifically, doesn't "unless" make it meaningless? At least if there's no limitation on what "unless" terms can be?
I added a provision to the basic copyleft clause that is designed to remove the copyleft requirement if the licensor separately offers a proprietary commercial version of essentially the same software. Maybe this isn't worthwhile, but it was something I'd wanted to experiment with trying to implement for a long time.
I enjoy this provision, a lot. Does it clearly only apply to offers of proprietary versions that the offerer actually has the rights necessary to legitimately offer?
Mike
On 07/22/2012 03:35 PM, Mike Linksvayer wrote:
I don't see any notion of additional conditions via supplements in the main license draft.
The old section 7 of GPLv3 is completely gone in copyleft-next, except that one sentence has been moved to the no-further-restrictions section. This is somewhat sad because section 7 is in many respects GPLv3 at its best. copyleft-next (at the moment) proposes to deal with inbound license compatibility differently from GPLv3 (though reaching almost the same practical results), by giving examples of a few well-known licenses that are compatible. I don't entirely like that mechanism but I think it is superior to the one in GPLv3.
Apart from the Apache License, where I now think the better approach (specifically avoided in GPLv3) is to single it out for explicit compatibility, supplemental additional conditions should be allowable under copyleft-next to the same degree they are under GPLv2, and understanding of what sorts of conditions ought to be allowable should have some space to evolve. This is partly motivated by a desire to shorten and simplify the license.
It is also not clear how the two draft supplements would work with GPLvn compatibility (which of course I think maintaining is a good and necessary thing). I'm not sure the affero clause implemented as a permissible restriction in GPLv3, rather than as a separate license with a compatibility mechanism, would have been better;
I don't think it would have been better, although I think the fears of a plethora of Affero-ish licenses and ad-hoc conditions were overblown.
In any case, copyleft-next+ws-supp relicensing under anything other than AGPLv3[+] doesn't make much sense.
Relicensing under GPLv3+ doesn't make sense there, but I suppose relicensing under "GPLv2 only" could. For a practical historical example, consider the license of stet. Bradley Kuhn has noted that stet was the first software to be released under AGPLv3, which is technically true. However, the actual license notice, which Bradley and I came up with, said this:
This notice constitutes a grant of such permission as is necessary to combine or link this software, or a modified version of it, with Request Tracker (RT), published by Jesse Vincent and Best Practical Solutions, LLC, or a derivative work of RT, and to copy, modify, and distribute the resulting work. RT is licensed under version 2 of the GNU General Public License.
*At the time* I considered this clever.
It'd be boring and relatively inflexible, but one way to go would be copyleft-next without lockdown and service features, compatible with all FSF strong copylefts, and arch-copyleft-next, compatible only with AGPLv3+.
That's an interesting idea.
I added a provision similar to Apache License 2.0 section 5 which is something like a built-in "inbound=outbound" contributor agreement for projects. (While I like this Apache feature very much it is a bit awkward in copyleft-next in its current form.)
I love the section name. I don't understand (purely because I'm ignorant) how this works -- specifically, doesn't "unless" make it meaningless? At least if there's no limitation on what "unless" terms can be?
Most contributions to projects don't have any explicit licensing information, so in most situations this will reinforce what I'd argue would already be implicit. You can imagine situations where someone might wish to contribute a patch under explicitly more permissive terms.
I added a provision to the basic copyleft clause that is designed to remove the copyleft requirement if the licensor separately offers a proprietary commercial version of essentially the same software. Maybe this isn't worthwhile, but it was something I'd wanted to experiment with trying to implement for a long time.
I enjoy this provision, a lot. Does it clearly only apply to offers of proprietary versions that the offerer actually has the rights necessary to legitimately offer?
No, that is currently not made explicit. But I suppose it should be, as otherwise it might be read as suggesting that a licensee is generally free to license modified versions of copyleft-next code under proprietary licenses.
- Richard
Richard Fontana wrote:
the actual license notice, which Bradley and I came up with, said this:
This notice constitutes a grant of such permission as is necessary to combine or link this software, or a modified version of it, with Request Tracker (RT), published by Jesse Vincent and Best Practical Solutions, LLC, or a derivative work of RT, and to copy, modify, and distribute the resulting work. RT is licensed under version 2 of the GNU General Public License.
*At the time* I considered this clever.
I still consider it clever, in the sense that it punts all decisions of license compatibility between GPLv2 and AGPLv3 for the specific circumstance to a Court. I still wonder sometimes if additional permissions of that nature might be the future of cross-copyleft compatibility.
-- bkuhn
On 07/30/2012 07:28 PM, Bradley M. Kuhn wrote:
Richard Fontana wrote:
the actual license notice, which Bradley and I came up with, said this:
This notice constitutes a grant of such permission as is necessary to combine or link this software, or a modified version of it, with Request Tracker (RT), published by Jesse Vincent and Best Practical Solutions, LLC, or a derivative work of RT, and to copy, modify, and distribute the resulting work. RT is licensed under version 2 of the GNU General Public License.
*At the time* I considered this clever.
I still consider it clever, in the sense that it punts all decisions of license compatibility between GPLv2 and AGPLv3 for the specific circumstance to a Court. I still wonder sometimes if additional permissions of that nature might be the future of cross-copyleft compatibility.
Maybe they are the only way to explicitly resolve historical cross-copyleft incompatibilities (in practice they seem to be resolved implicitly in many cases). I've become more skeptical of the value of additional permissions (or 'exceptions' as they were called in the pre-GPLv3 era) because of the complexity cost they add to a given licensing situation.
With respect to the license of stet, I am reminded of Michael Meeks' reference to the possible need for an "ALGPL" (I forget the precise term he used) in his talk at FOSDEM. A suitable integral weak copyleft variety of AGPL presumably could have been applied to stet such that the clever notice wouldn't have been necessary. (I'm not sure if the notice even *was* necessary, but I don't remember much about how stet and RT fit together.)
- Richard
Richard Fontana wrote at 21:49 (EDT) on Monday:
I've become more skeptical of the value of additional permissions (or 'exceptions' as they were called in the pre-GPLv3 era) because of the complexity cost they add to a given licensing situation.
To argue against additional permissions is effectively to argue against weak copyleft. Are you saying there should be no weak copyleft? (I'm not trolling; I'm asking a philosophical question: particularly given that you're the author of LGPLv3 as an exception set to GPLv3.)
A suitable integral weak copyleft variety of AGPL presumably could have been applied to stet such that the clever notice wouldn't have been necessary. (I'm not sure if the notice even *was* necessary, but I don't remember much about how stet and RT fit together.)
But... but... there's no philosophical difference between a weak copyleft and an additional-permission set. They are the same thing!
On 07/31/2012 07:57 PM, Bradley M. Kuhn wrote:
Richard Fontana wrote at 21:49 (EDT) on Monday:
I've become more skeptical of the value of additional permissions (or 'exceptions' as they were called in the pre-GPLv3 era) because of the complexity cost they add to a given licensing situation.
To argue against additional permissions is effectively to argue against weak copyleft.
No, because common weak copyleft licenses aren't structured as "strong copyleft plus additional permissions". The one exception is LGPLv3, of course.
Are you saying there should be no weak copyleft? (I'm not trolling; I'm asking a philosophical question: particularly given that you're the author of LGPLv3 as an exception set to GPLv3.)
I think the policy case for weak copyleft (vs. noncopyleft) is getting progressively weaker, as it were. I'm not prepared to say there should be no weak copyleft licenses, but it is significant that I have no intention of copyleft-next either being a weak copyleft license or having some official LGPL-like weak copyleft variant.
A suitable integral weak copyleft variety of AGPL presumably could have been applied to stet such that the clever notice wouldn't have been necessary. (I'm not sure if the notice even *was* necessary, but I don't remember much about how stet and RT fit together.)
But... but... there's no philosophical difference between a weak copyleft and an additional-permission set. They are the same thing!
There's more to licenses than philosophy.
- Richard
Richard Fontana wrote at 22:12 (EDT) on Tuesday:
No, because common weak copyleft licenses aren't structured as "strong copyleft plus additional permissions". The one exception is LGPLv3, of course.
But policy-wise, that's what they are, even if they aren't structured that way. Frankly, this finding may be the only actual interesting and new policy discovery that came from the GPLv3 process.
I think the policy case for weak copyleft (vs. noncopyleft) is getting progressively weaker, as it were. I'm not prepared to say there should be no weak copyleft licenses, but it is significant that I have no intention of copyleft-next either being a weak copyleft license or having some official LGPL-like weak copyleft variant.
I worry that line of thinking might serve to bifurcate the Free Software community even further into the historical BSD/GPL camps. Even now, we see folks teetering on the edge of anti-copyleft because of their dislike of the anti-lock-down provisions.
I actually think we need *more* weak copylefts along a spectrum. I hoped GPLv3 plus additional permissions sets were more widely adopted to take us there.
There's more to licenses than philosophy.
I feel like you just said to me: "There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy". :)
Anyway, Free Software licenses are about public policy and philosophy. The rest is, ultimately, just details. Agreement on what the philosophy and public policy should be theoretically yields a rather straightforward drafting task, right?
I think GPLv3 process had some issues because philosophy, public policy, and drafting were all conflated by everyone.
On 08/01/2012 06:07 PM, Bradley M. Kuhn wrote:
Richard Fontana wrote at 22:12 (EDT) on Tuesday:
No, because common weak copyleft licenses aren't structured as "strong copyleft plus additional permissions". The one exception is LGPLv3, of course.
But policy-wise, that's what they are, even if they aren't structured that way. Frankly, this finding may be the only actual interesting and new policy discovery that came from the GPLv3 process.
It is certainly an *interesting* theory of free software licensing, but I now believe it was in some sense an error. It is an unnatural way of looking at free software licenses. Licenses are tokens, as someone once said.
I actually think we need *more* weak copylefts along a spectrum. I hoped GPLv3 plus additional permissions sets were more widely adopted to take us there.
I used to think that too. When you did that oggcast on GPL exceptions, I was still generally thinking the way you still seem to be thinking today. Although I think listening to that oggcast may have caused me to begin rethinking the issue. Essentially the problem is that you are ignoring the complexity cost (real, perceived or both) that accompanies use of additional permissions.
Anyway, Free Software licenses are about public policy and philosophy. The rest is, ultimately, just details. Agreement on what the philosophy and public policy should be theoretically yields a rather straightforward drafting task, right?
No, because there are other valid goals too, like simplicity and comprehensibility (and maybe practical goals like 'ease of enforceability' which I wouldn't necessarily classify as public policy or philosophy), and these affect drafting. I also have some ideas about making legal improvements that were never made in GPLv3, though that would probably conflict at some point with the simplicity goal.
- Richard
Richard Fontana wrote at 22:50 (EDT) on Wednesday:
Essentially the problem is that you are ignoring the complexity cost (real, perceived or both) that accompanies use of additional permissions.
Constitutions are complex things. A license isn't a "token", as you said, IMO. A license is a Constitution of a community. And, every community should have the right to draft their own *but* that runs into the compatibility problem. GPLv3 additional permission sets handle both things at once.
No, because there are other valid goals too, like simplicity and comprehensibility (and maybe practical goals like 'ease of enforceability' which I wouldn't necessarily classify as public policy or philosophy), and these affect drafting.
I agree that's important work that shouldn't be ignored, but rather pointless to begin until the philosophy and policies are decided, right?
On 08/02/2012 05:48 PM, Bradley M. Kuhn wrote:
Richard Fontana wrote at 22:50 (EDT) on Wednesday:
Essentially the problem is that you are ignoring the complexity cost (real, perceived or both) that accompanies use of additional permissions.
Constitutions are complex things. A license isn't a "token", as you said, IMO. A license is a Constitution of a community.
I never really liked that phrase, but I accept that it has some validity. However, I"m not so sure it's the precise terms of the license that are functioning as the constitution.
And, every community should have the right to draft their own *but* that runs into the compatibility problem. GPLv3 additional permission sets handle both things at once.
So you agree with the view (which I've heard before) that the additional permissions scheme of GPLv3 allows GPLv3 to become the license to end all licenses? Again, sounds nice, but it doesn't work out in reality. Ignoring the fact that you can't fully express GPLv3-incompatible licenses by using GPLv3 + additional permissions [+ allowed additional restrictions](try it!), there is just a psychological difference between, say, the ISC license and (GPLv3 + lots of additional permissions [+ allowed additional restrictions] to make GPLv3 equivalent to ISC). One's a *really* long, complicated license. The other is a really short, (seemingly) simple license. They are perceived completely differently by human beings even if there is some argument that they are legally equivalent.
In any case, this vision of GPLv3 as the license to end all licenses has (in 5 years) failed. At best it provides a useful theoretical basis for understanding license (in)compatibility.
No, because there are other valid goals too, like simplicity and comprehensibility (and maybe practical goals like 'ease of enforceability' which I wouldn't necessarily classify as public policy or philosophy), and these affect drafting.
I agree that's important work that shouldn't be ignored, but rather pointless to begin until the philosophy and policies are decided, right?
The goal of simplicity/conciseness is sufficiently important to me that it is necessary to draft the license while figuring out philosophy and policy as I go along. I also wanted to start out with the GPLv3 text rather than starting over from scratch (even now there is a kind of "GPLv3 ghost" that influences the draft though so little of the original GPLv3 wording remains).
But also, right now at least, I don't really have lots of *new* ideas about what a strong copyleft license should be. (If other people do and want to propose them, great!) In that sense I'm not like RMS and Eben in 2005 thinking ambitiously about how GPLv3 could address DRM and DMCA and patents, or you thinking about network services. I think I have more ideas about what it *shouldn't* be, and also (more positively) ideas about what it should *look* like.
- Richard
Richard Fontana wrote at 20:42 (EDT) on Thursday:
So you agree with the view (which I've heard before) that the additional permissions scheme of GPLv3 allows GPLv3 to become the license to end all licenses?
I didn't mean it that broadly. Specifically, I believe GPLv3+additional_permissions can express any GPL-compatible copyleft license.
there is just a psychological difference between, say, the ISC license and (GPLv3 + lots of additional permissions [+ allowed additional restrictions] to make GPLv3 equivalent to ISC).
I agree it's not worthwhile to express highly permissive licenses that aren't copylefts as GPLv3 with additional permissions. Focusing on that part of it is IMO a strawman argument, though. I didn't mean to argue for that; I'm talking about copylefts.
In any case, this vision of GPLv3 as the license to end all licenses has (in 5 years) failed.
I wouldn't be participating in copyleft-next if I thought AGPLv3 were the perfect copyleft. I just believe it's the best copyleft we have right now available to us. Calling GPLv3/AGPLv3 a failure is just FUD. It's a good piece of work that could be better. You know I agree with you that some pointless compromises were made in GPLv3, but they don't make it a bad license by any means. AGPLv3, in fact, is IM (very biased) O, the best copyleft license ever written yet, but I expect it won't be the best copyleft license *ever* written in my lifetime.
The goal of simplicity/conciseness is sufficiently important to me that it is necessary to draft the license while figuring out philosophy and policy as I go along.
That's a reasonable position, although I think this process was used during GPLv3 drafting somewhat too, and I think there were major bugs in the GPLv3 process. OTOH, those bugs may be unrelated to this aspect of GPLv3 process.
(If other people do and want to propose them, great!)
I indeed did so, this morning.
On 08/03/2012 10:57 AM, Bradley M. Kuhn wrote:
Richard Fontana wrote at 20:42 (EDT) on Thursday:
In any case, this vision of GPLv3 as the license to end all licenses has (in 5 years) failed.
I wouldn't be participating in copyleft-next if I thought AGPLv3 were the perfect copyleft. I just believe it's the best copyleft we have right now available to us. Calling GPLv3/AGPLv3 a failure is just FUD.
Calling GPLv3 a 'failure' could be FUD. To me, it's just incorrect, since GPLv3 is now one of the most commonly used FLOSS licenses. (AGPLv3 cannot be similarly described as 'commonly used'.) In any case, wide adoption was not a stated goal of the FSF, as you know.
But *I* did not say GPLv3 or AGPLv3 were "failures"; see above. I said the vision of GPLv3 as a license to end all licenses has failed. When I say "license to end all licenses", I mean that rather literally: there was a serious view that section 7 of GPLv3 provided a framework that would enable standardization of FLOSS licenses through recharacterization as GPLv3 + additional permissions and additional restrictions. That never happened, apart from the existence of LGPLv3 and AGPLv3. As an experimental idea, the "license to end all licenses" concept continues to be interesting, but it has proved to have little practical significance.
- Richard
On Wed, Aug 1, 2012 at 3:07 PM, Bradley M. Kuhn bkuhn@ebb.org wrote:
Richard Fontana wrote at 22:12 (EDT) on Tuesday:
No, because common weak copyleft licenses aren't structured as "strong copyleft plus additional permissions". The one exception is LGPLv3, of course.
But policy-wise, that's what they are, even if they aren't structured that way.
In the world of platonic license forms, the structure doesn't matter. But in the world of actually reading and interpreting licenses, structure matters.
With no offense to our host, I find reading/interpreting LGPL v3 maddening for exactly this structural reason, and I am pretty sure I'm in the majority in this area. And I actually like GPL v3; for those who are for predisposed not to like v3 for any of the various reasons available, LGPL v3's structure is only insult to injury.
Anyway, Free Software licenses are about public policy and philosophy. The rest is, ultimately, just details.
Adoption is intimately linked to achievement of any public policy goals, and ease of comprehension (encompassing not just policy but also drafting and structure) is intimately linked to adoption.
Luis
On 08/02/2012 10:52 AM, Luis Villa wrote:
In the world of platonic license forms, the structure doesn't matter. But in the world of actually reading and interpreting licenses, structure matters.
I agree.
With no offense to our host, I find reading/interpreting LGPL v3 maddening for exactly this structural reason, and I am pretty sure I'm in the majority in this area. And I actually like GPL v3; for those who are for predisposed not to like v3 for any of the various reasons available, LGPL v3's structure is only insult to injury.
Hmm. Are you saying that you find LGPLv3 maddening to read/interpret because you have to map its terms to GPLv3 and this is difficult, or are you saying instead that you find the substantive terms (the additional permissions) of LGPLv3 maddening to read/interpret?
I assume you mean the former. If you mean the latter, LGPLv3 is largely recasting LGPLv2.1 in a different form - policywise there isn't too much that's different, except for what comes in (explicitly or otherwise) through GPLv3. What's principally different are a few clarifications (one or two rather subtle) that make LGPLv3 at least marginally more permissive than LGPLv2.1. For example, if anyone is puzzled by LGPLv3 section 2, this is just an effort to transform LGPLv2.1 2(d) into a GPLv3 additional permission.
The result is a license document that appears far simpler than LGPLv2.1. This simplicity is illusory since understanding the license depends on understanding GPLv3. But appearance counts for something, and I can remember hearing from some people that LGPLv3 seemed like a great accomplishment because it *appeared* to get rid of the LGPLv2.1 complexity. Historical documents do show that quite a few people complained about interpretive complexity with respect to LGPLv2.x.
But anyway, I assume you mean instead that it's maddening to have to map a non-trivial set of additional permissions to a separate license text. I'm curious if you have a similar criticism of the GCC Runtime Library Exception (current version 3.1 at http://www.gnu.org/licenses/gcc-exception-3.1.html) though that is much simpler than LGPLv3. Bradley and I were both involved in drafting that Exception, though I left SFLC for Red Hat while that effort was still in its earlier stages. The GCC Runtime Library Exception reveals the stylistic influence of LGPLv3.
If it's specific to LGPLv3, it might relate to the previous point that LGPLv3 preserves the substance of LGPLv2.1 (more or less). Thus if LGPLv2.1 sections 5 and 6 are difficult for one to understand, I wouldn't expect them to find it any easier to take LGPLv3 sections 3 and 4 and try to understand them in the context of GPLv3. (Although to be honest I'm not seeing why the mapping is so hard. They're just exceptions to section 6 of GPLv3, essentially.
I personally think the FSF should have started from scratch with LGPLv3, but that isn't what was done.
To tie this more closely with copyleft-next, I believe that the FSF's decision to draft LGPLv3 as a set of additional permissions is historically significant, as I see it as an acknowledgement by the FSF that structural or formal simplicity and brevity in a license document (or at least the appearance of it) can be useful and valuable for developers and users.
Anyway, Free Software licenses are about public policy and philosophy. The rest is, ultimately, just details.
Adoption is intimately linked to achievement of any public policy goals, and ease of comprehension (encompassing not just policy but also drafting and structure) is intimately linked to adoption.
I agree with that too (though sometimes I've wondered if it's wishful thinking on my part).
- RF
On Thu, Aug 2, 2012 at 9:32 AM, Richard Fontana fontana@sharpeleven.org wrote:
On 08/02/2012 10:52 AM, Luis Villa wrote:
In the world of platonic license forms, the structure doesn't matter. But in the world of actually reading and interpreting licenses, structure matters.
I agree.
With no offense to our host, I find reading/interpreting LGPL v3 maddening for exactly this structural reason, and I am pretty sure I'm in the majority in this area. And I actually like GPL v3; for those who are for predisposed not to like v3 for any of the various reasons available, LGPL v3's structure is only insult to injury.
Hmm. Are you saying that you find LGPLv3 maddening to read/interpret because you have to map its terms to GPLv3 and this is difficult, or are you saying instead that you find the substantive terms (the additional permissions) of LGPLv3 maddening to read/interpret?
The former, definitely! (I have quibbles with some bits of the latter, but that's the case with any legal document.)
<snip>
But anyway, I assume you mean instead that it's maddening to have to map a non-trivial set of additional permissions to a separate license text. I'm curious if you have a similar criticism of the GCC Runtime Library Exception (current version 3.1 at http://www.gnu.org/licenses/gcc-exception-3.1.html) though that is much simpler than LGPLv3.
In that case, my objections are of the latter form (objections to the language of the exception) rather than the former (objections to license + exceptions structure). As I think you intuit, that's because the set of additional permissions involved there are much smaller and simpler (relatively speaking) and so easier to map onto GPL.
To tie this more closely with copyleft-next, I believe that the FSF's decision to draft LGPLv3 as a set of additional permissions is historically significant, as I see it as an acknowledgement by the FSF that structural or formal simplicity and brevity in a license document (or at least the appearance of it) can be useful and valuable for developers and users.
I agree that brevity is important, but the interaction between the two sets of restrictions/permissions, and the "I have to have two documents in front of me to read the thing" in this particular case outweighs the benefits, IMHO.
Anyway, Free Software licenses are about public policy and philosophy. The rest is, ultimately, just details.
Adoption is intimately linked to achievement of any public policy goals, and ease of comprehension (encompassing not just policy but also drafting and structure) is intimately linked to adoption.
I agree with that too (though sometimes I've wondered if it's wishful thinking on my part).
Clearly, the policy choices embodied in the license have a huge impact; as you noted in a separate thread, GPL v3 has some clauses that have had a significantly negative impact on GPL v3 adoption even after a lot of careful drafting. But that doesn't mean that structure and clarity don't have a significant impact.
Luis
Richard Fontana wrote at 12:32 (EDT):
... because it *appeared* to get rid of the LGPLv2.1 complexity. Historical documents do show that quite a few people complained about interpretive complexity with respect to LGPLv2.x.
FWIW, ISTR I said I liked it because it actually encapsulated complexity (in the way your email I'm replying to described). :)
I believe that the FSF's decision to draft LGPLv3 as a set of additional permissions is historically significant,
I agree with this too.
Luis Villa wrote at 10:52 (EDT):
But in the world of actually reading and interpreting licenses, structure matters.... I find reading/interpreting LGPL v3 maddening for exactly this structural reason, and I am pretty sure I'm in the majority in this area.
I would guess that by "the majority" here, you mean big law firm and/or corporate lawyers who want to find the absolute minimum needed to comply with the license. After almost fifteen years of dealing with such people, I've no sympathy left for them.
There are two separate and distinct groups who read and interpret FaiF licenses: those who read them to make sure the policy is right for advancing software freedom, and those who try to get the bare minimum reading so they can avoid sharing software with others. These groups are diametrically opposed to each other. Indeed, it's impossible for these two groups to be anything but political enemies.
In my experience that majority who are looking for the "how do I get around this?" reading actually often also work in license drafting processes with a hidden agenda to thwart it. This likely described the average GPLv3 process participant, in fact.
Richard Fontana wrote at 12:32 (EDT):
I'm curious if you have a similar criticism of the GCC Runtime Library Exception (current version 3.1 at http://www.gnu.org/licenses/gcc-exception-3.1.html) though that is much simpler than LGPLv3. Bradley and I were both involved in drafting that Exception
In fact, now that Fontana brings that up, it leads directly into a great example of my last point:
When I was part of the drafting team for the GPLv3 GCC Runtime Library exception -- which is admittedly a complexly organized and drafted license (maybe the most in the GPLv3 suite, in fact) -- we had a long call with a corporate counsel of a large tech company that hates copyleft. (Fontana, this was after you'd left the team, so you won't recall this.)
The corporate counsel kept saying: "This exception doesn't give us the permissions we need. As drafted, it creates risk for us because permissions we need are missing."
We said: "Oh, we're sorry. Please propose texts that you think should be there that give you the permissions you think are missing, because it's likely just be an oversight on our part."
The corporate counsel replied: "The problem is that the permissions we need aren't there."
We did this pointless loop four times, and hung up. We sent a follow up email to ask for details, and we were ignored. At the end of the process, the company commented that the license was unacceptable and was incredibly risky for their business.
In short, those who are scheming to get around copyleft will say and do just about anything to disrupt the license EXCEPT give *useful* input on how things should be structured or stated, because their goal, of course, is to disrupt the process. Even worse, they'll give seemingly helpful input that is actually a trojan designed to disarm the license so it's not really a copyleft in certain places.
In my example, the disruption and attack was pathetically obvious and easily worked around. Others have better diplomatic skills; we thus must be constantly vigilant. Although, I *do* think the rule formerly known as the Harvey Birdman Rule helps on this point.
On Thu, Aug 2, 2012 at 3:01 PM, Bradley M. Kuhn bkuhn@ebb.org wrote:
Luis Villa wrote at 10:52 (EDT):
But in the world of actually reading and interpreting licenses, structure matters.... I find reading/interpreting LGPL v3 maddening for exactly this structural reason, and I am pretty sure I'm in the majority in this area.
I would guess that by "the majority" here, you mean big law firm and/or corporate lawyers who want to find the absolute minimum needed to comply with the license. After almost fifteen years of dealing with such people, I've no sympathy left for them.
No, the first time I heard someone complain about it was at Red Hat. The second through nth times it was people on my GPL committee, which was most distinctly not the big firm committee. And after that it was at Mozilla. All before I joined a firm.
Luis (glad to be reminded of where you think I stand, though, and only slightly demotivated from continuing to contribute)
Luis Villa wrote at 18:13 (EDT) on Thursday:
No, the first time I heard someone complain about it was at Red Hat.
Citation? I assume you mean Fontana complained about it, since he's the GPL expert at Red hat?
The second through nth times it was people on my GPL committee, which was most distinctly not the big firm committee.
I was on that committee. Note that it included Larry Rosen, who, while not at a big firm, is one of the people who has generally looked for ways to get around copyleft.
Allison Randal on that committee had complaints regarding seeking simplicity, which are similar to Fontana's arguments. Also, as you'll recall, I argued with her (IMO successfully) to point out that GPLv3 needed to be more verbose so that people could understand better copyleft policies.
On 08/03/2012 10:18 AM, Bradley M. Kuhn wrote:
Luis Villa wrote at 18:13 (EDT) on Thursday:
No, the first time I heard someone complain about it was at Red Hat.
Citation? I assume you mean Fontana complained about it, since he's the GPL expert at Red hat?
Luis, then in law school, was a summer intern at Red Hat while I was still at SFLC. I assume he's referring to something from that time period, though I could be wrong. :)
BTW, you don't have to be a lawyer at Red Hat to have views on the GPL. Many Red Hat developers have strong opinions on licensing issues, and there's no universal agreement, even among developers otherwise strongly supportive of GPL licensing.
Allison Randal on that committee had complaints regarding seeking simplicity, which are similar to Fontana's arguments.
Yes. copyleft-next is in some respects inspired by Allison's 2007 essay still available here: http://radar.oreilly.com/2007/05/gplv3-clarity-and-simplicity.html
- Richard
On a more productive note than my last email:
On Thu, Aug 2, 2012 at 3:01 PM, Bradley M. Kuhn bkuhn@ebb.org wrote:
There are two separate and distinct groups who read and interpret FaiF licenses: those who read them to make sure the policy is right for advancing software freedom, and those who try to get the bare minimum reading so they can avoid sharing software with others.
In the case of LGPL and other less-than-broadest copylefts, the explicit policy intent of the licensor is to allow the licensee to "avoid sharing software with others" under at least some circumstances. So in this case the groups are not separate or distinct - someone seeking to fulfill the policy goals of the license may also be seeking to reduce sharing to some non-full level. As a result, when writing a less-than-full-copyleft, in order to *fulfill the policy goals of the licensor*, it is quite important to use a clear, understandable structure that clearly delineates what is and isn't permissible reduced sharing. That allows the licensor to pick the level of sharing they feel is appropriate to their policy goals, and it allows the licensee to best respect the intent of the licensor when figuring out their own level of sharing.
I don't think LGPL v3 does this, unfortunately - as I said, it's quite hard to follow and integrate, and that reduces the effectiveness of its policy goal of allowing some proprietary software in certain circumstances.
Luis
Luis Villa wrote at 22:35 (EDT) on Thursday:
In the case of LGPL and other less-than-broadest copylefts, the explicit policy intent of the licensor is to allow the licensee to "avoid sharing software with others" under at least some circumstances.
This is a valid point, but I reiterate that I don't hear criticisms from the other side that say: "if you could clarify this point in this way, it'd be clearer that you allow what you say you want to allow". Such feedback is helpful, but such feedback is sadly rarely given.
I long ago noticed that most developers have in their head a belief of what any LGPL (v2 or v2.1 or v3) means to allow and to prohibit. Sadly, that view in their heads rarely matches the text of the license. I've often begged developers to spend time reading LGPL to figure out if it matches their reality and give feedback so it can someday be changed to make it match their reality.
But, again, I want to hear this from *community developers* who pick LGPL. What people on the other side say doesn't matter much to me, because their goal is to brow-beat developers to eviscerate weak copyleft too. Sometimes, even, developers fall for this and are browbeat into believing no one will ever touch their software if it's not Apache-licensed.
I don't think LGPL v3 does this, unfortunately - as I said, it's quite hard to follow and integrate, and that reduces the effectiveness of its policy goal of allowing some proprietary software in certain circumstances.
I don't think LGPLv3 is a perfect weak copyleft by any means. It's a heck of a lot better than LGPLv2.1, so it's progress. The main reason I'm participating in copyleft-next is I *do* think Fontana's ideas to make copyleft drafts more digestible by community developers are essential and valuable and should be encouraged and supported.
On Fri, Aug 03, 2012 at 10:50:56AM -0400, Bradley M. Kuhn wrote:
I long ago noticed that most developers have in their head a belief of what any LGPL (v2 or v2.1 or v3) means to allow and to prohibit. Sadly, that view in their heads rarely matches the text of the license.
What are the most common misconceptions you've noted when talking to developers?
My perspective (but I'm someone who's actually *taken* one or two I/T and law classes at the MIT Sloan School, so obviously I'm far too well-informed to be able to give a valid opinion or to be seated on a jury :-) is that most developers think about things in terms of shared libraries, since that's how 99% of libraries are consumed these days. Hence, many developers simply want to allow a non-GPL-compatible program to be able to use their library.
A lot of the misconceptions I think have come from FSF partisans wanting to stretch the concept of what is covered by derivitive works as far as possible. As I've often been fond of asking, suppose you wrap a GPL'ed library via RPC's, and then call the GPL'ed library from another machine across the internet --- does the program which call said library become a derived work? That is, does the GPL virus infect across an RPC call across the internet?
Now what if the RPC server is called via localhost, or a unix domain socket? Does the GPL virus infect across a local RPC call?
Now what if you use a shared library? Is a program which calls the shared library a derived work of the GPL'ed shared library?
Now what if you are using a language like Java, where the author calling program may have absolutely no idea whether the library it is calling is in the same address space, or in a different JVM on the same machine, or across the network on a different server. (In fact, this might be a run-time or real-time dynamic configuration decision made by the system administrator or by automated load balacing software.) Is the calling program a derived work of a GPL'ed library which *might* be in the same address space?
The reason for bringing up this old and tired issue now is to point out that if it was well accepted that callers of shared libraries did not form a derived work, the demand for weak copyright would have fallen to near-zero.
So if the FSF's goal was to promote strong copyleft, and to discourage weak copyleft, my claim is their attempt to make what I consider to be an overreaching claim for what might considered the bounds of a derived work and what might be considered fair use has probably harmed their own stated goals.
- Ted
Theodore Ts'o wrote at 13:45 (EDT) on Friday:
What are the most common misconceptions you've noted when talking to developers?
The most common one is that developers often tend to believe the LGPL is like the MPL, yet they're very different types of weak copylefts.
My perspective is that most developers think about things in terms of shared libraries, since that's how 99% of libraries are consumed these days. Hence, many developers simply want to allow a non-GPL-compatible program to be able to use their library.
Indeed, OTOH, I think you spend a lot of time with more informed developers, since you work on a project that's existed for a longer period of time and has a richer culture and understanding of these issues. In other words, there are a lot of developers who haven't spent the time to understanding copyleft licensing that the average Linux developer has.
A lot of the misconceptions I think have come from FSF partisans wanting to stretch the concept of what is covered by derivitive works as far as possible.
I certainly don't want it to stretch -- I'm still a copyright minimalist. The courts, however, have already stretched it pretty far. Duke Nuke 'Em case, for example, stretched it pretty far: http://en.wikipedia.org/wiki/Micro_Star_v._FormGen_Inc.
I *do* want copyleft to go as far as copyright law says derivative works and controls on the rights to modify say they go. If I felt that a situation was dicey enough that we should ask a court, I would, and I'd abide by what the Courts ultimately set as policy. (In other words, I believe in the rule of law on this issue.)
As I've often been fond of asking, suppose you wrap a GPL'ed library via RPC's, and then call the GPL'ed library from another machine across the internet --- does the program which call said library become a derived work?
Now what if the RPC server is called via localhost, or a unix domain socket? Does the GPL virus infect across a local RPC call?
Now what if you use a shared library? Is a program which calls the shared library a derived work of the GPL'ed shared library?
I think a lot of this would come down to intent. Folks tend to think intent doesn't matter, but I've seen a lot of judges really care. If you designed all this for no technical reason, but rather to avoid the requirements of GPL, that would come out in litigation, and the judge wouldn't look favorably on your behavior.
So if the FSF's goal was to promote strong copyleft, and to discourage weak copyleft, my claim is their attempt to make what I consider to be an overreaching claim for what might considered the bounds of a derived work and what might be considered fair use has probably harmed their own stated goals.
I think FSF's goal is to propose the right copyleft for a given situation. After all, both strong and weak copyleft were invented by FSF.
On 08/05/2012 10:37 AM, Bradley M. Kuhn wrote:
I think FSF's goal is to propose the right copyleft for a given situation. After all, both strong and weak copyleft were invented by FSF.
In the interest of historical accuracy, there is some reason to believe that weak copyleft was invented by Cygnus, and that Cygnus encouraged the FSF to adopt the invention.
- Richard
On 08/05/2012 10:37 AM, Bradley M. Kuhn wrote:
I think FSF's goal is to propose the right copyleft for a given situation. After all, both strong and weak copyleft were invented by FSF.
Richard Fontana wrote on 6 August:
In the interest of historical accuracy, there is some reason to believe that weak copyleft was invented by Cygnus, and that Cygnus encouraged the FSF to adopt the invention.
I have never heard this from anyone but you. Can you post your evidence to this list? Thanks!
copyleft-next@lists.fedorahosted.org