unsubscribe
unsubscribe Do you Yahoo!? Meet the all-new My Yahoo! Try it today!
Debian Free Documentation Guidelines was: License of old GNU Emacs manual
On Tue, Jan 04, 2005 at 10:24:56AM -0500, Theodore Ts'o wrote: > On Tue, Jan 04, 2005 at 03:43:15PM +0100, Florian Weimer wrote: > > > > [ redacted because it pointlessly appeared on debian-private ] > > > > (Permission to forward my text below to any one/list that people might > choose is hereby given.) > > We have a choice before us. Either we are super-strict about what > goes into the main debian pool, in which case more and more stuff will > end up in non-free (and people will take non-free less seriously), or > we become pragmatists, and bend the DFSG, or make the DFSG more > accomodating, in which case it could be argued that we will be taking > the DFSG more seriously. [snip] Or we can take what is behind Door number 3! We wrote the Debian /Free Software/ Guidelines, there isn't anything stopping us from creating the Debian /Free Documentation/ Guidelines. I don't believe that Documentation is similiar enough to Software that we can blindly apply the DFSG. But let us see what the consensus is; if there is one the DFDG will be exactly equivalent to the DFSG (it'd be a surprise though). As some first thoughts, can we agree that: - may be treated as software any Documentation which is explicitly under a Software licence that we have already determined to be DFSG okay is likewise DFDG okay - free redistribution no restrictions on who can redistribute. no royalties or fees required. - availability of 'preferred editing form' If AsciiDoc, then the source should be available so that once the US (or the rest of the world) switches to A4 (or Letter) things can be appropriately regenerated for the new paper size. (for example). - no discrimination No discrimination against specific people or groups of people. Or people who labour in a specific field or type of organisation. - licence is not specific to Debian The same licence should apply whether or not the documenation is part of Debian. There are many more contentious points that we ought to be able to enumerate as we did in while creating the DFSG. I shall try to post a summary, frequently, of guidelines raised to keep discussion progressing[1]. Thanks, Anand [1]: If you'd like to help with that, please let me know. -- linux.conf.au 2005 - http://lca2005.linux.org.au/ - Birthplace of Tux April 18th to 23rd - http://lca2005.linux.org.au/ - LINUX Canberra, Australia - http://lca2005.linux.org.au/ -Get bitten! signature.asc Description: Digital signature
Re: License of old GNU Emacs manual
I've Cc:ed this to -project - followups should probably go there. On Tue, 2005-01-04 at 10:24 -0500, Theodore Ts'o wrote: > Either way, the people who are pushing the strict DFSG above all else > have to see that the fundamental problem is that there are useful bits > out there that Debian users will want to use (such as the autoconf > documentation --- if someone hasn't issued an ITP for it in non-free > yet, I will, soon, because I need it), that are licensed under > licenses that do not meet a strict interpretation of the DFSG. I agree that interpretations of the DFSG that remove large quantities of material that we've previously thought of as free software are wrong, and I'm on record as being opposed to various attempts to do so. But DFSG 4 requires us to be able to modify content. We're willing to bend that somewhat due to requirements that the GPL and older BSD licenses have, but I don't believe that objecting to the existence of large and unmodifiable sections of political content that can't even be removed is a desperately strict interpretation of the DFSG. Now, I agree that the autoconf manual doesn't have this issue, and I agree that the /other/ problems with the GFDL are significantly less important. However, as written, the license forbids us from doing certain things that we generally believe should be possible. It's not really meant to, and it's fairly easily fixable. The fact that we have so far failed to do so is something of a disaster (yes, I know that it's not our fault), but I think we're acting in the right way here. We want to be /sure/ that we can guarantee our users the rights to put GFDLed documentation on sites requiring http authentication, or on an encrypted filesystem or whatever because those are freedoms that we tend to think are important *practical* issues. And free software is fundamentally about providing as many practical freedoms as possible. At some point, we have to draw a line and refuse to allow material into main if it doesn't ensure that certain freedoms are provided. GFDLed documentation with invariant sections plainly has issues there, and that's fairly fundamental. GFDLed documentation without them still has issues, even if they're accidental. > It's only a problem if view this as a central role that Debian can and > should play going forward. I happen to think an APT plugin might very > well be the right thing. We can mark packages in non-free with > different attributes how they are "non-free". Are the packages evil > firmware, or are the packages evil GFDL documentation from the FSF, or > are the packages evil in some other form? Let users choose for > themselves where they are willing to draw the line, instead of forcing > depriving users of useful software/documentation/bits --- such as the > autoconf documentation, (which I need, damn it!) --- because we > presume that we are somehow entitled to choose for our users what > software they can and should be able to run. I don't think it's unreasonable for us to expect our users to make different choices to us as to what levels of freedom are necessary, and providing tools to allow them to make that choice sounds like an excellent idea. However, I think it's also important for us to stick to the aim of producing a useful OS that can be entirely made up of components that provide all the freedoms of the DFSG. > P.S. Besides, given that the Debian Logo needs to go into non-free, > since the terms governing its use are also not DFSG compliant, who are > we really trying to kid? I think that that's an argument for the logo being under the wrong license (and hence us having fucked up in the past) rather than the DFSG being wrong. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Debian Free Documentation Guidelines was: License of old GNU Emacs manual
Anand Kumria <[EMAIL PROTECTED]> wrote: (Re: requirements for documentation) > There are many more contentious points that we ought to be able to > enumerate as we did in while creating the DFSG. I shall try to post a > summary, frequently, of guidelines raised to keep discussion progressing[1]. Perhaps an easier way to do this would be to look at the DFSG and work out what changes need to be made. We have a set of freedoms that we believe software should provide - rather than providing an entirely different set of freedoms for documentation, we should try to justify any changes in those freedoms. Personally, I'm inclined to believe that free documentation should have all the freedoms that we think should be provided by free software. Do you believe it needs more freedoms? Fewer freedoms? A slightly different set of freedoms? -- Matthew Garrett | [EMAIL PROTECTED]
Re: Debian Free Documentation Guidelines was: License of old GNU Emacs manual
O Mércores, 5 de Xaneiro de 2005 ás 03:39:25 +1100, Anand Kumria escribía: > We wrote the Debian /Free Software/ Guidelines, there isn't anything > stopping us from creating the Debian /Free Documentation/ Guidelines. For Debian, software is everything that is stored or transmitted in digital form. For example, a PDF is software, but a printed copy of that PDF is not software. Debian aims to distribute only free software, as in "only stuff which is stored or transmitted in digital form, and which is considered free by us". -- Jacobo Tarrío | http://jacobo.tarrio.org/
Re: Debian Free Documentation Guidelines was: License of old GNU Emacs manual
On Wed, 05 Jan 2005, Anand Kumria wrote: > We wrote the Debian /Free Software/ Guidelines, there isn't anything > stopping us from creating the Debian /Free Documentation/ Guidelines. Indeed. And as you suggested, we can just let the maintainer choose whether a document is to follow the DFSG (because he feels it is part of the software itself) or the DFDG (because he feels it is just a document). This assumes the DFSG to be more strict than the DFDG, and it should reduce a bit any resistance against the DFDG (since a lot of people feel that essential documentation that comes with a program IS part of the software itself, and I am one of them). As for what could compose the DFDG, there is a farily good set of ideas on Manoj's page (which are in line with the DFSG): < begin quote > Freedoms for Documentation Analogous to the software program freedoms, we need to articulate the freedoms required for the subset of software called documentation. 1. The freedom to read the text, for any purpose. 2. The freedom to study how the text is written, and adapt it to your needs. Access to the text in the preferred form for modification is a precondition for this. This includes the ability to modify the work to fit in low memory situations, reference cards, PDA's, embedded devices, etc. 3. Freedom to reformat the document into a preferred format or medium (converting to braille, or speech, or hardcopy, or postscript, etc). 4. The freedom to redistribute copies so you can help your neighbor. 5. The freedom to improve the text, and release your improvements to the public, so that the whole community benefits. Access to the preferred form for modification is a precondition for this. For program documentation, this implies being able to change the documentation to reflect the changes in the program. 6. Freedom to translate the text into any other language. 7. The freedom to keep your modifications, or even your possession of a copy of the text, confidential. < end quote > IF we ever add some sort of rule that lets less-free documents make it to Debian, I'd strongly suggest that said rule should only be applicable to **TECHNICAL** standards such as RFCs, W3C documents, ISO documents, IEEE documents, etc. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: Debian Free Documentation Guidelines was: License of old GNU Emacs manual
Henrique de Moraes Holschuh wrote: As for what could compose the DFDG, there is a farily good set of ideas on Manoj's page (which are in line with the DFSG): < begin quote > Freedoms for Documentation Analogous to the software program freedoms, we need to articulate the freedoms required for the subset of software called documentation. 1. The freedom to read the text, for any purpose. 2. The freedom to study how the text is written, and adapt it to your needs. Access to the text in the preferred form for modification is a precondition for this. This includes the ability to modify the work to fit in low memory situations, reference cards, PDA's, embedded devices, etc. And here the whole thing falls on its face: As I read it in the other messages, GFDL docs with (big) invariant sections must be rejected under this point, thus adopting such a policy wouldn't change the situation much. Regards, David
Re: Debian Free Documentation Guidelines was: License of old GNU Emacs manual
Anand Kumria <[EMAIL PROTECTED]> wrote: > I don't believe that Documentation is similiar enough to Software that > we can blindly apply the DFSG. Please explain what documentation is in debian which is not also software. That is conspicuously absent from your summary. I suggest that there is no non-software documentation in debian at present and there probably never will be. Remember that "software" and "programs" are not synonyms. -- MJR/slef My Opinion Only and maybe not of groups I know.
Re: Debian Free Documentation Guidelines was: License of old GNU Emacs manual
Henrique de Moraes Holschuh wrote: > On Wed, 05 Jan 2005, Anand Kumria wrote: > > We wrote the Debian /Free Software/ Guidelines, there isn't anything > > stopping us from creating the Debian /Free Documentation/ Guidelines. > > Indeed. And as you suggested, we can just let the maintainer choose whether > a document is to follow the DFSG (because he feels it is part of the > software itself) or the DFDG (because he feels it is just a document). This > assumes the DFSG to be more strict than the DFDG, and it should reduce a bit > any resistance against the DFDG (since a lot of people feel that essential > documentation that comes with a program IS part of the software itself, and > I am one of them). Here is my problem, and my take, on the situation. If we have a Free Documentation Guideline, where would these documents reside? In main? In doc/main? If in main, what distinguishes the bits in a document (README.TXT) from the program (hello_world)? If in doc/main, would there be a single source package generating the program .deb, and the documentation .deb? If so, what distunguishes the bits of the orig.tar.gz fromthe source (hello.c) and the documentation (README.TXT)? If we split out the upstream tarball, would there be a separate documetation cd? Perhaps I am Old School in as much as I think of software as being a logic stream, and hardware being the physical bits. Ink on paper is hardware. Pits in aluminum oxide is hardware. Aligned magentic domains are hardware. The logical representation of 1 and 0 is software. In this very simple definition, all of our documentation is software (except printed manuals that we do not distribute, except perhaps at trade shows in the form of flyers. Certainly no one thinks of a flyer as the Debian GNU/Linux Universal Operating System). Everything in our archive is software. Why would we create a second-class definition of software, to fit in common misconception that digital documentation is not software? Or am I just a dying breed? -- John H. Robinson, IV [EMAIL PROTECTED] http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html
Re: Debian Free Documentation Guidelines was: License of old GNU Emacs manual
MJ Ray <[EMAIL PROTECTED]> wrote: > Anand Kumria <[EMAIL PROTECTED]> wrote: >> I don't believe that Documentation is similiar enough to Software that >> we can blindly apply the DFSG. > > Please explain what documentation is in debian which is not also software. > That is conspicuously absent from your summary. I suggest that there is > no non-software documentation in debian at present and there probably > never will be. Remember that "software" and "programs" are not synonyms. We altered the social contract precisely because not everyone agrees with that statement. I agree that everything in Debian should be held to the terms of the DFSG, and I agree that software is a better term than most others to describe non-executable strings of bits. Others disagree. But that's not an argument we have to have again, because the social contract no longer includes the word "software" in point 1. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Debian Free Documentation Guidelines was: License of old GNU Emacs manual
On Tue, 04 Jan 2005, David Schmitt wrote:
> And here the whole thing falls on its face: As I read it in the other
> messages, GFDL docs with (big) invariant sections must be rejected under
> this point, thus adopting such a policy wouldn't change the situation much.
This is a *given*. The DFDG would have to be written along with the lines
of the DFSG, that will NOT allow RFCs, nor GFDL invariant docs.
We may have *exceptions* later ("we accept DFDG-compliant docs, plus
distributable documents that match the following criteria") that would
allow a certain set of documents that do not follow the DFDG in. Whether
that set will include GFDL docs, GFDL docs with invariant sections,
completely invariant non-GFDL docs (RFCs, w3c standards), or *some* of those
documents according to some criteria is something to be seen.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Re: Debian Free Documentation Guidelines was: License of old GNU Emacs manual
On Tue, 04 Jan 2005, John H. Robinson, IV wrote: > Here is my problem, and my take, on the situation. If we have a Free > Documentation Guideline, where would these documents reside? In main? In > doc/main? Wherever they are now. If they are acceptable, they go in main somewhere, this really matters very little. > If in main, what distinguishes the bits in a document (README.TXT) from > the program (hello_world)? If in doc/main, would there be a single Since this is an old point, and we already it clear that there are two camps in the project, and we need to cater for the two camps, why bother? There *is* a reason why I said that allowing a maintainer to decide if he would apply the DFDG or DFSG rules to a document would be a good idea. It is there so that you _can_ treat it as software if you wish to. > Why would we create a second-class definition of software, to fit in > common misconception that digital documentation is not software? Or am I > just a dying breed? May we discuss this in another thread, please? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: Debian Free Documentation Guidelines was: License of old GNU Emacs manual
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > On Tue, 04 Jan 2005, John H. Robinson, IV wrote: >> If in main, what distinguishes the bits in a document (README.TXT) from >> the program (hello_world)? If in doc/main, would there be a single > > Since this is an old point, and we already it clear that there are two camps > in the project, and we need to cater for the two camps, why bother? There is no necessity to attempt to make everyone happy. We do not need to cater for the two camps, especially as doing so will *not* make everyone happy. People who believe that documents should meet the same freedoms as programs will be unhappy about any documents in main that don't - people who believe that documents don't need to meet the same freedoms will be unhappy that any are removed. Either we treat documents in the same way as programs, or we don't. If we don't, we need to justify *why* a different set of freedoms is required. That justification needs to be strong enough to convince a 3:1 majority of developers, since it'll require changing the social contract. So far, I have not seen a single convincing argument as to why documentation needs different freedoms to executable code. The existence of this thread is a good opportunity to try to find some. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Debian Free Documentation Guidelines
Jacobo Tarrio: For Debian, software is everything that is stored or transmitted in digital form. I just checked my dictionaries and checked "define:software" on Google, and most sources define software along the lines of "computing programs designed to perform various applications, e.g. word processing"[1]. That is, only the pieces of information that is used to make the computer run is included in the definitions. Only a few definitions define software as "everything non-hardware", which would include the data and documentation. Why is it so clear that in Debian, we chose to subscribe to the second definition? Apparently from these discussions that pop up every now and then there are several people that agree more with the first one (that would include me). Debian aims to distribute only free software, as in "only stuff which is stored or transmitted in digital form, and which is considered free by us". We only talk about software in our social contract. There's no official statement that I know of that defines software to be that. -- \\// Peter - http://www.softwolves.pp.se/ [1] Quote from The Cassell Concise Dictionary, 1997
documentation x executable code
On Tue, 04 Jan 2005, Matthew Garrett wrote: > So far, I have not seen a single convincing argument as to why > documentation needs different freedoms to executable code. The existence > of this thread is a good opportunity to try to find some. Well, let's rename the thread then (did that). Here's what *I* think about it, so that you all know my position from day one: 1. The kama sutra is documentation (really :-) ) 2. The emacs manual is documentation 3. The autoconf info manual is documentation 4. The autobook and cvsbook books are documentation 5. The W3C recommendations, RFCs and POSIX standards are documentation BUT 1. The kama sutra is not software, because it is not part of anything containing executable code *and* it was *not* created with the intent of ever being such. 2. The emacs manual is software, because it is an *essential* part of the whole emacs suite. It was created with the clear intent to be distributed along with the emacs executable. 3. The autoconf info manual is also software, due to the same reasoning on (2). It also contains examples that are supposed to be used and are executable code. Upstream is fixing that little problem. 4. The autobook and cvsbook are NOT software. Even in sgml format + stylesheets, or in PostScript format (and PostScript *is* executable code). It is all on the *intent*. They are not *essential* documentation (otherwise they would have been part of the original CVS and autotools packages -- that the essential documentation was not good enough to preclude the two books being written is not an issue). 5. While RFCs and other standards are often *essential* documentation of something (e.g. when a RFC is the sole document of an API), they predate the executable AND they where NOT written to be the companion of any executable, but rather to define how all executables in a certain class should behave. Again, it is on the intent. So, I would not say they are software). That would mean that, if I take into consideration the whole reason WHY we have the DFSG freedoms as they are, and in order to protect the idea behind them IMHO 1, 4 and 5 would be eligible for a DFDG rule. 2 and 3 would NOT be, and I do consider a very hard blow on my trust on the FSF that such documents are being distributed in a more restrictive license than the executables. I have since understood why one might want the GFDL for stuff like 4 and 5 (even if I do not like the GFDL), but I do think that it has absolutely no place anywhere near software (and thus, anywhere near the essential documentation of the executables in a software package). I would not have too much trouble with GFDL documentation that is not software in Debian, the same way that I certainly would like to have the RFCs and other standards in Debian. In fact, I'd quite happly welcome such documentation in Debian as long as that means we'd turn all guns to make sure the *software* that is currently under the GFDL is properly relicensed to be free software again. That's where the fight worth fighting is, IMHO. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: Debian Free Documentation Guidelines
Peter Karlsson <[EMAIL PROTECTED]> wrote: > Why is it so clear that in Debian, we chose to subscribe to the second > definition? Apparently from these discussions that pop up every now and then > there are several people that agree more with the first one (that would > include me). It doesn't matter. The social contract says: "We promise that the Debian system and all its components will be free according to these guidelines (the DFSG)." The word software is not used here. Possibly the DFSG should have been renamed at the same time as the word software was removed, but never mind. > We only talk about software in our social contract. There's no official > statement that I know of that defines software to be that. We don't actually talk about software at all in our social contract. We did do until April, though. -- Matthew Garrett | [EMAIL PROTECTED]
Re: documentation x executable code
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > I would not have too much trouble with GFDL documentation that is not > software in Debian, the same way that I certainly would like to have the > RFCs and other standards in Debian. In fact, I'd quite happly welcome such > documentation in Debian as long as that means we'd turn all guns to make > sure the *software* that is currently under the GFDL is properly relicensed > to be free software again. That's where the fight worth fighting is, IMHO. Right. But all you've said is "I think these things are not software", not how or why they should have different freedoms. Let's just list the 9 points of the DFSG: Free Redistribution Source Code (ie, it has to have it) Derived Works (ie, the right to create them) Integrity of The Author's Source Code (patch files and forced renamings are ok) No Discrimination Against Persons or Groups No Discrimination Against Fields of Endeavor Distribution of License License Must Not Be Specific to Debian License Must Not Contaminate Other Software Do you believe that we should provide documentation in main that does not meet all of these? If so, why do you believe that these freedoms are less useful for documentation than executables? -- Matthew Garrett | [EMAIL PROTECTED]
Re: Debian Free Documentation Guidelines was: License of old GNU Emacs manual
* Henrique de Moraes Holschuh: >2. The freedom to study how the text is written, and adapt it to your > needs. Access to the text in the preferred form for modification is a > precondition for this. This includes the ability to modify the work to fit > in low memory situations, reference cards, PDA's, embedded devices, etc. This is could be more restrictive than the DFSG. We consider software free even though redistrubtion is only possible with license texts of substantial length.
Re: Debian Free Documentation Guidelines was: License of old GNU Emacs manual
On Tue, 04 Jan 2005, Florian Weimer wrote: > * Henrique de Moraes Holschuh: > >2. The freedom to study how the text is written, and adapt it to your > > needs. Access to the text in the preferred form for modification is a > > precondition for this. This includes the ability to modify the work to fit > > in low memory situations, reference cards, PDA's, embedded devices, etc. > > This is could be more restrictive than the DFSG. We consider software > free even though redistrubtion is only possible with license texts of > substantial length. We probably have to cater for license texts in documents as well. Good call. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
What the social contract actually says
(Cc:ed to -project, since it's effectively an interpretation of the DFSG argument. Again.) On Tue, 2005-01-04 at 22:53 +0100, Jonas Smedegaard wrote: > Ah, maybe the posts stuck here are not "problems"? Well haleluja - let's > rewrite our contract to clarify that we will hide anything but problems! The social contract says that our bug database will be publicly available. That's all. Yes, that's a limited definition of "problems", but it's *our* definition of problems. It's up to individuals to decide whether they should speak publicly or privately. Your definition would appear to preclude the use of #debian-devel (it's not publicly logged), private mails between developers (they might discuss problems!) or developers discussing any sort of awkward issue when they happen to meet each other (unless it's recorded and put online afterwards, of course). -private is not always used appropriately. This is irritating, but it's not a breach of the social contract in any way whatsoever. -- Matthew Garrett | [EMAIL PROTECTED]
Re: documentation x executable code
On Tue, 04 Jan 2005, Matthew Garrett wrote: > Right. But all you've said is "I think these things are not software", > not how or why they should have different freedoms. Let's just list the > 9 points of the DFSG: > > Free Redistribution > Source Code (ie, it has to have it) > Derived Works (ie, the right to create them) > Integrity of The Author's Source Code (patch files and forced renamings > are ok) > No Discrimination Against Persons or Groups > No Discrimination Against Fields of Endeavor > Distribution of License > License Must Not Be Specific to Debian > License Must Not Contaminate Other Software > Do you believe that we should provide documentation in main that does > not meet all of these? Yes, but not without extra criteria. > If so, why do you believe that these freedoms are less useful for > documentation than executables? I always go back to the technical standards when asked that. Clearly, if anyone can change a standard (without going through whatever is the revision procedure for that standard), it loses most of its most important characterstics. It is no longer capable of ensuring that all implementantions are based on common ground, for example. On the other hand, techinical standards are the kind of documents that would be useful to have/keep in Debian (please recall that I consider stuff like the emacs manual to be software, since IMHO it is an essential part of emacs) EVEN if we are not supposed to change them at will. So, I'd say that for *technical* *documentation*, yes, we should have more relaxed criteria. Again, this does *not* apply to essential parts of software packages. If emacs is GPL, so should be the manual that is supposed to be shipped along with it. That criteria would _not_ be compatible with the GFDL's annoying non-drm-media clauses, but it would be compatible with invariant sections... but since it only would be applied to non-essential documentation, if the invariant parts (of a standard, of a GFDL-revised doc, whatever) start becoming too bothersome, we simply remove the package. I also think that for any other text/documents, we must require something at least as strict as the DFSG. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: documentation x executable code
On Tue, Jan 04, 2005 at 09:04:41PM -0200, Henrique de Moraes Holschuh wrote: > I always go back to the technical standards when asked that. > > Clearly, if anyone can change a standard (without going through whatever is > the revision procedure for that standard), it loses most of its most > important characterstics. It is no longer capable of ensuring that all > implementantions are based on common ground, for example. This is a misconception that has been made and rebunked many times. To prevent pollution of standards, you don't prevent people from modifying the document. That's a very useful thing to do; for example, to reuse an old protocol to create a new one. The solution is to require that the new document not be misconstrued as the one being modified, not to prohibit its reuse entirely. There's no harm in me taking the HTTP standard, renaming it to the "GlennHTTP standard" and making all sorts of changes to it. This type of restriction is explicitly allowed by DFSG#4. Technical standards should be (and are--once 2004-003 kicks back in, at least) held to the same standards of freedom as everything else in Debian. -- Glenn Maynard
Re: documentation x executable code
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > On Tue, 04 Jan 2005, Matthew Garrett wrote: >> If so, why do you believe that these freedoms are less useful for >> documentation than executables? > > I always go back to the technical standards when asked that. > > Clearly, if anyone can change a standard (without going through whatever is > the revision procedure for that standard), it loses most of its most > important characterstics. It is no longer capable of ensuring that all > implementantions are based on common ground, for example. But that's covered by DFSG 4 - it would be acceptable for people to have to rename modified versions. What if I base my fridge stock querying system on IMAP? The easiest way to describe it to others would be to modify the IMAP RFC. We don't require the freedom that modified software can be passed off as the original, and nor do we require the freedom that modified technical standards should be passed off as the original. But we should require that technical standards be modified. The argument fails to stand up anyway. I can write a description of how SMTP works by reverse engineering exim. My standard will deviate from the RFC, but I could still claim that this was how SMTP worked. Microsoft could do the same. Despite this, for the most part people agree on what the standards are - in the case of RFCs, it's the RFC as issued by the IETF. Having modifiable RFCs would make no difference in this respect. -- Matthew Garrett | [EMAIL PROTECTED]
Re: documentation x executable code
On Tue, Jan 04, 2005 at 11:17:06PM +, Matthew Garrett wrote: > Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > > On Tue, 04 Jan 2005, Matthew Garrett wrote: > >> If so, why do you believe that these freedoms are less useful for > >> documentation than executables? > > > > I always go back to the technical standards when asked that. > > > > Clearly, if anyone can change a standard (without going through whatever is > > the revision procedure for that standard), it loses most of its most > > important characterstics. It is no longer capable of ensuring that all > > implementantions are based on common ground, for example. > > But that's covered by DFSG 4 - it would be acceptable for people to have > to rename modified versions. What if I base my fridge stock querying > system on IMAP? The easiest way to describe it to others would be to > modify the IMAP RFC. And indeed, specifications *must* be as free as the software they specify for precisely this reason. It is absolutely vital that when I change a piece of software, I can update the specification to match. This is the same as "Why free software needs free documentation". The situation with the RFCs is an unmitigated disaster, and we should not encourage it to continue by supporting them. Those documents should all have been released under free licenses, and they weren't. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: License of old GNU Emacs manual
On Tue, Jan 04, 2005 at 04:45:34PM +, Matthew Garrett wrote: > I've Cc:ed this to -project - followups should probably go there. > > On Tue, 2005-01-04 at 10:24 -0500, Theodore Ts'o wrote: > > > Either way, the people who are pushing the strict DFSG above all else > > have to see that the fundamental problem is that there are useful bits > > out there that Debian users will want to use (such as the autoconf > > documentation --- if someone hasn't issued an ITP for it in non-free > > yet, I will, soon, because I need it), that are licensed under > > licenses that do not meet a strict interpretation of the DFSG. > > I agree that interpretations of the DFSG that remove large quantities of > material that we've previously thought of as free software are wrong, > and I'm on record as being opposed to various attempts to do so. But > DFSG 4 requires us to be able to modify content. We're willing to bend > that somewhat due to requirements that the GPL and older BSD licenses > have, but I don't believe that objecting to the existence of large and > unmodifiable sections of political content that can't even be removed is > a desperately strict interpretation of the DFSG. why not? we allow it for software, so why not for documentation? in case it's not obvious what i'm talking about, we (grudgingly) allow software which only allows distribution of modifications by patch. this is in no way different to adding extra material which modifies or refutes an invariant section, or even a patch which changes it after installation. > > P.S. Besides, given that the Debian Logo needs to go into non-free, > > since the terms governing its use are also not DFSG compliant, who are > > we really trying to kid? > > I think that that's an argument for the logo being under the wrong > license (and hence us having fucked up in the past) rather than the DFSG > being wrong. actually, it's just a natural consequence of wanting to protect the logo and the trademark from misuse by scumbags -- "scumbags" being defined as anyone who would want to misrepresent themselves or whatever they're doing as being an official part of the debian project, regardless of whether what they are doing is compatible with or contradictory to our aims or not. craig -- craig sanders <[EMAIL PROTECTED]> (part time cyborg)
Re: License of old GNU Emacs manual
Craig Sanders <[EMAIL PROTECTED]> wrote: (invariant sections) > why not? we allow it for software, so why not for documentation? > > in case it's not obvious what i'm talking about, we (grudgingly) allow > software which only allows distribution of modifications by patch. this is in > no way different to adding extra material which modifies or refutes an > invariant section, or even a patch which changes it after installation. It's clearly different to the idea of extra material which modifies or refutes an invariant section, since the user is never exposed to the code that's been patched out - it's an implementation detail. A GUI application which included text saying "This software supports communism" and was under a license that allowed us to add a line saying "Debian does not necessarily endorse this statement" is clearly very different to an application which allowed us to patch that line out. On the other hand, I find the idea of post-installation modification interesting. I think we'd want to talk to a lawyer first, though. Preferably several. > actually, it's just a natural consequence of wanting to protect the logo and > the trademark from misuse by scumbags -- "scumbags" being defined as anyone > who would want to misrepresent themselves or whatever they're doing as being > an official part of the debian project, regardless of whether what they are > doing is compatible with or contradictory to our aims or not. We can provide the logo under a free copyright license but fairly strict trademark license. A restrictive copyright license prevents legitimate modifications as well, which isn't what we want. -- Matthew Garrett | [EMAIL PROTECTED]
Re: License of old GNU Emacs manual
On Wed, Jan 05, 2005 at 12:12:42AM +, Matthew Garrett wrote: > We can provide the logo under a free copyright license but fairly strict > trademark license. A restrictive copyright license prevents legitimate > modifications as well, which isn't what we want. It's not clear whether a work which is affected by a "strict" trademark license is DFSG-free. I don't think much headway has ever been made on figuring out how trademarks and the DFSG interact, probably because there hasn't been much need (the logos clearly havn't been sufficient). I suspect the Mozilla issue may make that happen, though. My intuition is that the Open Use logo should be under a Free copyright license and no trademark, and allowed in main, and the Official Use logo should be under a strict trademark license, and not allowed in main. It doesn't seem to make sense that a logo with a license (of any sort) that says "this image can only be used for these purposes" belongs in main, even Debian's. I don't know if Mozilla-in-Debian should be renamed to avoid the trademark entirely, or if it's acceptable for a work in main to be affected by a non-free trademark license if it's readily changed. As long as it's an easy change, it feels like a change-of-name requirement, eg. DFSG#4. At a glance, that seems contradictory: a trademarked logo not allowed, but a trademarked name allowed. But one's a work in itself, with restrictions on that work (the logo), and the other is a name, which we allow requirements to change. It also seems to make sense from a licensing standpoint: people will frequently be told that "renaming requirements" in a copyright license are pointless, since someone can always create an independant work which is easily confused with that work (eg. fork sendmail and call it "Postfix"), and that trademarks are the correct approach. So, it seems to make sense that DFSG#4 allow implementing change-of-name requirements via trademark. I'm not certain about any of this, though. -- Glenn Maynard
Re: Re: wrong meaning of "GNU/Linux" on Debian Project mainpage
Think about it, just as there is "Debian GNU/HURD" there is "Debian GNU/Linux" and if you want to make it short just make it "Debian". Not that I feel like arguing about or changing the intro text on the website though... It looks ok right now. Cheers Floris I agree with you. What is there currently is quite clear, and I don't think that it is misleading, either. Just as Richard Stallman states, the system comes with GNU utilities, and in our case, GNU utilities, various other unencumbered utilities, and a choice of kernels. I see absolutely nothing either ambiguous or inaccurate about that's there now. I do respect Richard Stallman and I do definitely want to protect software freedom. I think we're already doing that, and we are every bit as vigilant about it, too. Why change what's there? It has said what we intended to say for quite some time. That's my opinion. -- Brian Masinick mailto:[EMAIL PROTECTED]
Re: What the social contract actually says
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thank you for posting in public, matthew! On 04-01-2005 23:28, Matthew Garrett wrote: > The social contract says that our bug database will be publicly > available. That's all. Right. [I would've added something here, but then realized that I would be revealing secrets: text by you in same thread but posted only to - -private and not permitted public quoting - quite frustrating!] > Yes, that's a limited definition of "problems", but it's *our* > definition of problems. It's up to individuals to decide whether they > should speak publicly or privately. Your definition would appear to > preclude the use of #debian-devel (it's not publicly logged), private > mails between developers (they might discuss problems!) or developers > discussing any sort of awkward issue when they happen to meet each other > (unless it's recorded and put online afterwards, of course). I am not against secrets. I am against non-secrets held secret. All emails posted to -private has an implicit "...and don't you dare tell anyone outside of Debian" attached if not explicitly declared differently. That is (to my knowledge) not the case with either #debian-devel or private discussions. - - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB20DOn7DbMsAkQLgRAnhnAJwMSjD+UNetliiTRl6F91WKz3n0uACgpyH7 JGxfg0iYcSTfVDHsOFABUE4= =SlHz -END PGP SIGNATURE-
Re: License of old GNU Emacs manual
On Wed, Jan 05, 2005 at 12:12:42AM +, Matthew Garrett wrote: > On the other hand, I find the idea of post-installation modification > interesting. I think we'd want to talk to a lawyer first, though. > Preferably several. I vaguely recall that we raised this issue with the FSF and they expressed the opinion that they would consider it a breach of the GFDL if the stuff displayed to the user was not the exact invariant form. So the GFDL does not qualify for the patches-only clause. All possible ways in which the GFDL could be suborned to be DFSG-free have been explored at length, years ago. We eventually concluded that it was watertight and the FSF did indeed intend to create a non-DFSG-free license. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: documentation x executable code
On Tue, Jan 04, 2005 at 09:08:57PM +, Matthew Garrett wrote: > Let's just list the 9 points of the DFSG: > > Free Redistribution > Source Code (ie, it has to have it) > Derived Works (ie, the right to create them) > Integrity of The Author's Source Code (patch files and forced renamings > are ok) > No Discrimination Against Persons or Groups > No Discrimination Against Fields of Endeavor > Distribution of License > License Must Not Be Specific to Debian > License Must Not Contaminate Other Software which of these 9 points does the GFDL not meet? craig -- craig sanders <[EMAIL PROTECTED]> (part time cyborg)
Re: documentation x executable code
On Tue, Jan 04, 2005 at 11:17:06PM +, Matthew Garrett wrote: > Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > > On Tue, 04 Jan 2005, Matthew Garrett wrote: > >> If so, why do you believe that these freedoms are less useful for > >> documentation than executables? > > > > I always go back to the technical standards when asked that. > > > > Clearly, if anyone can change a standard (without going through whatever is > > the revision procedure for that standard), it loses most of its most > > important characterstics. It is no longer capable of ensuring that all > > implementantions are based on common ground, for example. > > But that's covered by DFSG 4 - it would be acceptable for people to have > to rename modified versions. What if I base my fridge stock querying > system on IMAP? The easiest way to describe it to others would be to > modify the IMAP RFC. actually, the easiest way would be to write a new RFC (or other document) which referenced the IMAP RFCs. "... except as described below, the protocol is the same as IMAP (note that it requires a refridgerator or freezer of at least 80 litres capacity) ..." craig -- craig sanders <[EMAIL PROTECTED]> (part time cyborg)
Re: documentation x executable code
On Wed, Jan 05, 2005 at 02:11:03PM +1100, Craig Sanders wrote: > > But that's covered by DFSG 4 - it would be acceptable for people to have > > to rename modified versions. What if I base my fridge stock querying > > system on IMAP? The easiest way to describe it to others would be to > > modify the IMAP RFC. > > actually, the easiest way would be to write a new RFC (or other document) > which referenced the IMAP RFCs. > > "... except as described below, the protocol is the same as IMAP (note that it > requires a refridgerator or freezer of at least 80 litres capacity) ..." Sometimes this is a good approach, sometime it isn't. It certainly isn't good to do this for several generations of protocols, so a reader would have to understand a chain of several protocols, each described as a plain-English diff against the previous. Whether to modify the document directly or to explain as a set of changes should be up to the person creating a new standard, not set in stone by the license in an overly- broad attempt at preventing confusion. This is not a convincing argument for why freedom is unimportant for standards documents (and so unimportant that Debian should actually make an exception to allow it, with all of the slippery slopes and other messes that would entail). -- Glenn Maynard
Re: Debian Free Documentation Guidelines
Peter Karlsson <[EMAIL PROTECTED]> wrote: > I just checked my dictionaries and checked "define:software" on Google, and > most sources define software along the lines of "computing programs designed > to perform various applications, e.g. word processing"[1]. That is, only the > pieces of information that is used to make the computer run is included in > the definitions. Most sources are biased. Think about what the source may gain or lose if more people realise they are producing software rather than "electronic books" or whatever. The program-only definition isn't the original one. An example that I think is the earliest one in print from Tukey was given on debian-legal many months ago. The one quoted above is also terribly wrong. That definition would mean that some of the programs in debian aren't software because they do not perform an application themselves. Ow. It shames the FSF that they only care about free programs rather than free software. Some of their prominent members have written about the absurdity about trying to distinguish types of bitstream in order to apply different rules, but the advice hasn't been heeded by FSF. Finally, I suspect it is easier for second-language speakers of English to mis-equate "program" and "software", especially if they consult a bilingual dictionary. It seems that some languages don't have their own word for software, only one for program. Ow. -- MJR/slef
Re: documentation x executable code
On Tue, Jan 04, 2005 at 10:28:29PM -0500, Glenn Maynard wrote: > On Wed, Jan 05, 2005 at 02:11:03PM +1100, Craig Sanders wrote: > > [ ... referencing earlier docs ... ] > > Sometimes this is a good approach, sometime it isn't. It certainly isn't > good to do this for several generations of protocols, so a reader would > have to understand a chain of several protocols, each described as a > plain-English diff against the previous. Whether to modify the document > directly or to explain as a set of changes should be up to the person > creating a new standard, not set in stone by the license in an overly- > broad attempt at preventing confusion. sorry, but that argument is bogus. convenience is NOT the same as freedom. more to the point, freedom does not require convenience. there are reasons why RFCs qualify as non-free, but convenience isn't one of them. > This is not a convincing argument for why freedom is unimportant for > standards documents (and so unimportant that Debian should actually > make an exception to allow it, with all of the slippery slopes and > other messes that would entail). personally, i think that: a) the utility value of RFCs and similar technical documentation, combined with b) the fact that there is an established procedure for amending RFCs and creating new ones which is *open to all*, AND c) the fact that very few people (far less than one in a million readers) will ever have any desire to modify them, is more than sufficient reason to be a bit more tolerant about freedom criteria for documents. in short, it doesn't make any practical *OR* ethical difference so it doesn't matter in the slightest. craig ps: the GPL itself is non-free. you're not allowed to modify it, so it is non-free. it must therefore be discarded from debian (or moved to non-free). furthermore, since GPL-licensed software requires that the license be distributed with the software, and we are unable to meet that requirement, all GPL-licensed software must likewise be discarded from debian. please explain why we should be willing to make an exception for the GPL text, but not for other texts. also, please convince me why i should not file a bug report against base-files for including the non-free documents "/usr/share/common-licenses/GPL" and "/usr/share/common-licenses/GPL-2", and against all other packages which include a copy of the GPL, and all packages which reference these files in their own copyright statement (i.e. probably about 70% of debian). i probably should file bugs against all packages which depend on base-files too, but since it is "Essential: yes" that effectively means all packages in debian, and that would be silly. -- craig sanders <[EMAIL PROTECTED]> (part time cyborg)
Re: documentation x executable code
On Wed, Jan 05, 2005 at 04:02:38PM +1100, Craig Sanders wrote: > On Tue, Jan 04, 2005 at 10:28:29PM -0500, Glenn Maynard wrote: > > On Wed, Jan 05, 2005 at 02:11:03PM +1100, Craig Sanders wrote: > > > [ ... referencing earlier docs ... ] > > > > Sometimes this is a good approach, sometime it isn't. It certainly isn't > > good to do this for several generations of protocols, so a reader would > > have to understand a chain of several protocols, each described as a > > plain-English diff against the previous. Whether to modify the document > > directly or to explain as a set of changes should be up to the person > > creating a new standard, not set in stone by the license in an overly- > > broad attempt at preventing confusion. > > sorry, but that argument is bogus. convenience is NOT the same as freedom. > more to the point, freedom does not require convenience. Convenience and freedom are not the same, but they are related. You have the freedom to write a program which operates in a manner exactly the same as acroreader, but without some irritating bug (choose whichever one you like). It would be far more convenient if you had the source to acroread to make simply the bugfix you require, but freedom does not require convenience. So acroread is Free. Cool. > personally, i think that: > > a) the utility value of RFCs and similar technical documentation, > > combined with > > b) the fact that there is an established procedure for amending RFCs and >creating new ones which is *open to all*, > > AND > > c) the fact that very few people (far less than one in a million readers) will >ever have any desire to modify them, > > is more than sufficient reason to be a bit more tolerant about freedom > criteria for documents. > > in short, it doesn't make any practical *OR* ethical difference so it doesn't > matter in the slightest. I don't see much of a case at all for "no practical difference" in what you wrote above. The only form of "amendment" that can be made is to reissue a newly written RFC saying "this previous one is wrong", but your new RFC cannot be a derived work of the superceded one. That's a real practical difference to me. > ps: the GPL itself is non-free. you're not allowed to modify it, so it is > non-free. it must therefore be discarded from debian (or moved to non-free). > furthermore, since GPL-licensed software requires that the license be > distributed with the software, and we are unable to meet that requirement, all > GPL-licensed software must likewise be discarded from debian. > > please explain why we should be willing to make an exception for the GPL text, > but not for other texts. Ghods, not this one again. The GPL, as a text of it's own, would most certainly fail the DFSG. We only include the GPL as a description of the terms under which much of the software in Debian is distributed, which is very, very inviolable -- the moment you start trying to modify the licence terms of a piece of software without the permission of the copyright holder, you're deep in "do not pass go, do not collect $200" territory. - Matt signature.asc Description: Digital signature
Re: documentation x executable code
On Wed, Jan 05, 2005 at 04:02:38PM +1100, Craig Sanders wrote: > sorry, but that argument is bogus. convenience is NOT the same as freedom. > more to the point, freedom does not require convenience. This isn't a matter of convenience. A "standard" which is explained as a set of changes to a previous standard, which itself is a set of changes to another, going down a chain of several old documents, is not inconvenient; it's completely useless. The only thing forcing me to make a choice between "writing a standards diff that's too many generations down" versus "start from scratch" is the license. > personally, i think that: > > a) the utility value of RFCs and similar technical documentation, > > combined with > > b) the fact that there is an established procedure for amending RFCs and >creating new ones which is *open to all*, > > AND > > c) the fact that very few people (far less than one in a million readers) will >ever have any desire to modify them, > > is more than sufficient reason to be a bit more tolerant about freedom > criteria for documents. I disagree strongly. b) is unsufficient, as I've already explained. a) is very weak; the utility of Netscape, back when it was important, was very high for a massive number of users, and it was just as weak then. c) is very weak; very few people will want to modify anything at all in Debian: most users are not programmers (even if Debian is probably biased high compared to other systems), and most programmers modify a tiny percentage of the code installed on their machines. > ps: the GPL itself is non-free. you're not allowed to modify it, so it is Actually, this is incorrect. You can modify the GPL, but you have to remove the preamble, and rename it to something other than the "GPL"[1]. However, the preamble itself is an invariant text, so the question does apply (even though it's been asked and answered many times before--as I suspect you're aware). (The misconception that the GPL can not be modified is usually a result of #1: the "changing it is not allowed" text at the top of the GPL, but the FSF grants that permission anyway at [1], and #2: [2], which is confusingly written, which appears to really mean "no, you can't modify the GPL, but if you rename it, it's no longer the GPL, so you can modify it". The FSF refuses to clarify this; I suspect it's a deliberate bit of confusion to discourage people from forking the license, a goal which I sympathize with but a method I do not.) > non-free. it must therefore be discarded from debian (or moved to non-free). > furthermore, since GPL-licensed software requires that the license be > distributed with the software, and we are unable to meet that requirement, all > GPL-licensed software must likewise be discarded from debian. > > please explain why we should be willing to make an exception for the GPL text, > but not for other texts. We shouldn't be. However, there is absolutely no choice but to include the text of the GPL; it'd leave us with no operating system. License texts (when detached from an actual work) don't need to be invariant, but as many important ones (unfortunately) are, we have no choice. I'm not aware of any other non-free bits of data in Debian with the status of "we have absolutely no choice", other than license texts, so nothing else puts Debian in this position. Attempting to use license texts as a lever to shove other non-free stuff into Debian is not going to work (that's been tried many times already). With everything else, Debian has a choice--and GR 2004-003 shows that Debian has, in fact, made that choice: to not include non-free standards documents. [1] http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL [2] http://www.gnu.org/licenses/gpl-faq.html#GPLOmitPreamble -- Glenn Maynard
