Manoj Srivastava <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
