[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

modification notification requirements, and Who To Write Your License For

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
* 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

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
(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

Reply to: