Re: First call for votes for the GFDL position statement
t;we would need to list any licenses like that explicitly, or modify >the guidelines to not conflict. While you are deciding how to vote, please think for a moment what is your personal interpretation of the words "must allow modifications". Please make sure that we are not pushing Debian onto the slippery path that makes Debian divorce the free software community by rejecting many licenses (besides GFDL) that the free software community has always and will always accept as free licenses. Anton Zinoviev [1] The following is my proposal: http://lists.debian.org/debian-vote/2006/01/msg00178.html [2] When Adeodato proposed Choice 2 the Project Secretary insisted for quiet a long time that Choice 2 requires supermajority. It is not completely clear what made him yield his position. [3] http://lists.debian.org/debian-vote/2006/02/msg00128.html Please notice that this interpretation of DFSG is not part of my proposal in the current voting procedure. signature.asc Description: Digital signature
Re: A new practical problem with invariant sections?
On Mon, Feb 13, 2006 at 08:32:19PM +0100, Florian Weimer wrote:
> * Craig Sanders:
>
> > there's nothing in the GFDL that prevents you from doing that. the
> > capabilities of your medium are beyond the ability of the GFDL (or any
> > license) to control.
>
> Uhm, the existence of the anti-DRM clause disproves this claim.
The anti-DRM clause ("you may not use technical measures to obstruct
or control the reading or further copying of the copies you make or
distribute") means that you may not use intentionaly the limitations
of the device for the purpose of obstructing the user's ability to
read the document. In our case there is no intention.
Anton Zinoviev
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GFDL GR, vote please!
On Sun, Feb 12, 2006 at 05:20:41PM -0700, Hubert Chan wrote: > > But the question is not whether or not I am allowed to protect 2. The > question is whether or not that document is free. We can not answer that question. We already saw that there are different notions for "free". Some people want to be allowed more in order to acknowledge some work as free, but other people require modifiability only as far as it is necessary for practical purposes. Some people admire the existence of free works but consider the existence of non-free works to be part of the freedom. For other people it is immoral to forbid the improvements and the widening of the practical usefulness of the work; they use this as a criterium for freeness. For some people main/contrib/non-free are designators to what extend we are allowed to modify the works. For other people main/contrib/non-free should mean moral_works/free_works_promoting_immoral_works/immoral_works (of cource currently they don't mean this -- I have packages in contrib). > I consider footnotes to be part of the text. If I write a text and > include my own footnotes, and I release my text under a no-modification > license, I would be extremely angry if anyone modified my footnotes. To > me, a footnote is just as much a part of the text as punctuation, or the > words that I use. And so, to me, adding footnotes is adding to the > text. Yes, of course the author's footnotes are part of the text and you have the right to be angry if someone modified your footnotes. However if I add my own footnotes to your text, your text will still be preserved unaltered and this is what GFDL requires. > >> The question is whether or not useful modification is being > >> prevented. My license prevents you from taking my text and modifying > >> it to be more useful. That makes it non-free. > > > I see. I can answer that there are other ways to achieve the seeking > > result but I must admit that if you don't give me explicit permission > > to modify your section the result will not be the best possible. > > I would say that in some cases, the result may be completely useless for > your purposes, depending on what you want to do. Which to me means that > it makes useful modifications impossible, which means non-free. I am not allowed to "repair" your text but I can use your reasoning in my own text. I prefer the first of the following two choices: > It seems to me that you have either two choices. Either you distribute > your work as "my original plus modifications" (but as I said above: > >> It is completely useless to give someone else my original essay, > >> plus your modifications -- If the situation you described was real my first duty would be to ask you 1. why you placed your text in invariant section, 2. would you allow some modifications of your text (authorized by you). If you answer to 2 "yes" then I will proceed with the modifications. Otherwise: 3. I will ask you for your reasons to not allow modifications in the text. Knowing the answer of 3. I will be able to give your invariant section proper framework inside the document. For example depending of your answer I can try to explain to the readers the historical context of your text, your wishes, etc. > it would just be too painful to read. The users don't have to read (except for curiosity). Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A new practical problem with invariant sections?
On Sun, Feb 12, 2006 at 07:31:20PM -0500, Anthony DeRobertis wrote: > > I don't recall the following example being brought up. Thank you for this example. It was new and I liked it because it is not as abstract as most of the other examples. > Let's assume a manual, written by in Japanese, with Japanese invariant > sections. Someone translates this manual to English. The translator, of > course, leaves the Japanese invariant section intact. > > Now, I'd like to download this (translated) manual and place it on a > portable device I own, so I can easily read it without killing a bunch > of trees. I think this is clearly a useful modification, and I think > that I should be able to do this for a DFSG-free work. > > But, there is a problem: My portable device understands only ASCII, or > maybe ISO-8859-1 if I'm lucky (at least in the US, this is pretty > common). It doesn't understand UTF-8, Shift-JIS, etc. It is not > technically possible to keep the Japanese invariant section. Actually I can see here two different problems. The first problem is that you are unable to install the document on your device together with the invariant sections. This however is not a real problem because you don't have to do this. I am not sure, but I suppose Craig meant this in part of the discussion. GFDL does not require from you to install the invariant sections on your device. The other problem, on the other hand, is more interesting. How can we distribute the document, respecting the requirements of GFDL, in a way that is convenient for use on your device. I can see two ways for this. The first way is to distribute the text in some encoding that supports Japanese such as UTF-8. That way on your device you will be able to read the English part of the document (which contains only ASCII characters), but the non-English part will be visible to you in that way: ã¹ãã¤ã³èªã»ãã·ã¢èªã»ãã©ã«ã¼ã·èªã»ãã«ã¬ãªã¢èªã»ãã±ããã¢èªã» ¼Â¹Ô¤¹¤ë¤È¡¢¤µ¤Þ¤¶¤Þ¤Ê¥É¥Ã¥È¥Õ¥¡¥¤¥ëÃæ¤Ëºî¤é¤ì¤ë¡¢ Ofcourse the users whose devices can read UTF-8 will be able to view the text properly. The second way to distribute the text exploits the fact that GFDL doesn't place requirements about the format of the document. There is no requirement acording to which the document must be included in only one file. There is also no requirement to use same format for the different files belonging to the document. This makes possible to distribute the document in a bundle of two parts -- the part to be installed on your device and the part that can not be read by your device. Infact the described problem is very similar to the situation when some invariant sections contains pictures. Ofcourse the plain text files can not contain inline pictures, but this doesn't mean we are unable to distribute such a document in plain text files. It is enough to distribute the text and the graphical images in separate files provided that the text includes references to the graphical file names when appropriate. Consider the HTML format -- it is text-only but can contain references to graphical images. The graphical browsers include these images inline but the text-browsers show the users only the names of the images. The user decides whether to look at the image or not. The plain-text files are similar case -- the text contains references to the images and the user decides whether to look at them or not. > I believe this gives a notable, practicle reason why invariant sections > are not free. I hope I managed to explain why in this interesting example the invariant sections do not deprive our rights to read, to adapt, to distribute and to improve. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG4 and combined works
On Sat, Feb 11, 2006 at 01:51:08PM -0700, Hubert Chan wrote: > > You are allowed to *accompany* your document with the license. But an > invariant section must be *part of* the document. [...] > > In the case of a reference card (as I understand the DFSG), you > would not be allowed to just distribute the card, with a separate > sheet of paper that includes the invariants. You would have to > distribute the reference card as a booklet that includes the > invariant sections, and make the card a tear-out section if you want > it to be usable as just a card. GFDL doesn't place any restrictions on the form of the printed document. For example it can be a collection of unbound sheets of paper plus some unbound pictures plus some bug maps plus a cup or two. All you have to do in order to make such a heterogeneous collection to count for one document is to make it completely clear in the copyright notice what exactly is the document. (Optionaly you can provide the readers with "table of contents".) > (And then, of course, you would not be allowed to just give the card > away, without the rest of the booklet.) Yes. Anton Zinoviev P.S. I don't want to sent a message whose entire contents is "I agree", so for the record: I agree with your reasoning in http://lists.debian.org/debian-vote/2006/02/msg00551.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GFDL GR, vote please!
On Sat, Feb 11, 2006 at 02:31:30PM -0700, Hubert Chan wrote: > > > If my opinion is not the same as yours I am allowed to express my > > opinion in additional invariant section. Or if I think your opinion > > is misleading the readers I can object your opinion in footnotes. > > I think you completely missed my point. Yes, I missed it, albeit not completely. ;-) Your essay serves two purposes: 1. to support some of your ideas and 2. to represent your way of thinking up to the smallest details. The invariant sections are the way for you to ensure that both 1. and 2. will be satisfied all the time (albeit not in the best possible way). It would not be possible to protect 2. if the license permited modifications of your essay. > This has *nothing* to do with expressing a different opinion. This > is about expressing my opinion in a better, more coherent way. This > is all about taking what I wrote, keeping the useful bits, and > *making improvements* where needed. This is about creating a better > essay from the one I wrote without having to start from scratch -- > something that you could give to someone else, and convince them of > my views. It is completely useless to give someone else my original > essay, plus your modifications -- it would just be too painful to > read. Yes, you are right -- I am not allowed to improve 1. in a ways that would invalidate 2. If you think that 2. is not important for you, then in the copyright notice you can give to the users additional permission to modify your essay under certain conditions. > (And no, you are not allowed to object to my opinion in footnotes, > because then you would be modifying the invariant section. The only way > you can object is to add another section.) The text of GFDL says that you have to "preserve all the Invariant Sections of the Document, unaltered in their text and in their titles". This means you are allowed to use footnotes - the text will still be unaltered. Very often the publishers are adding footnotes without permission to modify the author's text. In translated texts the footnotes are even more often (again without explicit permission from the authors). > > You didn't have to include your essay in an invariant section. You > > however used invariant section so I suppose that for you the arguments > > in your essay are not the most valuable about it. > > Why would you make that assumption? An invariant section is basically > the only way of preventing non-removal. I see. > The question is whether or not useful modification is being > prevented. My license prevents you from taking my text and > modifying it to be more useful. That makes it non-free. I see. I can answer that there are other ways to achieve the seeking result but I must admit that if you don't give me explicit permission to modify your section the result will not be the best possible. > If it is not difficult, then please show how *my particular* example > prevents useful modifications. It makes impossible to adapt your code to another programming language. However ... [read below] > OK, fine. Then instead of saying that the variable "invariant" is > unmodifiable, I just say that you must cause the resulting binary to > include that text, unmodified. Is such a license free? This probably means that the final result of your code has to be executable binary. However: Suppose your license contains the following rule: 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 the following text: YOUR TEXT FOLLOWS HERE. Notice that this requirement is very similar to section 2c of GPL. Do we consider such a license free? My personal opinion is that this depends of what exactly the license requires to be printed. However I am unable to give any precise rules. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG4 and combined works
On Sat, Feb 11, 2006 at 10:42:19AM -0800, Thomas Bushnell BSG wrote: > > We're talking about a binary which is so integrated that it snarfs > bits of documentation and prints them as docstrings The integration is not very tight. The binary can work without the auxiliary file so it can not be considered combined work with that file. (There are cases when it is even desirable to use the binary without that auxiliary file, for example if you want to save disk space.) Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG4 and combined works
On Sat, Feb 11, 2006 at 09:48:37AM -0800, Thomas Bushnell BSG wrote: > Anton Zinoviev <[EMAIL PROTECTED]> writes: > > > If you want your binary to use pieces from the manual for help > > strings, then your binary has to read these pieces from auxiliary file > > which would be (speaking in the terms of GFDL) an opaque copy and > > would be covered under GFDL. > > Likely not. In all likelihood the result would be a single combined > work. Technical obfuscations do not defeat copyright law or software > licenses. If the binary doesn't even depend on the auxiliary opaque copy for its work then there is no reason to consider them combined works. Many GPL-covered programs can print the text of GPL but this doesn't mean that the text of GPL is part of these programs (the text of GPL can not be part of these programs because it is covered under incompatible with GPL non-free license). 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 02:29:20PM -0800, Thomas Bushnell BSG wrote: > Anton Zinoviev <[EMAIL PROTECTED]> writes: > > > This is strange. :-) The program is covered under BSD license and you > > say it is non-free. > > No. The resulting program is covered under the BSD license and the > GFDL together. This was not the license I suggested. For the non-commented parts of the source files of GDB the license I suggested gives you the right to choose between GFDL and BSD. I have the right to use such dual licensing. By placing the entire sources under GFDL I have satisfied the requirements of GDFL. On the other hand the non-commented parts do not depend on the manual in any way so I am allowed license them under BSD additionaly. The binary depends only on the non-commented parts so it is covered under BSD. 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 02:30:05PM -0800, Thomas Bushnell BSG wrote: > Anton Zinoviev <[EMAIL PROTECTED]> writes: > > > Returning back to the topic, we have the following situation: > > > >1. The binary form of GDB would be covered under BSD license > > Wrong. Because the binary would be including text from the manual, it > would be covered under the GFDL too. The binary doesn't have to include any text from the manual. Notice that what I proposed places all pieces taken from the manual inside comments. If you want your binary to use pieces from the manual for help strings, then your binary has to read these pieces from auxiliary file which would be (speaking in the terms of GFDL) an opaque copy and would be covered under GFDL. 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:20:36PM -0700, Hubert Chan wrote: > On Fri, 10 Feb 2006 12:43:30 +0200, Anton Zinoviev <[EMAIL PROTECTED]> said: > > > 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. > > I'm a bit surprised nobody has brought this up yet (but maybe I'm just > crazy): invariant sections prevent improvements to the invariant > sections. > > Leaving aside the (seemingly) highly charged issue of the Emacs manual > and the GNU Manifesto, let's go into the fantasy world. Let's say that > I write some software, and some documentation for it. Suppose that I > license the documentation under the GFDL, and I include an essay about > why I like free software as an invariant section. Suppose that I make > some good, new, convincing arguments (that's where the fantasy comes > in), but my writing style is a bit off at times (that part would be > reality). And then there's that part where I go off on a tangent about > my pet platypus... The invariant sections should be used only in order to express what someone thinks or saw or what someone belives. It is not useful to change such texts. If my opinion is not the same as yours I am allowed to express my opinion in additional invariant section. Or if I think your opinion is misleading the readers I can object your opinion in footnotes. > Since the essay is an invariant section, it prevents anyone from taking > my essay, keeping the good bits, fixing my terrible writing style (and > correcting my tpyos), and turning it into something that you could put > on a manager's desk and convince them of the value of using and > developing free software. Is that not a useful modification? You didn't have to include your essay in an invariant section. You however used invariant section so I suppose that for you the arguments in your essay are not the most valuable about it. The most varluable thing about the essay for you must be that the essay reflects truly the way you think. Ofcourse I may assume that the terible writing style in your essay is not voluntary so I can suggest to you my help. However if you deny I have no moral right to change one so individual text. > P.S. For those who say that we don't have software licenses that include > non-modifiable bits because they prevent useful modifications, is the > following a free software license? > > /* Permission is granted for distribution of verbatim or modified copies > of this program in source or binary forms under the condition that > contents of the variable "invariant" are not deleted or modified, and > that you do not prevent the compiler from including its contents from > the resulting binary. > */ Any fixed piece of code can be prohibitive for some usefull modifications - it is not difficult to find examples. Notice that GFDL doesn't restrict the changes in the sources in any way - in the transparent (i.e. source) copies you can do with the invariant sections whatever you want provided in all opaque (i.e. binary) copies their text is included unmodified. Anton Zinoviev -- Ако не отговарям на писмата ви: http://6lyokavitza.org/mail -- 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 02:30:43PM -0800, Thomas Bushnell BSG wrote: > Anton Zinoviev <[EMAIL PROTECTED]> writes: > > > On Fri, Feb 10, 2006 at 11:55:11AM -0800, Thomas Bushnell BSG wrote: > >> > >> But that isn't my point. My point is that you can't include the > >> GFDL'd material in any free program. (Or, by doing so, you render the > >> program non-free.) This is not controversial; even the FSF agrees. > > > > This won't be true if you use dual licensing. I showed one way to > > achieve this in http://lists.debian.org/debian-vote/2006/02/msg00472.html > > However, the resulting program is *not* a free program! > > I cannot include GFDL'd text in a BSD-licensed program without > *changing the license to require the GFDL's terms*. I suppose we are talking about different things. Notice that the procedure I proposed places all pieces taken from the manual inside comments. The binary of GDB doesn't depend on the comments and thats why you can choose the BSD license for it. 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 09:08:54PM +, Roger Leigh wrote: > Anton Zinoviev <[EMAIL PROTECTED]> writes: > > > On Fri, Feb 10, 2006 at 11:55:34AM -0800, Thomas Bushnell BSG wrote: > >> Anton Zinoviev <[EMAIL PROTECTED]> writes: > >> > >> > If GDB were under BSD, you could: > >> > > >> >1. Add docstrings to the sources of GDB in a way permissible by > >> > GFDL. In particular the invariant sections should be present in > >> > all opaque copies of the produced documentation. GFDL does not > >> > place restrictions on how the invariant sections are present in > >> > the transparent form, so it is enough if they exist in separate > >> > files. > >> > > >> >2. Add the text of the BSD license in a new invariant section. > >> > > >> >3. Use the following license for the new GDB sources: > >> > > >> > Permission is granted to copy, distribute and/or modify THE NAME > >> > under the terms of the GNU Free Documentation License, Version > >> > 1.2 or any later version published by the Free Software > >> > Foundation; with with the Invariant Sections being LIST THEIR > >> > TITLES, with the Front-Cover Texts being LIST, and with the > >> > Back-Cover Texts being LIST. > >> > > >> > Additionally, you have permission to use the non-commented parts > >> > of the sources of THE NAME under the following license: > >> > > >> > INCLUDE THE BSD LICENSE HERE > >> > >> And the result would be a *non-free program*. > > > > This is strange. :-) The program is covered under BSD license and you > > say it is non-free. > > Anton, please consider what you are writing before posting. What you > wrote is content free and completely uninformative (as was the post > you are replying to). There is no explanation at all, so we are non > the wiser than had you not posted at all. This is not at all helpful. Thomas wrote "the result would be a *non-free program*" and I replied by "the program is covered under BSD license". There is no way for me to know whether he noticed that fact and I think it would be impolite to ask him directly. That said, I agree that the comment "This is strange" was not completely appropriate. I had to write "Could you explain this. Please, notice that the program is covered by BSD license." Returning back to the topic, we have the following situation: 1. The binary form of GDB would be covered under BSD license 2. The source files used to build GDB would be covered under combination of licenses that permits to modify them in every possible way. 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 08:59:59PM +, Roger Leigh wrote: > Anton Zinoviev <[EMAIL PROTECTED]> writes: > > > On Fri, Feb 10, 2006 at 01:41:42PM +, Roger Leigh wrote: > >> >> > > >> >> > 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. > >> >> > >> >> This is no good. Where is it defined what is "necessary", and who > >> >> deems what is "necessary"? What /I/ consider to be necessary may be > >> >> considered "unnecessary" (and hence, not allowed) by the copyright > >> >> holders. > >> > > >> > I don't think we disagree what "necessary" means. > >> > >> Please answer the question I asked: Where is it defined what is > >> "necessary", and who deems what is "necessary"? > > > > OK. The modification is necessary in order to adapt the document to > > some need if there is no way to adapt the document to serve the > > purpose in question without this modification. > > Please could you still answer my question: *Who* defines what is > "necessary"? > > Your partial answer above also appears to be nothing more than your > personal opinion. Can you properly justify your reasoning with a > detailed rationale? I think we need something rather more concrete > than the personal opinion of a single developer for something which > has important ramifications. It's all still rather too vague and > handwavy to be of any practical use. I realy don't know what you want. I proposed a test, you asked what "necessary" means and I answered. You are free to accept this test together with my answer, or you can use your own meaning of "necessary", or you can reject that test completely. In this thread Steve Langasek asked how he could understand DFSG in a way under which GFDL would be a free license. I proposed one particular way - the way I understand DFSG. However I am not trying to persuade anyone that my way is the only way. If you want, I can try to explain why this is a reasonable way to understand DFSG, but it is definitely not the only possible way. 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 11:55:34AM -0800, Thomas Bushnell BSG wrote: > Anton Zinoviev <[EMAIL PROTECTED]> writes: > > > If GDB were under BSD, you could: > > > >1. Add docstrings to the sources of GDB in a way permissible by > > GFDL. In particular the invariant sections should be present in > > all opaque copies of the produced documentation. GFDL does not > > place restrictions on how the invariant sections are present in > > the transparent form, so it is enough if they exist in separate > > files. > > > >2. Add the text of the BSD license in a new invariant section. > > > >3. Use the following license for the new GDB sources: > > > > Permission is granted to copy, distribute and/or modify THE NAME > > under the terms of the GNU Free Documentation License, Version > > 1.2 or any later version published by the Free Software > > Foundation; with with the Invariant Sections being LIST THEIR > > TITLES, with the Front-Cover Texts being LIST, and with the > > Back-Cover Texts being LIST. > > > > Additionally, you have permission to use the non-commented parts > > of the sources of THE NAME under the following license: > > > > INCLUDE THE BSD LICENSE HERE > > And the result would be a *non-free program*. This is strange. :-) The program is covered under BSD license and you say it is non-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 11:55:11AM -0800, Thomas Bushnell BSG wrote: > > But that isn't my point. My point is that you can't include the > GFDL'd material in any free program. (Or, by doing so, you render the > program non-free.) This is not controversial; even the FSF agrees. This won't be true if you use dual licensing. I showed one way to achieve this in http://lists.debian.org/debian-vote/2006/02/msg00472.html > The question is, is it an important thing to be able to do? > > I think the answer is obviously yes. Ofcourse I agree that the answer is 'yes'. 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 10:07:31AM -0800, Thomas Bushnell BSG wrote: > Anton Zinoviev <[EMAIL PROTECTED]> writes: > > > 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. > > But the resulting program would be a non-free program. In this paragraph I was talking about the opposite process - you can borrow already existing docstrings from a BSD-licensed program and include them in your free GFDL covered manual. 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 01:41:42PM +, Roger Leigh wrote: > >> > > >> > 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. > >> > >> This is no good. Where is it defined what is "necessary", and who > >> deems what is "necessary"? What /I/ consider to be necessary may be > >> considered "unnecessary" (and hence, not allowed) by the copyright > >> holders. > > > > I don't think we disagree what "necessary" means. > > Please answer the question I asked: Where is it defined what is > "necessary", and who deems what is "necessary"? OK. The modification is necessary in order to adapt the document to some need if there is no way to adapt the document to serve the purpose in question without this modification. 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 10:07:00AM -0800, Thomas Bushnell BSG wrote: > > The Emacs Manual requires rather more than one additional sheet of > paper. If a small footnote could handle it, that would be fine. You can not include the whole text of GPL in a footnote either, not to mention that you are not allowed to include the text of GPL anywhere in the document. You have to distribute it printed separately. > Suppose gdb didn't already have docstrings, and you wanted to add them > using text from the GDB manual. You would not be allowed to do this, > because use of that manual text invokes the GFDL, and would require > including the invariant sections in the program. This would > contradict the GPL (because the GFDL and the GPL are incompatible). > > But this is not merely a license incompatibility. It is merely a license incompatibility as I will show below. > If GDB were under the BSD license, you still couldn't do this and > have a free program, because the standards for free programs (even > by the FSF's definition) are that they can't carry around invariant > sections and still be a free program. If GDB were under BSD, you could: 1. Add docstrings to the sources of GDB in a way permissible by GFDL. In particular the invariant sections should be present in all opaque copies of the produced documentation. GFDL does not place restrictions on how the invariant sections are present in the transparent form, so it is enough if they exist in separate files. 2. Add the text of the BSD license in a new invariant section. 3. Use the following license for the new GDB sources: Permission is granted to copy, distribute and/or modify THE NAME under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. Additionally, you have permission to use the non-commented parts of the sources of THE NAME under the following license: INCLUDE THE BSD LICENSE HERE > When this problem was pointed out to the FSF, the response was that > the manual author could just relicense the text so that you could put > it in your program. This is of course irrelevant, but explains why > the FSF doesn't see the problem. Whenever we have license incompatibility the only solution is to ask the author to relicense the text. BTW, with some tricks it is possible to use docstrings from GFDL document even in a GPL-covered program (you distribute the GPL and GFDL parts only separately and combine them only when you want to edit the sources; it is possible to do the combining and the separation automatically). 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 12:33:05PM +, Roger Leigh wrote: > Anton Zinoviev <[EMAIL PROTECTED]> writes: > > > > 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. > > This is no good. Where is it defined what is "necessary", and who > deems what is "necessary"? What /I/ consider to be necessary may be > considered "unnecessary" (and hence, not allowed) by the copyright > holders. I don't think we disagree what "necessary" means. > As an example, the FSF do not appear to consider the ability to remove > invariant sections necessary in the current version of the GFDL for > example, whereas I (and others) do. The reference cards were just an > example of this need; aggregate works were another, The reference cards do not require the removal of the invariant sections. You can print the invariant sections on separate sheet(s) of paper. > and there were several other real-world cases where a need was > demonstrated. I tried to list them in the following link and I don't think that a need was demonstrated in any of the examples. http://lists.debian.org/debian-vote/2006/02/msg00226.html > Applying your test, in my eyes, still leaves the GFDL a non-free > licence. I understand that this seams so, but no example was given to prove this. > Could we draw this debate to some sort of conclusion? I continue to > remain unconvinced by the majority of your arguments, many of which > are still poorly explained. If necessary I can try to explain better. 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]
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: 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: 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: 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 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: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: 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 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: 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 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: 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 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: 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 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: 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: 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 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 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]
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 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]
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: 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: {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 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: 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: 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: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 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 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 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 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 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 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 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 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 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: {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: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: 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 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: 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 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 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: 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: 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: 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: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: 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]
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: 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]
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 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 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 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 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 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 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 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 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 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 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: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 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: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: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 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: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 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 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 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 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 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: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 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 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: 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: 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 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 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]
