"Benj. Mako Hill" <[EMAIL PROTECTED]> writes: > <quote who="Jeremy Hankins" date="Sun, Feb 12, 2006 at 01:52:53PM -0500"> >> "Benj. Mako Hill" <[EMAIL PROTECTED]> writes: >> > <quote who="Jeremy Hankins" date="Sat, Feb 11, 2006 at 10:34:48PM -0500">
>> >> But the question of whether this is a use restriction or a >> >> modification restriction is an interesting one. I believe that it is >> >> an attempt to accomplish a restriction on use via a restriction on >> >> modification. The intent behind both the AGPL and GPLv3(7d) is fairly >> >> easy to summarize: don't offer this software as a service to others >> >> unless you also offer the source. Unfortunately, offering the >> >> software as a service to others is neither copying nor modification. >> >> So any attempt to put this restriction naturally into a license will >> >> be a use restriction (or possibly a public performance restriction). >> > >> > Under this logic, copyleft is also a use restriction. It bars >> > proprietary use of free software. >> >> No, it doesn't. Proprietary use (i.e., use of private modifications) is >> very much permitted -- if it wasn't the ASP loophole wouldn't be an >> issue. In fact, licenses that don't permit private changes (e.g., >> through forced distribution) have been considered non-DFSG free in the >> past. What copyleft prevents is proprietary distribution of software. > > So, I think we agree that this is a modification restriction > attempting to protect users freedom to modify and redistribute their > software. But in the text I quoted originally we were talking about > the *intent* of the license. You claimed that because the modification > restriction *intended* to block proprietary use, it was a use > restriction. Minor nit: copyleft is a restriction on distribution, not modification. But yes, I do think that the Affero clause is an attempt to engineer a use restriction via a restriction on modification. That's significant not because use restrictions are bad (though I think they are), but because the restriction is engineered rather than simply stated. This is an argument against the feasibility of coming up with wording good enough to pass the DFSG, not an argument against it being able to pass the DFSG in principle. > Perhaps you don't share my belief that classic copyleft is designed to > block proprietary use Obviously, I can only guess at the intentions of the early adopters of the GPL[1]. But the GPL does not, technically or in practice, discourage my private use of GPL software that I have modified. I'm not certain that I understand you properly, because you seem to be saying that classic copyleft is designed to prevent me from doing things like testing out bug fixes before distributing them, or hacking on software for private purposes and never distributing it. If that is what you mean I think you're very much in the minority in the free software community. If you're talking about "proprietary use" in a general sort of sense (e.g., the practice of selling software), then you're conflating the casual, general meaning of "use" with the technical, software licensing sense of the word "use". If you mean something else I'm afraid I'll have to ask you to make it more clear, because I don't understand. > and the only reason that distribution was the > "hook" was that distribution was (a) very meaningful in terms of > copyright so didn't require a contract, etc and (b) always happened > before someone used the software. I believe that RMS's statements and > position in regards to the AGPL and GPLv3(7d) support my position in > this regard. I think that given the current way technology is > deployed, GPLv3(7d) is appropriate in that it takes both my (a) and > (b) above. I know there are others who disagree, but I'm perfectly willing to go along with the theory behind GPLv3(7d) and the AGPL -- _provided_ that it is implemented in a way that doesn't cause more problems than it solves. But any attempt to put that theory into practice as a modification or distribution restriction is going to run into the problem of engineering a use restriction as a modification restriction. Based on my experience, I'm extremely doubtful that that can be done in a clean, clear, and straightforward way. A good principle for writing licenses should be: "State the requirement instead of dictating the means of meeting it." The AGPL violates this principle, and a clause that satisfies the GPLv3(7d) would necessarily violate it as well. Consequently, all these hairy, complicated scenarios of loopholes and collateral damage come up. > In other words, I'm saying that classic copyleft is a distribution > restriction that was intended as a use restriction on a narrow class > of "use" (i.e., distribution that ended up taking away *users* > freedom). Distribution is not use. At least, I haven't been using the term "use" to include distribution (see above). > Because the distribution requirement was not too onerous and > because the purpose was in the interest of freedom, the community was > willing to accept it. I don't see how the goals behind the GPLv3(7d) > is fundamentally different. Clearly the mechanism is now modification > and the precise language may be more problematic but I don't see how > this is fundamentally different. The point I've been trying to make is not a theoretical one, but a practical one. A license which tries to control what happens when the software is used by controlling how the software is modified is inevitably going to be complicated and fragile, and have unintended consequences. It should come as no surprise no one has come up with good example wording. The fact that no one has come up with a sample clause is not a minor detail to be worked out later. It's a crucial point, because I don't believe it can be done (as I've argued above). By asking, via GPLv3(7d), that J. Random Hacker give it a try we're simply giving ourselves endless headaches down the road. [1] With the possible exception of RMS. Anyone know if he's ever weighed in on the subject explicitly? -- Jeremy Hankins <[EMAIL PROTECTED]> PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
