Notes on a license how-to

Sun Aug 1 03:36:33 UTC 1999

Hello all;

> I got to thinking some about the license how-to thing. I 
> *do* believe       that a guide to selecting licenses 
> *would* be useful.

It's a reasonable thing to look at. As I've said before:
there's no reason why hackers should *have* to be
lawyers too. Of course, some of us enjoy the fiddly
grey technicalities that are the very soul of the Law,
as this list demonstrates. But I doubt that all
hackers would.

> I was planning on writing that document.

Good to see.

>  The following is the table of contents I thought it 
> should have, as I wrote it two days ago:

Two days ago?

> 1 Introduction
>    Just stating the reasons for writing the HOWTO and some

> other metainfo.

There is a standard, generally accepted format for
HOW-TOs which is expected by the LDP. I note that
metainfo is usually top of most HOW-TOs (whereas
I would have put them at the bottom ... oh well ...
hackers thinking that readers are computers :).

Alas, I do not know sweet buckley about SGML or
the LinuxDoc/Thingamajig DTD that is used. 

>     Stating that the author personally preffers to use GPL

> but tried to be completely unbiased and objective in this 
> document.

Fair enough.

> 2 What is free software?
>    This section attempts to define free software. Being 
> gratis and being free are different things.  The typical 
> stuff.

I don't think this absolutely necessary. Might be better
to include "more information" links right up the top in
the intro, along the lines of "if you are a suit or
lawyer unfamiliar with the history, philosophy or
general hackishness of Free Software and Open source,
press 2 now ..."

A HOW-TO is (IMHO!) *meant* to be a pared-down source
of information. It presents a set of information
aimed at informing the reader on how to achieve no
more than a very small handful of goals (connect to
the net, set up printing, etc).

I think we need to avoid bloat and vision erosion
by asking ourselves: "What *exactly* does a License
HOW-TO do?". And I venture the opinion that it
might well be that a License HOW-TO would be a
sharp, concise guide to the issues of licensing
to openness/freedom and to the licenses themselves.

> 2.1 Debian Free Software Guidelines
>     Just a short mention of DFSG.  Links provided to
> Debian's web site.

Again, this can be moved into an introduction or just
cut out altogether.

> 2.2 Open Source Initiative
<snip>
> 2.3 Free Software Foundation
<snip>

A sure way to attract the licking toungues of flame,
I suspect ... again, these might be better as references
than as entire subjects. Remember, we are striving
to assist hackers chose the ideal license for their
code. We can partially assume that they are aware of
the ideological landscape of the hacker world. If they
are not, some carefully-selected references will
enlighten them. This is the web - think reference,
not replication.

> 2.4 Freeware and Public Domain software
>    Mentioning how being freeware and public domain is not 
> the same as being free.

This can be folded into a larger section on the legal
underpinnings of OSS licenses (into OSS I fold Free
Software from herein, apologies to purists). The FSF
has some excellent (if somewhat GPL-centric) material
on the many *wares and how they relate to Stallmanist
capital-F Free Software.

> 2.5 Why Free Software?
>     Just a short section explaining both the ethical and 
> practical reasons why free software is superior.  Links to

> The Cathedral and the Bazaar, The Magic Cauldron and 
> similar essays (send me suggestions).

Again, cull this and fold a link or two into the intro.
I note in passing that I will soon publish an essay
that does a very rough quantitative examination of
ESR's largely qualitative claim.

> 3   Free Software Licenses
>    This section attempts to explain popular licenses.  It 
> also provides examples of the most popular programs that 
> use a given license.

Yes ... no problems with introducing the licenses. But
remember that *all* of the licenses are written with
one eye on a particular strain of hacker ideology, and
another one on The Law. Really, every license that is
Gee-It's-Free-But-Just-Not-Exactly-The-Same-And-Almost-
Wholly-Incompatible-With-Uhm-Er-The-GPL-Say has just
found a combination of ideology and legal laxity or
strength that suited the author(s).

That means it may be worth introducing these things
briefly. Ideology can be referenced out, as I have
already noted. There exists hacker ideology in
volumes that would level several mid-sized forests
in its printing.

But the legal stuff is trickier, and less easy to
find material on. A License HOW-TO might be just
the document of most use in defining these legal
issues and explaining them to the Need-To-Know
Hacker.

As an aside, a matrix-style classification of licenses
may be more effective than multiple lists. Put on one
axis Ideology (from "Free, dammit" to "Microsoft") and on
the other, Legal Principles (Copyleft to EULA). It's
not quantitative, but it might give a feel for the
licensing landscape.

> 3.1 GNU General Public License
>    Explains the GPL.  After that, mentions common arguments

> used  against it: linking with non GPL software, is it really

> freedom, it is a virus, it does not define derivative works

> clearly (or: will it hold in court?).
> 3.3 BSDish licenses
<snip>
> 3.4 Other licenses

etc.

On selecting and presenting licenses, there are several
things we may wish to consider.

One is formatting. I am all for a standard way to
present each license within the HOW-TO. It might run
thus:

* Name
* Author, Creator, Maintainer
* Qualitative classification (matrix?)
* A history, no more than 200 words or so
* An outline of its ideological tenets
* An outline of its legal tenets
* Legal implications of using the license ...
    * on opening closed code
    * on starting an open project
    * in conjunction with closed code
* inter-license compatability
* legal fortitude (will it hold in court? what
  issues weaken its legal standing?)
* pros and cons (ideo/legal/monetary)
    * for a Freedomware/OSS hacker
    * for a large project
    * for a commercial enterprise
* some well-known projects using the license
* contacts and links

> What other licenses should we include?

That's the other thing. If we follow a standard format
for licenses, then I see no reason why more than one
person cannot contribute to the license listings. It
would only be polite to ask the creators of the licenses
to help write up each section!

There are dozens of licenses. I see no criteria that
could fairly and reasonably select which licenses make
it in, and which do not. If somebody wants to add a
license to the HOW-TO, they may, but under obvious
editorial auspices (ie: get out your Bias Attenna).

> 4   Comercial free software
>    A common topic of discussion.  Using/developing/supporting

> free software for monetary gain.

"And Lo, unto them THE HACKER spake, saying 'let it be
linked unto the OSI', and it was so." -- from the
Testament 2.0, Raymond 32:12.

> 4.1 Netscape Public License
<snip>
> 4.2 Apple Public Source License

With the other licenses?

> 4.3 Comercial software around the GPL
>     Mentioning the classical cases such a Linux distributions

> or Cygnus.

It think it's unfair - and, yes, biased - to say "comm. soft
around the *GPL*". What about commercial software around the
BSDL? MIT/X? MPL? Artistic? Besides, I don't think a list
of software tells the hacker how to pick a license; and this
information can be included in each licenses' info.

> 5.  Practical considerations
>     Just some suggestions for people choosing licenses. The

> conclusions of the HOWTO. What else would you add here?

Perhaps a check-list of things to consider would be
helpful here, covering ideological, legal and monetary
items. Perhaps someone could run up a little perl
script that computes answers and spits out a "most likely
match" license.

> 5.1 Problems with the GPL
>    Just a short note so people avoid problems with it. This

> could mention the situation with KDE.

In the GPL's info. Let there be equality amongst licenses
in their presentation. If the License HOW-TO so much as
farts in the direction of any one of the licenses, the
accusations of bias will bury it.

> 5.2 Don't create your own license
>     Just asking people to try to use an already existing 
> license instead of creating their own.

We can fold this into the "choosing a license" section, and
onto the checklist. And, in keeping with the even-handedness
that we'd all like, we can only present pros and cons and
consensually agreed 'facts'. Exhortation is apt to rub
hackers the wrong way (which is why *I* am *so* unpopular :).

> That is it. Did I leave any important things out?

You did a good first run at it, better than mine, I think.
I may have been a harsh, critical arsehole, but that's
only because this is my third pass at the issue and things
are becoming clearer. I'm an iterative thinker, at heart.

>      * "Ranking": popularity in terms of percentage
> representation in  licenses
>
> I believe this would be hard to measure.
<snip>
> In my opinion, the HOWTO should not include such information.
I 
> believe it would be very interesting to have it, but I think
it 
> belongs more to independent studies than to the License HOWTO.

And, on reflection, I agree with you.

> Is someone currently working on the HOWTO? I will continue

> working on it unless someone else is doing it already. Please

> let me know.

Those are my thoughts. I don't have the time to pen the
thing myself, but I am happy to bitch and criticise
anything anyone else writes. As you may have noted, I
am keenly interested in the content and structure of the
HOW-TO, so I will be happy to debug (read: bitch and
carp about) either if they are forthcoming. And so,
I suspect, would this list.

> Alejo.

JC.

-----
Sent using MailStart.com ( http://MailStart.Com/welcome.html )
The FREE way to access your mailbox via any web browser, anywhere!