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[1].
(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!
[1] 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
branden@debian.org | get drawn away from it to a
http://people.debian.org/~branden/ | discussion about cough medicine.
Attachment:
pgpB41xiqYME4.pgp
Description: PGP signature