On Wed, Apr 09, 2003 at 04:56:28PM -0700, Mark Rafn wrote: > > Uh, better yet, let's use what the GPL's wording *should* be. See the > > PHPNuke thread. > > I'd agree, except that I don't think there was any consensus (or even > suggestion, but my memory is imperfect) on what such a wording should be. Well, Dave Turner disappeared from the list, so we kind of hit a wall there. If there were someone from the FSF still willing to listen to us, we might have been able to nail something down. Without that, our discussion lacks a necessary focus. > Much of the discussion was around whether the requirement to inform users > (as opposed to recipients) of anything can be free. It seemed to me that > it is acceptible in part due to it's ambiguity and the ability to ignore > it in many cases (non-interactive use). > > GPL 2c isn't perfect, and I'd be happier without it entirely, but it's > pretty clearly an allowed restriction that a free software license can make. I don't share your reasoning. I don't have a problem with the spirit of 2c so much as the letter of it, whereas you appear to feel that it is by its ambiguous letter than it is saved. Dave pointed out that it is these notices, as well as static strings in executables, that enable the FSF in many cases to identify cases of infringement, and I have some sympathy for that argument. If it's practically impossible to prove infringement, then the GNU GPL is without teeth and we might as well just cast all our software into the public domain. I'd like a bright-line test for what's "onerous" and what isn't, but I haven't thought of one. GPL 2c is a bit more onerous than I think is ideal, but I am sympathetic to the reported motivations behind it. > On Wed, 9 Apr 2003, Branden Robinson wrote: > > Mandating technologies in license documents really rubs me the wrong > > way. > > I'll say that more strongly: mandating use of a specific technology or > method of communication is a non-free restriction on the type of > modification allowed. This type of thing belongs in adjunct documentation > and community feedback on good citizenship. Agreed, except that GPL 2c comes perilously close to this. > > Why not say something like: > > "If you distribute modified copies of the work, you must ensure that its > > modified status is clearly, unambiguously, and obviously communicated to > > users of the work."? > > IMO, this is non-free without the GPL's permission to ignore this in > non-interactive use. "Non-interactive" is a technological term. "Mandating use of a specific technology or method of communication is a non-free restriction on the type of modification allowed." Equally, then, Debian cannot rely upon technological definitions when critiquing a license as non-DFSG-free, don't you think? I think you might be reading things into my proposed wording that aren't there: * It doesn't specify a means of communicating this information. * It doesn't say that this information has to be communicated to the user every time the work is used. * It doesn't say that there must not be anyway for the user to disable the communication of this notice. All the modifier has to do is take steps that a reasonable person would expect would result in users learning of the work's modified status. IMO -- and this reasoning applies to more than just the LPPL -- those of us who write licenses need to set limits on the amount of paranoia we permit into the document. Consider people who modify and distribute Free Software as being placed on a plane with two axes: axis of resources (4) | | (5) | | | (1) | (3) (2) ------------------------------------------------------------ axis of evil (I'm regarding "evil" as being able to take negative values (meaning "good", but resources have a floor at zero for the purposes of my analysis.) Let's consider the practical implications of dealing with each of the cases (1) through (5). (1) is the most common case in volunteer projects; the lone hacker. His motives are pure, his goals noble, but he doesn't have a lot of time or money. He is not motivated to violate the license or do wicked things. If you find this guy in breach of the license, a gentle notification will suffice. He'll probably fall all over himself apologizing and rectifying the problem. He'll probably even indulge requests by the author that aren't clearly expressed by the license. In short, if everybody were like (1) we wouldn't *need* software licenses. (2) is the malicious little cheapskate, the "w4r3z d00d", if you will. There's not much you can do about this sort of person. He doesn't cause much real-world damage, may not have even read your license, and certainly can't afford a lawyer. If you do decide he's worth the trouble, he'll probably get scared and go away. But it's unlikely anyone is going to trust him, so his power to distribute a hacked-up, license-violating version of your work is limited, because the people with the means to do large-scale distribution have other things to worry about; see below. You don't write licenses for (2) because he won't read them anyway. He simply doesn't care. (3) is the case where someone is pretty neutral about software licensing and this whole "community" concept, but is yet another case of the lone hacker. This is a guy you write your license for. You need to make clear what your expectations are, because he may not have the context of community participation, or have any particular fealty to Free Software as a concept. At the same time, he's not particularly malicious, just neutral. So he's likely to abide by the license as far as he understands it. He's just not going to go out of his way to figure out what you "really meant". If you write a clearly understandable license document, you'll likely never have to phone this guy up, or send him a cease-and-desist, etc. (4) is a case where we have a community celebrity with greatly respected hacking skills, or a company that has proved it's a good neighbor with the community. You don't have to fret about this case for much the same reason that you don't have to fret about case (1). A company or organization at point (4) may even have lawyers on staff who can help you make your license better, like Eben Moglen. (5) is, oh, say, Microsoft, or a company from a hypothetical alternative universe that happens to have that name. This company is rich beyond the dreams of avarice and can afford to hire an entire matriculating class straight out of Harvard Law. They are also bent on the destruction of anything that challenges their conception of how copyright law should work in the courts and in the market. There's no use trying to write a license to trap these guys. If you dare to try suing them, they can afford to spend $100,000 just on briefs for a summary judgement to dismiss the case. They have the power to forum shop so they can see to it that any copyright infringement case is heard in a jurisdiction where the judge is -- ahem -- "sympathetic" to the "value" they bring to their "community". Only if you yourself are way up there on the resource axis should you even consider yourself as standing a chance against any such colossus. Even then, I think writing for (5) instead of (3) is misguided. The clever and resourceful people who will think of ways to use your work that violate the letter but *not* the spirit of your license while spreading it and adapting it far and wide for success in the Free Software "ecosystem" are almost exclusively people who are low on the resource axis. By adopting a paranoid stance and writing for case (5), you intimidate and freeze out people around points (1) and (3), and possibly some (4)s as well, because the lawyers for (4) will look at your license and say, "Gee, there's a lot of little places here where we could be tripped up and exposed to a lot of liability to this guy -- our shareholders won't like that. What are our alternatives?" So, please, write licenses for the audience at (3). > Also, your proposal goes WAY further than requiring > a notice that a user could see if she is interested, it requires that the > user is prevented from suppressing it. I'm sorry, but as I stated above, I do not think my proposed wording requires this at all. "Clear, obvious, and unambiguous" to "every use" does not mean "clear, obvious, and unambiguous" at "every use", even when the user is already aware of the fact in question!  Just an example of a "friendly expert"; I don't know if Prof. Moglen does individualized consulting, so please don't use this message as an excuse to nag him for free (or fee-based) legal consulting. -- G. Branden Robinson | You don't just decide to break Debian GNU/Linux | Kubrick's code of silence and then firstname.lastname@example.org | get drawn away from it to a http://people.debian.org/~branden/ | discussion about cough medicine.
Description: PGP signature