Subject: Re: [was Cygnus] now Ghostscript and Aladdin
From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
Date: Wed, 23 Jun 1999 13:41:47 +0900 (JST)

>>>>> "Ian" == Ian Lance Taylor <ian@airs.com> writes:

    Ian> I disagree.  I wouldn't worry about GPL vs. other free
    Ian> licenses.  But I would worry about GPL vs. Aladdin public
    Ian> license, or, say, GPL vs. NPL.

Agreed.  In the Aladdin case, having read the license and observed
Peter's conduct for some years, I have no worries.

Summary of the argument:

In general

  o Interest in a project is generated by the content of the project;
    license issues are secondary.  If people didn't make a big deal of 
    non-freeness of Aladdin or NPL, the license issues might inhibit
    the _second_ hack.  (I think that effect would be rather small.)
  o "Random hackers" (Brock's original point) are likely to code first 
    and read the license later if the source is already available.  I
    think many people would contribute to avoid feeling spiteful.
  o Authors _always_ have special rights.
  o One objection to "special rights" may be the obvious intent to
    exercise monopoly power, not asymmetry between primary author and
    others.
  o License FUD is due to transactions costs == having to read all
    those boring things.  Doesn't need to be "spread," and unavoidable
    as long as people have different needs.  (This is tangential to
    the thread, but important to me.)

About the AFPL

  o The viral clause of the Aladdin Free Public License applies to
    Peter, too, as long as you retain copyright.

Here we go:

    Ian> My interest in contributing to a project is higher if I am on

Even if you don't give a rat's ass about the project itself?

My main point is that people are attracted to projects primarily by
project content and the fact that the source is in front of them;
license bias is a second order effect.  If you built a program from
source and a bug bit, would license willies keep you from chasing it?
Having fixed it, would you not submit a patch?  I think the answer
there is pretty obvious.  (Dunno about anyone else, I've submitted
patches to the install csh script of GAMS, a large app for Linux that
I paid thousands of dollars for, with no source available other than
for that script.  With no license willies.)

It's less clear, but I still find it hard to imagine that you would
add a feature you personally needed and not contribute it.  (I'd
probably GPL and contribute such a thing to GAMS, eg a Bourne shell
version of that install script, or a Debian or RPM "install package.")

It seems to me that those two categories cover most of what Brock's
"random hackers" would do.  What's left (contributing large subsystems
for the joy of hacking) would be inhibited more or less, of course.
But that likely doesn't matter to Peter, who is operating a cathedral
model in any case.

    Ian> the same basis as the author, and lower if the author has
    Ian> special rights to the code which I do not have.

Isn't that based on misperception?

The author always has special rights to the code you do not have.  The
author can always relicense under proprietary terms; I'm not sure how
you could write a free public license to fully alienate your copyright
while preserving the viral property, although I assume it's possible.
The GPL, however, does not (see the gloss at the end of section 7,
which makes this absolutely clear).

And license isn't all that matters.  I believe that Peter does not
require a copyright assignment.  That means that you can guarantee
that your code will be free in perpetuity, under the GPL, if you so
desire.  You do not have that right under FSF policy; you delegate it,
permanently, to the FSF.  I suspect that the FSF could relicense
assigned code under non-free terms,[1] although as long as Stallman
runs it I have absolute trust it will not, because he is a fanatic,
excuse me, a "man of great determination."

As for the spirit of the assignment, I don't know that I would trust a
future board of trustees not to sell my code to support the
development of more free software (see para 1e, last sentence).  As
the example of Cygnus shows, it is possible to do so while explicitly
encouraging customers to redistribute.  I have no problem with Cygnus
doing that with their own code, or in fact with code I contribute to
projects they maintain; I would be upset if the FSF did it with mine.

As for your own code, you don't have to contribute under the project's
usual license.  You can make whatever conditions you like on your
code; it's your copyright.  They can reject your contribution if they
like.

Certainly, if the author restricts the right to make money off the
code, and you think you could make money off your contribution, you
could negotiate a royalty.  But I don't really think that's what you
mean "by rights I don't have."  I think you just don't like people
taking advantage of monopoly power, since you would not do yourself.
I don't disagree you on that (if so), but I personally would and do
forgive grantors of "sufficiently free" licenses for exercising some
monopoly power.

    Ian> If I were to contribute to Ghostscript (which is unlikely
    Ian> simply because I rarely use it) I would be concerned that my
    Ian> patch would be non-free and effectively hidden for some time.

You, too, are subject to FUD?[2]  :-(

Currently, I believe that the Ghostscript code base is publically
available in regularly released betas.  It is however only announced
to a selected group of beta testers AFAIK.  This is precisely the same
policy that the FSF has---those in the know can get relatively current
code.  I prefer projects that make the CVS tree available and have
open beta lists, but betas every couple of weeks are pretty good.

Then read the license, admittedly it's non-free.  But "effectively
hidden"?  That's FUD[3]; in plain English, "effectively hidden" means
"can't be studied and applied to anything," and that's just not true.
Anybody can do anything they want with Ghostscript, except that if
their use of Ghostscript constitutes value-added to a commercial
product, they must negotiate with Aladdin (actually Artifex, I guess).

    Ian> I could distribute it separately, of course, but that would
    Ian> be awkward.  You say that Peter does distribute GPL patches
    Ian> along with the source code, but that too seems awkward for

"Freedom is bought by the paperwork of true patriots."  :-)

But that's the GPL.  Not Peter's problem.  You want to save
awkwardness, dual license the code at time of contribution.  I don't
think Peter would have a problem with that, and surely it's legally
valid; of course Larry Wall does exactly that with Perl.  You could
even add a required line to the header that "this code is also
available under GPL."

I can't see any problem with that, from your point of view; as long as 
you retain the copyright, Peter is not exempt from the viral clause in 
the AFPL, so he can't "take it private" as would be possible with an
XFree86-style license.

Still, you may not want to.  The point is that when I first realized
that AFPL wasn't free, I read the thing carefully.  I decided I could
live with it.  Of course, my standards are obviously as lax as a
spammer's, I've publically admitting contributing code to a
commercial, open-only-where-obfuscating-source-would-be-inconvenient,
project.

So I know there are people who are religious about freedom of other
people's software (as opposed to insisting that their own code be
free).  I just haven't hacked with any of them, I've only observed
them on mailing lists.  Your sample is probably biased in the opposite
direction.

(Granted, all of this would be easier if one license fit all.  Hell,
let's get rid of all this crap, and the last 8 Commandments, too.
Isn't "Love your brother" enough?)

    Ian> all concerned.  So the licensing issues would indeed
    Ian> discourage me from even starting to contribute.

Your logic is impeccable, and I cannot say that "most" people don't
think that way.  But from introspection and observing the people who I
know well enough to see them "thinking about contributing," I find
they hack on a program because they use it, or because it has
incredible hack value.  This hacking happens naturally if the program
is source-accompanied, as all GPL programs and Ghostscript and Mozilla
are.  Then they usually mail off the patch.


Footnotes:
[1]  Paragraph 4 of my copy of assign.future is pretty strong, but
retaining copyright would be stronger.  I am not a lawyer, but since
assign.future is assigning copyright, it looks to me like the FSF
could change change the terms to say AFPL or XFree86 (probably not
XF86, para 4 is very viral) under para 4.  (If AFPL, it would _not_
permit the FSF to charge royalties as that is explicitly
forbidden---but the software would no longer be free.)  If I am
correct, this is a bug, not a conspiracy, of course.  (I imagine the
paragraph is written as it is so that the FSF can license the code
under the current version of the GPL without being bound by this
paragraph---it's not just an oversight.)  I imagine one could write
one's own version requiring distribution under a specific version of
the GPL, and it would be legally valid, but the FSF might not accept
it, because it bind any program it was a part of to that version.  As
long as we're arguing about "willies," there's mine.

[2]  Please note, I do not assume that FUD itself is the product of
malice, although "spreading FUD intentionally" is.

[3]  Ian is obviously _not_ _spreading_ FUD; he is simply telling how
he sees it, and explaining that that would inhibit him from
contributing.  This kind of FUD is due not to malice, but transactions
cost, that is, the cost of studying all the different kinds of
licenses to decide whether you like them or not.

-- 
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."