Amendment: GFDL is compatible with DFSG
Hereby I am proposing an amendment to the GR about GFDL opened by Anthony Towns [Sun, 01 Jan 2006 15:02:04 +1000] I wish to thank everybody who will support this amendment, especially I wish to thank those who second it. I wish to thank also the members of the Debian mailing list at lists.uni-sofia.bg, who assisted me with the text. Anton Zinoviev --- GNU Free Documentation License protects the freedom, it is compatible with Debian Free Software Guidelines ~~ (0) Summary This is the position of Debian Project about the GNU Free Documentation License as published by the Free Software Foundation: We consider that works licensed under GNU Free Documentation License version 1.2 do fully comply both with the requirements and the spirit of Debian Free Software Guidelines. Within Debian community there has been a significant amount of uncertainty about the GNU Free Documentation License (GFDL), and whether it is, in fact, a "free" license. This document attempts to explain why Debian's answer is "yes". (1) What is the GFDL? The GFDL is a license written by the Free Software Foundation, who use it as a license for their own documentation, and promote it to others. It is also used as Wikipedia's license. To quote the GFDL's Preamble: The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. (2) The Invariant Sections - Main Objection Against GFDL One of the most widespread objections against GFDL is that GFDL permits works covered under it to include certain sections, designated as "invariant". The text inside such sections can not be changed or removed from the work in future. GFDL places considerable constraints on the purpose of texts that can be included in an invariant section. According to GFDL all invariant sections must be also "secondary sections", i.e. they meet the following definition A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. [...] The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. Consequently the secondary sections (and in particular the invariant sections) are allowed to include only personal position of the authors or the publishers to some subject. It is useless and unethical to modify somebody else's personal position; in some cases this is even illegal. For such texts Richard Stallman (the founder of the Free Software Movement and the GNU project and author of GFDL) says [1]: The whole point of those works is that they tell you what somebody thinks or what somebody saw or what somebody believes. To modify them is to misrepresent the authors; so modifying these works is not a socially useful activity. And so verbatim copying is the only thing that people really need to be allowed to do. This feature of GFDL can be opposed to the following requirement of Debian Free Software Guidelines: 3. Derived Works The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. It is naive to think that in order to fulfil this requirement of DFSG the free licenses have to permit arbitrary modifications. There are several licenses that Debian has always acknowledged as free that impose some limitations on the permitted modifications. For example the GNU General Public License contains the following clause: If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the p
Re: Amendment: GFDL is compatible with DFSG
On Mon, Jan 23, 2006 at 02:29:38AM +0100, Wouter Verhelst wrote: > On Mon, Jan 23, 2006 at 01:45:40AM +0200, Anton Zinoviev wrote: > > > For example the GNU General Public License contains the following > > clause: > > > >If the modified program normally reads commands interactively when > >run, you must cause it, when started running for such interactive > >use in the most ordinary way, to print or display an announcement > >including an appropriate copyright notice and a notice that there > >is no warranty (or else, saying that you provide a warranty) and > >that users may redistribute the program under these conditions, and > >telling the user how to view a copy of this License. > > This argument has been brought up a number of times already, but it does > not hold. It is possible that this argument does hold the way it has been used. However here I am using it in a different way - to prove something you will certainly agree. This is my point: many licenses, including GPL, enforce some restrictions on the modifications and despite that we consider them DFSG clean. Consequently when judging whether some license is free or not, one has to take into account what kind of restrictions are imposed (not just whether there are restrictions or not). > The primary objection to the invariant sections in the GFDL is precisely > that this is not possible; if you would want to synthesize a manual into > something small, you would still not be allowed to remove the invariant > sections. Worse; since after synthesizing the text the bits that are > about the subject matter could end up being smaller than the cumulative > amount of invariant sections, it might not even be legally possible to > synthesize a manual. We are not allowed to remove the copyright notices from many programs and manuals but we don't claim they are non-free because of these copyright notices. These notices can be very long as we see from /usr/share/doc/x11-common/copyright. These notices can also contain personal statements as we see from the preamble of GPL. What if someone includes the GNU Manifesto in the preamble of a free documentation license - we would not say that this license is non-free, would't we? > Synthesizing info manuals is something that Debian does regularly (or, > at least, should do; our policy requires that every binary comes with a > manpage, and that info documentation is not sufficient. Extracting the > relevant bits from the info manual would be the logical choice to remedy > this). If the man-page is structured as a chapter from a bigger document, then it would be unnecessary to include the invariant sections in it. The man-pages of Perl show how a man-page can be a part from bigger document. (I must admit it didn't occured to me that if we remove the GFDL-licensed info-manuals from Debian, then we will have to remove also the automatically generated man-pages...) > > The licenses that contain the so called "advertising clause" give us > > another example: > > > >All advertising materials mentioning features or use of this > >software must display the following acknowledgement: "This product > >includes software developed by ..." > > Again, this analogy does not hold. Advertising clauses only apply to > advertising material, not to the software (or the manual) itself; > conversely, the requirements in the GFDL regarding invariant sections, > acknowledgements and cover texts _do_ apply to the manual itself. Nevertheless, the Advertising clauses can apply to components that Debian distributes and considers 100% free. The requirements in the GFDL are limited only to some special sections from the manual. The requirements of the Advertising clause can potentially apply to anything - for example to the Help/About dialogs or to any manuals that mention features or use of the software. GFDL restricts only directly derived documents, the Advertising clause restricts all advertising materials. > > Consequently when judging whether some license is free or not, one has > > to take into account what kind of restrictions are imposed and how > > these restrictions fit to the Social Contract of Debian: > > > >4. Our priorities are our users and free software > > This part of the Social Contract does not mean that we should bend the > rules of freedom to accomodate for our users. As such, it cannot be an > argument as to whether the GFDL is free or not. Ofcourse it does not mean that. The point is that me can not impose on the free software community alternative meaning of "free software". > It says that you *must* either include a Transparent copy along with > each opaque copy If the website contains both the tr
Re: Amendment: GFDL is compatible with DFSG
or maintain > > > a website (or something similar) for no less than one year after > > > distributing the opaque copy. > > > > Sadly - many Debian developers consider this an argument against GFDL > > even though the restrictions of GPL are way more severe. For printed > > books GPL would require from you to include either CD-ROM or written > > offer to distribute the transparent copy at minimal cost at least for > > three years. > > First, I do not consider a requirement to write a little text on a piece > of paper and to sign it a more severe requirement than to either include > a CD-ROM or maintain a website. Acording to the licenses this is the choice here: GPL: include CD-ROM or obligate myself to distribute the sources at minimal cost for three years GFDL: include CD-ROM or maintain a website for one year > While the GPL does indeed allow you to offer both and let the user > take whatever he or she wants, the requirement as written in the > GFDL does not allow that. Sure, that's a bug, but the fact that it > is a bug does not make the problem go away. It is not a bug, it is a wrong interpretation of the license. > > The lawyer of FSF is a professor in jurisprudence. > > So? He is not omnipotent, so can make errors. If a judge somewhere > decides against the intent of the license, then the harm has been done. This can happen with all licenses and if it happens the harm can be irreparable. If it ever happens with GFDL then the harm will be reparable because FSF can release a new version of the license. With that I do not claim the rules of GFDL are more clear than the rules of some other licenses - maybe they are not. What I claim is we should not exaggerate the problems. The rules of GFDL are not so unclear to make a real danger for the license to be misinterpreted in a court. > > > >You may not use technical measures to obstruct or control the > > > >reading or further copying of the copies you make or distribute > > > > > > > > This clause disallows the distribution or storage of copies on > > > > DRM-protected media only if a result of that action will be that the > > > > reading or further copying of the copies is obstructed or controlled. > > > > It is not supposed to refer the use of encryption or file access > > > > control on your own copy. > > > > > > No; however, as written it can be interpreted as such. > > > > If you do not have any access to my encrypted or "chmod -r" copy, then > > I am not controllyng your reading or further copying > > Really. If you maintain a copy of a GFDL'ed work on one of your > debian.org home directories without the world-writable read bit set, you > are in violation of the license, as written. You are not in violation of the license. You can not control the reading or further copying if you do not allow the reading or further copying to happen. You would be in a violation only if the world-readable bit is not set for part of the document. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: GFDL is compatible with DFSG
imal cost for three years > > > > GFDL: include CD-ROM or maintain a website for one year > > First, the GPL says "reasonable", not "minimal". I don't understand this. > Second, maintaining a website with the transparent versions of your > opaque copies in such a way that they are ready for download at any time > for a whole year sounds like more effort to me than the requirement to > be able to, somehow, find that patch that you applied somewhere in your > version control system, and then mail it to someone asking you for it, > together with a source tarball which you could then download again from > the project's website of which you used the source. Thats up to personal opinion. Anyway, its not this requirement what makes some people think GFDL is non-free. > > > While the GPL does indeed allow you to offer both and let the user > > > take whatever he or she wants, the requirement as written in the > > > GFDL does not allow that. Sure, that's a bug, but the fact that it > > > is a bug does not make the problem go away. > > > > It is not a bug, it is a wrong interpretation of the license. > > However, I do not think that the interpretation that I gave you here is > inconsistent with the text of the license. As such, it is a valid > interpretation of the license text and, since it was not intended to be > the meaning of this license, a bug. The preposition "along" in the license does not mean "with". > You cannot undo whatever a judge decided; if this involves fines for > some party who acted in accord with the license's intend, you cannot > undo those fines. > > You cannot prevent it from happening to already-existing documents under > the same license; anyone could use the old version of the document under > the old terms, and sue you. OK. > > What I claim is we should not exaggerate the problems. The rules of > > GFDL are not so unclear to make a real danger for the license to be > > misinterpreted in a court. > > We clearly disagree here. OK. > > You are not in violation of the license. You can not control the > > reading or further copying if you do not allow the reading or further > > copying to happen. > > Uh, go find a dictionary somewhere. If you do not allow the reading or > further copying to happen, then you are, effectively, controlling the > reading or further copying of the document. My dictionary says the meaning of "control" is "to have power to direct or restrain; to regulate". You can not control something that does not exist. To "control the reading" means to make you able to read the document today but not tomorow. To "control the further copying" means to make you unable to give a copy of the document to your friends. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: GFDL is compatible with DFSG
we don't have to put all invariant sections and the full text of GFDL in every single GFDL-covered man-page. > > > > Acording to the licenses this is the choice here: > > > > > > > > GPL: include CD-ROM or obligate myself to distribute the sources at > > > > minimal cost for three years > > > > > > > > GFDL: include CD-ROM or maintain a website for one year > > > > > > First, the GPL says "reasonable", not "minimal". > > > > I don't understand this. > > "reasonable" means "you're allowed to ask money for the act of producing > the source, but you're not allowed to try and scare people away from > asking the source by setting the price extremely high". > > "minimal" means "you must do your best to make sure the price is as low > as possible". I must be missing something - I can't see these words in the licenses. > The latter would not allow anyone to make some profit out of selling > CD-ROMs with source; the former does. GPL says: "for a charge no more than your cost of physically performing source distribution". This does not seam to allow making profit. > To comply with the GPL's source requirement (without offering it along > with the binaries, or without passing on any offer you already > received), it suffices to take out a piece of paper, scribble an offer > on that for source until some date at least three years into the future, > and sign it (and to make sure you'll be able to actually get that > source, should anyone ever choose to excercise their rights -- but you > can deal with that if it is ever necessary). Total time required to > comply with the GPL: 45 seconds. If you are speaking for you or me then I agree. This is the time that we need. However for a firm the burden is much more - if someone requests the sources after 35 months then the firm must be prepared to extract the sources from its archive, to write them on CD, to pack the CD and to send the CD by parcel post. Thats why most firms that sell GPL-covered software do not take advantage of that option and they always sell the software together with the sources. > To comply with the GFDL's transparent copy requirement, you must have a > website large enough to hold the full transparent copy to the document, > and pay the bills for that webspace for at least a year. Total time > required to comply: impossible to say. Not everyone is a geek with their > own webserver; some people have a 20MB quota on their ISP's webserver. > Having to use 5MB for a transparent copy of a document which they just > printed out for a friend isn't very interesting. Having to pay some tens > of euros per month for a whole year for webspace at a commercial hoster > just so you'll be able to legally distribute a printed copy isn't much > better. Acording to GFDL you don't have do anything if you just printed out the document for your friend. You have to take some actions only if you publish or distribute more than 100 printed copies of one document. If you realy want to distribute more than 100 printed copies of one document and it is a burden for you to have some webspace, then you can offer the sources on CD together with the printed copies. > > The preposition "along" in the license does not mean "with". > > 'along with'... OK. Let's check again the dictionary. Acording to it the "along" from the license should mean "in company, in addition" (the other meanings are not applicable). So this is what the license says: "include a machine-readable Transparent copy in addition with each Opaque copy". If you include the transparent copy in the web-server in addition to the opaque copy, then you are ready with the requirements of GFDL. > > > > You are not in violation of the license. You can not control the > > > > reading or further copying if you do not allow the reading or further > > > > copying to happen. > > > > > > Uh, go find a dictionary somewhere. If you do not allow the reading or > > > further copying to happen, then you are, effectively, controlling the > > > reading or further copying of the document. > > > > My dictionary says the meaning of "control" is "to have power to > > direct or restrain; to regulate". You can not control something that > > does not exist. > > > > To "control the reading" means to make you able to read the document > > today but not tomorow. To "control the further copying" means to make > > you unable to give a copy of the document to your friends. > > It also means you try to 'direct or restrain' anyone who tries to make a > copy of your version. If you use technical measures to make the act of > making copies impossible, you 'control the further copying'. It would be possible to interpret the license that way if the text was "you may not use technical measures to obstruct or control how someone reads or further copyes...". If I do not allow you to read some text written on sheet of paper then I am controlling you, not your reading (there is no reading to control). If I show you the text but I hide it before you completed the reading then I am controlling both you and your reading. > If you chmod -r a file, you are use technical measures to make the act > of making copies impossible. So there exists no act I can control. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: GFDL is compatible with DFSG
On Tue, Jan 24, 2006 at 12:42:27AM +1300, Anthony Towns wrote: > > > It is naive to think that in order to fulfil this requirement of DFSG > > Calling your fellow developers "naive" isn't terribly nice, you sell > out... ;) I do not call my fellow developers "naive" because they do not think this. In order to not write twice same thing, both to you and to Wouter Verhelst, I will elaborate in a separate thread. > > It is a fact confirmed by Richard Stallman, author of GFDL, > > Cite, please. I sent Richard Stallman a draft of my proposal where this paragraph contained the words "it is our belief that". The responce by Stallman was "You can state that as more than just your belief. It's a fact." Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: GFDL is compatible with DFSG
On Mon, Jan 23, 2006 at 07:59:44PM -0600, Peter Samuelson wrote: > > That does not follow at all. If the GNOME Foundation chooses to > license documents as GFDL, it does not mean they believe it is a free > software license. It can just as easily signify that they do not > believe documentation should be free software. They certainly believe the documentation should be free. > As for "violating its Social Contract", that's just rhetoric. The > Contract assumes that our users are entitled to free software; if > certain users who write documentation for other projects decide that > they don't care about free software, that's beside the point. Maybe they just don't care about your personal opinion what "free software" means. ;-) > >You must either include a machine-readable Transparent copy ALONG > >WITH each Opaque copy > > Yeah, "along with" means "with". In my dictionary "along" is explained as "in company, in addition" (the other meanings of "along" are not applicable). So the license says "include a machine-readable Transparent copy in addition with each Opaque copy". If you include the transparent copy in the web-server in addition to the opaque copy, then you are in comply with the requirements of GFDL. > >or state IN OR WITH each Opaque copy a computer-network location > >from which the general network-using public has access to download > >using public-standard network protocols a complete Transparent > >copy of the Document, free of added material. > > So "free of added material" means that if you want to offer CD images > for download, you can't just offer source CD images, or even Debian > source packages - you have to offer individual documents in source > form. "A complete Transparent copy of the Document, free of added material" clearly means that the transparent copy has to be free of added material, not the CD image. > For at least a year after you take down the binary CD images from > your site. Only if the the transparent copy is not along with the opaque copy. On Debian servers the transparent copy is always along with the opaque copy so there is no need to keep any images for a year. > People should think long and hard about this requirement, independent > of whether it is DFSG-compliant. Think about the implications for the > ftp.debian.org mirror network, and for CD and DVD vendors. It's a > pretty significant added burden for everybody - is it worth it? This > is about more than DFSG compliance. A lot of things can be > DFSG-compliant yet could still cause serious practical problems if > Debian were to ship them. I would agree with you but the license doesn't require this burden. > > It is a fact confirmed by Richard Stallman, author of GFDL, and > > testified by the common practice, that as long as you make the source > > and binaries available so that the users can see what's available and > > take what they want, you have done what is required of you. It is up > > to the user whether to download the transparent form. > > I thought that was what RMS said about the *GPL*. Did he also say that > about the GFDL? When and where? He said this when I asked him to comment the draft of my proposal. It is easy to ask him to confirm that publicly but I don't think this is necessary because this follows from the most natural interpretation of the preposition "along with". > Also, what RMS says about the GFDL matters very little when > distributing material not copyrighted by him or the FSF. What > matters then is the interpretation by the author of the material. > This is why it's important to read what a license says, not just > what someone says a license is supposed to mean. Do you believe that someone not connected with Debian interprets the lincense in this peculiar way? The obvious interpretaion allows us to place the transparent copy along with the opaque copy on a web server and to distribute them separately without the one-year requirement. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
The invariant sections are not forbidden by DFSG
[In order not to write twice same thing and because this can be of interest to many developers, I will reply to some of the comments of Wouter Verhelst and Anthony Towns in this separate thread.] My thesis is that the invariant sections do not contradict DFSG. Notice that in this particular email message I do not claim that the invariant sections do not make the documents non-free. I only say that DFSG says nothing about whether the invariant sections make a document free or non-free. This is the portion of DFSG that matters here: Derived Works The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. Notice that DFSG do not say "arbitrary modifications". This is important because "arbitrary modifications" are not allowed by GPL and by many other licenses. For example GPL says If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. It doesn't matter how strong this GPL-restriction is. The point is that GPL does not allow arbitrary modifications and that DFSG do not require arbitrary modifications. If we want to decide whether some particular restrictions in the license make the license non-free or not, we have to use external to DFSG arguments. For example everybody is free to decide that the invariant sections make the document non-free but this can not be a consequence from DFSG. My personal addition to DFSG is this: the license must allow us to improve the program and/or the documentation. I think GFDL is free because GFDL allows us to improve the document (even the invariant sections can be improved as I demonstrated in my proposal). However you see that my conclusion is not based only on DFSG. It can not be based only on DFSG because DFSG say nothing about what modifications must be allowed by the license. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: GFDL is compatible with DFSG
On Mon, Jan 23, 2006 at 05:39:07PM -0600, Peter Samuelson wrote: > > > The notable practical problems I'm alluding to would include: > > - All Debian mirrors must retain source packages one year after the > corresponding binary packages are deleted The license does not require this because on all our mirrors the transparent copy is always along with the opaque copy. > - Debian CD vendors must either ship source CDs to all customers > regardless of whether a customer wants them, or maintain their own > download mirrors. Do you know how many Debian CD vendors ship the binary CDs together with written offer valid for at least three years, to give any _third party_, for a charge _no more_ than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code. For the CD vendors the requirement of GPL can be even more impractical than the requirement of GFDL and as a result they always ship the source CDs. > - Neither Debian, nor the mirror network, nor the users, can use > rsync-over-ssh to update their CD images or individual packages. You can use any way to update the CD images or individual packages because by doing so you are not controlling the reading and furthure copying. Everybody who receives the data is free to read and copy it. If I do not give you access to read some file then I am controlling you, not your reading - there exists no reading I can control. I would be controlling your reading if the copy I gave to you was protected in such a way that you could read it today but not tomorow. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: GFDL is compatible with DFSG
On Tue, Jan 24, 2006 at 06:39:41AM -0500, Nathanael Nerode wrote: > On Sunday 22 January 2006 16:45, Anton Zinoviev wrote: > > > In fact, the license says only this: > > > > > >You may not use technical measures to obstruct or control the > > >reading or further copying of the copies you make or distribute > > Did any of you actually *read* this? Read it. > > What it actually *says*, means that storing a copy on a multiuser > machine with UNIX permissions set so that it can't be read by > everyone is *prohibited*. > > The permissions are clearly a "technical measure". Yes, they are. > They clearly obstruct and control the reading or further copying of > that copy. No, they can not. They can not control something that doesn't exist. If you do "chmod -r" then I am unable to read the file and there exists no reading to control. If you use some technical measures to make me able to read today but not tomorow a text you gave to me, then you would be controlling the reading. The encrypted file systems and "chmod -r" do not achieve this. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The invariant sections are not forbidden by DFSG
On Tue, Jan 24, 2006 at 07:28:18AM -0500, Nathanael Nerode wrote: > Anton Zinoviev wrote: > >Derived Works > > > >The license must allow modifications and derived works, and must allow > >them to be distributed under the same terms as the license of the > >original software. > > > > Notice that DFSG do not say "arbitrary modifications". > > The general interpretation we've taken of this is "must allow > modifications in general, with restrictions allowable if they do not > prevent reasonable use cases". What is the meaning of "modifications in general"? I am just asking. > "Invariant sections" prevent several reasonable use cases, which is why > they're generally considered non-free. The only example in this and the previous thread about such case is the requirement to include the invariant sections and the text of GFDL in man-pages generated from info-manuals. I explained why this is not necessary. > > If we want to decide whether some particular restrictions in the > > license make the license non-free or not, we have to use external to > > DFSG arguments. For example everybody is free to decide that the > > invariant sections make the document non-free but this can not be a > > consequence from DFSG. > > Well, it's true that it can't be a pure, logical consequence. There > is *interpretation* (of the DFSG, of the Social Contract, of the > license) involved. It is not a matter totally separate from the > DFSG either, however. Then this interpretation should be written and voted. > > My personal addition to DFSG is this: the license must allow us to > > improve the program and/or the documentation. > > Ah. You've omitted an absolutely vital freedom, which the FSF seems to have > forgotten about when writing the GFDL: the freedom to adapt the work for > another purpose. I do not opose the freedom to adapt the work for another purpose. In my opinion this freedom follows from the freedom to improve. > Many of us care very strongly about this freedom. This freedom is > one of the primary reasons why free software has been successful. > Licenses which deny or severely restrict this freedom must IMNSHO be > considered non-free. I agree. > The major limits it places on this freedom are the fundamental > practical reason why the GFDL is a bad license. Can you give me some hints about that? Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: GFDL is compatible with DFSG
On Tue, Jan 24, 2006 at 02:02:25PM +0100, Frank Küster wrote: > > > > If you do "chmod -r" then I am unable to read the file and there > > exists no reading to control. > > Come on. If the directory is world (or just group) readable, there *is* > in fact something to read. Simply defining that every copy that cannot > be read is not there, and therefore not letting others read it is okay, > is just ridiculous. The copy _is_ there but there exists no reading, so there is nothing to control. I mean there is no reading of the copy, the directory can be read but it is obviously not covered by GFDL. > > If you use some technical measures to make me able to read today but > > not tomorow a text you gave to me, then you would be controlling the > > reading. The encrypted file systems and "chmod -r" do not achieve > > this. > > The clause was explicitly introduced to forbid distribution on a > particular type of encrypted file system, namely, > Digital-Rights-Management-enabled media. You are wrong. OK. That was just an example. If I give you handheld that allows you to read the Glibc manual only today but not tomorow then I would be in violation of the license. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: GFDL is compatible with DFSG
On Tue, Jan 24, 2006 at 02:48:20PM +0100, Frank Küster wrote: > Anton Zinoviev <[EMAIL PROTECTED]> wrote: > > > On Tue, Jan 24, 2006 at 02:02:25PM +0100, Frank Küster wrote: > >> > > >> > If you do "chmod -r" then I am unable to read the file and there > >> > exists no reading to control. > >> > >> Come on. If the directory is world (or just group) readable, there *is* > >> in fact something to read. Simply defining that every copy that cannot > >> be read is not there, and therefore not letting others read it is okay, > >> is just ridiculous. > > > > The copy _is_ there but there exists no reading, so there is nothing > > to control. I mean there is no reading of the copy, the directory can > > be read but it is obviously not covered by GFDL. > > With that reasoning, I would be allowed to make as many copies of my > WindowsXP CD's as my CD burner manages before it blows up in smoke, as > long as I don't let anybody else read them. I repeat: Claiming that a > copy doesn't matter just because you can't read it, and doing this when > discussing the specific clause that forbids to obstruct other's reading > of the copy, is just ridiculous. I don't say the copy doesn't matter. I say that there is no process of reading the copy. Do I control your reading of the image on my videomonitor? Maybe I control you, but not your reading, because there is no reading at all. And yet my videomonitor is very real. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The invariant sections are not forbidden by DFSG
On Tue, Jan 24, 2006 at 02:52:41PM +0100, Frank Küster wrote: > An other example is a reference sheet to be printed on the front- and > backside of a sheet of paper (autogenerated to always match the current > version) that contains the most important commands, functions or > whatever of the software that the manual documents. For example a cheat > sheet for GNU Emacs. It is not difficult to print two sheets - the invariant sections go on the second sheet and FSF wins more popularity. :-) > And I must say that I didn't get your reasoning why it wouldn't be > necessary to include the invariant sections. You talked about whether a > book with 90% non-technical invariant stuff is still technical, but I > missed how you want to explain that I may remove the invariant > sections. Yes, the discussion was very large. You can structure the man-pages in a way that makes every single man-page to be only a part from a bigger document. In order to fulfil the requirements of the license you only need to include the invariant sections in only one of your man-pages. When the document is distributed in HTML-format, we do exactly this - each chapter can have its own short sized html-page and the invariant sections are separated in their own html-pages. We do not include the invariant sections in all chapters of the document. GFDL does not say what constitutes the whole document. It is easy to write in each of the man-pages that it is only a chapter from a bigger text and to point to the man-page with table of contents. Ofcourse you will have to distribute the man-pages as a whole. It is also possible to split the manual into files in plain-text format. As a matter of fact the info-format is almost plain-text and can be read without info-reader. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: GFDL is compatible with DFSG
On Tue, Jan 24, 2006 at 04:27:25PM +0200, Kalle Kivimaa wrote:
>
> So you agree that using permission bits is obstructing the reading, as
> defined in the GFDL?
>
> >From WordNet (r) 2.0 [wn]:
> obstruct
>v 1: hinder or prevent the progress or accomplishment of; "His
> brother blocked him at every turn" [syn: {blockade}, {block},
> {hinder}, {stymie}, {stymy}, {embarrass}]
The following is my reasoning (and similar for "control").
"Progress or accomplishment" means that the process that is being
hindered or prevented has already started. Hence you can not
"obstruct the reading" if the process of reading has not started yet.
When the permission bit for reading is not set then the reading can
not start.
Anton Zinoviev
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The invariant sections are not forbidden by DFSG
On Tue, Jan 24, 2006 at 04:55:19PM +0100, Frank Küster wrote: > > > It is not difficult to print two sheets - the invariant sections go on > > the second sheet and FSF wins more popularity. :-) > > This is just working around the issue. Yes, it is. > Let the sheet instead be a coffee cup; in Germany Lehmann's sell > cups with Emacs or vi commands on them. You can't add a second cup > for the invariant sections, even if they fit on it, since people > usually buy or donate (and use) only one cup at a time. The same trick works here - one cup and one sheet of paper. Not everybody will like that solution but it works. > > You can structure the man-pages in a way that makes every single > > man-page to be only a part from a bigger document. In order to fulfil > > the requirements of the license you only need to include the invariant > > sections in only one of your man-pages. > > How would that work technically? The manpages need to end up as > separate files in /usr/share/man/man/, needn't they? So you > mean that there would be one foo_manifesto.7.gz, one foo_history.7.gz > along with the actual executable's manpages? Yes. > I'm not convinced that simply referring to the invariant sections' > manpages in the SEE ALSO section would comply with the definition of > "Secondary section" and thus of "invariant section": It won't comply. Instead I am thinking for something like that: LINKS foo_toc(1) - table of contents foo_bar(1) - previous chapter foo_baz(2) - next chapter COPYRIGHT (c) 1994, 1995, 1996 Free Software Foundation, Inc. This manual page is a chapter from the foo manual. You may copy, distribute and/or modify this manual under the terms specified in foo_toc(1). > But this would only work if we always distribute the whole thing > together, and it works because the html page contains a back or contents > link that ultimately leads to the invariant sections. If the document > is GFDL, you cannot legally distribute just one of the html pages. Yes. > And that's what we want. Why? :-) > Imagine that AUCTeX's manual was under GFDL, and I want to distribute > only file:///usr/share/doc/auctex/HTML/auctex/auctex_11.html (which > deals with language support) in a documentation bundle about "Optimizing > TeX workflow for i18n and l10n". It is not inconvenient to distribute auctex_11.html together with the invariant sections. > It might be possible to do this, but what if I don't want to distribute > the whole thing? Like because I'm only interested in one particular > part? Yes, you have to distribute the invariant sections. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: GFDL is compatible with DFSG
On Tue, Jan 24, 2006 at 12:17:24PM +0100, Wouter Verhelst wrote: > > Well, if you ask the people that use this man-page they will tell. > > Uh. You'll have to make a choice here: either the text is the entirety > of _all_ manpages (in which case you can split off the invariant > sections and the FDL text to different manpages, but you have to > consider all of them together in order to decide what the overall > subject matter is), or the text is one manpage specifically (in which > case you cannot split off the invariant sections and the FDL text to > different manpages, but you can consider each of them individually in > order to decide what the overall subject matter is). I agree, that was confusing. We were talking for a document with short technical contents and long secondary sections. So I imagined a manual distributed in the form of man-pages where the only technical contents is the description of only one single command. Acording to the users the overall subject of that manual will be the description of the command, not the topic of the secondary sections. Most of the users will not read the secondary sections at all. If we talk about a manual describing describe more than one command, then it is easy to make the technical contents more than 50%. > > > Note that you even have the freedom to take a license text and modify > > > it, including any preamble such a license text might have. > > > > Not exactly. The BSD-alike licenses allow you do this but other > > licenses state that "everyone is permitted to copy and distribute > > verbatim copies of this license document, but changing it is not > > allowed." > > You're referring to the GPL, right? No. That was only a remark that not all licenses allow modifications in their text. > No. I meant there that I agree that the actual, practical results of a > license restriction are more important than whether or not they happen > to be okay according to some DFSG-guideline; but I do still think that > DFSG3 requires arbitrary modifications. I don't understand what you mean. GPL does not allow arbitrary modifications. > > It does not make the useful types of modification impossible. I > > already demonstrated why we don't have to put all invariant sections > > and the full text of GFDL in every single GFDL-covered man-page. > > You failed to do so in a logically and legally sound way. Look at the following two messages from the thread "The invariant sections are not forbidden by DFSG" in debian-vote: http://lists.debian.org/debian-vote/2006/01/msg00262.html http://lists.debian.org/debian-vote/2006/01/msg00267.html > I was specifically talking about selling printed copies. OK. > Oh well. I guess it's clear you won't agree with me, and I'm fed up with > the same rehash of this very same discussion that's been done for years > now. It isn't getting us anywhere. I find our discussion very interesting and usefull. I agreed with some of your arguments and it seams to me that you agreed with some of my arguments. Moreover, I think I can create something like a FAQ about GFDL. Without your help and the help of other opponents I won't be able to do this. Definitely, our discussion isn't getting us nowhere and I must thank you. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: GFDL is compatible with DFSG
On Mon, Jan 30, 2006 at 03:09:53PM +, MJ Ray wrote: > > "you CAN modify an invariant section - but you can only do so > by adding a new section that subverts or refutes or simply adds > to the invariant section." (Craig Sanders, January 2005) > vs > "If it is modified, it does not do its job." (RMS, May 2003) > > and so on and so forth. Even RMS's comments disagree with > some pro-FDL Craig Sanders ones. There is absolutely no contradictions between these two statements. It is not useful to change a text in invariant section (Stallman) but nevertheless it is possible to improve it by adding a new secondary section (Craig Sanders). BTW, I couldn't find the source of the quotation of Craig Sanders. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG, GFDL, and position statementsd
On Mon, Jan 30, 2006 at 01:47:02PM -0800, Thomas Bushnell BSG wrote: > > > but neither of those is grounds for imposing a 3:1 > > supermajority requirement. > > The problem with this view is that it effectively would nullify the > 3:1 requirement if applied in some other cases. Not necessarily. Acording to the Constitution "A Foundation Document is a document or statement regarded as critical to the Project's mission and purposes." This seems to imply that the Foundation Documents take precedence over any "non-foundational" resolution. > For example, a resolution which said "All software hereby meets the > DFSG", and which passes by a slim majority, would effectively repeal > the DFSG. In this case the Foundation Documents effectively invalidate any part of the resolution that contradicts with them. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The invariant sections are not forbidden by DFSG
On Tue, Jan 31, 2006 at 09:50:46AM +0100, Wouter Verhelst wrote: > On Tue, Jan 31, 2006 at 03:41:03PM +1100, Craig Sanders wrote: > > On Wed, Jan 25, 2006 at 09:54:40AM +0100, Frank Kuster wrote: > > > Anton Zinoviev <[EMAIL PROTECTED]> wrote: > > > > > > > > It is not inconvenient to distribute auctex_11.html together with the > > > > invariant sections. > > > > > > Of course it is - imagine that my documentation contains parts from 10 > > > documents, all under GFDL, all using lots of invariant sections - that > > > would be more than inconvenient. > > > > the DFSG does not require convenience. it requires freedom. lack of > > convenience DOES NOT equate to non-free. > > True; however, Frank said "it would be more than inconvenient", which > does not say he thinks that the main problem is lack of convenience > here. Since obviously we all use the words "convenient/inconvenient" in many different ways, let me make more clear how the GNU project and I understand which inconvenience is allowable and which is not. In general, we say that some software license is free if it doesn't obstruct the users to exercise their basic four freedoms and in particular the freedoms to adapt the work to your needs and release improved versions to the community. Speaking more specificly, if the AUCTeX's manual was under GFDL, then Frank would not be allowed to distribute auctex_11.html alone -- GFDL would require him to ship this file as a component of a valid document containing the invariant sections also. However it is not impossible task to ship auctex_11.html together with the invariant sections and as a matter of fact it is a relatively easy task. Would that be inconvenient to Frank? -- Yes. Does this inconvenience obstruct the software freedoms somehow? -- Certainly not, the users get the file Frank wants to give them. Sometimes when applied to some license, the four basic software freedoms can look too abstract. Fortunately we have our Debian free software guidelines -- they are more concrete and and easier to apply to the particular rules of the license. DFSG are guidelines showing us which licenses obstruct the users freedoms and which do not. Unfortunately, if we forget the purpose and the source of DFSG it is easy to misinterpret them. For example it is easy to say that DFSG3 protects the freedom "to modify the software as you see fit". However DFSG3 doesn't say "as you see fit". The purpose of DFSG3 is to ensure that we are allowed to distribute improve versions of the software and to adapt the software to particular needs. > Hence, if you keep adding invariant sections, eventually any > reasonable definition of "the document's overall subject" would be > whatever all those invariant sections talk about. Here are some questions to help to determine what the overall subject of the document is: 1. Why the people read the document? 2. How the people will remember the document? 3. What informal name the people will give to the document? (In most cases this will be the same as the real name of the document) 4. If the document is printed as a book/pamphlet, how it is going to be classified in the public libraries? Regardless of how many the secondary sections are and how short the technical contents is, in many cases the overall subject of the document can still be the technical contents and not the secondary sections. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The invariant sections are not forbidden by DFSG
On Tue, Jan 31, 2006 at 02:37:18PM +0100, Frank Küster wrote: > > We are not talking about software licenses here, but documentation. > Since Debian has decided to treat both types equally, but the FSF has > not, you shouldn't mix things up when claiming to present the FSF's > view. > > So do you claim that the GNU project thinks that the basic four freedoms > should apply to documentation? If so, please provide some evidence, > since I have read a couple of quotes from RMS saying the opposite. As formulated at http://www.gnu.org/philosophy/free-sw.html, the four software freedoms can not be applied directly to works that are not programs and in particular they can not be applied directly to documentation. "Run the program" and "study how the program works" are certainly not activities that can be applied to documentation. Nevertheless, this doesn't mean that the GNU project doesn't use more or less the same notion of "freedom" for the free documentation. Acording to Stallman more or less the same freedoms should apply to all so called functional works. The functional works include all works that are considered to be of practical use, such as software, software documentation, textbooks, handbooks, dictionaries, reference books, encyclopedia, cooking recipes, etc. He has expressed this opinion in several of his speaches, for example the following is a quotation from http://www.gnu.org/philosophy/copyright-and-globalization.html: This includes recipes, computer programs, manuals and textbooks, reference works like dictionaries and encyclopedias. For all these functional works, I believe that the issues are basically the same as they are for software and the same conclusions apply. People should have the freedom even to publish a modified version because it's very useful to modify functional works. People's needs are not all the same. If I wrote this work to do the job I think needs doing, your idea as a job you want to do may be somewhat different. So you want to modify this work to do what's good for you. At that point, there may be other people who have similar needs to yours, and your modified version might be good for them. Everybody who cooks knows this and has known this for hundreds of years. It's normal to make copies of recipes and hand them out to other people, and it's also normal to change a recipe. If you change the recipe and cook it for your friends and they like eating it, they might ask you, "Could I have the recipe?" Then maybe you'll write down your version and give them copies. That is exactly the same thing that we much later started doing in the free-software community. > > Would that be inconvenient to Frank? -- Yes. Does this > > inconvenience obstruct the software freedoms somehow? -- Certainly > > not, the users get the file Frank wants to give them. > > No, many won't download the file if they know they have to download 10 > MB in order to get 900kbyte of content. The invariant sections in the GNU manuals are not that large but I suppose you are not talking about some existing document? If so I will agree with you -- it is possible to create the invariant sections that large that it becomes serious burden to distribute them. If this is realy the case, then this document would be non-free. The invariant sections with offensive material give us a similar example -- documents that contain such invariant section would also be non-free. > Moreover, I doubt that it would be allowed to structure the text > like this: > > 1. Intro, including explanation of the structure > 2. Content > 2.1 to 2.12 the individual documents' internationalization docs > 3. Legalese > 3.1 to 3.12 the individual documents' invariant sections Yes, this is allowed. Acording to GFDL "Section numbers or the equivalent are not considered part of the section titles" and "multiple identical Invariant Sections may be replaced with a single copy". > Instead, I fear I would be oblidged to go like this: > > 1. Intro > 2. AUCTeX manual > 2.1 Invariant front texts > 2.2 Interesting page > 2.3 Invariant back texts > 3. Some other manual > 3.1 Invariant front texts > > and so forth up to > > 12.3 Invariant back texts. > > This would make the manual basically unusable. This would be required only if you are creating "aggregation with independent works". You will have to create such an aggregation only if some of your sources are covered under incompatible with GFDL license. But even in that case you may combine your GFDL sources and as a result all invariant sections will be grouped in one place. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The invariant sections are not forbidden by DFSG
On Tue, Jan 31, 2006 at 04:34:19PM +0100, Frank Küster wrote: > > May I ask you to please read the mails you answer to? If you do, you'll > know. If I did something wrong, that was not intentional. You wrote about some document with 9MB invariant sections. > That makes more than 20 pages of invariant sections, or less than 13% of > interesting material. Do you agree that the GNU Emacs Manual is non-free? It is free. 20 pages do not obstruct the users to exercise their freedoms. (Although it can be forbiddable if you want to donate large quantity of printed documents to your students.) > > The invariant sections with offensive material give us a similar > > example -- documents that contain such invariant section would > > also be non-free. > > The GNU manifesto might well be considered offensive by the authorities > of some not-so-hypothetical country. Then I guess the web-pages of Debian would also be considered offensive in this country. :-) Now seriously. I meant a text that is considered offensive by most of the users, not by the authorities. If the authorities ban some document due to its contents, the effect would be similar to that of a free program that is encumbered by patents in some countries. > I don't think that RMS would appreciate if the part from the Emacs > manual would not only come immediately after the one from the Foo > manual, but somewhere 40 pages down his Manifesto would follow > immediately after Michael Foo's "Why GNU is bad Manifesto" with only > a small note saying "End of invariant sections from the Foo manual" > and "Beginning of invariant sections from the Emacs manual". I don't know how much RMS would appreciate this, but it doesn't matter. :-) Acording to GFDL you don't even need to put the notices "End of invariant sections from the Foo manual" and "Beginning of invariant sections from the Emacs manual". > That will probably the case. Moreover, I have the feeling that the GFDL > is incompatible with itself in the sense that I can't have more than one > front cover text. The cover should contain all cover texts in arbitrary order. If there is no enough space to fit legibly all cover texts then they should continue onto the adjacent pages. > but still a ratio of 87% of rubbish is a bit high. I think this > would make it not just inconvenient, but instead non-free. For > example, even copying costs forbid to to distribute 11 sheets of > paper to a group of students if I want to hand them out a 2-pages > condensed version of the above nearly-3-pages section on coding > selection in Emacs. This cost can not be avoided even if it was only due to the long license text. You can print the invariant sections with small font as far as this doesn't obstruct the user's reading. It is probably illegal to print the license with a small font. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The invariant sections are not forbidden by DFSG
On Tue, Jan 31, 2006 at 04:59:45PM +0200, Kalle Kivimaa wrote: > > Debian consideres _everything_ to be under the same guidelines and > there should be no difference between a program, a manual or a > specification. FSF does not agree with us on this, FSF never claimed that it is principly impossible to apply one and the same guidelines to a program, a manual or a specification. Acording to Stallman in order for some functional work to be considered free, we must be allowed to use it, to adapt it, to distribute it, to improve and release the improvements to the public. Programs, manuals and specifications are examples for functional works so it is not principly impossible to modify the definition http://www.gnu.org/philosophy/free-sw.html in a way that would allow us to apply it unambiguously to manuals and specifications. > so it is not always possible to say "FSF Free == DFSG Free". It is possible to say FSF free functional work == DFSG free functional work. On Tue, Jan 31, 2006 at 05:33:17PM +, Roger Leigh wrote: > > Sure they can. Consider that most GNU GFDL'd documentation is written > in Texinfo format. This format is program code designed to run > through the TeX or makeinfo interpreters. The same applies to troff > documentation which is a program run through the groff interpreter. > > The line between "code" and "documentation" is not a clear one, since > they are often one and the same thing, and this has been discussed > quite a lot during past discussion. I agree. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The invariant sections are not forbidden by DFSG
On Tue, Jan 31, 2006 at 08:59:08PM +0100, Frank Küster wrote: > > >> That makes more than 20 pages of invariant sections, or less than 13% of > >> interesting material. Do you agree that the GNU Emacs Manual is non-free? > > > > It is free. 20 pages do not obstruct the users to exercise their > > freedoms. > > I believe that 12 times 20 pages do obstruct the freedom. If you have 12 documents each with 20 pages invariant sections and all invariant sections are different then this would indeed result in 12 times 20 pages in the combined document. For a printed document that would be impractical. (I'm sorry that I didn't come to that conclusion from your previous posts but this situation appears to me very unlikely. In most real cases GFDL won't cause that many invariant sections.) It is always a great inconvenience to be unable to combine two or more free works into one. Nevertheless this can not be a reason to consider these works non-free. For example, if the licenses are incompatible then it is impossible and illegal to combine such works. Notice however that we accept as free some licenses that do not allow combined works in principle -- that is you can have two works covered by same license and yet, you are not allowed to combine them. An example of such license is the Q Public License (QPL). The sources of all derived works should be distributed in the form original_source+patch so if you have two works covered by QPL then there is no permissible way to distribute the source of the combined work (unless the combined work is merely aggregation of independent derivatives of both works). > > (Although it can be forbiddable if you want to donate large > > quantity of printed documents to your students.) > > So the freedom to give away documents to students is not important, or > what? The convenience to give away copies is important but not something we can use to determine whether some work is free or not. In some cases you can give only 10 copies without much inconvenience, in other cases you can give 100 copies and in other cases you can give more than 1000 copies. The only difference is how big the number is and the license is only one of many factors that have influence on that number. > > Now seriously. I meant a text that is considered offensive by most of > > the users, not by the authorities. If the authorities ban some > > document due to its contents, the effect would be similar to that of a > > free program that is encumbered by patents in some countries. > > The effect is the same, but the reason is different: In one case the > developers where not careful enough about choosing their algorithms, or > the patent law in this country is so strict that there's no way out. In > the other case, the developers deliberately chose to make the text > non-distributable in this country. OK. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 01:22:02AM -0600, Manoj Srivastava wrote: > > Could some one tell me why including the invariant sections of > a GFDL licensed work in main would not require us to modify the DFSG > or the social contract? Unfortunately DFSG are not unambiguous and obviously the people understand them in various ways. If we decide that the invariant sections are free, this will require some of us to change their interpretations of DFSG. Because of this ambiguity I realy belive that we need to modify DFSG in some future GR. > Specifically, I am looking at the SC: > >> 1. Debian will remain 100% free Yes, Debian must remain 100% free. > And the DFSG: > >> The license must allow modifications and derived works, and must > >> allow them to be distributed under the same terms as the license > >> of the original software. > > We would need to change the must allow modifications bit, as I > see it -- since a license attached to a work must allow modifications > to the work, as it is currently stated. (I do not consider the > license to be part of the work). Here are three possible interpretations of "The license must allow modifications": FIRST The license must allow us to modify the work as we see fit with possible exception for the license and [list here restrictions we already accept as free]. SECOND The license must give us enough permissions to modify the work in order to adapt it to various needs or to improve it. THIRD The license must allow as to make some modifications of the work. Obviously, the third interpretation is too loose and I doubt that there are Debian developers who accept it. Nevertheless, it is a possible interpretation of the current text of DFSG. For the first and the second interpretation I can say that there are developers who accept them. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 09:37:12AM -0600, Manoj Srivastava wrote: > > > Here are three possible interpretations of "The license must allow > > modifications": > > > FIRST > >The license must allow us to modify the work as we see fit with > > possible exception for the license and [list here restrictions we > > already accept as free]. > > Actually, the license attached to a work (of which the license > is not a part) must allow the work to be modified as the user sees > fit. I understand that this is how you interpret DFSG. (BTW, the list in the brackets is not empty.) > > SECOND > >The license must give us enough permissions to modify the work in > > order to adapt it to various needs or to improve it. > > You must change the DFSG to allow such leeway. There is > nothing in the DFSG that permits such leeway; if anything, the DFSG > must be modified to "clarify" it in an editorial change. This seams so to you because you use the first interpretation. The same way I could say that the first interpretation is a leeway because DFSG don't say "as the user sees fit". > > THIRD > >The license must allow as to make some modifications of the work. > > This contradicts what the DFSG says. This contradicts the common notion of "free software", but otherwise it is completely valid textual interpretation of DFSG. > If you want to interpret things quite so differently, it is of > course your right to do so, you just must change the DFSG to cater to > this interpretation. Just the opposite -- I wish we had more unambiguous DFSG. The problem is that the current DFSG allow these different interpretations. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 10:41:55AM -0600, Manoj Srivastava wrote: > > > I understand that this is how you interpret DFSG. (BTW, the list in > > the brackets is not empty.) > > I think that is what is written, and is not just an interpretation. Not everybody reads the text as you so it is just an interpretation. > If you wish to extend the list of exceptions, that is fine. But that > does mean the DFSG must be clarified to add to the list. I don't belive it is reasonable to create exhaustive list of exceptions. I prefer the second interpretation of DFSG3. > When someone says "The license must permit modifications", > there are no restrictions placed on the mods by the license. Notice that: 1. Even GPL places restrictions on the modifications (look at http://lists.debian.org/debian-vote/2006/01/msg00240.html) 2. If some license says "you are allowed to change the word "foo" to "bar" or "baz" then this license permits at least two different modifications. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 02:38:30PM -0300, Daniel Ruoso wrote: > Em Qua, 2006-02-01 às 11:53 +0200, Anton Zinoviev escreveu: > > Unfortunately DFSG are not unambiguous and obviously the people > > understand them in various ways. > > Well, the text in DFSG3 may be not well tight. But I think we should > look at its direct reference, which can be said as the most sane > interpretation. It's clear to me that there is a reference to freedom > 1[1], and then, it can guide the interpretation of DFSG3. I agree with you that there is a reference to freedom 1 (and also freedom 3) so my interpretation of DFSG is probably the same as yours. However other developers (for example Manoj) do not accept this interpretation. > So, In some cases removing the invariant sections is needed to adapt it > to whoever needs (be it a library that wants to reduce paper cost, be it > a embedded apps developer that wants to reduce disk usage, If the invariant sections are unreasonably long then I'd agree the document is non-free. However some developers object even short invariant sections. > or be it a debian packager who wants to include part of some GFDL > doc in a man page). Here I explained why there is no problem with the man-pages: http://lists.debian.org/debian-vote/2006/01/msg00262.html http://lists.debian.org/debian-vote/2006/01/msg00267.html > P.S.: One thing I don't know if has been already suggested to FSF is to > require changing the work's name before removing the invariant sections, > as it's clear to me that the invariant sections exists to preserve the > author's integrity (in the sense of DFSG4), this way, it would fit in > the exception already stated there. FSF would not accept this. The purpose of the secondary sections is to express "the relationship of publishers or authors of the Document to the Document's overall subject (or to related matters)... The relationship could be matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them". Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 10:20:31AM -0800, Thomas Bushnell BSG wrote: > Anton Zinoviev <[EMAIL PROTECTED]> writes: > > > Not everybody reads the text as you so it is just an interpretation. > > This is not sufficient. You must explain how your interpretation is > more plausible or likely. If it is just an ad-hoc thing, designed > only to get the particular conclusion you want for this case, then > Manoj is on solid ground. > > I have not yet seen such an interpretation of this sort, in which > explanation and analysis of similar cases and such is proffered. This > does not mean it cannot be done, but it has not. This interpretation is not ad-hoc thing and I strongly belive that it represents not only my view but also the view of FSF. I asked Richard Stallman for confirmation and I will report here when I receive his reply. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 07:41:45PM +0100, Wouter Verhelst wrote: > On Wed, Feb 01, 2006 at 08:38:25PM +0200, Anton Zinoviev wrote: > > On Wed, Feb 01, 2006 at 10:20:31AM -0800, Thomas Bushnell BSG wrote: > > > I have not yet seen such an interpretation of this sort, in which > > > explanation and analysis of similar cases and such is proffered. This > > > does not mean it cannot be done, but it has not. > > > > This interpretation is not ad-hoc thing and I strongly belive that it > > represents not only my view but also the view of FSF. > > Again, the view of the FSF is of no relevance to the Debian project. Notice that in the message you cited I didn't claim that this view is the right view. I only claimed that it is not ad-hoc thing. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 07:44:58PM +0100, Wouter Verhelst wrote: > On Wed, Feb 01, 2006 at 11:13:05AM -0700, Wesley J. Landaker wrote: > > Sure, it says it must permit modifications, but it doesn't way > > that it must permit ALL modifications. The way it reads, > > literally, could be interpreted as it must permit ALL > > modifcations, or as it must permit at least two modifications (so > > that "modifications" is plural). > > Are you seriously suggesting that a webserver which allows one to only > modify the name it advertizes and the path to the default configuration > file is Free? Nobody is suggesting that. The point is that DFSG allow many interpretations and the Debian developers have to decide which one is the correct one. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 03:11:25PM -0300, Margarita Manterola wrote: > > Ok, but by being invariant they are turning the documentation into > non-free documentation. As you say, people won't be able to change it, > therefore, it's a non-free text. The modifications that are permited by GFDL are enough to make useful modifications, that is to adapt the document and to improve it. Yes, you can not do whatever you whish but this is not necessarily the right interpretation of DFSG. > I think that we agree that for a piece of software to be free, you > have to be allowed to do modifications. And even if we don't go all > the way to clarify "modifications to the whole program", it's implied > in what we say: you are supposed to be able to modify anything you > like, not just the particular part that the author of the program > didn't mind being modified. If the license says that some particular piece of code must be kept unchanged and executed then it is very likely that such license won't allow as to do some useful modifications. > With documentation it's the same thing, if you cannot modify the whole > text, it's non-free. It is non-free if the license disallows some useful modifications. > As it has been discussed here, having the Manifesto attached as > invariant is not only non-free, but also quite problematic when you > are trying to produce a derivative work that is either a) a > compilation of many documents With the currently existing documents this is not a problem. Moreover, Debian already accepts some licenses that forbid compilations. > b) a reduced version of the document (as in a cheat-sheet or > similar) This is allowed. When you distribute such documents you have to accompany them with the invariant sections but thats all. > c) printed on some non-paper medium (for example, a cup) Also allowed. When you distribute such cup you can accompany it with the invariant sections printed on paper medium and thats all. > d) you want to give out copies to students and want to minimize > cost. I doubt someone can make a formal rule that the free works have to minimize the distribution cost and I hardly see how such a rule fits in the context of DFSG. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 10:24:36AM -0800, Thomas Bushnell BSG wrote: > > The FSF insists that only modification of "functional" parts is > important, and this is a key in the disagreement. We insist on the > modifiability of all parts, not only in the parts which someone says > are the important parts to be able to modify. The decision we have taken is that DFSG applies to all works, not just to software programs. We have never taken decision acording to which "we insist on the modifiability of all parts". I'd say that we insist on the modifiability of some particular part only if this is necessary in order to solve some practical task, for example to extend or change the functionality of the work. > Regardless of the particular reasons--and even if there are not any > good reasons--it is the case that this is the DFSG as written, and so > I agree with Manoj that a 3:1 requirement is necessary for the > proposed amendment. The 3:1 requirement would be necessary only if you can prove that "we insist on modifiability of all parts". Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 11:13:45AM -0800, Thomas Bushnell BSG wrote:
>
> Yes. So, what is the interpretation being seriously put forth? That
> we should allow licenses which restrict parts of a program to being
> off-limits? ("You may change gnugo in any way you like, except that
> you may not make any changes which weaken its playing strength."?)
> ("You may change exim any way you like, except that you must not cause
> it have any spam-filtering features not already present"?) ("You may
> change Gnu Emacs any way you like, as long as you don't change the
> default keybindings"?) We would not accept any of these.
We would not accept any of these because they prohibit some useful
modifications.
> So what *is* the interpretation, under which the modification
> prohibitions of the GFDL are ok, and which similar modifications of
> programs are not?
The following: the license must give us enough permission to modify
the work in order to adapt it for various tasks and to improve it.
Anton Zinoviev
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 10:39:12AM -0800, Thomas Bushnell BSG wrote: > > The DFSG says *nothing* about "functional parts", and was recently > amended *specifically* to clarify that the same conditions apply to > software and programs. I have never objected this decision. > To interpret the DFSG to read into it language about functional parts > or to have different standards for programs and documentation, is to > insert something that is simply not there. I do not interpret DFSG that way. If I decide to create a package with some essays from www.gnu.org that package would be free acording to FSF and non-free acording to DFSG (because these essays are not modifiable). I have no problems with that. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 03:40:32PM -0300, Margarita Manterola wrote: > On 2/1/06, Anton Zinoviev <[EMAIL PROTECTED]> wrote: > > This interpretation is not ad-hoc thing and I strongly belive that it > > represents not only my view but also the view of FSF. I asked Richard > > Stallman for confirmation and I will report here when I receive his > > reply. > > RMS has NO POWER to decide in Debian. We are talking about the DFSG. So do I. But I had to disprove that my interpretation is ad-hoc. > What is it that you are going to ask from him? To confirm what we > already know? That the FSF regards the GFDL as a free licence, no > matter what? I asked if the second interpretation of DFSG expresses properly what modifications must be allowed about a particular software program or documentation for it to be considered free by FSF. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 10:36:48AM -0800, Thomas Bushnell BSG wrote: > "Wesley J. Landaker" <[EMAIL PROTECTED]> writes: > > > Sure, it says it must permit modifications, but it doesn't way > > that it must permit ALL modifications. The way it reads, > > literally, could be interpreted as it must permit ALL > > modifcations, or as it must permit at least two modifications (so > > that "modifications" is plural). > > So, would you regard a license which permitted the modification of > some features of a program, but not others, to be free? I would not. > > This is why your interpretation sounds entirely ad-hoc. If you > *really* think that the correct reading of this part of the DFSG is to > say that as long as two modifications are permitted, it does not > matter what restrictions are on the rest of a program, then I think > you are proffering something so implausible it need not be considered. Wesley wrote "The way it reads, literally, could be interpretted". This doesn't mean he thinks this is the correct reading of DFSG. > But this must be done in a *principled* way. If you are saying simply > that thet GFDL should be subject to a *different* set of requirements > than the ones you think should be applied to programs, then you can > find no support for this position in the DFSG. Indeed, we recently > amended the DFSG *specifically for the purpose* of saying that the > same conditions apply to everything in Debian, whether a program or > documentation or something else. It is not necessary to apply different conditions for programs and documentations in order to say that GFDL is free. I insist that with proper reading the _current_ version of DFSG is compatible with GFDL. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 03:28:30PM -0300, Daniel Ruoso wrote: > > The use cases I gave are just examples, I could think in other > examples to show you the fact that they being invariant prevents it > from fitting in a particular need, but that's not what's going to > make us move forward... I understand you point but I really belive that it is impossible to think out better examples than the examples you already gave. I am positive that if it is at all possible to think out interesting example for a task that can not be solved because of the features of GFDL then the same task could not be solved with some other license that we already accept as free. > This was what I tried to show you, not the opposite. My interpretation > of DFSG3 is guided by freedom 1, which says "adapt it to your needs". > Invariant sections are a restriction not covered by it. I still belive that my interpretation of DFSG3 is the same as yours. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 01:25:37PM -0800, Thomas Bushnell BSG wrote: > > But you have not explained how your amendment is an interpretation > rather than a modification of the DFSG. You cannot simply write > something new, and say "and this is an interpretation of the DFSG!" > It must actually *be* an interpretation, whether correct or not. > > Nothing in the DFSG suggests treating documentation and programs > differently, and it was recently changed (by 3:1 vote!) to explicitly > treat them the same. Nothing in the interpretation I proposed treats documentation and programs differently. Debian project has never taken decision that makes my interpretation invalid. > Which means that any interpretation must account for this fact: that > whatever the rules are, they are the same for documentation and > programs. > > Now, what is the interpretation you suggest? The second interpretation from my first post in this thread. I received confirmation and clarification from Stallman that I will report in separate message. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 03:24:16PM -0600, Manoj Srivastava wrote: > > I beg to differ. There is a reason the foundation docuyments > have a 3:1 modification requirement: If a simple majority were > enough to "interpret" codicils on a novel and unconvetional fashion, > then there is no point of the constitutional requirement for super > majority. The interpretation I proposed is not a novel and unconventional. It is not novel because it represents notion for "free software" that is older that Debian. It is not unconventional because it is widespread among the free software community. I'd say that your interpretation is more unconventional than mine. So far there is absolutely _no_ decision taken by Debian project that invalidates my interpretation. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 11:00:34PM -0600, Manoj Srivastava wrote: > > Yes, I am uneasy myself on that clause. But see, I regard > removal of copyright notices as prohibited by copyright law, and if > the original program displayed copyright notices, not being able to > remove those notices from the displayed text is closer in spirit to > the non-removal of copyright notices from the sources that I think it > passes my "is free" radar. I can see why you are uneasy with that clause - it makes impossible to just say "arbitrary modification". And the clause we are talking about is not the only necessary exception for "arbitrary modification". If you say that the non-removal of those notices from the displayed text passes your "is free" radar and the invariant secondary sections do not pass -- I can acknowledge this and I understand this. However I don't understand why you think that your interpretation is the only one possible -- it is not. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 01:36:09PM -0800, Thomas Bushnell BSG wrote:
>
> Can you please explain then where the DFSG contains any statement of
> limitation on the concept of modifiability? Where does it allow for
> any limitations on modifiability?
>
> More specifically: if there is such a limitation in the text, surely
> it must be clear whether the limitation is:
I consider this an argument in favour of my interpretation. It is
clear and doesn't require any exceptions in the applicability of DFSG.
Your interpretation ("arbitrary modifications") requires list of
exceptions so I can ask: why DFSG doesn't contain any hints about such
exceptions.
Anton Zinoviev
P.S. I mean the second interpretation from my first post in this thread.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 01:32:17PM -0800, Thomas Bushnell BSG wrote: > > If your proposal is as Manoj construed it, a proposal to modify the > DFSG, then I agree it is not ad hoc. > > But if it is a proposal to *interpret* the *existing* DFSG, then the > *interpretation* is ad hoc. The text of my proposal clearly states that it is not a proposal to modify the DFSG. It is not even a proposal to interpret the existing DFSG. It makes some of the existing interpretations of DFSG invalid but it doesn't suggest which interpretation is the right. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 03:32:00PM -0600, Manoj Srivastava wrote: > On Wed, 1 Feb 2006 19:22:10 +0200, Anton Zinoviev <[EMAIL PROTECTED]> said: > > >> If you wish to extend the list of exceptions, that is fine. But > >> that does mean the DFSG must be clarified to add to the list. > > > I don't belive it is reasonable to create exhaustive list of > > exceptions. I prefer the second interpretation of DFSG3. > > You have your right to clarify the DFSG to say explicitly what > you interpret it to mean. You also have your right to clarify the DFSG to say explicitly what you interpret it to mean. > >> When someone says "The license must permit modifications", there > >> are no restrictions placed on the mods by the license. > > > Notice that: > > >1. Even GPL places restrictions on the modifications (look at > > http://lists.debian.org/debian-vote/2006/01/msg00240.html) > > That is a reiteration of your statement, but without any > additional reasoning that actually sways me. > > (BTW, you elided the following in that message: Exception: if > the Program itself is interactive but does not normally print > such an announcement, your work based on the Program is not > required to print an announcement. ) With or without the exception it makes impossible the intepretation of "must allow modifications" as "must allow arbitrary modifications". You may think that the text "arbitrary modifications with the following exceptions ..." is better than my interpretation but that is not enough. You have to prove that DFSG or some other decision of Debian make my interpretation invalid. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 03:59:14PM -0600, Manoj Srivastava wrote: > On Wed, 1 Feb 2006 23:29:22 +0200, Anton Zinoviev <[EMAIL PROTECTED]> said: > > > The 3:1 requirement would be necessary only if you can prove that > > "we insist on modifiability of all parts". > > Procedurally, I think that the 3:1 requirement stays until you > can prove "The license must allow modifications" only talks about > sections that the author says can be modified. I do not claim that "the license must allow modifications" only talks about sections that the author says can be modified so I don't have to prove it. My interpretation doesn't limit the modifications to some particular sections. I expressed my interpretation in my first message in this thread. I received a clarification by Stallman that I will report in a separate message and you can see that there are no limitations of this sort. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 01:30:45PM -0800, Thomas Bushnell BSG wrote: > Anton Zinoviev <[EMAIL PROTECTED]> writes: > > > The modifications that are permited by GFDL are enough to make useful > > modifications, that is to adapt the document and to improve it. Yes, > > you can not do whatever you whish but this is not necessarily the > > right interpretation of DFSG. > > For many purposes it is quite useful to be able to remove invariant > sections. This has been pointed out to RMS, and on debian-legal, a > bazillion times. I will recite one such case: So far all examples of this kind I have been given are either prohibited by some other free license or do not realy require the invariant sections to be removed. > If I want to reproduce only one small part of a GFDLd manual which has > invariant sections, then I can only do so if I reproduce all the > invariant sections, which can be quite large, in comparison to the few > paragraphs I wish to copy from the text. If you want to copy only few paragraphs that would be fear use and you don't have to follow GFDL. If you want to copy more than few paragraphs in quantity (more than 100 copies) you have reproduce the invariant sections. This doesn't prohibit your right to copy, it only adds some inconvenience. (I am not talking here for extremely large invariant sections, such sections would probably make the document non-free). > This is a frequent operation one might want to do (think doc strings, > after all). Sorry, I don't understand what "think doc strings" means. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 06:32:50PM -0300, Daniel Ruoso wrote: > Em Qua, 2006-02-01 às 23:28 +0200, Anton Zinoviev escreveu: > > On Wed, Feb 01, 2006 at 03:11:25PM -0300, Margarita Manterola wrote: > > > Ok, but by being invariant they are turning the documentation into > > > non-free documentation. As you say, people won't be able to change it, > > > therefore, it's a non-free text. > > The modifications that are permited by GFDL are enough to make useful > > modifications, that is to adapt the document and to improve it. > > I must remeber that, in this case, you're not letting the user judge if > something fits or not to his needs. > This breaks freedom 1[1], which DFSG3 clearly refers to. Notice that freedom 1 doesn't talk about distribution. However if you interpret "need" as "need" and not as "whatever the user decides are his needs" then this modification would be useful and required by freedom 3. > As I said more than three times in this thread, I can show you one > document[1] that DFSG clearly refers to which contradicts your > interpretation. Can you show me something like this that contradicts my > argument? I hope in this message I answered you. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 09:48:24PM +, Roger Leigh wrote: > > Subject to minor licence considerations, I'm free to modify any piece > of software in Debian to satisfy my needs. However, this does not > apply to many GFDL works. "Append only" modification isn't really > freedom in my book; even if it is considered free, it's a long-term > maintenance nightmare. Debian project has not decided what "minor license considerations" mean and I am pretty much sure that many developers will consider the invariant secondary sections to be a "minor license consideration". > >> As it has been discussed here, having the Manifesto attached as > >> invariant is not only non-free, but also quite problematic when you > >> are trying to produce a derivative work that is either a) a > >> compilation of many documents > > > > With the currently existing documents this is not a problem. > > Why? Because even if you want to create a compilation of all GFDL works ever released all over the world, the invariant sections that currently exist are very few. > > Moreover, Debian already accepts some licenses that forbid > > compilations. > > Would you care to provide examples? They would probably be non-free. Debian acknowledges as free some licenses that require that the source of all derived works is distributed in the form original_source+patch. If you have two works covered by such license then there is no permissible way to distribute the source of the combined work (unless the combined work is merely aggregation of independent derivatives of both works). > >> b) a reduced version of the document (as in a cheat-sheet or > >> similar) > > > > This is allowed. When you distribute such documents you have to > > accompany them with the invariant sections but thats all. > > "That's all"?! That's a serious restriction. Have you fully > considered the implications? I hope I have. > >> c) printed on some non-paper medium (for example, a cup) > > > > Also allowed. When you distribute such cup you can accompany it with > > the invariant sections printed on paper medium and thats all. > > And you think that's acceptable!! Even when the invariant sections > total fifty pages of irrelevant paper-wasting garbage? If the invariant sections are extremely voluminous, the document would be probably non-free (I mean non-free acording to FSF). But if the invariant sections are not voluminous, then the invariant sections are inconvenience at most. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 02:17:54PM -0800, Thomas Bushnell BSG wrote: > Yavor Doganov <[EMAIL PROTECTED]> writes: > > > No, I think that Anton Zinoviev's amendment to the GR does *not* > > require a change to the DFSG. > > For this to be true, it must seem like a plausible interpretation of > the words of the DFSG. Can you work me through this then, since I > (and others) are so lunk-headed that we have not seen it? Everybody has the right to have his own opinion. I do not insist that you have to acknowledge my interpretation as plausible. The point is that 1. There is absolutely no decision in the Debian project that would make my interpretation invalid. 2. My interpretation is supported by some Debian developers (and probably by many Debian developers). Hence my interpretation may not be disqualified as novelty for Debian. > Where does the DFSG contain any limitations or hint of limitations on > the nature of the modifications that must be permitted? This is an argument in favour of my interpretation of DFSG. My interpretation does not require any limitations or hints of limitations. However your interpretation requires a list of exceptions because "must permit arbitrary modifications" would render GPL and some other free licenses to be non-free. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Wed, Feb 01, 2006 at 04:44:59PM -0600, Manoj Srivastava wrote: > > This is a procedural nightmare. What happens if we do split > things and Anton's proposal asses, we issue a statement, and the DFSG > amendment fails? We'll have a contradiction between a position > statement and the DFSG, which is bad. This would mean that Debian developers decided that DFSG do not require clarification. Notice BTW, that the interpretation of DFSG that I proposed is not the only one possible interpretation of DFSG that makes my proposal about GFDL consistent with DFSG. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
A clarification for my interpretation of GFDL [was: Anton's amendment]
On Wed, Feb 01, 2006 at 01:22:02AM -0600, Manoj Srivastava wrote: > > And the DFSG: > >> The license must allow modifications and derived works, and must > >> allow them to be distributed under the same terms as the license > >> of the original software. In reply to Manoj I proposed the following interpretation of the words "the license must allow modifications" (as I have explained many times "must allow arbitrary modifications" is impossible interpretation): The license must give us enough permissions to modify the work in order to adapt it to various needs or to improve it. In order to make reasonably evident that this is not just my interpretation but also interpretation that is shared by many other Debian developers I decided to ask Richard Stallman for the opinion of FSF. This was the question I asked Stallman: Can you confirm that the second interpretation expresses properly what modifications must be allowed about a particular software program or documentation for it to be considered free by FSF. Notice that I intentionaly mentioned both software program and documentation. This was the answer by Stallman: Basically yes, though I would put it more precisely, because that text still has multiple interpretations. The license must give us permissions to modify the work in order to adapt it to various needs or to improve it, with no substantive limits on the nature of these changes, but there can be superficial requirements on how they are packaged. Ofcourse we have the right to have our own opinion, opinion that differs from the opinion of FSF. We have the right to decide that our notion for "free software" differs from the notion of FSF. We have the right to interpret DFSG in a different way. However Debian project has not decided this yet. If the project secretary decides that my proposal (for GFDL) requires 3:1 supermajority, this would mean that the project secretary decides on behalf of the whole project that our notion of "free software" differs from the notion of FSF. I acknowledge that with respect to the so called non-functional works the notion of Debian project for "freeness" is clearly different to the notion of FSF. However here we are talking about GFDL which is a license that applies to functional works only. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A clarification for my interpretation of GFDL
On Thu, Feb 02, 2006 at 01:02:54PM +0200, Kalle Kivimaa wrote: > > Actually, I think that both FSF and DFSG define "free software" pretty > similarily. The problem arises from the fact that our Social Contract > applies DFSG to all works, not just software, whereas FSF considers > software a special case. Do note that (eg.) the invariant sections are > _not_ present in the GPLv3 draft. They are not present because this would make some useful modifications impossible. GFDL is applied only to the so called functional works and for such works FSF requires pretty much the same freedoms as from the software programs. There is no disagreement between Debian and FSF for such works, at least not yet. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Thu, Feb 02, 2006 at 01:10:56PM +0100, Frank Kьster wrote: > > So which is "your interpretation", exactly? It is described in my message entitled "A clarification for my interpretation of DFSG". Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Thu, Feb 02, 2006 at 01:12:51PM +0100, Frank Kuster wrote: > > Excuse me, what exactly is your interpretation? And I don't mean "The > GFDL is free", but a general statement which modifications DFSG 3 > requires to be allowed. Look at my message entitled "A clarification for my interpretation of DFSG". Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Thu, Feb 02, 2006 at 01:16:55PM +0100, Frank Kuster wrote: > Anton Zinoviev <[EMAIL PROTECTED]> wrote: > > >> >> As it has been discussed here, having the Manifesto attached as > >> >> invariant is not only non-free, but also quite problematic when you > >> >> are trying to produce a derivative work that is either a) a > >> >> compilation of many documents > >> > > >> > With the currently existing documents this is not a problem. > >> > >> Why? > > > > Because even if you want to create a compilation of all GFDL works > > ever released all over the world, the invariant sections that > > currently exist are very few. > > So the license is "currently free in practice", because the option to > thave invariant sections is only used by mainly one copyright owner who > continues to add the same invariant sections over and over again? I am unable to see how you can make a conclusion like that provided you cited what I actualy wrote. I will repeat the dialog: Margarita: the invariant sections can be a problem for compilation works Anton: 1. Currently there is no such a problem. 2. Even if there is such a problem we already acknowledge as free some licenses that prohibit compilation works Roger: Why? Anton explains why 1. and 2. are true. I am not goint to repeat the explanations. > Do you really think that such a license is in fact free? What would > happen if more people used it with the invariant sections option - at > which point would it get non-free? Don't you see that such a reasoning > can never lead to a general guideline about freeness, and must therefore > be rejected? It is no less free than the licenses that directly prohibit compilation works. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A clarification for my interpretation of GFDL [was: Anton's amendment]
On Fri, Feb 03, 2006 at 04:31:18AM +, MJ Ray wrote: > > The current opinion of FSF, at least. I know the policies of FSF well enough to be confident that this is not just "current opinion". This has always been the opinion of FSF. > In the past, RMS has worked against advertising clauses far less > obnoxious than the FDL ones. You could summarise what's happening > today with http://www.gnu.org/philosophy/bsd.html and doing > s/BSD/FDL/g; s/sentence/chapter/g; s/system/manual/g; s/University > of California/GNU Manifesto/g and similar In 2003 Stallman tried to explain in debian-legal the difference between invariant sections and the advertising clause. If you use a software with advertising clause then you are obliged to say some fixed sentence whenever you are mentioning some features of that software. If you write completely independant program and it mentions these "features" your program has to display this fixed sentence. If you are writing some documentation that mentions these "features" you also have to add the fixed sentence. Think now what would happen if you use quiet a large number of programs that are licensed in this way. On the other hand invariant sections apply only to documents that are derivatives of the initial document. This is much easier to keep requirement and thats why FSF considers it acceptable for the GNU project. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A clarification for my interpretation of GFDL
On Thu, Feb 02, 2006 at 01:23:18PM +0100, Frank Küster wrote: > Anton Zinoviev <[EMAIL PROTECTED]> wrote: > > > In order to make reasonably evident that this is not just my > > interpretation but also interpretation that is shared by many other > > Debian developers I decided to ask Richard Stallman for the opinion of > > FSF. > > > > This was the question I asked Stallman: > > > >Can you confirm that the second interpretation expresses properly > >what modifications must be allowed about a particular software > >program or documentation for it to be considered free by FSF. > > So you did ask him some question about free software. And now you want > to use his answer to justify a particular interpretation of DFSG clause > 3. How does that go together? I don't use his answer to justify a particular interpretation of DFSG. The common notion of "free software" justifies my interpretation. I only wanted to make sure to everybody that my interpretation is not only mine but it is interpretation acceptable by the free software community in general. > If at all, you should have asked him (or some linguist or lawyer or my > mother) the same sentence ending "free according to DFSG clause 3". Before you go to use such voice you'd better think what "free according to DFSG clause 3" realy means. Please explain me the meaning of the phrase "must allow modifications" in a way that would not make GPL a non-free license. Together with Stallman we made a perfectly acceptable interpretation of DFSG3. People who object it have failed in their attempts to explain what their "obvious" interpretatioin of DFSG3 realy is. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Thu, Feb 02, 2006 at 07:58:44AM -0600, Manoj Srivastava wrote: > On Thu, 2 Feb 2006 12:39:52 +0200, Anton Zinoviev <[EMAIL PROTECTED]> said: > > > The interpretation I proposed is not a novel and unconventional. It > > is not novel because it represents notion for "free software" that > > is older that Debian. It is not unconventional because it is > > widespread among the free software community. I'd say that your > > interpretation is more unconventional than mine. > > It is a novel and unconventional reading of the foundation > document. It is funny to call this reading "novel" considering that it is the only possible reading. It is the only possible reading because nobody else could tell us another reading of DFSG3 that would keep GPL free license. Possibly you didn't know how the free software community understands the words "free software", if so I can see why you are considering this reading "novel". You already agreed that "the license must allow arbitrary modifications" is an absurd reading that would make GPL and many other free licenses non-free. So far you failed in your attempts to refine this absurd reading but still you are trying to bind the whole project with it. > > So far there is absolutely _no_ decision taken by Debian project > > that invalidates my interpretation. > > You are, of course, entitled to your opinion. But when we > ratified "The license must allow modifications", we did take a > decision. And you are, of course, entitled to yours, provided you manage to clarify your opinion to yourself. Even then you have no rights to bind Debian with your opinion. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A clarification for my interpretation of GFDL
On Thu, Feb 02, 2006 at 08:11:11AM -0600, Manoj Srivastava wrote: > > Firstly, if my needs require me to rtemove the secondary > sections, and invariant sections, I should be allowed to do so Ok. However so far, nobody could give a resonable example of needs that can require you to remove the secodary sections. When I say "reasonable example" I mean example that doesn't make the other free licenses non-free. > Secondly, I reject this as being wehat the text already > present says. "The license must allow modifications" means that the > license must allow modifications -- with no codicils that the > modifications be what the author thinks is non-arbitary. Are you still insisting on the absurd requirement "the license must allow arbitrary modifications"? Are you going to say that for the Debian project it has been always obvious that GPL is a non-free or at least almost non-free license? Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Thu, Feb 02, 2006 at 08:21:58AM -0600, Manoj Srivastava wrote: > > > Notice BTW, that the interpretation of DFSG that I proposed is not > > the only one possible interpretation of DFSG that makes my proposal > > about GFDL consistent with DFSG. > > I would think not clarifying the DFSG would make for a > contradiction. What contradiction? > At the very least, it would confuse a large set of readers. It is not difficult to make the readers aware of the proper meaning of DFSG3. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Thu, Feb 02, 2006 at 02:37:28PM -0300, Daniel Ruoso wrote: > > Sorry, it's "adapt to your needs", not "adapt to the needs the author > judges reasonable"... You're forcing your interpretation beyond > reasonable limits... Sorry, I was more brief than I had to be. Freedom 1 is the freedom to study how the program works and adapt it to your needs. On one hand you can do whatever you want, but on the other hand freedom 1 says nothing about the distribution of your modified version. Only freedom 3 talks about distribution -- the freedom to improve the program and release your improvements to the public. Freedom 3 says nothing about your needs. What I wrote was the following: if your modifications solve some real need, not just your whims, then your modifications are usefull and freedom 3 gives you the right to distribute them. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Thu, Feb 02, 2006 at 11:40:13AM -0600, Manoj Srivastava wrote: > > Advertising clauses are not about the work > itself -- they are about ancillary activities, so are a different > issue. Advertising clauses are much worse than if they applied only to the work. In fact they apply not only to the work but also to many activities of the users of software with advertising clause. Any program or documentation (even unrelated) that mention features of the software with the advertising clause have to include the advertising sentence. > > We also explicitly say in the DFSG that we hold these restrictions > > to still be free, since we explicitly name the GPL and the 4 clause > > BSD as examples of free licenses. Being unable to excise or modify > > a piece of secondary literature is onerous and inconvenient, but I > > am not sure it is sufficiently different to things we already accept > > to make it non DFSG free. > > You are also free to explicitly state that the GFDL > restrictions are also to be considered free. Hence, the 3:1 > requirement, to allow that statement to be inserted into the DFSG. He is free to explicitly state that GFDL restrictions are also free but he doesn't have to. There is nothing in DFSG that can make GFDL a non-free license. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: {SPAM} Re: Anton's amendment
On Thu, Feb 02, 2006 at 01:07:50PM -0600, Manoj Srivastava wrote: > > > Except that the GPL already explicitly precludes modifications of > > this type (not this scope, but this type, mind you), and our > > foundation documents consider the GPL a free license. > > A difference in degree is still a difference. OK. You can see that your interpretation of GFDL3 is absurd and impossible and that is the only reason why you are accepting this "degree". If GPL didn't contain the clause we are discussing then you would say that a license with such clause is non-free. This makes more than evident that you don't have steady notion for "free software". Nevertheless you are trying to impose on Debian your _current_ notion for "free software". Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Thu, Feb 02, 2006 at 11:22:29AM -0800, Thomas Bushnell BSG wrote:
> Anton Zinoviev <[EMAIL PROTECTED]> writes:
>
> > On Wed, Feb 01, 2006 at 01:36:09PM -0800, Thomas Bushnell BSG wrote:
> >>
> >> Can you please explain then where the DFSG contains any statement of
> >> limitation on the concept of modifiability? Where does it allow for
> >> any limitations on modifiability?
> >>
> >> More specifically: if there is such a limitation in the text, surely
> >> it must be clear whether the limitation is:
> >
> > I consider this an argument in favour of my interpretation. It is
> > clear and doesn't require any exceptions in the applicability of DFSG.
> > Your interpretation ("arbitrary modifications") requires list of
> > exceptions so I can ask: why DFSG doesn't contain any hints about such
> > exceptions.
>
> What? My interpretation does not require any list of exceptions,
> because there is no such list.
If your interpretation does not require any list of exceptions than
your interpretation makes GPL and many other licenses non-free. You
are free to have such interpretation but you have no right to call it
obvious reading of DFSG.
Anton Zinoviev
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Thu, Feb 02, 2006 at 03:03:13PM -0500, Kevin B. McCarty wrote: > Anton Zinoviev wrote: > > > The text of my proposal clearly states that it is not a proposal to > > modify the DFSG. It is not even a proposal to interpret the existing > > DFSG. It makes some of the existing interpretations of DFSG invalid > > but it doesn't suggest which interpretation is the right. > > Then it _is_ a proposal to modify the DFSG: by excluding some > interpretations, it makes the DFSG more specific. Any proposal that states "GFDL is non-free" also makes DFSG more specific but I doubt our secretary is going to require 3:1 majority for the proposal favoured by him. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Fri, Feb 03, 2006 at 12:24:44PM +0100, Frank Küster wrote: > > And the reasoning why "Currently there is no such problem" is based > on the assumption that there are only a few invariant sections > (except for history, of course), in other words because mostly only > the FSF uses this option. Yes - I am explaining why _currently_ this is not a problem. :-) I have some considerations that make me think this won't be a problem in future but I can not prove this for sure and I don't have to prove it. DFSG allows licenses that prohibit compilations. > > It is no less free than the licenses that directly prohibit compilation > > works. > > Personally, I would regard a license that prohibits compilation of a > work under that license with other works under the same license, but > from a different copyright holder, to be non-free. I am not aware of > any works in Debian under such a license. OK, I am going repeat this at least for third time :-) Debian acknowledges as free some licenses that require that the source of all derived works is distributed in the form original_source+patch. If you have two works covered by such license then there is no permissible way to distribute the source of the combined work (unless the combined work is merely aggregation of independent derivatives of both works). Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Fri, Feb 03, 2006 at 12:25:55PM +0100, Frank Küster wrote:
>
> Removing lengthy political rants is clearly a real need if it comes to
> reducing space.
We have already looked at many examples of this sort but they all fall
in one of the following three categories:
1. GFDL prohibits some particular use of the document but some
other free license also prohibits this use.
2. GFDL adds some inconvenience for some particular use of the
document, but it doesn't prohibit this use.
3. The invariant sections of some hypothetical document are so
lengthy that they are obstructing the users to really excercise
the rights they have acorging to GFDL. Such a document would be
non-free.
Anton Zinoviev
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Fri, Feb 03, 2006 at 11:59:54AM +, Matthew Garrett wrote: > Anton Zinoviev <[EMAIL PROTECTED]> wrote: > > >Debian acknowledges as free some licenses that require that the > >source of all derived works is distributed in the form > >original_source+patch. If you have two works covered by such > >license then there is no permissible way to distribute the source > >of the combined work (unless the combined work is merely > >aggregation of independent derivatives of both works). > > Distribute a build system that applies a patch against work A which > turns it into a patch against work B. Applying this results in work C. > Pain? Yes. Possible? Yes. You are not allowed to distribute a patch against work A which turs it into a patch against work B. You are not allowed to do this because this patch would be based both on works A and B. This makes it to be "work based on B" so you have to distribute it in the form original_B+patch. We have here a circular deadlock. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Fri, Feb 03, 2006 at 02:01:18PM +0200, Kalle Kivimaa wrote: > Anton Zinoviev <[EMAIL PROTECTED]> writes: > >original_source+patch. If you have two works covered by such > >license then there is no permissible way to distribute the source > >of the combined work (unless the combined work is merely > >aggregation of independent derivatives of both works). > > Umm, why could I not distribute it as follows? > > original_work_1.src.tar.gz > original_work_2.src.tar.gz > patch_set_to_these_two.tar.gz This is not allowed. The license of work 1 requires you to distribute the sources of the combined work in the form original_work_1+patch_for_work_1. In the same time the sources of the combined work should be distributed in the form original_work_2+patch_for_work_2. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Fri, Feb 03, 2006 at 12:28:08PM +, Matthew Garrett wrote: > Anton Zinoviev <[EMAIL PROTECTED]> wrote: > > > You are not allowed to distribute a patch against work A which turs it > > into a patch against work B. You are not allowed to do this because > > this patch would be based both on works A and B. This makes it to be > > "work based on B" so you have to distribute it in the form > > original_B+patch. We have here a circular deadlock. > > "Patch" doesn't have to mean unified diff format. It's practical to > produce a file that describes a mechanical transformation of work B plus > an insertion of lines from work A. That's not realistically a derived > work of B. It is very questionable whether DFSG prohibits licenses that require unified diff format (I won't be surprised if we already have such licenses). But let we assume for a moment that acording to DFSG the license should permit patch system of any kind. Then your mechanical procedure must is able to insert in arbitrary file some lines from work A (if your procedure is unable to insert lines from A into files that do not belong to B, then it would be work based on B). Suppose that you use this prodedure. The result would be a file that contains portions both from A and B. If we want to call this work free acording to DFSG the user must have a way to edit this file. Suppose now that the user takes some text that originates from A and inserts into the code for a function from B or makes any other modification in the resulting file. You should have a way to update your mechanical prodedure in a way that would make these modifications buildable and I don't think this is possible if your prodedure is not work based both on A and B. However now I see that I missed another more obvious problem. You have to distribute the combined work in the form original_B+ +patch_file_for_B. Instead you are distributing in the form original_B+build_system_for_patch_for_B. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Fri, Feb 03, 2006 at 12:43:35PM +, Matthew Garrett wrote: > > > The license of work 1 requires you to distribute the sources of the > > combined work in the form original_work_1+patch_for_work_1. In the > > same time the sources of the combined work should be distributed in > > the form original_work_2+patch_for_work_2. > > What license do you believe work 1 to be under? Most patch clauses do > nothing to forbid this. I didn't mean one specific license, but the requirement of DFSG: The license may restrict source-code from being distributed in modified form _only_ if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. So the license may require the distribution as original_source+patch_file. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Fri, Feb 03, 2006 at 01:07:46PM +, Matthew Garrett wrote: > Anton Zinoviev <[EMAIL PROTECTED]> wrote: > > > However now I see that I missed another more obvious problem. You > > have to distribute the combined work in the form original_B+ > > +patch_file_for_B. Instead you are distributing in the form > > original_B+build_system_for_patch_for_B. > > Where does this "have to" come from? >From DFSG: The license may restrict source-code from being distributed in modified form _only_ if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Fri, Feb 03, 2006 at 01:10:10PM +, Matthew Garrett wrote: > Anton Zinoviev <[EMAIL PROTECTED]> wrote: > > I didn't mean one specific license, but the requirement of DFSG: > > > >The license may restrict source-code from being distributed in > >modified form _only_ if the license allows the distribution of > >"patch files" with the source code for the purpose of modifying the > >program at build time. > > > > So the license may require the distribution as original_source+patch_file. > > If the license didn't also allow the distribution of the patch files > independently, it's unlikely that we'd consider it free. Any patch file for A is a work based on A. The copyright law forbids the independent distribution of such works unless the license of A explicitly permits it. I don't know of any license that permits such distribution (includingly the old Qt license). Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Fri, Feb 03, 2006 at 03:18:00PM +0200, Kalle Kivimaa wrote: > Anton Zinoviev <[EMAIL PROTECTED]> writes: > >>From DFSG: > > > >The license may restrict source-code from being distributed in > >modified form _only_ if the license allows the distribution of > >"patch files" with the source code for the purpose of modifying the > >program at build time. > > What is the difference between a "patch file" as used in DFSG and a > "build system to produce a patch file" as used by you? I think a set > of files which run on the original source to produce the modified > source do qualify as a "patch file set", no matter how complex the > production run needs to be, as long as it is automated. I accept your reasoning. However I don't mean that DFSG forbid us to use such "build system". I mean that the license is allowed to require explicitly the use of conventional patch files then and still it will be free acording to DFSG. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Fri, Feb 03, 2006 at 01:38:24PM +, Matthew Garrett wrote: > Anton Zinoviev <[EMAIL PROTECTED]> wrote: > > > Any patch file for A is a work based on A. The copyright law forbids > > the independent distribution of such works unless the license of A > > explicitly permits it. I don't know of any license that permits such > > distribution (includingly the old Qt license). > > "You may make modifications to the Software and distribute your > modifications, in a form that is separate from the Software, such as > patches" > > In the context of the QPL, "Software" refers to the original, unmodified > software. How, precisely, does that forbid me from distributing a patch > that contains elements of work A and work B when both are released under > the QPL? Yes, I was wrong about this property of QPL. On the other hand the combination of the following two requirements of QPL is enough to make the combined works impossible: You may distribute machine-executable forms [provided that you] ensure that all modifications included in the machine-executable forms are available under the terms of this license. When modifications to the Software are released under this license, a non-exclusive royalty-free right is granted to the initial developer of the Software to distribute your modification in future versions of the Software provided such versions remain available under these terms in addition to any other license(s) of the initial developer. Our discussion became too complicated and I am not sure on what we agree and on what we disagree. I will try to explain my current opinion in a separate message and if we have some disagreement we can continue from there. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A clarification for my interpretation of GFDL
On Fri, Feb 03, 2006 at 12:33:34PM +0100, Frank Küster wrote: > > > > Ok. However so far, nobody could give a resonable example of needs > > that can require you to remove the secodary sections. > > No, several people have. You just don't want to accept these, and > therefore each time one example is mentioned, you start arguing about > small details and only concede the others are right step by step, until > nobody knows whether you have been proven wrong by the example or until > nobody cares enough to further discuss your statements. I'll try to list the examples I can remember. Category 1. GFDL prohibits some particular use of the document but some other free license also prohibits this use. This category includes: 1. Printed newssheets. There is no space for the invariant sections but there is no space for the text of the license either and many licenses require you to ship the full text of the license. Not to say that some licenses would make necessary to distribute the sources together with the newssheets. 2. Compilation works. Such works are based on many different documents and as a result the volume of all invariant sections for the resulting document can be too big. However DFSG accept as free some licenses that prohibit any compilation works. Category 2. GFDL adds some inconvenience for some particular use of the document, but it doesn't prohibit this use. During the previous discussions we agreed that there cases when the inconvenience can be prohibitive if you want to give away copies at no cost on expensive media. This category includes: 1. Reference card with Emacs commands printed on single sheet of paper. In this case you can accompany the reference card with the invariant sections printed on additional sheets. 2. The same, but the Emacs (or vi) commands are printed on cup. In this case you can accompany the cup with the invariant sections printed on additional sheets of paper. 3. Embedded device where one has to be economical about the disk space. This is only an inconvenience because the user is not obliged to install the invariant sections on the device. 4. Distribution via expensive media such as SMS. When the document is distributed in HTML-format you don't have to put everything in one file and the user is not obliged to download all invariant sections in order to read one specific short chapter. The same trick can work for distribution via SMS. You only have to make sure that all components of the document are equaly available. Category 3. The invariant sections of some hypothetical document are so lengthy that they are obstructing the users to really excercise the rights they have acorging to GFDL. Such a document would be non-free. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: {SPAM} Re: Anton's amendment
On Fri, Feb 03, 2006 at 02:59:51PM -0300, Daniel Ruoso wrote: > Em Sex, 2006-02-03 às 11:43 +0200, Anton Zinoviev escreveu: > > If GPL didn't contain the clause we are discussing then you > > would say that a license with such clause is non-free. > > I still don't know why you think this GPL clause has something to do > with invariant sections... But I am not comparing this GPL clause with the invariant sections! Manoj requires 3:1 supermajority for my proposal with the argument that my reading of DFSG is unconventional. This argument means that there is some conventional reading of DFSG. So far the only presumably "conventional" reading of DFSG was that "the license must allow arbitrary modifications". This reading would make GPL non-free so it can not be "conventional". Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A clarification for my interpretation of GFDL
On Fri, Feb 03, 2006 at 06:52:45PM +0100, Frank Küster wrote: > > > 2. Compilation works. Such works are based on many different > >documents and as a result the volume of all invariant sections for > >the resulting document can be too big. However DFSG accept as free > >some licenses that prohibit any compilation works. > > You're talking about the patch clause? Many others have, IMO > convincingly, explained why a patch clause does not prohibit to combine > two or more works. I belived that any license using the patch clause would make the combined works impossible and the others showed me that this is possible with some licenses. On the other hand at least for QPL it is quiet obvious that the combined works are impossible [*]. The discussion has not finished yet, we have to determine exact conditions in the license that make the combined works impossible. In order to simplify the discussion I promised to post a message with my conclusions and I haven't done this yet. > > 3. Embedded device where one has to be economical about the disk > >space. This is only an inconvenience because the user is not > >obliged to install the invariant sections on the device. > > How is he not? In other words, how can we distribute the manual to him > without the invariant sections in the package? If we want we can do this the same way as in 4. However here I only wrote that the user doesn't have to install the invariant sections, not that we have to distribute the manual without the invariant sections. > > 4. Distribution via expensive media such as SMS. When the document is > >distributed in HTML-format you don't have to put everything in one > >file and the user is not obliged to download all invariant sections > >in order to read one specific short chapter. The same trick can > >work for distribution via SMS. You only have to make sure that all > >components of the document are equaly available. > > I'm not sure that the license allows this. > > > Category 3. The invariant sections of some hypothetical document are > > so lengthy that they are obstructing the users to really > > excercise the rights they have acorging to GFDL. Such a > > document would be non-free. > > What do you mean by this? Which rights specifically? Theoretically it is possible to make the invariant sections so lengthy that nobody would make printed copies. This is obstruction of the right to make printed copies. Anton Zinoviev [*] http://lists.debian.org/debian-vote/2006/02/msg00224.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Fri, Feb 03, 2006 at 11:16:40AM -0800, Thomas Bushnell BSG wrote: > Anton Zinoviev <[EMAIL PROTECTED]> writes: > > > If your interpretation does not require any list of exceptions than > > your interpretation makes GPL and many other licenses non-free. You > > are free to have such interpretation but you have no right to call it > > obvious reading of DFSG. > > The GPL does not place any restrictions on which sections of the > program may be changed. Yes. I am not arguing that the invariant sections are better than the restriction in GPL. What I am arguing is that "the license must allow arbitrary modifications without list of exceptions" makes GPL to be non-free license. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Fri, Feb 03, 2006 at 06:21:19PM -0800, Steve Langasek wrote: > > > I didn't mean one specific license, but the requirement of DFSG: > > >The license may restrict source-code from being distributed in > >modified form _only_ if the license allows the distribution of > >"patch files" with the source code for the purpose of modifying the > >program at build time. > > > So the license may require the distribution as original_source+patch_file. > > Do I understand correctly that you are now arguing that the interpretation > of the DFSG as *not* requiring permission to make arbitrary modifications In this part of the thread we are not talking about any particular interpretation of DFSG. We are trying to determine the exact conditions under which the "patch clause" would make the compilation works impossible. > by arguing that some other hypothetical license that we've never > seen and never had an opportunity to decide on the freeness of as a > community *also* passes a strict literal reading of the DFSG? How > is this at all productive? If someone would provide us with list of licenses that Debian accepts and that use the "patch clause", I would appreciate this. Unfortunately the only license I could find was QPL and QPL is not typical "patch requiring" license because it does not require patches but accepts any technique that allows to keep the changes separate from the original software. > The pervailing sentiment on debian-legal (and, TTBOMK, among the ftp team) > is *not* "if there is at least one way the license passes the letter of the > DFSG, it must be ok for main", so I don't see how providing your own > interpretation of the DFSG that allows a hypothetical license Debian has > never considered to pass the patch clause really does anything to support > your thesis. I am not going to use any specific interpretation of DFSG. DFSG says the license may restrict the code from being distribute in modified form if allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. This is all I am going to use. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
DFSG4 and combined works [was: Anton's amendment]
On Fri, Feb 03, 2006 at 05:16:24PM +0200, Anton Zinoviev wrote: > > Our discussion became too complicated and I am not sure on what we > agree and on what we disagree. I will try to explain my current > opinion in a separate message and if we have some disagreement we can > continue from there. I tried to find some criterion upon which we can easy determine whether some license makes the compilation works impossible or not. Unfortunately I could only find a list of different cases with different proofs. For example all proofs I gave in the former discussion are valid for some licenses and invalid for others. Here I will give another proof for a case which I am intentionally making as close to the text of DFSG4 as possible. For reference the text of DFSG4 is: The license may restrict source-code from being distributed in modified form _only_ if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. Suppose we have a license X that makes use of this rule of DFSG. In particular the X license gives us only the following permissions with respect to the source code: 1. Permits to distribute and build unmodified copies of the source of the program. 2. Permits to distribute "patch files". It is not necessary to require the distribution of the "patch files" together with the original source code even though DFSG seams to allow such a requirement. 3. Permits to use the "patch files" for the purpose of modifying the sources of the program at build time. Suppose that the works A and B are covered by X and C is a combined work based on A and B. Under these conditions the sources of C can not be distributed because theyr distribution form should have simultaneously the form sources_of_A+patches_for_A and sources_of_B+patches_for_B and this is impossible. (The formal proof of this impossibility is too abstract, but I hope the following analisys will make it clear.) During the previous discussion Matthew Garrett and Kalle Kivimaa proposed some ways to distribute the sources of C. Here I am going to analise the proposed ways: 1. Distribute a build system that applies a patch against work A which turns it into a patch against work B. Applying this results in work C. You are allowed to distribute the original sources of A and a patch which turns them into a patch against work B and the license of B may permit to use such automatically generated patches. Obviously any patch that is automatically generated in this way is a work based on A. The license of A permits to use "patch files" for the purpose of modifying the sources of A at build time. However the license of A doesn't explicitly permit us to use "patch files" or any other work based on A for the purpose of modifying the sources of another program, in our case B. 2. We distribute the sources of C in the form sources_of_A + sources_of_B + patch_set_to_A_and_B. >From the license of A it follows that patches_for_A == sources_of_B + patch_set_to_A_and_B. Consequently patches_for_A is a work based on the sources of B. Because of that the license of B does not allow us to apply these patches to anything different than the original sources of B. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Mon, Feb 06, 2006 at 10:40:38AM -0800, Thomas Bushnell BSG wrote: > Yavor Doganov <[EMAIL PROTECTED]> writes: > > > This is not a proper example. Non-modifiability of secondary.c may > > obstruct further improvements of the program. This is not the case > > with the invariant sections, which do not prevent the manual to be > > enhanced. > > Sometimes an enhancement requires removing invariant sections. For > example, if you want to turn the manual into a reference card. You can attach the invariant sections to the reference card and the conditions of GFDL will be satisfied. > Sometimes an enhancement requires rewriting invariant sections. For > example, to correct factual mistakes or express more correct opinions. You can arrange a secondary section with the following content (notice that only A.1 is invariant, the rest of appendix A can be modified): - Appendix A The Opinion of Ty Coon, President of Vice about Gnomovision At 1989 Ty Coon made a public statement regarding the impact of Gnomovision on the mental development of the children. Since then several criticisms of Coon's opinion have been made: * Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. * Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. The interested readers can find the full text of the statement of Ty Coon in section A.1. Section A.2 briefly describes the current status of the scientific analysis of the problem. A.1 Gnomovision and the Children Mentality [the text of the invariant section follows] A.2 Scientific Analysis . ----- Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Sun, Feb 05, 2006 at 08:47:54AM -0500, Zephaniah E. Hull wrote: > > I am unconvinced that the DFSG means 'all modifications', I think that > it really does mean all reasonable modifications. 'All reasonable modifications' is a reasonable interpretation provided we agree what 'reasonable' means. :-) > So I chop it down until there is nothing _except_ the copyright > statement and the invariant sections. > > I can no longer make any modifications, I can't change the copyright > statement because, well, the law where I live forbids me from doing > that. > > And I can't change _anything_ in the document itself, I can add to it, > but I can't change it. You can do everything you want with the document as far as you keep the invariant sections intact. If 'reasonable modification' means 'any modification I'd like to do' then the document is obviously non-free. But if 'reasonable modification' means 'modification that is necessary in order to solve some particular need' then it is not obvious that the document is non-free as we can see from the examples given so far [*]. Anton Zinoviev [*] http://lists.debian.org/debian-vote/2006/02/msg00226.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Tue, Feb 07, 2006 at 09:21:58AM -0800, Mike Bird wrote: > > It seems to me that there an awful lot of potential *practical* > problems with invariant sections in documents. > > They may contain outdated, narrow, or even dangerous advice or > code examples. For example: code fragments written against > obsolete APIs in other packages, scripts which work with standard > dev but not with udev, or insecure methods of temp file creation. GFDL doesn't allow these to be part of an invariant section. All invariant sections are required to be secondary sections and the secondary sections deal exclusively with the relationship of the publishers or authors to Document's overall subject (or related matters). The secondary sections may not contain anything that could fall directly within that overall subject. Acording to the license the relationship could be a matter of historical connections, of legal, commercial, philosophical, ethical or political position. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
On Tue, Feb 07, 2006 at 09:58:55AM -0800, Mike Bird wrote: > On Tue, 2006-02-07 at 09:42, Anton Zinoviev wrote: > > I think I could accidently or deliberately slip something nasty > into a GFDL invariant section. For example, a manual for some > application could contain a polemic on the security advantages > of open source which lauded an open source encryption algorithm > that had subsequently been cracked. If necessary, in addition to the text that encloses the invariant section you can state in footnotes that the algorithm has been cracked. GFDL requires to preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. In order to fulfil this requirement you'd have to make completely clear to the reader which of the footnotes are part of the text of the original author and which of them are additions. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG4 and combined works
On Tue, Feb 07, 2006 at 03:33:10PM -0800, Russ Allbery wrote: > > So I don't understand what you're trying to get at, or what possible > relevance this theoretical discussion could have to anything else we're > talking about. If we have many documents covered under GFDL and all of them contain different invariant sections, it might be impractical to combine all of them into a new document. This was used as an evidence that GFDL is a non-free license. My point was that this can not be used as an argument that GFDL is non-free because GFDL explicitly permits licenses that disallow any combined works. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG4 and combined works
On Wed, Feb 08, 2006 at 10:59:09AM +0200, Anton Zinoviev wrote: > > GFDL explicitly permits licenses that disallow any combined works. Sorry, I wanted to say DFSG explicitly permits. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG4 and combined works
On Wed, Feb 08, 2006 at 09:40:36AM -0800, Russ Allbery wrote: > > The problem with the GFDL with invariant sections is very, very simple: it > doesn't allow modifications of portions of the work. Either people > consider that non-free or not. People who don't consider that non-free > are probably not going to be persuaded by any other, more subtle argument > either During the the discussions in this and the previous month it became clear there are two completely different notions of "freedom" among us. The first notion of freedom is: the work is free if we are allowed to do whatever we want with it. The second notion of freedom is: the work is free if we are allowed to adapt it to various needs and to improve it. The strong point of the first notion of freedom is that in every person there is a natural desire to be able to do whatever he wants. The strong point of the second notion of freedom is that 1. this freedom is all we need for practical purposes (thats why FSF holds this notion of freedom) and 2. this is the status quo in Debian. I think it is useles to persuade each other which one of these two 'freedoms' is the right one -- each of them has its own rights and its benefits. What I am trying to persuade the people is that the first notion of freedom is unnatural for Debian. It is unnatural because we already accept as free many licenses that do not allow us to do everything we would want. For now the first notion of freedom can be at most an ideal with many exceptions. The Debian developers have the right to determine which way Debian will go and I hope our secretary will give them this right. Whatever the developers decide, a determined Debian will be better for everyone than the current Debian with no clear policy. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GFDL GR, vote please!
On Thu, Feb 09, 2006 at 09:45:43PM +1000, Anthony Towns wrote: > > [ ] Choice 3: GFDL is DFSG-free and suitable for main in all cases [3:1] I need to correct this. The title for my proposal is [ ] Choice 3: GFDL is compatible with the current DFSG First, the whole text of my proposal talks entirely about the current DFSG. Second, my proposal doesn't revoke automatically the decision of the release team to remove the GFDL-documents from main. If my proposal wins, it is the release team who will have to change this decision Anton Zinoviev signature.asc Description: Digital signature
Re: DFSG4 and combined works
On Wed, Feb 08, 2006 at 02:39:17PM -0800, Russ Allbery wrote: > > > The first notion of freedom is: the work is free if we are allowed to do > > whatever we want with it. > > > The second notion of freedom is: the work is free if we are allowed to > > adapt it to various needs and to improve it. > > It would probably be a good idea if you would not try to characterize > other people's positions that you don't agree with, since you are mostly > just getting them wrong. For example, I agree more with the latter > definition than the former, but I think the GFDL is clearly non-free. This doesn't change the fact that there are people who have wrote many times in this list that the DFSG text "must allow modifications" should be interpreted as "must allow arbitrary modifications". Yes, there are people like you who agree with the latter definition and consider GFDL non-free. Thats why I tried to show whenever I could why GFDL doesn't obstruct us to adapt the documents or to improve them. See for example http://lists.debian.org/debian-vote/2006/02/msg00226.html Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG4 and combined works
On Wed, Feb 08, 2006 at 02:46:16PM -0800, Thomas Bushnell BSG wrote: > Anton Zinoviev <[EMAIL PROTECTED]> writes: > > > The first notion of freedom is: the work is free if we are allowed to > > do whatever we want with it. > > > > The second notion of freedom is: the work is free if we are allowed to > > adapt it to various needs and to improve it. > > This is a false dilemma, of course. > > Moreover, if by "various needs" you mean an unspecified list, then > these are the same. If you mean some specified list, then it is clear > no such list exists at present in Debian, for you cannot point to any > record of what is on the list and what is not. I do not place limitations on "various needs". Any modification that is not just subjective wish but serves some practical purpose is desirable. > What thoroughly disgusts me here is the following history: > > [ .. long history reminder skipped ... ] If you call me "beer" I am going to accept this as personal insult. You can see from the voting archives that I voted for the complete removal of non-free. You can also see that the main "toad" (the one who proposed to keep non-free) is also the author of the current proposal that GFDL is non-free. So your analogy is not well-founded. > So, Anton, the developers *have*, in fact, voted on this very question > twice already. Give it a rest. They have not. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG4 and combined works
On Wed, Feb 08, 2006 at 11:47:21PM +0100, Laurent Fousse wrote:
> Hello,
>
> * Anton Zinoviev [Thu, Feb 09, 2006 at 12:33:30AM +0200]:
> > During the the discussions in this and the previous month it became
> > clear there are two completely different notions of "freedom" among
> > us.
> >
> > The first notion of freedom is: the work is free if we are allowed to
> > do whatever we want with it.
>
> I don't think any debian developer seriously holds that opinion.
Neither did I but I was proved wrong. It was insisted many times in
this list that the text of DFSG ("must allow modifications") means
"must allow arbitrary modifications".
> > The second notion of freedom is: the work is free if we are allowed to
> > adapt it to various needs and to improve it.
> >
> > The strong point of the first notion of freedom is that in every
> > person there is a natural desire to be able to do whatever he wants.
> >
> > The strong point of the second notion of freedom is that 1. this
> > freedom is all we need for practical purposes (thats why FSF holds
> > this notion of freedom) and 2. this is the status quo in Debian.
>
> The problem with this second notion is that "practical purposes" is
> ill-defined.
What do you mean by "ill-defined"?
Anton Zinoviev
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A clarification for my interpretation of GFDL [was: Anton's amendment]
On Thu, Feb 09, 2006 at 01:43:42AM -0500, Nathanael Nerode wrote: > Anton Zinoviev <[EMAIL PROTECTED]>: > > If the project secretary decides > > that my proposal (for GFDL) requires 3:1 supermajority, this would > > mean that the project secretary decides on behalf of the whole project > > that our notion of "free software" differs from the notion of FSF. > This is not correct. > > The FSF, through RMS, has officially claimed that documentation does > not need the same freedoms as programs, and furthermore has stated > that the GFDL is not a free software license (they appear to be > using "software" to mean "programs"). No, this is not correct. As most people FSF is using "software" to mean "programs". This does not mean that FSF doesn't support the freedoms of the users to 1. read the documentation freely without any controll by technical means (DRM). 2. to change the documentation to suit their needs 3. to copy and distribute the documentation 4. to improve the documentation and to release the improvements to the public, so that the whole community benefits You see that these are pretty much the same freedoms as the freedoms on http://www.gnu.org/philosophy/free-sw.html Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG4 and combined works
On Thu, Feb 09, 2006 at 01:19:58PM -0800, Thomas Bushnell BSG wrote: > Anton Zinoviev <[EMAIL PROTECTED]> writes: > > > I do not place limitations on "various needs". Any modification that > > is not just subjective wish but serves some practical purpose is > > desirable. > > So, once more, the prohibition on removing invariant sections prevents > many modifications which serve practical purposes. Even if your assertion is true the following is also true: The prohibition to remove the invariant sections doesn't prevent modifications which are necessary for practical purposes, except for modifications that are prohibited by other free licenses also. We have already discussed many examples, if you have some new example you are welcome to share it with us. :-) Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GFDL GR, vote please!
On Fri, Feb 10, 2006 at 06:59:04PM +1000, Anthony Towns wrote: > On Fri, Feb 10, 2006 at 12:22:12AM -0800, Steve Langasek wrote: > > > In spite of the Project Secretary's determination that this ballot > > option requires a 3:1 supermajority because it modifies the DFSG, > > given that I can't reconcile these claims that the GFDL always > > complies with the DFSG with any (IMHO) reasonable reading of the > > DFSG themselves, I am left without a suitable consistent > > interpretation that I can apply in the exercise of my own duties. > > The interpretation being proposed seems to be "the DFSG allows certain > restrictions on modifications, including the GPL's interactivity > notification stuff and the GFDL's unmodifiable sections, with others > potentially to be determined later". That seems reasonably easy to apply: > deal with the existing ones as is, and assume there'll be another vote > in future should any more come up. The interpretation that I hold is the following: The license must give us permissions to modify the work in order to adapt it to various needs or to improve it, with no substantive limits on the nature of these changes, but there can be superficial requirements on how they are packaged. However this interpretation is not part of my proposal. My proposal invalidates some possible interpretations of DFSG but it doesn't state which interpretation is the correct one. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG4 and combined works
On Thu, Feb 09, 2006 at 01:54:27PM -0800, Thomas Bushnell BSG wrote: > > It does prohibit some modifications which are useful. > > Geez, reference cards. Useful! You can make reference cards but if you make more than 100 copies you have to accompany the reference cards with additional sheet(s) of paper. The other licenses have the same limitation - you may not distribute the reference cards alone. Depending on the license you may be required to accompany each reference card with the full text of the license, with history who and when has edited the document, with the sources in machine readable format, various copyright notices, etc. > Docstrings. Useful! Not prohibited by other free licenses! Wow! I don't understand what you mean by "docstrings". Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GFDL GR, vote please!
On Thu, Feb 09, 2006 at 04:12:38PM -0600, Manoj Srivastava wrote: > > Err, that doeds not compute. If the developers decide that the > GFDL is compatible, then is it not tantamount to overriding gthe > decision taken? It is not as if the release team can go around doing > otherwise. The vox populi has power :) Vox populi has the power to override the decision that GFDL-covered documents are non-free. But technicaly speaking the decision to remove these documents from main is a technical decision than may have other reasons (who knows? :-) ) than the non-freenes of the documents. Of course I can have nothing against the automatic overriding the decision so if everybody thinks my proposal overrides it, I am OK with this. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GFDL GR, vote please!
On Fri, Feb 10, 2006 at 03:06:03AM -0800, Steve Langasek wrote: > > > > The interpretation being proposed seems to be "the DFSG allows certain > > > restrictions on modifications, including the GPL's interactivity > > > notification stuff and the GFDL's unmodifiable sections, with others > > > potentially to be determined later". That seems reasonably easy to apply: > > > deal with the existing ones as is, and assume there'll be another vote > > > in future should any more come up. > > > The interpretation that I hold is the following: > > >The license must give us permissions to modify the work in > > order to adapt it to various needs or to improve it, with no > > substantive limits on the nature of these changes, but there > > can be superficial requirements on how they are packaged. > > > However this interpretation is not part of my proposal. My proposal > > invalidates some possible interpretations of DFSG but it doesn't state > > which interpretation is the correct one. > > Which is for me a big problem, given that mine is one of those > interpretations that's invalidated -- and, according to my reading, so is > *yours*, since being unable to remove multiple pages of essays when > borrowing a few paragraphs of text is a "substantive limit". I think the following is an useful test. If the license forbids some modification that is necessary in order to adapt the document to some need, then the document is non-free. Otherwise, that is if the license does not forbid any necessary modification, the document may be free. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG4 and combined works
On Fri, Feb 10, 2006 at 12:52:33PM +0100, Bernhard R. Link wrote: > * Anton Zinoviev <[EMAIL PROTECTED]> [060210 11:36]: > > On Thu, Feb 09, 2006 at 01:54:27PM -0800, Thomas Bushnell BSG wrote: > > > > > > It does prohibit some modifications which are useful. > > > > > > Geez, reference cards. Useful! > > > > You can make reference cards but if you make more than 100 copies you > > have to accompany the reference cards with additional sheet(s) of > > paper. The other licenses have the same limitation - you may not > > distribute the reference cards alone. Depending on the license you > > may be required to accompany each reference card with the full text of > > the license, with history who and when has edited the document, with > > the sources in machine readable format, various copyright notices, etc. > > No, you cannot. At least I found nothing that allows to keep a invariant > stuff out. > > There's is nothing restricting > "H. Include an unaltered copy of this License." > (not that e.g. GPL speaks about "give any other recipients of the Program a > copy of this License along with the Program") or > "L. Preserve all the Invariant Sections of the Document, unaltered in > their text and in their titles. Section numbers or the equivalent are > not considered part of the section titles." > > So a reference card is already quite complicated, a shortcut-cup is > practically impossible. Both are possible. You ship the reference card or the cup together with the invariant sections printed on regular sheets of paper and the requirements of GFDL are satisfied. > The 100 copies is only for front and back-cover texts and about > a machine-readable non-opaque copy. Yes, you are right. If you want to ship the reference card in some electronic format, then the document has to contain on separate pages both the reference card and the invariant sectins. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG4 and combined works
On Fri, Feb 10, 2006 at 12:03:45PM +, Roger Leigh wrote: > > You neglected to mention what happens about reference cards for > documentation with invariant sections. Reference cards for Emacs and > GCC would be most useful, but AFAICT both of these manuals have > invariant sections. Yes, they are useful, but GFDL doesn't make them impossible. You only have to accompany the reference card with the invariant sections printed on separate pages. > >> Docstrings. Useful! Not prohibited by other free licenses! Wow! > > > > I don't understand what you mean by "docstrings". > > Did you try google? They are documentation inlined in the source > code. Some languages (e.g. Python (DocStrings), Perl (POD), Common > Lisp) have native support for it; other languages (C, ObjC, C++, Java) > have special tools to extract the documentation (gtk-doc, doc++, > doxygen, javadoc). Ok. > If you want an example of it, grab a copy of > https://alioth.debian.org/download.php/1437/schroot-0.2.2.tar.bz2, and > look at the comments in schroot/*.h, then look at > doc/schroot/html/index.html. > > Consider what happens if the documentation is extracted and > incorporated into a manual with a GFDL licence, and the source is GPL. We all know that GFDL is incompatible with GPL, but if the sorce was covered by BSD-like license there is no problem - you can satisfy the requirements of the BSD license by additional invariant section. > In other situations, we might want to incorporate parts of the manual > into the source (for tooltips, help texts, usage examples, etc..). We > certainly couldn't do that with a GFDL manual and GPL source. Yes, it is not possible to incorporate such parts directly into the source so indirect way has to be used. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
