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

Re: {SPAM} Re: Anton's amendment



Manoj Srivastava <srivasta@debian.org> writes:

>         I have been thinking about this (originally brought up by
>  Russ). I have also been re-reading the SC/DFSG, and the time they
>  were written. I also started with the idea that the SC/DFSG are  to
>  be considered to be consistent, unless strong evidence exists to the
>  contrary.

>         So, the DFSG are what they say they are --
>  guidelines. However, some licenses were deemed by the project to be
>  de-facto free, even if they do contravene some of the guidelines,
>  hence explicitly naming the GPL and the bsd  licenses. The naming
>  them specifically removes the requirement that they meet all the
>  guidelines.

Admittedly, I'm somewhat new to these parts, but I've been following this
discussion for long enough that I'm pretty uncomfortable with this
interpretation.  It doesn't seem to match what other people have said
about the beginnings of the DFSG and feels contrary to the language of the
DFSG.  The DFSG specifically calls those licenses *examples*, not
exceptions, which isn't the language that I'd expect to be used if this
was the case.

I'd be a lot more comfortable with an interpretation that says that
anything in the GPLv2 or four-clause BSD (the Artistic License has the
problem of not being clearly written and is hard to use for comparison
purposes) that appears to contradict the DFSG indicates that the DFSG
aren't being applied in the manner that they were intended to be applied.

Unfortunately, that does leave us with this vague notion of acceptable
limitations on modification, which I'm not horribly comfortable with.
It's very open to interpretation and feels likely to be an endless source
of argument.  But I don't see a way out of that given what the DFSG says
right now.  Reading it to imply that the GPL is not otherwise free but is
accepted as a special exception seems as tortured to me as reading it to
say that a license is free provided that *some* modifications are
permitted.

I'd rather try to develop a better definition of what would be an
acceptable restriction on modification.  Since the GPL is our example,
let's start there.  The GPL interactive execution clause has the following
properties:

 * The exact form of the notification is not specified by the license.
   The license allows one to translate it, rephrase it, move where it's
   displayed, make it a dialog box instead of standard output, etc.

 * The restriction is solely on the functionality of the code, not on the
   form of the code.  In other words, every part of the implementation of
   the interactive notice may be freely modified provided that some notice
   is still displayed.

 * The restriction is specifically limited to a case where displaying such
   information does not cause harm.  If the modified program does not read
   commands interactively when run, you're no longer required to print out
   the notice.

Note that invarient sections in the GFDL are more restrictive than clause
2c of the GPL in every respect I list above.  The exact form of the text
is fixed, the ability to modify the source that produces the invarient
sections is unclear (to me at least) from the license, and the invarient
sections must be retained no matter what the derivative work looks like,
even if only a portion is being excerpted into a space-limited environment
(the infamous coffee mug example).

I think this is a stronger argument than deciding that the GPL isn't
really DFSG-free but is just grandfathered in.

To me, this whole discussion is over exactly what "allow" and
"modifications" mean in:

    The license must allow modifications and derived works, and must allow
    them to be distributed under the same terms as the license of the
    original software.

The example of the GPL argues that this means some requirements can be put
on the form of those modifications, but those requirements should not be
so strict as to enforce a particular implementation strategy, method of
presentation, interface, or retention of code that is unsuitable for a new
purpose.  I think the GFDL is not DFSG-free because it goes far farther
than the GPL in this area.

However, at this point we're unfortunately way off into grey areas that,
at least to me, are not explicit in the text of the DFSG.  Allowing the
GFDL in main seems like a huge stretch to me, and I'm not really arguing
that it shouldn't require a 3:1 majority (it would certainly be a
significant change to what I thought the DFSG was supposed to mean), but I
can at least see the argument.

>         Besides, not removing a copyright notification already present
>  is a different kettle of fish from invariant sections.

I'm not sure that I agree with this.  So far as I know, there is no legal
requirement that copyright and warranty disclaimers be presented in
interactive programs.  They must accompany the work in some legal
jurisdictions, but the GPL goes much farther than that.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Reply to: