Scripsit Glenn Maynard <[EMAIL PROTECTED]> > 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 ..."
