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

Re: Draft new DFSG



Ian Jackson <ian@chiark.greenend.org.uk> writes:

<SNIP>
> > All right, it's a Debian version of the Communications Decency Act!  As with
> > the original CDA in the U.S., you will probably find that "offensive" is way
> > too vague to enforce.
> 
> You don't understand.  All that that sentence does is make a program
> not DFSG-free if it says things like
> 
>  You may only distribute a port of this program to a Microsoft
>  operating system if you place prominent notices stating that Bill
>  Gates is an evil bastard.
> 
> Whereas the purely factual
> 
>  You may only distribute a port of this program to a Microsoft
>  operating system if you place prominent notices stating that the
>  original authors strongly disapprove of Bill Gates.
> 
> is OK.
>
> Or do you think a program whose licence requires you to place
> offensive notices should be DFSG-free ?

How about then saying that the license may require only notices of
objective fact?  Would that avoid this problem?

<SNIP>
> Daniel Martin writes ("Re: Draft new DFSG"):
> > I'd suggest rephrasing point (2) to:
> >      (2) may not require that any such offer remain valid for more
> >          than 3 years
> > That still is a bit convoluted, but it seems slightly clearer - it
> > took me a little while to realize that point (2) as written does in
> > fact mean what it's intended to mean.
> 
> If you say just `may not require' then the fact that it may require a
> minimum validity at all is not stated, but implied.

Yeah; after looking at it in several different ways, I think that
something very close to what you'd proposed at first fits better:

  (2) may specify some minimum length of validity of the offer (though 
      not more than 3 years)

<SNIP>
> > I'd like to see this changed to:
> >   The licence may require modified versions or (versions distributed
> >   under a different license per (b) above) to be distributed under a
> >   different name or with a different version number, provided that this
> >   doesn't interfere with using the modified version as a replacement for
> >   the original.
> > 
> > This is so that a name change can be required if, for example, I take
> > some bit of code under a NPL-ish license (that is, free but entity XYZ 
> > can use the code for non-free stuff) and release a GPLed version.
> > (A license that allows stuff similar to this came up in an IRC
> > conversation about how TT might adjust the Qt license so that it could 
> > be GPL-compatible).
> 
> How about `the licence may require certain versions' ?  After all,
> there's no harm in a restriction like
> 
>  You may not call a port of this program to Windows `foobar'.

OK; but make sure that this clause doesn't override the ability to
take something and pass it on verbatim (i.e. same code and same
license) with the same name.

> > <BSD-ish advertising clause stuff>
> 
> This needs to be discussed.

Fair enough.

> > <SNIP>
> > > 4. Restrictions due to law
> > > 
> > > (a) If in a particular jurisdiction the distribution, modification or
> > > use of a work is restricted by law, then the work is not
> > > DFSG-free in that jurisdiction.
> > > 
> > > (b) It is still DFSG-free in other jurisdictions, provided that those
> > > who control (directly or indirectly) the work and the conditions under
> > > which it is distributed, do not have the power to lift the
> > > restrictions other than by changing the nature of the work, and
> > > express a desire that the legal restrictions be lifted.
> > 
> > I object to the phrase "express a desire that the legal restrictions
> > be lifted" - I'd like to consider xyz crypto package free even if the
> > author heartily approves of the US crypto restrictions because, for
> > example, they allow his country to have a booming software crypto
> > industry.
> 
> How about changing `and' to `or' and adding a requirement that they
> don't act inconsistently with the expressed desire ?
> 
> > > (c) In the case of restrictions due to patents, a work can in any case
> > > not be DFSG-free if those who control the work and the conditions
> > > under which it is distributed are software patent aggressors.
> > 
> > I _strongly_ object to this.  In fact, I can't think of any possible
> > way to rephrase it that will satisfy me.
> 
> Why do you object to it ?
> 
> Do you disagree with the Leage for Programming Freedom ?!

These can be both answered together - it seems that in these two
clauses we attempt to use the DFSG as a carrot and stick to effect
change other than a change in the licensing of a particular bit of
software.  I see both these issues (the issue of US crypto
restrictions - that being the majority of clause (b) - and the
"software patent agressors" issue) as orthogonal to software freedom
as far as it concerns software licences.

The basic principle is that I'm not going to blame a piece of software
for its author.  When discussing free software, a stance like the one
taken in your proposed DFSG becomes not only objectionable but also
untenable, since it is deliberately impossible to define who the
person is who controls the work.

Let's take an example:
Suppose Unisys releases some GIF-encoding and GIF-decoding algortihms
under the GPL and decrees that all programs using that code or a
derivative of it (and therefore covered by the GPL) are granted a
royalty-free license on their patent on LZW with regard to encoding
and decoding images.
Now, under this proposed DFSG, these bits of code couldn't be included 
in, say, the /usr/doc portion of some package that goes into main.  So 
far, so good.
Now suppose the gimp folks take note of these bits of code and
incorporate them into their library.  Under the proposed DFSG, the
gimp with gif support added this way would still be free, since none
of the gimp folks happens to own a controlling portion of the stock in 
Unisys.
Now what if I take the bits of code, find a way to optimize a loop
here or there, make the modifications and post them on my website.  Is 
this bit of code (as it appears on my website) DFSG free?  How much of 
a modification do I need to make to cause the bits I distribute to be
DFSG free?  Need I make any modification at all, or does the mere act
of redistributing the code make me the person who "controls" it in
some way?
Now one gets into the incredibly silly situation that this code is
non-free if it was downloaded from Unisys, but free if downloaded from 
somewhere outside Unisys.  Situations as ridiculous as these should
come only from outside laws (the absurd consequences of various laws
being already well documented); we shouldn't do things like this to
ourselves.

I would contend that it is impossible with free software to identify
with certainty who it is who controls the software - by definition,
anyone is free to redistribute the code, either in original form or
with modifications, and therefore anyone can become "those who control
the work".  (that is, forks can happen) Free software is not shackled
to an owner - the chains of intellectual property have been removed.

I would support some statement like this:
  A piece of software is non-free if its operation or distribution is
  covered by patents and it is not accompanied by a license to use
  those patents to the extent necessary to operate the software;
  furthermore, such a license must apply equally well to derivative
  versions of the software.  This clause applies only in jurisdictions
  which recognize the relevant patents as they apply to the software.

This clause is intended only to ensure that those rights granted in
the license (which take care of copyright problems) are not taken away 
by patent issues.  It does not, I believe, modify the concept of
freedom expressed in the DFSG; it only makes clear that the necessary
freedoms must be hampered by neither patent nor copyright.


Reply to: