Re: A radical approach to rewriting the DFSG
On Mon, May 31, 2004 at 04:33:47AM +0100, Henning Makholm wrote:
> I understand and respect your opinion. However, it seems likely that a
> GR to "update" the DFSG *will* be proposed by someone within the next
> handful (or two) of months. I think that if we are to update it at
> all, it deserves being done properly.
Another use of this is as another way to examine the DFSG: any case
where the result of a license evaluation under these guidelines (at
least after some more polishing) differs from one under the DFSG
is an interesting one to consider. ("What do we really want?")
> > I think it's a feature of the DFSG that it does not reference any
> > particular set of laws (copyright, patent, trademark).
>
> There is space in my draft to say something about patents. It'll
> probably end up referring back to the other sections, after specifying
> roughly that we're only interested in patents that are actively
> enforced and not obviously invalid.
What I'm suggesting is that the fundamental core of the guidelines
(which feels like part 3) not mention any of these. I'm not sure if
that's as important with this approach as it was with the DFSG, though.
> N. Acknowledgements in documentation
>
> The license for a free program may require that end-user
> documentation which accompanies the program contains a short
> acknowledgement that credits the author.
What about this?
5. Redistributions of any form whatsoever must retain the following
acknowledgment:
"This product includes the Zend Engine, freely available at
http://www.zend.com";
> > 4. j: "Specific exception for GPL #2(c)"
>
> > A note that this does not apply to verbatim statements may be appropriate.
>
> Hmm, for some kinds of clauses we accept verbatim statements, and for
> some we do not. They are all obnoxious anyway; is it really worth the
> extra complexity of the guidelines [1] to insist on preserving the
> freedom to edit exactly in the cases where we happen to have it now?
I'm just looking for the 4j exception to be limited more closely to what
is needed for the GPL. I can't think of any licenses that require a verbatim
statement on startup, but 4j seems to allow it.
(Of course, I'm being picky on this because I personally think that restriction
is onerous--as I've argued in the past--and that we should be careful to
prevent this boundary case from being nudged any further.)
> Perhaps a compromise could be to say that all that can be required is
> a *short* notice?
Since the clause already makes reference to the GPL (perhaps it should
say "GPL 2.0"), perhaps "... most ordinary way, under the terms of
GPL 2.0 #2(c)"? That would explicitly say that the restriction can not
be more restrictive than what the GPL requires.
E. ... "The license may require derived works to carry notices that make
it clear that they are not the original."
Should this also allow requiring dating, which GPL #2(a) requires?
Also, I believe GPL2a does not prohibit these notices from being removed
in the future, which is important. Assuming the "revision control logs
count as carried notices" interpretation is valid, if I can't remove
the notices, then I'd have to copy those notices into the file for source
snapshots. However, allowing removal doesn't seem to be required by 4E.
... "The license may require derived works to carry a different name or
version number from the original work."
Here's a sticky one:
5. Products derived from this software may not be called "Apache",
nor may "Apache" appear in their name, without prior written
permission of the Apache Software Foundation.
This is definitely overreaching; it prohibits code reuse in any project
named "Apache Helicopter Flight Simulator". Since this is the Apache
license, lots of other projects have followed their lead on this clause,
too.
> > /usr/share/doc/libkrb53/copyright
> > WARNING: Retrieving the OpenVision Kerberos Administration system
> > source code, as described below, indicates your acceptance of the
> > following terms.
>
> Argh! I doubt that a court will agree with that statement. And I'm not
> sure that it is free. Has this been discussed on debian-legal before?
> Google says no. FWIW, the terms that one has to accept are very free
> themselves.
I only noticed this while grepping for "acceptance" in
/usr/share/doc/*/copyright. (I'm starting to wish for a package,
even non-free, containing all copyright files; /usr/share/doc/XXX/copyright ->
/usr/share/licenses/XXX.)
2. Source code
"The source for a work is a machine-readable form that is appropriate
for modifying the work or inspecting its structure and inner workings."
Is there a benefit to using a different definition than the GPL?
One case where this seems different is images. For example, I have
several PNGs, generated by Photoshop. The PNG itself is appropriate
for modifying the work, but it's not the preferred form for modification.
Going by feel, it's not the source of the work at all.
This also reveals a case that hasn't been resolved: do we expect source
for PNGs, when such a form exists? In practice, we don't, and I tend
to classify it as "that would be nice, but it's not a worthwhile battle".
Another major case of this (and one which is less ambiguous) is fonts.
It would be nice to find a consensus on these, rather than having a new
set of guidelines that still doesn't address the issue.
(I'll admit that "I don't want Debian to have to drop most of its high-
quality fonts" is probably a major factor in my opinion on this, which sounds
somewhat like "I don't want Debian to have to drop Netscape".)
--
Glenn Maynard
Reply to: