Free software licensing myths (was Re: [linux-elitists] The breadth of SCO's claims)

Rick Moen
Sat Jul 5 14:16:49 PDT 2003

Quoting Jon Carnes (

> I found this site to be very helpful:

I have not.  I found it to be a grievous disappointment, in fact.  Let's
look briefly at one of the primary documents on the site[1], notes from
a lecture the author delivered at Atlanta Linux Showcase 1998,
"Evaluation of Public Software Licenses":

Quotations that follow are from that essay.  (I've corrected the author's
use of non-standard Microsoft ASCII, at various points.)

[Several meandering, platitudinous paragraphs, followed by:]

> Today we're going to take a wide look at the free software licenses
> and ask whether they are legal, spend some time on the GNU General
> Public license, and then compare commercial and non-commercial modes
> of licensing.

By "legal", he appears to mean legally enforceable.

There is no such thing as "commercial and non-commercial modes of
licensing":  He appears to be trying and failing to find the terms
proprietary and open-source (AKA free).  

(Of course, my point is that he is _not_ trying to find an appropriate
term, because he is at sea concerning basic concepts:  Confusion between
licence category and commercial status is of course the traditional
Bridge of Asses that this author, like so many others, cannot figure out
how to cross.)

> The truth is that free licenses are enforceable only under the current
> copyright laws.

This is correct.  However, he contradicts it later on.

> In any case, a well-written free license should have a clause like No.
> 4 in the GNU GPL, which says that violating the license terms voids
> the license, leaving further distribution, etc.  open to copyright
> violation enforcement.

Misses the point that such is the case by default, absent such a clause.
(GPLv2 clause 4 simply emphasises the point -- which is certainly not a 
bad idea, but shouldn't be strictly necessary.)

> But software developers and vendors need to remember that only a
> copyright holder who has code in the project in question has standing
> to bring a suit, and that although their work is considered
> copyrighted with no action on their part, the copyright must be
> registered before a suit can be brought.

The latter assertion is simply untrue.  Without registration (with the
LoC, in the USA), legal remedies are merely limited.

> A greater problem with the free licenses and their enforceability is
> that of binding persons down the distribution chain from the original
> parties to the license.  This is an area in which contract law, which
> binds only the actual parties to the contract, borrows from real
> estate law, which binds successive parties who were not part of the
> original agreement.

This is (1) false, and (2) contradictory to his earlier assertion 
(which _was_ correct) that copyright law alone gives force to licences
such as the GNU GPLv2.

If the latest RIAA wares fall off a truck in front of your house, you
have no contract with that recording studio, yet your rights to use the
goods that fell in your yard are restricted -- by the Copyright Act (or
your nation's local equivalent).

The particular pity of the author blowing this question is that there
are indeed significant questions whether copyright law can and will
support a copyright holder's grant of additional rights (ones otherwise
reserved to him) conditioned on assuming related obligations.  The
matter hasn't been adjudicated.  Judges might eventually rule "Sorry,
copyright law just doesn't work that way."  If so, the code instances in
question would very likely revert to the statutory bundle of rights
impliedly conveyed to any lawful recipient of a copyright-covered work
-- which does not include the right of redistribution or creation of
derivative works.  (One might regard this as a sort of legal
failsafing mode.)  The copyright holders would then be free to issue
separate codebase instances under some other terms thought to be less
prone to whatever legal defect the hypothetical court case points to.

> Free licenses might appear to be working satisfactorily right now,
> while there is not much interest in the products, and everyone who
> uses them is in the potlatch culture....

Ideological rubbish.

> You probably remember the man who trademarked the Linux name; you have
> also seen the abortive Linux Standards Association

The problem is that _neither_ of these examples is the least bit
relevant to copyright law and licensing.  He _could_ have cited relevant
examples, such as the MySQL AB lawsuit, but missed the opportunity
because (again, all too typically) he lumps trademark law and copyright
law together, as if they were the same problem.

> The key requirement is that the user pass on these rights, unimpaired,
> to other users.  This automatically means that any changes passed on
> by the user must be distributed in source code form as well.

Well, no, they must be _available_ in the preferred ("source") form for

> If passing along the source code is an inconvenience, you don't have
> to do it with every copy, but you must say with every copy that source
> code is available, and tell how to obtain it.

This is of course true only if the distributor is using the clause 3b
form of source access, not the other two.

> The whole process is commonly called "copylefting;" anyone can use the
> General Public License, and a copy of it must go with each copy of the
> distributed program. 

That is of course _not_ the meaning of the term copylefting.

> If the developer were to place the program in the public domain, free
> for all comers, anyone would be free to take it, modify it, and
> copyright and sell the result, thus returning the software to
> proprietary ways.

It is not at all clear that, as a matter of law, anyone can through an
act of will "place in the public domain" a creative work.  A responsible
commentator would warn people of this fact.

> Proprietary products that simply link to GPL software are allowed to
> remain proprietary; only derivative products need be placed under the
> GPL.

This sentence is fuzzy enough that it's only _probably_ wrong, as
stated.  To absolutely determine whether it's wrong would require that
the author clarify the first half of the sentence.

> The GPL notice must be displayed on start-up.

This is not generally true at all.  Derivative works that the recipient
creates, _if_ "the modified program normally reads commands interactively
when run" must, per clause 2c, display an appropriate copyright notice, 
disclaimer of warranty, and notice of where the user can view a copy of 
the covering licence.  This requirement is waived if the original
program the recipient modified didn't display such an announcement.

> There are other free licenses besides the GPL; these include the Open
> Group X License....

There is no "Open Group X License".  He probably means the MIT / X
Consortium Licence.

> There are other free licenses besides the GPL; these include the Open
> Group X License and the other BSD-style licenses, the Perl Artistic
> License (none insists on source code distribution).

This is untrue, as the author is apparently unaware of one of the
most-important licences of the last decade, the Mozilla Public Licence.
(Ironically, he then discusses that licence, later on.)  That's not to
mention the LGPL.

> There is a loophole for commercial (i.e., proprietary) software: 

"Commercial" and "proprietary" are, again, not synonymous.

> The big issue surrounding the GPL is the "tainting" ("viral" or
> "contaminating") effect, which is actually a liberating effect.  The
> principle is that any code combined with GPL 'd code must be issued
> under the GPL.....

This is of course false, and is one of the most common misapprehsions
about open-source licensing.  

The derivative work created thereby is in a state of licence conflict.
If distributed, that act of distribution causes the distributing party
to commit the tort of copyright infringement on the GPLed work he used.
Various remedies are possible, and the distributor may be liable for
damages (not to mention cessation of the violation), if the matter comes
up as a matter of civil dispute, but there is no legal precedent
whatsoever for mandated licensing of the distributor's proprietary code
under the GNU GPLv2 or any other terms not of the owner's choosing.

> The BSD license offers a counter to the anti-proprietary effects of
> the GPL.  As to what constitutes the BSD license, forget the
> "advertising/copyright line requirement; that condition is
> practically obsolete nowadays.

In far fewer words, he could have _accurately_ described the 2-clause
and 3-clause variants.

> Thus derivative works forbidden by the GPL are allowed by the BSD
> license.

There are no derivative works that the GNU GPL "forbids".  There are
obligations that apply to derivative works _when distributed_.  If the
distributor cannot meet those obligations, then the GNU GPLv2 doesn't
grant him distribution rights.  Distribution without that permission 
them becomes the tort of copyright violation, subject to claims under
civil law, etc.

> You can't put GPL code into a BSD binary

As noted, this is absolutely false.

[Discussion of Qt licensing dates from October 1998, prior to the QPL.]

> Troll Tech says you can distribute your free application under the BSD
> as well, but this is not correct either, since the BSD-type license
> allows you to distribute your code in binary-only form, clearly not
> allowed by the Qt Free Edition License.

The author is confused:  A BSDed application linked to then-proprietary 
Qt would not be seeking to apply BSD terms to Qt.

> The MPL divides a software work into files, which are separated into
> a) the Open Source part (called "Covered") and b) anything the user
> adds.  The arrangement allows the developer to add his own files and
> distribute them with the Covered files, provided he does not modify
> the Covered files.  If he does modify the Covered files, then he must
> distribute those modifid files under Open Source MPL rules.

This of course contradicts his earlier claim that only the GPLv2
requires source code distribution.

And then the author closes with a long, fuzzy discussion of codebase
forking that strikes me as just about 100% content-free.

Overall, unfortunately, this essay like so many others tends to produce
a subtractive effect on the reader's understanding:  Before, you
presumably were aware that you didn't know much about licensing.  After,
you know things that are not the case.

There are places to read substantive analyses of licensing.  In my view,
the Stromian Technologies site most definitely isn't one of them.


[1] Mostly, the site wants to sell you the author's _book _on the subject.
My mind scarce has the courage to contemplate that prospect.

Cheers,             "Don't use Outlook.  Outlook is really just a security
Rick Moen            hole with a small e-mail client attached to it."                        -- Brian Trosko in r.a.sf.w.r-j

More information about the linux-elitists mailing list