[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DFSG2: Morality and advertising clause?



On Fri, Dec 04, 1998 at 07:42:42PM -0500, Raul Miller wrote:
> Hi,
> 
> I have a vauge recollection of seeing posts that said that there are moral
> or ethical reasons to not drop BSD with advertising clause from the DFSG.
> Or maybe they were arguments that partial permission for software such
> a clause (a grandfather clause, with or without a timeout) was immoral?

Let me see if I can both explain it and test my understanding.

The premise of this discussion is what is 'free' software.  Is
software free if its use requires the display of a slash screen?  Is
software free if it can only be used in non-commercial endeavors?  Is
software free when we can ship it only in source code form?  Is
software free when we can ship binaries only when we ship the original
source and a separate patch?  When is license a nuisance and when does
it inhibit freedom?  

The indent of the GPL, on which the DFSG was drawn, is to prevent
people from turning something that was released as free into something
where the user cannot access the source and maintain freedom to use
and reuse that software.  The difficulty has been how to write a
license that protects the author's work from becoming something
non-free.  It is desirable to have projects such as egcs spawn from
the gcc project as long as the freedom to use the derivative projects
is not inhibited.  A better example is the original gcc project that
has benefited profoundly free software.  Companies such as NeXT and
Sony use it for their commercial ventures.  Every change they make to
the source *must* be made available under the same free license as the
original.  The practical implication is that their changes have
returned to the original project to fix bugs and add features.

The disagreement about the advertising and patch clauses has been what
do we, as members of Debian, feel is appropriate licensing for the
software we release as free.  GPL'd code is easy to categorize.  TeX,
for example, is more difficult.  BSD derived code, too, stands in a
less comfortable position than GPL'd code.

Let's take a non-software example.  You are given a shirt made by
Acme.  Acme give you the shirt for free, but requires that you wear
their name in large print letters on the front and back of the shirt.
Making a shirt like this is very difficult because it is both cool in
the summer and warm in the winter.  Thus it is desirable to have this
free shirt, to benefit from the clever work of Acme.  Some companies
sell their shirts, but Acme gives theirs freely.  Over the years,
plenty of Acme shirt wearers have benefited from it's fine features
and have added piping, a pocket, and a draw-strings to keep cold air
out.  While some people don't care about being a billboard for Acme,
not everyone feels that way.  We all like the shirt and would like to
remove the advertising blemish.

I am indifferent right now to the BSD clause, but lets say that every
library I link with requires some advertisement.  I now have a
significant burden, dozens of lines crediting these authors, and the
nuisance of being responsible for adhering to all of the other
egotistical requirements written into their licenses.

We have the opportunity to propose to our community what we feel are
appropriate standards for free-ness.  Advertising clauses can be
construed as Hassleware.  So, we may decide to keep the ones already
accepted because we choose to live with the decisions of the past
without disrupting the flow of our software.  This is where the dated
DFSG clauses come in.  We may decide to write more strict standards of
acceptance and drop (or move) everything that fails to meet our
guidlines into non-free.  This would be an abrupt, but consistent
methodology.

Let's look at the ramifications.  If we decide that only strict GPL
and public domain software is free, we cannot ship things such as TeX
and other things deemed crucial to our distribution.  Allegedly, FSF
accepts TeX as free even though its license has some restrictions
about how the source is distributed.  As we loosen our requirements,
we permit authors to add requirements that may tend to inhibit the
freedom of use that we all desire.  If change our guidelines now,
accepting all that was accepted in the past but make tighter
requirements for all future packages, we encourage anyone interested
in being distributed with one of the best GNU/Linux distributions to
release their code with the freedom we all appreciate.

This issue is not so simple.  It hinges on our perception of the
direction of free software.  It has begun to receive much attention in
the press as traditionally commercial operations release their
software as a form freeware.  I believe that those who wish to rewrite
the DFSG are concerned that our definition be clear so that we don't
fall to the fate that 'organic' has for produce.  Where 'organic' is
being legislated into a meaningless tag the way that 'natural' and
'healthy' have been, 'free' has the potential to become a vague term.
Even where we stand today, we do not agree what constitutes free.  Or,
what is free enough?  I may not approve of the advertising clauses,
but I may also be unwilling to stop wearing Acme shirts until
something comes along with the same features, the same price, and
lacks the grafiti.

> Could someone please describe the underlying logic of these reasons?
> I seem to have a bad case of "I just don't get it".
>
> Also, if there are any arguments against dropping such software other than
> "that software is important to us" [which seems to be a purely pragmatic
> argument -- lacking in any moral substance], could someone also please
> describe those reasons?

HTH.

Cheers.


Reply to: