Re: Bug#200411: www.debian.org: confusing description of non-US sections
On Mon, Jul 14, 2003 at 09:15:01PM +, Brian M. Carlson wrote: > On Mon, Jul 07, 2003 at 09:59:34PM -0700, Matt Kraai wrote: > > The thread > > > > http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00029.html > > > > documents the exact rationale for these sections. The following > > patch incorporates its conclusions into the packages page. > > > > I'd appreciate it if the readers of debian-legal would > > double-check it. > > What I saw in that thread was Wichert saying that things in non-US > needed to be there because of patents, and Steve Langasek saying that > that those things needed to be in non-US/non-free. That's not what I see > below. I only found one reply from Steve Langasek at http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00032.html I interpret this as saying that cryptographic software that is non-free cannot move to a server in the US because it does not fall under the same BXA exemptions that allow us to export free cryptographic software. I didn't see anything in his message regarding patents. > > -Non-US/Main and Non-US/Non-Free > > - These packages cannot be exported from the USA, they are mostly > > - encryption software packages, or software that is encumbered by > > - patent issues. Most of them are free, but some are non-free. > > +Non-US/Main > > + Packages in this area are free themselves but cannot be > > + stored on a server in the USA because they are encumbered by > > + patent issues. > > Things in main or non-US/main should not be patent encumbered. > non-US/main is designed so that packages can be imported into the US, > but not exported. If it would not fit the DFSG for any reason, including > being patent-encumbered in the US or other places, then it does not > belong in non-US/main. What belongs in non-US/main? Only software left over from the crypto-in-main transition? [snip] > > One final nitpick: please properly capitalize "non-US", "non-free", and > "main". I was being consistent with the titles of the other sections as listed on that page. -- Matt Kraai [EMAIL PROTECTED] Debian GNU/Linux
Re: GFDL and man pages
Walter Landry <[EMAIL PROTECTED]> writes: > You can make a manpage, but you must > have to include inside the manpage Actually, it's sufficient to refer to this information in the SEE ALSO section of the manpage, so that elaborateness of the GFDL doesn't interfere with the intendend use of the manpage for quick reference. > Note that this all has to be _in_ the manpage. The FSF has a different view on this matter.
Transfer of copyright on death
[Please Cc: me on this thread; I'm not on the list] Hi. I've recently taken over the 9menu package. Looking over the copyright file, it wasn't clear whether it passed DFSG 4. The upstream maintainer has confirmed that in his reading of the copyright, patched binaries may be distributed. The sole maintainer collaborated with another author in writing the program, and they have joint copyright. He would like to get it relicenced under a standard licence but the other author has now died. Is there any way to get it changed? FYI, the current licence is below: 9menu is free software, and is Copyright (c) 1994 by David Hogan and Arnold Robbins. Permission is granted to all sentient beings to use this software, to make copies of it, and to distribute those copies, provided that: (1) the copyright and licence notices are left intact (2) the recipients are aware that it is free software (3) any unapproved changes in functionality are either (i) only distributed as patches or (ii) distributed as a new program which is not called 9menu and whose documentation gives credit where it is due (4) the authors are not held responsible for any defects or shortcomings in the software, or damages caused by it. There is no warranty for this software. Have a nice day. -- Andrew Stribblehill <[EMAIL PROTECTED]> Systems programmer, IT Service, University of Durham, England
Re: Transfer of copyright on death
Andrew Stribblehill <[EMAIL PROTECTED]> writes: > FYI, the current licence is below: > > 9menu is free software, and is Copyright (c) 1994 by David Hogan and > Arnold Robbins. Permission is granted to all sentient beings to use > this software, to make copies of it, and to distribute those copies, > provided that: > > (1) the copyright and licence notices are left intact > (2) the recipients are aware that it is free software > (3) any unapproved changes in functionality are either > (i) only distributed as patches > or (ii) distributed as a new program which is not called 9menu > and whose documentation gives credit where it is due > (4) the authors are not held responsible for any defects > or shortcomings in the software, or damages caused by it. How does the problematic part differ from, say, the license of TeX?
Re: Transfer of copyright on death
Andrew Stribblehill <[EMAIL PROTECTED]> writes: > The sole maintainer collaborated with another author in writing the > program, and they have joint copyright. He would like to get it > relicenced under a standard licence but the other author has now > died. Is there any way to get it changed? The copyright is now probably partially held by the estate of the deceased author. The estate can give a legal permission to relicense the software. -- * Kettering's Law: Logic is an organized way of going wrong * * with confidence.* * PGP public key available @ http://www.iki.fi/killer *
Re: Transfer of copyright on death
Andrew Stribblehill <[EMAIL PROTECTED]>:
> The sole maintainer collaborated with another author in writing the
> program, and they have joint copyright. He would like to get it
> relicenced under a standard licence but the other author has now
> died. Is there any way to get it changed?
I would guess that you have to find the dead author's heir and ask
their permission. The heir is unlikely to be interested in the details
of free software licensing, so perhaps the best thing would be for the
living author to ask the heir to give him permission to do anything he
wants with the code, including create derivative works with a licence
of his choice ("so that the dead author's work can live on, etc").
Alternatives might be to assign the copyright to the living author or
put the dead author's work into the public domain, but both of these
are likely to sound less attractive to the heir (though they do seem
to have the advantage of handling the situation where the other author
dies and his estate wants to relicense).
If it turns out that the dead author made no provision for copyrights
in his will and asked his property to be shared out among several
people, or given to a charity, then finding and contacting the heir(s)
might be very difficult.
Edmund
Re: GFDL and man pages
Florian Weimer <[EMAIL PROTECTED]> wrote: > Walter Landry <[EMAIL PROTECTED]> writes: > > > You can make a manpage, but you must > > have to include inside the manpage > > Actually, it's sufficient to refer to this information in the SEE ALSO > section of the manpage, so that elaborateness of the GFDL doesn't > interfere with the intendend use of the manpage for quick reference. > > > Note that this all has to be _in_ the manpage. > > The FSF has a different view on this matter. The FSF doesn't read its own license. Section 4 states: In addition, you must do these things in the Modified Version: ... # H. Include an unaltered copy of this License. That looks pretty clear to me. Regards, Walter Landry [EMAIL PROTECTED]
Re: GFDL and man pages
Florian Weimer said: > Walter Landry <[EMAIL PROTECTED]> writes: >> You can make a manpage, but you must >> have to include inside the manpage > Actually, it's sufficient to refer to this information in the SEE ALSO > section of the manpage, so that elaborateness of the GFDL doesn't > interfere with the intendend use of the manpage for quick reference. > >> Note that this all has to be _in_ the manpage. > > The FSF has a different view on this matter. Unless the FSF is the sole copyright holder of the relevant GFDL document, their interpretation of the license is irrelevant. --Joe
Re: GFDL and man pages
Walter Landry <[EMAIL PROTECTED]> writes: > Florian Weimer <[EMAIL PROTECTED]> wrote: >> Walter Landry <[EMAIL PROTECTED]> writes: >> >> > You can make a manpage, but you must >> > have to include inside the manpage >> >> Actually, it's sufficient to refer to this information in the SEE ALSO >> section of the manpage, so that elaborateness of the GFDL doesn't >> interfere with the intendend use of the manpage for quick reference. >> >> > Note that this all has to be _in_ the manpage. >> >> The FSF has a different view on this matter. > > The FSF doesn't read its own license. Section 4 states: > > In addition, you must do these things in the Modified Version: > > ... > > # H. Include an unaltered copy of this License. > > That looks pretty clear to me. It would be clear, if this were the GNU Free Manpage License. The FSF makes a claim I know I've heard here before: that there is no one-to-one mapping from files to works. They'd presumably consider all the manpages in the csound package to be a single work, and have each refer to a central gfdl(8) page. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: GFDL and man pages
* Brian T. Sniffen [Tue, 15 Jul 2003 at 08:34 -0400] > > # H. Include an unaltered copy of this License. > > > > That looks pretty clear to me. > > It would be clear, if this were the GNU Free Manpage License. The FSF > makes a claim I know I've heard here before: that there is no > one-to-one mapping from files to works. They'd presumably > consider all the manpages in the csound package to be a single work, > and have each refer to a central gfdl(8) page. Indeed, the manpages for gcc and friends seem to do just this. (see gcc(1), cpp(1), gfdl(7gcc), etc.) -- Hans Fugal | De gustibus non disputandum est. http://hans.fugal.net/ | Debian, vim, mutt, ruby, text, gpg http://gdmxml.fugal.net/ | WindowMaker, gaim, UTF-8, RISC, JS Bach - GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460 pgpliE7Xqb13O.pgp Description: PGP signature
Re: Bug#200411: www.debian.org: confusing description of non-US sections
On Mon, Jul 14, 2003 at 11:42:09PM +0200, Matt Kraai wrote: > On Mon, Jul 14, 2003 at 09:15:01PM +, Brian M. Carlson wrote: > > On Mon, Jul 07, 2003 at 09:59:34PM -0700, Matt Kraai wrote: > > > The thread > > > > > > > > > http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00029.html > > > > > > documents the exact rationale for these sections. The following > > > patch incorporates its conclusions into the packages page. > > > > > > I'd appreciate it if the readers of debian-legal would > > > double-check it. > > What I saw in that thread was Wichert saying that things in non-US > > needed to be there because of patents, and Steve Langasek saying that > > that those things needed to be in non-US/non-free. That's not what I see > > below. > I only found one reply from Steve Langasek at > http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00032.html > I interpret this as saying that cryptographic software that is > non-free cannot move to a server in the US because it does not > fall under the same BXA exemptions that allow us to export free > cryptographic software. I didn't see anything in his message > regarding patents. Essentially correct. To be precise, I think the BXA exemptions cover software under a wider range of licenses than what we consider free; however, trying to bring any non-free crypto software into the primary mirror ring is not worth the risk, IMHO. > > > -Non-US/Main and Non-US/Non-Free > > > - These packages cannot be exported from the USA, they are mostly > > > - encryption software packages, or software that is encumbered by > > > - patent issues. Most of them are free, but some are non-free. > > > +Non-US/Main > > > + Packages in this area are free themselves but cannot be > > > + stored on a server in the USA because they are encumbered by > > > + patent issues. > > Things in main or non-US/main should not be patent encumbered. > > non-US/main is designed so that packages can be imported into the US, > > but not exported. If it would not fit the DFSG for any reason, including > > being patent-encumbered in the US or other places, then it does not > > belong in non-US/main. > What belongs in non-US/main? Only software left over from the > crypto-in-main transition? There have, in practice, been packages relegated to non-US for purely patent reasons. Whether these packages warrant the classification of non-US/main or non-US/non-free is a bit of a judgement call. Since the DFSG mainly talks about software licenses, I would question whether it's appropriate to speak of patent-encumbered software as non-free when the patent holder is not the author. -- Steve Langasek postmodern programmer pgplnUQMsLkqj.pgp Description: PGP signature
DFSG FAQ (draft)
With a little help, I've composed a draft DFSG FAQ. It meant as an introduction to issues discussed on debian-legal, with some general background material to help bring naive readers up from ground zero. http://people.debian.org/~bap/dfsg-faq.html It is a bit rough, so I'd welcome modifications. You can email patches, or for little things just edit in place - the file is g+w and under CVS control so I'll just cvs diff / cvs commit as appropriate. If people think it could be of some official use, I'd be pleased if it were taken over into a more formal location. -- Barak Pearlmutter
Re: GFDL - status?
On Sun, Jul 13, 2003 at 03:59:00PM -, MJ Ray wrote: > You disagree that the documentation part of a GFDL-covered work is > acceptably licensed? Yes. It is encumbered with invariant sections. That clearly doesn't meet DFSG#3, and it doesn't qualify for the exception in DFSG#4. > I do not talk about the work as a whole, which seems > clearly not to be. If it were _possible_ to just ignore the invariant sections when considering the documentation, then we wouldn't be having this discussion. Their stickiness is precisely the problem, since it encumbers documentation that would otherwise be free. > Related points that I consider interesting and relevant to what happens > next are: is there any legal basis for distinguishing programs from other > literary works? There seems to be; several European laws make specific exceptions for computer programs. They don't define "computer program", as far as I know. > From other electronically stored works? What about > fonts? Encoding tables? Is DFSG sufficiently general? If it's electronically (YM digitally?) stored, then I say it's software. I see no reason to make this word a synonym for "computer programs", and in practice I see people refer to a large variety of digitally stored data as "software". (For example, does the MirrorMagic package contain "software, documentation, sounds and graphics"? Or is the whole thing just "software"?) Richard Braakman
Re: GFDL and man pages
On Tue, Jul 15, 2003 at 07:02:18AM -0600, Hans Fugal wrote: > > It would be clear, if this were the GNU Free Manpage License. The FSF > > makes a claim I know I've heard here before: that there is no > > one-to-one mapping from files to works. They'd presumably > > consider all the manpages in the csound package to be a single work, > > and have each refer to a central gfdl(8) page. > > Indeed, the manpages for gcc and friends seem to do just this. (see > gcc(1), cpp(1), gfdl(7gcc), etc.) If you convert any sufficiently large Texinfo source file to Info format (or to HTML), multiple files are the result, so the FSF interpretation clearly makes sense when you user their tools. 8-)
Re: DFSG FAQ (draft)
Barak Pearlmutter <[EMAIL PROTECTED]> writes: > With a little help, I've composed a draft DFSG FAQ. It meant as an > introduction to issues discussed on debian-legal, with some general > background material to help bring naive readers up from ground zero. > > http://people.debian.org/~bap/dfsg-faq.html Here are a few suggestions: You may want to mention the pine license fiasco wrt question #3, as it's an excellent example of a license that would ordinarily have been considered free, but the copyright holder had an odd interpretation of the license which we decided to honor, thus making it non-free. 7. (d), answer: No, not unless the clickwrap stuff can be removed. In principle one could put the GPL in a clickwrap and the license would be perfectly fine. But once you add a requirement that the software must be distributed via the clickwrap, or that clickwrap code can not be removed from the software your license becomes non-free. Since clickwraps without such a requirement are a bit pointless, clickwrap licenses are virtually always non-free. In 7 (g) & (h) you mention adding suggestions that are not part of the license. Whether these suggestions are part of the license text (even if optional) is left ambiguous. The advantage to being part of the license text, of course, is that it becomes a sort of "invariant text" that must follow the work. I'm not saying we should necessarily change that, mind, we may *want* that to be ambiguous so as to avoid folks adding lots of extraneous text to licenses. In the answer to question 9 it might be worth noting the question of whether or not things can actually be released into the public domain. My understanding is that debian-legal generally quietly re-interprets such claims as an extremely permissive license. 11 A: In order for two licenses to be compatible it must be possible to mingle code under both licenses in a new work. When this is done the result is that the terms of both licenses must be met for the work as a whole. The GNU GPL makes this feature of copyright law explicit by stating that if you cannot for any reason (e.g., because of another license) meet the terms of the GPL, the GPL grants no rights at all. In order for a license to be GPL compatible, then, you must be able to meet both the terms of the GPL and the other license simultaneously. 12 A: (should probably be combined with 13) When a work is released under a dual license the recipient is explicitly given the option to choose which license to apply to a derivative work. Someone making modifications may include new code under the GPL (thus making the result strictly GPL) or the alternative license (thus selecting the alternate license). The GPL is particularly common in dual licenses because it allows the code to link with the large number of GPL code out there, or to be pulled into GPL works. (I'm not sure where you want to go with the bit about "dual GNU GPL/Artistic" or "dual GNU GPL/QPL".) -- Jeremy Hankins <[EMAIL PROTECTED]> PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: DFSG FAQ (draft)
Scripsit Jeremy Hankins <[EMAIL PROTECTED]> > In the answer to question 9 it might be worth noting the question of > whether or not things can actually be released into the public > domain. My understanding is that debian-legal generally quietly > re-interprets such claims as an extremely permissive license. I think it depends on who on debian-legal you ask. I understand that there are jurisdictions that do recognize explicit donations of intellectual property to the public domain. In those, a statement that "FOO is (in the) public domain" would be taken at face value, and DFSG-freedom follows immediately. There are other jurisdictions that do not have any systematic concept of "public domain" - a count in one of those, would probably reinterpret the statement as an extremely permissive license, with much the same effect. I have previously made a point of distinguising between these two cases, but I'm not sure anymore that the distinction is relevant for debian-legal's purpose. -- Henning Makholm "Also, the letters are printed. That makes the task of identifying the handwriting much more difficult."
Re: DFSG FAQ (draft)
>In the answer to question 9 it might be worth noting the question of >whether or not things can actually be released into the public >domain. My understanding is that debian-legal generally quietly >re-interprets such claims as an extremely permissive license. In the United States I believe this is not in question. A work can be released into the public domain by its author(s), provided he/she/they has the copyright and has not entered into contracts regarding it. This is the usual case where free software is concerned. (Other situations are less clear because of the rule where authors can recover transfered copyrights in a particular year, potential violations of contract, etc. -- you can't give away rights you don't have.) It's probably best to specify a particular preferred form for public domain releases; Creative Commons has a rather verbose form for this, quoted below, which makes it quite clear that the author *really* means to release it to the public domain. (I have heard rumors that Germany does not recognize copyright transfers (treating them as revocable licenses), and the same may apply to public domain dedications. But this is another issue.) Here's the Creative Commons boilerplate: -- The person or persons who have associated their work with this document (the "Dedicator") hereby dedicate the entire copyright in the work of authorship identified below (the "Work") to the public domain. Dedicator makes this dedication for the benefit of the public at large and to the detriment of Dedicator's heirs and successors. Dedicator intends this dedication to be an overt act of relinquishment in perpetuity of all present and future rights under copyright law, whether vested or contingent, in the Work. Dedicator understands that such relinquishment of all rights includes the relinquishment of all rights to enforce (by lawsuit or otherwise) those copyrights in the Work. Dedicator recognizes that, once placed in the public domain, the Work may be freely reproduced, distributed, transmitted, used, modified, built upon, or otherwise exploited by anyone for any purpose, commercial or non-commercial, and in any way, including by methods that have not yet been invented or conceived. -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Re: DFSG FAQ (draft)
Thanks. I incorporated your mods, leaving out the public domain change because I'm not sure how to phrase "except in France and places like that where we take that to mean effectively the same thing even though their legal system doesn't have such a concept except for people like Leonardo da Vinci because obviously it's what the author wants and they do have the concept of doing what the author wants even though authors don't technically have the right to actually put their own works in the public domain so don't worry about it." Especially without sounding like I'm baiting the French. Which, don't get me wrong, I enjoy as much as the next red-blooded American expat. But here, not there. I think that's what Henning Makholm meant in his followup.
Re: GFDL and man pages
"Joe Moore" <[EMAIL PROTECTED]> writes: > Unless the FSF is the sole copyright holder of the relevant GFDL document, > their interpretation of the license is irrelevant. Yours is as well, and so is everyone's on this list. Then why do we discuss at all?
Re: DFSG FAQ (draft)
Barak Pearlmutter <[EMAIL PROTECTED]> writes: > If people think it could be of some official use, I'd be pleased if it > were taken over into a more formal location. | Unless the material is dual-licensed under the GFDL and an accepted | free license, Debian in general does not consider material under the | GFDL to be free. I think it's premature to include such a statement in an official document. As far as I can tell, only a very vocal minority shares this point of view. I'd like suggest a further question and anser: X. If some software is free according to Debian's standards, do I still face legal risks when I use, modify or distribute it? We sincerely hope you don't, but our process does not guarantee this. As stated above, Debian just looks at the license of the software to decide whether it meets the project's standards for free software. However, beyond that, there are sill many causes for legal problems, some of them listed below. o The software has been misappropriated, and a license has been applied to it without approval of the actual copyright owner. In this case, Debian's evaluation is based on false premises and therefore useless. o The software includes code which is copyrighted by third parties and not released under a free license, or the license terms are violated (e.g. if they are incompatible with other license requirements). As Debian only examines the license and not the actual code, this cannot be detected (in particular if the problematic code is copied without proper attribution). However, in a few cases, such license violations are detected (in particular between the GPL and requirements for advertising). o The software can infringe trademarks. Distributors may be held liable in some countries. Currently, Debian does not check for trademarks and their misuse. o The software can infringe patents. Again, distributors may be held liable. Debian checks only a very short list of well-known, but rather arbitrary patents, and this check is only performed on a case-by-case basis. o Use of the software might be illegal according to local law. o Distribution of the software could be illegal, as a result of import or export restrictions and/or regulations of what software can legally implement. As a result, Debian's claim that a particular computer program is free software is a *political* statement, not a statement of legal relevance on which you can rely, be it as a user, software developer or distributor.
Re: GFDL and man pages
On Tue, 15 Jul 2003, Florian Weimer wrote: > "Joe Moore" <[EMAIL PROTECTED]> writes: > > Unless the FSF is the sole copyright holder of the relevant GFDL document, > > their interpretation of the license is irrelevant. > Then why do we discuss at all? The court system is the interpretation that matters. However, until we actually get a few court decisions regarding (and interpreting) the license, we're left with our reading and understanding of it. The FSF folks occasionally are more lenient with their interpretation of licenses than a very strict reading would indicate. In cases where they are the sole copyright holder, that's acceptable, especially in areas where the license is less than clear. Yet, if there is someone else holding the license, without a statement from them regarding its interpretation, we have to read the license strictly, and conservatively. [In many cases the FSF says to effect: "Well, the license may or may not preclude this, but we feel that it's resonable for you to do X, Y and Z." In lieu of such a statement, we should probably assume that we cannot do X, Y, and Z, even if it would make such a license non-free.] Don Armstrong -- Clothes make the man. Naked people have little or no influence on society. -- Mark Twain http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu pgpW3Xd6sj26B.pgp Description: PGP signature
Re: DFSG FAQ (draft)
Barak Pearlmutter wrote: > With a little help, I've composed a draft DFSG FAQ. It meant as an > introduction to issues discussed on debian-legal, with some general > background material to help bring naive readers up from ground zero. > > http://people.debian.org/~bap/dfsg-faq.html I read: For a concrete example, the PINE mail reader has a license which might normally be interpreted as free, but the copyright holder told us they wished to interpret it in a somewhat counterintuitive but nonetheless plausible way, which made it non-free. This would be only accurate if applied to pine 3.91, which had a BSD-like license. The way UW interpret pine 3.91 license, it's non-free, because you can't "modify and then redistribute". After pine 3.91, UW changed the license to make clear that they do not want modified binaries to be distributed without their explicit permission.
Re: DFSG FAQ (draft)
> > free license, Debian in general does not consider material under the > > GFDL to be free. > I think it's premature to include such a statement in an official Good point. Can you suggest a re-phrase for the GFDL question? I think it is fair to say that Debian strongly discourages its use, ie there does seem to be consensus on that. There also seems to be consensus that it is not free if enough of the clauses are "activated". With no clauses activated, there seems to be consensus that it is unpleasant but tolerable, although that feeling was not unanimous. With just minimal activation, I'm not sure... --Barak.
Re: DFSG FAQ (draft)
Barak Pearlmutter <[EMAIL PROTECTED]> writes: >> > free license, Debian in general does not consider material under the >> > GFDL to be free. > >> I think it's premature to include such a statement in an official > > Good point. > > Can you suggest a re-phrase for the GFDL question? > > I think it is fair to say that Debian strongly discourages its use, ie > there does seem to be consensus on that. "Debian strongly discourages its use. However, there is an ongoing discussion whether software documentation in Debian has to meet the DFSG, or some different standards specific to documentation. Even if Debian literally applied its free software guidelines to documentation, some choices in the range of license terms offered by the GFDL could still meet Debian's standards, although this subject to debate as well. The way the GFDL is applied to a lot of GNU software documentation and some other source is not compatible with the DFSG, so if the DFSG do apply to documentation, Debian would have to remove such documentation from its distribution." (Modulo some smoothing by a native speaker, as usual. And you might want to drop the reference to GNU software documentation.)
Re: DFSG FAQ (draft)
Barak Pearlmutter <[EMAIL PROTECTED]> writes: > Okay, I rephrased the GFDL stuff a bit. Let me know if you're not > comfortable with it. "Debian in general does not consider material under the GFDL with any significant clauses "activated" to be free." "Almost no one would seriously contend that the GFDL is a good license for digital materials." I think it's still too harsh. A few active posters on debian-legal are not "Debian in general". (IMHO, the GFDL is a very interesting starting point, and will almost certainly evolve to something genuinely useful. The problems that are considered fundamental by the fundamentalists are actually pretty minor, the question of invariant sections aside.)
Re: DFSG FAQ (draft)
Okay, I rephrased the GFDL stuff a bit. Let me know if you're not comfortable with it. --Barak.
Re: GFDL - status?
Richard Braakman <[EMAIL PROTECTED]> wrote: > On Sun, Jul 13, 2003 at 03:59:00PM -, MJ Ray wrote: >> You disagree that the documentation part of a GFDL-covered work is >> acceptably licensed? > Yes. It is encumbered with invariant sections. That clearly doesn't > meet DFSG#3, and it doesn't qualify for the exception in DFSG#4. How are you not free to create derivative parts of the documentation section and distribute it under the same terms (ie with invariants in tow)? The invariant sections are not part of the documentation (and they must not be documentation). I'm not saying the complete work is DFSG-free. I'm just trying to give a possible reason why it is named "free document*ation* licence". >> [...] is there any legal basis for distinguishing programs from other >> literary works? > There seems to be; several European laws make specific exceptions for > computer programs. The exception in UK law is quite limited, classifying them as literary works with just one exception from moral rights. Can anyone point us to a survey of this? I can't find one. > They don't define "computer program", as far as I know. I've noticed that I've not found that, too. I wonder why? > If it's electronically (YM digitally?) [...] I think analogue tape representations are included, don't you? Thanks for some interesting points (some trimmed in this reply). -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ jabber://[EMAIL PROTECTED] Creative copyleft computing services via http://www.ttllp.co.uk/ Thought: Edwin A Abbott wrote about trouble with Windows in 1884
Re: GFDL and man pages
Florian Weimer <[EMAIL PROTECTED]> wrote: > Then why do we discuss at all? Because consensus of this list is normally taken as direction for Debian action? -- MJR/slef My Opinion Only and possibly not of any group I know. Thought: Edwin A Abbott wrote about trouble with Windows in 1884
Re: DFSG FAQ (draft)
Florian Weimer <[EMAIL PROTECTED]> wrote: > X. If some software is free according to Debian's standards, do I > still face legal risks when I use, modify or distribute it? I've said many times, many ways, that talking about "free" on its own may not be clear enough. Perhaps rephrase "If some software is free..." to "If this is free software..."? Similarly, I think it would be safe to say that the FDL is not a free software licence, as FSF seem to think that even trying to judge FDL-covered works as software at all is absurd. (Correct me if I'm wrong, with references, please.) > [...]and not released under a free license, or the license terms are "Free license" is also a clumsy term, IMO. -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ jabber://[EMAIL PROTECTED] Creative copyleft computing services via http://www.ttllp.co.uk/ Thought: Edwin A Abbott wrote about trouble with Windows in 1884
Re: DFSG FAQ (draft)
> (IMHO, the GFDL is a very interesting starting point, and will almost > certainly evolve to something genuinely useful. The problems that are I'm not aware of any plans on the FSF's part to significantly evolve the GFDL. That's not to say that no such plans exist, but we still need to deal with what we have today. I agree that it read much too harshly. I've tried to soften it way down, eg by removing the second half and adding a gentler first sentence. --Barak.
Re: DFSG FAQ (draft)
Scripsit Florian Weimer <[EMAIL PROTECTED]> > I'd like suggest a further question and anser: > X. If some software is free according to Debian's standards, do I > still face legal risks when I use, modify or distribute it? I can see the point, but I think the answer you propose sounds too much like automatic CYA-legalese. In particular, I have to disagree with the ending: > As a result, Debian's claim that a particular computer program is free > software is a *political* statement, not a statement of legal > relevance on which you can rely, be it as a user, software developer > or distributor. In my opinion we actually try our damnedest to make sure, to the best of our knowledge, that people *can* rely of having the DFSG freedoms when they use software from Debian. To claim that we're doing all of this solely to make a political statement would be dishonest in the extreme, in addition to being a great joke considering the differences in political views among d-l regular that occasionally escalate into flamewars. I'd be more comfortable with an ending that called a spade a space, perhaps something like In short, while we try our best to include only free software in Debian, we can and do make mistakes on occasion. When that happens and is found out, we shall be immensely embarrassed, but we cannot be liable legally to users or distributors who, trusting our judgement, suffered losses because of the mistake. We expect our users and distributors to understand that the existence of some software in Debian does not constitue any guarantee that it is free. It merely means that either we have not yet become aware of any reasons why it is not free, or that we have found such reasons but have not yet taken action on them. [1] Users and distributors must understand that they alone must bear the legal risk inherent in relying on information that they got for free from a self-appointed team of mostly unknown unpaid volunteers who gathered it in their own time and using their own, mostly lay, knowledge. If you cannot accept that risk yourself, we must advise you either not to use or distribute Debian, or to hire a lawyer for yourself and have him/her research the legal state of each piece of software indicidually. [1] Perhaps then there should also be a follow-up question along the lines of Q. How can I find out if there are known doubts about the freedom of a particular package in Debian but for some reason they have not yet led to it being removed from the archive? A. If someone becomes sufficiently convinced that a package already in Debian is not free after all, they will file a release-critical bug against the package, so your first step would be to search our bug-tracking database at http://bugs.debian.org/ It is common for such bugs staying open for several weeks or months without the package actually being removed, for example because the Debian maintainer hopes to be able to reslove the situation through dialogue with the upstream author. If you want to track even preliminary suspicions that have not yet reached that degree of certainty, you will need to follow debian-legal or read its archives. except that I don't know if that can say with a straight face that such RC bugs will always filed if the maintainer acknowledges the problem and is working with upstream to get the license changed or clarified. -- Henning Makholm "Punctuation, is? fun!"
Re: DFSG FAQ (draft)
Florian Weimer <[EMAIL PROTECTED]> wrote: > discussion whether software documentation in Debian has to meet the > DFSG, or some different standards specific to documentation. Three problems with that hypothesis:- 1. We don't have any way of distinguishing software and this documentation in a safe manner. My local research suggests that software is generally treated as a literary work and electronic documentation definitely is. Even if Debian can distinguish them, I'm not sure that the law can. 2. The documentation is not the issue. The entire FDL-covered work is. 3. What about other content? > [...] some choices in the range of license terms offered by > the GFDL could still meet Debian's standards, although this subject to > debate as well. Consensus appeared to be forming that there were other problems than the optional parts, I thought, but the thread is cold. [...] -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ jabber://[EMAIL PROTECTED] Creative copyleft computing services via http://www.ttllp.co.uk/ Thought: Edwin A Abbott wrote about trouble with Windows in 1884
Re: DFSG FAQ (draft)
Henning Makholm <[EMAIL PROTECTED]> wrote: > In my opinion we actually try our damnedest to make sure, to the best > of our knowledge, that people *can* rely of having the DFSG freedoms > when they use software from Debian. [...] Calling it a political statement is probably wrong, yes, but it's also not legal advice and some people have to be reminded of that :-/ > I'd be more comfortable with an ending that called a spade a space, If you want me, I'll be out back digging the garden with the space bar. > [...] It merely means that either we have not > yet become aware of any reasons why it is not free [...] For it to get into Debian in the first place, it also means that a mistake was made, to be neutral about it. -- MJR/slef My Opinion Only and possibly not of any group I know.
Re: DFSG FAQ (draft)
Scripsit Henning Makholm <[EMAIL PROTECTED]> > I'd be more comfortable with an ending that called a spade a space, > perhaps something like For the record, I'm also happy with the version that is in Barak's faq presently (which starts with "You should take this answer as a total disclaimer of everything. ...") -- Henning Makholm "En tapper tinsoldat. En dame i spagat. Du er en lykkelig mand ..."
Re: DFSG FAQ (draft)
MJ Ray <[EMAIL PROTECTED]> writes: > Three problems with that hypothesis:- > > 1. We don't have any way of distinguishing software and this documentation > in a safe manner. My local research suggests that software is generally > treated as a literary work and electronic documentation definitely is. > Even if Debian can distinguish them, I'm not sure that the law can. If we want to make a distinction, we want to make it for our own sake, not for legal reasons. We can chose completely arbitrary rules (as long as we don't encourage copyright infringement, of course). For our peace of mind, they should be consistent, but even that is unnecessary. For example, we could happily distribute unmodified RFCs from a legal point of view, but we might well reject the very cumbersome restrictions on derived works, and choose to distribute it nevertheless (*gasp*), but with an attached "non-free" sticker (obviously for purely political reasons). (I don't want to ridicule the approach towards RFCs. After some consideration, I find it perfectly sound. It's hardly a burden anyway; for those following stable, an RFC mirroring script is much more practical.) > 2. The documentation is not the issue. The entire FDL-covered work is. In my eyes, the GNU Manifesto is an integral part of the GNU Emacs documentation. > 3. What about other content? Can be decided case-by-case. For example, if the maintainer is forced to do something which would violate the license (or a user makes a convincing real-world case that the license fails to provide him with his natural rights to this content), it still can be removed.
Re: DFSG FAQ (draft)
Henning Makholm <[EMAIL PROTECTED]> writes: > In my opinion we actually try our damnedest to make sure, to the best > of our knowledge, that people *can* rely of having the DFSG freedoms > when they use software from Debian. But this is not true. Almost never, the source code itself is examined, although it's the source code that matters from a legal point of view. > To claim that we're doing all of this solely to make a political > statement would be dishonest in the extreme, Maybe, but it's important to refute the idea that a DFSG license audit alone implies that it's legal to distribute the software. > In short, while we try our best to include only free software in > Debian, we can and do make mistakes on occasion. "try our best" is a bit too euphoric. You simply cannot check the legal status of some piece of software without examining the source code. Maybe we could add the following sentences at this point: "Debian relies on the judgement and integrity of the developers whose software it distributes. In some rare cases, these developers knowingly or inadvertently misrepresent the legal status of their software." > When that happens and is found out, we shall be immensely > embarrassed, but we cannot be liable legally to users or > distributors who, trusting our judgement, suffered losses because > of the mistake. The project itself might not be liable (I don't know the legal setup at all, if it exists), but the distributors could be. This particular section looks pretty much like wishfully thinking. 8-( > Users and distributors must understand that they alone must bear the > legal risk inherent in relying on information that they got for free > from a self-appointed team of mostly unknown unpaid volunteers who > gathered it in their own time and using their own, mostly lay, > knowledge. If you cannot accept that risk yourself, we must advise > you either not to use or distribute Debian, or to hire a lawyer for > yourself and have him/her research the legal state of each piece of > software indicidually. Sadly, most upstreams do not properly keep track of contributions, so you are asking for something which is practically impossible (but that's not Debian's problem, of course). > [1] Perhaps then there should also be a follow-up question along the > lines of > > Q. How can I find out if there are known doubts about the freedom of > a particular package in Debian but for some reason they have not > yet led to it being removed from the archive? I think it's a good idea to include this question and answer.
Re: DFSG FAQ (draft)
Henning Makholm <[EMAIL PROTECTED]> writes: > For the record, I'm also happy with the version that is in Barak's faq > presently (which starts with "You should take this answer as a total > disclaimer of everything. ...") It's fine with me, too.
FDL and doc/sw distinction, was Re: DFSG FAQ (draft)
Florian Weimer <[EMAIL PROTECTED]> wrote: > If we want to make a distinction, we want to make it for our own sake, > not for legal reasons. Indeed, but that would need consensus that a distinction is essential (all evidence so far suggests it isn't) or desirable (consensus unlikely, IMO) and at least a proposal of how to make the distinction. One thing that has irritated me is the suggestion by some that there needs to be a distinction for legal reasons *and* then not providing anything concrete to back that claim up. Sorry if I dropped that on you. I don't think that's your stance at all. > We can chose completely arbitrary rules (as long as we don't encourage > copyright infringement, of course). For our peace of mind, they should > be consistent, but even that is unnecessary. I hope that we can avoid arbitrary and illogical distinctions. That way madness lies, with all the horrors of different decisions for identical licence terms, etc. [...] >> 2. The documentation is not the issue. The entire FDL-covered work is. > In my eyes, the GNU Manifesto is an integral part of the GNU Emacs > documentation. The GNU Manifesto is not documentation for the subject of the GNU Emacs Manual, which is given as "how to edit with Emacs and some of how to customize it." If it is documentation for GNU Emacs, it is not allowable as an invariant section under the FDL. Arguably it is documentation in a way, but it is documentation for the history of GNU Emacs, which is outside the current scope of the Emacs Manual. I think this is another questionable bit of the FDL and something that has been mentioned here before more than once :-( I hope some FDL supporters start answering the questions, preferably with an FDL FAQ. >> 3. What about other content? > Can be decided case-by-case. Let's use DFSG for all these cases. > [...] his natural rights to this content [...] I'm guessing that the ability to edit the works of others isn't something you regard as a natural right? -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ jabber://[EMAIL PROTECTED] Creative copyleft computing services via http://www.ttllp.co.uk/ Thought: Edwin A Abbott wrote about trouble with Windows in 1884
