Subject: Re: Exploring the limits of free software
From: "Karsten M. Self" <>
Date: Fri, 21 May 1999 13:43:38 -0700

Brian Bartholomew wrote:

> Now suppose I make one or more of the following incremental changes to
> those business practices:
>         tell customers bitcopies do not inherit brand properties

I'm assuming, FWIW, a GNU GPL license (which is appropriate for much of
Cygnus's software, IIRC) in most of my responses.  Other licensing
arrangements either allow for proprietization of free software (e.g.: 
BSD, Artistic), or retain some degree of proprietary control over
software (e.g.:  NPL/MozPL, Sun's quasi-PL, JikesPL (IBM)).

What specific brand properties do you have in mind?  Vendor support,
warrantee, ancillary services?  This would be consistant with existing
practice from, say, Red Hat, which does not support even its own
distribution when it is sold by third parties such as MacMillan (Sams
Publishing), Mandrake, etc.  
>         do not put anything up for ftp gratis

Straw man.  So long as _someone_ can, it doesn't matter _who_ does or
does not provide source.  Moreover, compiance with GPL does not require
posting sources to an FTP site, it merely requires sources be available
on request (GNU GPL 3(b) and 3(c)).
>         pay customers a bounty not to redistribute

You're now entering into market mechanisms territory.  If the bounty is
less than a customer might receive from its own redistributions, then it
will be insufficient to deter redistribution.  Cygnus (or any other free
software company) would essentially be competing in a market by paying
down its own profits in an effort to restrict redistribution of its
code.  There is a marked limit beyond which this is not a viable

Also, FWIW, the GNU GPL specifically allows any recipient of the
software to redistribute, and allows this redistribution itself to be
compensated (GNU GPL 1).  The GPL distinguishes between price for the
service of providing software, and price of the software itself

>         charge $10K, $100K, USL Unix source license price, $1M, $10M,
>         Microsoft Windows source license price, $100M, $1B

See above.  You're now establishing a market in which other entrants
could consider not only redistribution, but their own independent
development efforts, financed by their own market pricing of $<price> -
$<epsilon>, where <epsilon> is arbitrarily small, but sufficient to
differentiate product on a cost basis.
>         tie free licensed products to proprietary licensed ones, and
>         intermix them throughly on the distribution

Void argument without specifics of how you would accomplish this in such
a manner as not to violate sections 2 and 4 of the GNU GPL

>         make it confusing enough to need documentation to use

Market pressures, again -- this creates incentive to produce a more
comprehensible, user-friendly fork.
>         make it unreliable enough to need support to use

See above.   Note that OSS is first and foremost excellent at providing
technically solid, reliable, dependable software.  These are the itches
begging to be scratched first.  Likely outcome:  development forks to 
the most reliable new code maintainer.
>         allow improvements in old files to be proprietary

Not under GPL, unless the improvements are made by the original author
of the work, and if the author is the author of the entire work.  There
is nothing under GPL to deny an author to license a work under any terms
s/he wishes, because such permissions are not required under copyright
law as it currently exists (17 U.S.C. in the United States, Berne
Convention as applied in other nations).  However, where multiple
authors hold joint copyright on a work, my understanding of the law
(IANAL) is that the permission of all authors is required to make a
change in licensing arrangements.
>         withhold releasing improvements gratis for 1 year, 2 years, 5
>         years, 17 years, or until the copyright expires

Not under GPL, to the extent that recipients of software are forbidden
from releasing enhancements.

Note however that this is what the Alladin License provides for, however
this is software which is released (by the author) initially under the
Alladin Public License, then relicenced under the GNU GPL.  One term for
such delay of full freedoms for software is "Delayed Public Licensing"
(DPL) -- more a concept than a specific license.  It allows the author a
period of time in which proprietary advantage (and revenues) can be
collected, while also turning the work into the public sphere in a
relatively brief time.

I suspect that the length of the delay is largely a function of the
nature of the program, its user base, and other market characteristics. 
Specialization, differentiation, value, small user base, non-technical
user base, complexity, and proprietary technology (ie: patents) will
favor less open code.  Again, market pressures will tend to restrict the
degree to which such a DPL might actually delay the opening of code.

The pressures I see are the ability of other parties to ship versions of
the same product incorporating changes which improve the product.  Too
slow a release cycle loses vs. more open code from an evolutionary
> When does it stop being free software?

When the following conditions are not met:

   - The freedom to run the program, for any purpose (freedom 0). 
   - The freedom to study how the program works, and adapt it to 
     your needs (freedom 1). 
   - The freedom to redistribute copies so you can help your 
     neighbor (freedom 2). 
   - The freedom to improve the program, and release your improvements 
     to the public, so that the whole community benefits. (freedom 3). 


It is possible for different versions of a program to be free and
non-free at the same time, depending on licensing restrictions. 
However, a given version, under its specific license terms, is either
free or non-free.

> A member of the League for Programming Freedom (LPF)
> -------------------------------------------------------------------------------
> Brian Bartholomew - - - Working Version, Cambridge, MA

I suggest generally that Brian is continuing to confuse free (beer) with
free (speach), and fails to differentiate source code with other
software-related services including support, documentation, and
training.  In a world where software itself is freely (speach)
distributable, development costs must be recouped either by direct
benefit (user-based development), by sale of ancilary products and
services, or by sponsored development (gov't funded, academic,
consortium, user-group sponsorship).  Decoupling software distribution
from revenue generation does not majikly remove production costs from
the equation.

Karsten M. Self (

    What part of "Gestalt" don't you understand?
    Welchen Teil von "Gestalt" verstehen Sie nicht?

  SAS for Linux: