Subject: Re: EROS license
From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
Date: Mon, 28 Jun 1999 20:32:20 +0900 (JST)

>>>>> "Crispin" == Crispin Cowan <crispin@cse.ogi.edu> writes:

    Crispin> Russell Nelson wrote:
    [quoting someone else]
    >> > I think that the whole discussion VERY clearly shows that
    >> > GPL-licensed projects have the advantage of more readily
    >> > attracting contributions, while other licenses have the

I still don't think this is necessarily true.  It is true for some of
the members of this list, and I wouldn't be surprised if it is true
for a large proportion of currently active contributors.  But I
suspect that that fraction will decrease as the penetration of free
software increases and the number of users and contributors expand.

Especially for the "if there's money to be made from _my_ code, I want
my share" licenses like Aladdin, which doesn't give Aladdin any extra
rights that any copyright owner doesn't already have.

    >> > advantage of more readily allowing the original author to take
    >> > the project proprietary for financial gain.  None of this

From the point of view of the original author, unless she assigns the
copyright, she is the proprietor of that program.  That's why she can
be so generous as to use the GNU Public License if she chooses.

It's not surprising, and quite human, and I think a good thing, that
we like people who make a habit of choosing to use the GPL.  I think
that people who like that kind of person should consider the license
terms in their contribution decisions.  And people who don't use free
licenses at all should expect to pay for improvements.  People who
sometimes use free licenses or use partially free licenses should
expect that only people who really like them for some other reason
will contribute.  And people who use only the GPL should expect the
same, except for some people like Ian who will give them substantial
precedence in their priorities, simply because the original developer
has been reliable about contributing under free terms.

But that doesn't change the fact that legally and morally the
copyright holder is a proprietor.

    >> > should be surprising, but it apparently needs to be
    >> > re-stated.
    >> 
    rn> My understanding does not match your re-statement of it.  The
    rn> author of a GPL-licensed project has the option of licensing
    rn> the code under another license.  That doesn't change the status
    rn> of the GPL-licensed version.  To "take the project proprietary"
    rn> is not possible under US Copyright law, and the whole Berne
    rn> Convention for all I know.  Copy rights cannot be retracted
    rn> once granted.

    Crispin> The procedure for "taking a project proprietary" is to
    Crispin> re-issue it under a new, proprietary license.

We've been through this before, quite recently.  If the project is the
code, that is not "taking the project proprietary", it is "abandoning
the project to anyone who will have it and starting a new project
(which happens to be proprietary and also happens to be based on the
same code)."[1]

The semantic difference is significant to some people, although not to
others.  I wish people who don't care about the semantic difference
would stop using the prejudicial phrasing, though.  It creates FUD in
people who otherwise would be sympathetic to the more precise
description (me, for one; being taken for a fool that way is why I'm
so vehement now).

The only interpretation where something non-proprietary becomes
proprietary I can come up with smacks of slavery, and that is that the
developer (or development organization) is "the project".  Then the
implication is that once a person has begun working on a free software
project, they can't stop and use their accumulated expertise for any
purpose resembling making money, or they're "taking the project
proprietary."  That interpretation definitely sucks.

    Crispin> The proprietary version can be made attractive relative
    Crispin> to the gratis/libre version by adding features not found
    Crispin> in the gratis/libre version.

Irrelevant, of course.  New features are the developer's own work.

    Crispin> The GPL confounds this procedure if someone else has
    Crispin> contributed a valuable feature to the gratis/libre
    Crispin> version.  The original author then has to get the
    Crispin> contributing author to grant non-GPL rights to the
    Crispin> contribution, or else give up the contributed code.

The latter in general is not very difficult to do, as long as you keep
good records.  Peter Deutch says that the former is generally not very
difficult to do either, in his experience, when the non-GPL
alternative is licensing Aladdin to use the code in proprietary
versions while simultaneously promising timely release under the AFPL.

    Crispin> Non-GPL licenses do not give contributing authors this
    Crispin> protection, which is why the GPL encourages

Wrong.  The license granted by the original developer has nothing to
do with use of contributions.  It is the license granted by the
contributor to the original developer that matters.  _The contributor
owns the copyright to the contribution_, unless and until she assigns
it to someone else.

It is true that contributors may have difficulty distributing their
own derivative works under non-GPL licenses, but that is a feature of
specific licenses, not of non-GPL licenses in general.  Eg ("there I
go again") under the Aladdin license, there is no prohibition against
redistributing any contribution you may make, only against you making
money on it without negotiating with Aladdin/Artifex first.  But you
can make the same condition on Aladdin's use of your code, or any
project where you contribute.

You can always make your contribution under the GPL (although you
probably will not be able to distribute it except as a "mere
aggregation,"[2] because of the viral clause in the GPL).  If you
really want to make an effective protest against say the Mozilla
license, write a really good extension, advertise it on the Web, and
send it to mozilla.org---under the GPL.  Then Netscape has to decide
whether to give up your code and look inconsistent (about open source;
they're not responsible for any statements in your ad, of course) in
the process, or put the whole shebang under GPL.

    Crispin> contributions.  Non-GPL licenses enable the "take it
    Crispin> proprietary" procedure, encouraging some originating
    Crispin> authors to choose licenses that grant them special
    Crispin> rights.

    rn> Some authors request back-licensing for the purposes of
    rn> dual-licensing.  Others use a GPL-like license which requires
    rn> it.  This is what Ian is objecting to.

The fact is that the GPL asserts a very strong property right in other
people's work, just because it happens to be based on the original
author's.  The GPL does this for a noble purpose: to provide really
strong incentives to avert backsliding by fools who might be tempted to
earn some revenue by evilly asserting a property right in the product
of their own labor.  The only difference between that and the Mozilla
license is the purpose; the incentive remains the same:

                 "Using my code is accepting my right
                to decide what can be done with yours."

(Not strictly equal; the Mozilla license reserves the right to decide,
while the GPL is restricted to using GPL terms.  But both do strongly
constrain downstream contributors from making decisions about their
own code.)

I'm not yet convinced that this incentive clause is a good idea, in
either the GPL, the AFPL, or the MPL, in the long run.  (For true
believers in free software as such, it is surely a good idea.  I'm
doubtful about the instrumental value in incenting creation of more
published-source software overall, both free and not.)

    Crispin> This is the difference between GPL and non-GPL licenses.
    Crispin> The GPL puts a contributor on exactly the same footing as
    Crispin> the original author, in proportion to the amount of code

This is a myth.  In practice, the original author contributed a
working application, and can take that working application
proprietary.  The later contributor has no such advantage, and is very
unlikely to have anything that they could "take proprietary" (or "take
free," for that matter) without a prohibitive amount of extra work.

Thus, there can never be symmetry between the copyright owner of the
original work, and a later contributor.  The only important practical
exception is if the original work is assigned to the FSF, because the
standard assignment papers bind the FSF to viral terms (my devil's
advocate interpretation), at least, and effectively to the GPL
(consensus interpretation, and I agree for any reasonably likely FSF
management).

But I know a number of people who would never contribute code under
anything but the GPL, but whose response to FSF assignment is "turn
the thumbscrews, thank you."  So that's not a complete solution, either.

    Crispin> contributed.  Licenses that give the original author
    Crispin> special rights mean that a contributor might be denied
    Crispin> rights to their own work.

False, in the sense that the contributor can always withhold the
contribution subject to negotiation with the original author to
preserve those rights.

Of course, as Ian points out, the transaction costs involved in the
negotiation between author and contributor are likely to be much
higher than the contribution is worth, thus having a chilling effect
on contribution.  My assessment that this effect is probably not large 
and likely to shrink is not intended to deny that it is real, and I
freely admit I have no privileged knowledge of how many people feel
which way.  Ian also disclaims such knowledge, you know.

But "foregone gains from trade due to transactions costs" are a far
cry from this mythical bogeyman of "taking projects proprietary."

And (Brian Behlendorf will have my head for this, I suspect), if the
sourceXchange and so on really work to reduce transactions costs (and
I think they will), either they or a more catholic version will make
it possible for contributors to sell their work back to the maintainer
on proprietary terms.  In that case, a large number of potential
contributors may actually _prefer_ the Mozilla license because it
announces "hey, we're ready to deal!"  (Not in so many words, of
course, but the first time they do, word will get around.  And they
may take that opportunity to make it explicit.)

If you want to kill that idea, just call it "MLM".  That's not
entirely accurate, but it should do the job ;-)

Footnotes: 
[1]  Both of the parenthetical conditions are in some sense accidental;
I know of several former leaders of free software projects (eg, Jamie
Zawinski) who were later exclusively occupied in proprietary work, but
on different code bases, while a code fork (eg, *BSD) in a free
project shows that a fork need not include a proprietary branch.  And
sometimes both fail:  some projects are orphaned because the leader
chooses to work on what he considers a more important free project.

[2]  And may not be able to distribute at all, of course, if the other 
license has a clause asserting a proprietary right in any enhancements.


-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for?  "Free software rules."