Re: A radical approach to rewriting the DFSG
Scripsit Glenn Maynard <g_deb@zewt.org>
> FWIW, I don't particularly like this idea. The DFSG, in practice,
> is working very well, and the "case law" developing around it is
> practical and, at least on debian-legal, well-understood.
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.
Personally I ought to like the current status quo - it makes me part
of an initialistic priesthood which knows the Right Way to read our
obscure sacred text. More power to us!
It is true that the current DFSG plus our collective memory is fairly
adequate as an instrument for reaching a desicion when somebody brings
a license to us for scrutiny.
However, it is not easy for outsiders to understand the current DFSG.
I suspect that many of the non-free licenses we see are written by
people who *try* to write a license that meets the DFSG (or the OSD),
just while implementing as much CYA as possible. Then they release
their software under a not-quite-free license and we have to keep it
out of Debian. We get to keep Debian clean, but apart from that the
upstream loses, we lose, and our users lose.
It would be better if an upstream license author had a document to
refer to that was clearer about what can and can't be done in a free
license. We now have the debian-legal FAQ, which is a tremendous
improvement over the state of a year ago (and will be even greater
once it gets a link from www.d.o/legal, by the way).
But it would be even better if the actual guidelines were less
obscure. I'm trying to cater for a wannabe license author who goes out
on the web and grabs every set of semi-formal rules he can find about
what software freedom means, and prints them out before he goes to
that meeting with the Legal Department. He probably does not read FAQs
unless he becomes *aware* that he has a question.
> Perhaps you could call this the "Henning Free Stuff Guidelines" for now?
> Having the same abbreviation is inconvenient.
They are now "DFSG^HM".
> 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.
However, before I can write that section, I need to decide what I
think our consensus about patent retribution traps is.
As for trademarks: To the best of my knowledge we do not even now
require trademarks to be licensed DFSG-freely.
> What about the old Apache license:
> 3. The end-user documentation included with the redistribution,
> if any, must include the following acknowledgment:
> "This product includes software developed by the
> Apache Software Foundation (http://www.apache.org/)."
> Alternately, this acknowledgment may appear in the software itself,
> if and wherever such third-party acknowledgments normally appear.
> Any exception for this should be careful; some would try to require inclusion
> of a full page of funding and sponsorship credits, for example.
Current attempt:
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.
> 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?
Perhaps a compromise could be to say that all that can be required is
a *short* notice?
[1] It increase the complexity of my attempt to write down explicit
guidelines, but it is also already increases the complexity of the
line we're implicitly drawing while we interpret the current DFSG.
> > ..."A free license cannot require that the user notices the author prior
> Did you mean to suggest s/notices/notify/?
Yes. Fixed.
> > (The license can specify that exercising the rights granted by the license,
> > absent alternative permissions, will be interpreted as acceptance of the
> > license.)
> A nitpick: does "rights granted by the license" include grants of rights that
> users have anyway?
It is not meant to, certainly. I edited to:
... will be interpreted by the author as acceptance of its
terms. It cannot unilaterally make this interpretation legally
binding, however.
> /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.
--
Henning Makholm "... popping pussies into pies
Wouldn't do in my shop
just the thought of it's enough to make you sick
and I'm telling you them pussy cats is quick ..."
Reply to: