Re: Software and its translations (was: A possible GFDL compromise: a proposal)
On Mon, Sep 22, 2003 at 03:46:53PM -0700, Thomas Bushnell, BSG wrote: Branden Robinson [EMAIL PROTECTED] writes: No. Software is a collective noun, like information or stuff. No, software is a mass noun, like information or stuff. A collective noun is a word like committee, which is singular in form but refers to a plurality of individuals. In some dialects (notably in England) collective nouns get plural verbs. Curses! Foiled again! -- G. Branden Robinson|It was a typical net.exercise -- a Debian GNU/Linux |screaming mob pounding on a greasy [EMAIL PROTECTED] |spot on the pavement, where used to http://people.debian.org/~branden/ |lie the carcass of a dead horse. signature.asc Description: Digital signature
Re: Starting to talk
MJ Ray [EMAIL PROTECTED] writes: On 2003-09-22 15:14:45 +0100 Mathieu Roy [EMAIL PROTECTED] wrote: Does the DFSG definition of freedom that applies to program (nobody question that) help us to draw the line at the correct place also for documentation? Trivially, all Debian developers who have passed PP should have agreed to this. Any who agreed but do not agree should know the process for resignation. Whoa. You don't agree with me/the majority, so go away... I don't like the way you say this. I'm free to think whatever I chose to think, and to be a member of debian at the same time. The only constraint I've is that when I act as a debian maintainer, I must conform to the DFSG/Social contract and to its interpretation as made by the consensus of debian maintainer. -- Rémi Vanicat [EMAIL PROTECTED]
Re: Attribution-ShareAlike License
David B Harris writes: However, I'm not one who believes that just because a file format only has non-Free editor implementations that the file format itself is non-Free. There are many ways one can edit PDFs with Free tools, but this is beside the point for me. It's not (to my knowledge) patent-encumbered, and Adobe hasn't (to my knowledge) attempted to stop anybody who has written those tools that manipulate PDFs. Adobe has patents which it claims apply to PDF and has licensed them only for the purpose of creating compatible implementations. http://partners.adobe.com/asn/developer/legalnotices.jsp If you modified an application which implements PDF so that it was incompatible with Adobe's specifications, you might be outside the scope of Adobe's patent license grant. -- Seth David Schoen [EMAIL PROTECTED] | Very frankly, I am opposed to people http://www.loyalty.org/~schoen/ | being programmed by others. http://vitanuova.loyalty.org/ | -- Fred Rogers (1928-2003), |464 U.S. 417, 445 (1984)
Re: Starting to talk
On 2003-09-23 02:38:44 +0100 Remi Vanicat [EMAIL PROTECTED] wrote: Whoa. You don't agree with me/the majority, so go away... I don't like the way you say this. That's probably because I didn't write that at all. Feel free to put whatever words you want into my mouth if you want to be sure that you get something that you don't like. What I really wrote was that all DDs who did NM should agree that DFSG draws the line in a correct place for Debian, because that is what they agreed to and were question about. If they cannot agree with that line, what are they doing here? I wrote nothing about life outside Debian in that message, as it would be even more wildly OT here. I think you spend the rest of your message arguing the same point. -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ [EMAIL PROTECTED] Creative copyleft computing services via http://www.ttllp.co.uk/
Re: There was never a chance of a GFDL compromise
Richard Stallman [EMAIL PROTECTED]: This reinforces my conclusion that it is essential for these sections to be unremovable as well as unmodifiable. Well in that case you can rest assured that they will be removed from Debian together with the documentation to which they are attached!
Re: A possible GFDL compromise: a proposal
* Mathieu Roy ([EMAIL PROTECTED]) [030923 08:51]: Andreas Barth [EMAIL PROTECTED] a tapoté : Now, then next question is very clear for debian-legal: The Social Contract (and the DFSG) say that all software in Debian must be 100% free. So, the answer for Debian is: Every software. I think this question too simplistic. The current situation is the fact that we have manuals with some part that will never be DFSG-compliant. It was important to ask to ourselves if, in this case, removing these manuals is more harmful than letting these manuals. You can ask the very same question for non-free software, e.g. some jdk. Debian has one very consistent answer. The answer is that everything that wants to be in main, must be DFSG-free. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Starting to talk
Le mar 23/09/2003 à 08:31, Mathieu Roy a écrit : MJ Ray [EMAIL PROTECTED] a tapoté : On 2003-09-22 15:14:45 +0100 Mathieu Roy [EMAIL PROTECTED] wrote: Does the DFSG definition of freedom that applies to program (nobody question that) help us to draw the line at the correct place also for documentation? Trivially, all Debian developers who have passed PP should have agreed to this. Any who agreed but do not agree should know the process for resignation. So any member of GNU must resign from Debian or GNU? Interesting. If he is not able to make a separation between what GNU calls free and what is suitable for Debian main, yes. Apparently you misunderstood my question which still seems to me pretty clear. So, does the DFSG definition of freedom help us to draw the line at the correct place also for documentation? Please try and write a different set of guidelines for documentation. We'll see if it differs by a single word from the DFSG. PS: Am I the only one with the impression every single thing must be repeated to RMS AND yeupou AND Fedor Zuev AND Sergey foobar and any other blind GFDL advocate who is told Debian is BAD, because they want to drop FREE (it is written free on it, so it is certainly free) documentation from the GREAT GNU project ? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: There was never a chance of a GFDL compromise
O Luns, 22 de Setembro de 2003 ás 10:57:37 -0400, Richard Stallman escribía: Not long ago, people were trying to reassure me that if invariant sections were removable, nobody would remove them. I guess not. If they were both removable and modifiable (so not invariant), they would be DFSG-free and nobody would have any reason to remove them. Even if they were removable but not modifiable, they would still not be DFSG-free, so the only way to get a DFSG-free document would be to have them removed. This reinforces my conclusion that it is essential for these sections to be unremovable as well as unmodifiable. Well, in that case they'll make the document DFSG-nonfree. If they were removable and modifiable the document would be DFSG-free (except for the DRM clause, of course). So, to summarize: Removable and modifiable - Debian would most certainly carry them Removable but unmodifiable - Debian would remove them Unremovable and unmodifiable - Debian would not carry the document at all -- Tarrío (Compostela)
Re: A possible GFDL compromise
Thomas Bushnell, BSG wrote: Richard Stallman [EMAIL PROTECTED] writes: The DFSG lists three specific licenses that are meant to satisfy its criteria. Nowadays some Debian developers tend to say that these three licenses are listed as exceptions to the rules of the DFSG, but I think that is a misinterpretation. I think they are meant as examples to help people understand what the DFSG criteria mean. An interpretation of the rules which would lead to rejecting any of thee licenses is the wrong interpretation. I think you are right. Note that the DFSG is not listed. You mean that the GFDL is not listed, of course.
Re: Software and its translations (was: A possible GFDL compromise: a proposal)
On Mon, 2003-09-22 at 20:44, Branden Robinson wrote: On Mon, Sep 22, 2003 at 01:51:14PM +0200, Roland Mas wrote: - un logiciel can even be used to mean a software program, whereas the phrase a software sounds awkward to me in English (but then again, I'm not a native English speaker, and maybe software is a countable noun -- can you say two softwares?). No. Software is a collective noun, like information or stuff. ...The Debian Free Stuff Guidelines (DFSG)... Ya know, it just *might* work :o) Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: Starting to talk
On Tue, Sep 23, 2003 at 09:24:12AM +0200, Josselin Mouette wrote: PS: Am I the only one with the impression every single thing must be repeated to RMS AND yeupou AND Fedor Zuev AND Sergey foobar and any other blind GFDL advocate who is told Debian is BAD, because they want to drop FREE (it is written free on it, so it is certainly free) documentation from the GREAT GNU project ? No, you're not the only one with that impression. -- G. Branden Robinson| Human beings rarely imagine a god Debian GNU/Linux | that behaves any better than a [EMAIL PROTECTED] | spoiled child. http://people.debian.org/~branden/ | -- Robert Heinlein signature.asc Description: Digital signature
Re: There was never a chance of a GFDL compromise
On Tuesday, Sep 23, 2003, at 03:30 US/Eastern, Jacobo Tarrio wrote: Well, in that case they'll make the document DFSG-nonfree. If they were removable and modifiable the document would be DFSG-free (except for the DRM clause, of course). The DRM clause isn't all. There is also the transparent form definition (excluding, e.g., OpenOffice); and, as has been recently pointed out to me, the requirements for distributing opaque forms in quantities over 100. If you distribute opaque forms in quantities over 100 via FTP, you can't just place the transparent forms on the same server. Instead, you must force the user to download the transparent form as well, or you must keep the transparent form around for a year. I've already emailed with RMS about this, and he says he'll look into it. There may be more...
Re: A possible GFDL compromise
Nathanael Nerode [EMAIL PROTECTED] writes: Thomas Bushnell, BSG wrote: Richard Stallman [EMAIL PROTECTED] writes: The DFSG lists three specific licenses that are meant to satisfy its criteria. Nowadays some Debian developers tend to say that these three licenses are listed as exceptions to the rules of the DFSG, but I think that is a misinterpretation. I think they are meant as examples to help people understand what the DFSG criteria mean. An interpretation of the rules which would lead to rejecting any of thee licenses is the wrong interpretation. I think you are right. Note that the DFSG is not listed. You mean that the GFDL is not listed, of course. Right.
Re: Some licensing questions regarding celestia
On Monday, Sep 22, 2003, at 01:15 US/Eastern, Nathanael Nerode wrote: I'd like to nail it as open as humanly possible, so I'd like to apply to to anyone receiving a derivative work based on the work as well, unless there's a legal complication in that. Anthony DeRobertis wrote: Well, that's not public domain any more. If I take a public domain work, create a derivative work, then I have copyright over my portions of the derivative work, and can license it how I want. You misunderstand me. I want to give a license to *my* work (not the derivative work) to anyone receiving a derivative work, regardless of whether they receive my work or not. :-)
Re: A possible GFDL compromise: a proposal
On Tue, 2003-09-23 at 20:13, MJ Ray wrote: That is intersection, not equation. It is known that undesirable stunts limiting freedom, such as software patents, are allowed under most definitions of open source. It is also known that undesirable stunts limiting freedom, such as Invariant sections, are allowed under the FSF's definition of free. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: A possible GFDL compromise: a proposal
RMS wrote: A manual is free if you can publish modified versions as manuals. Brian T. Sniffen wrote: And is a text editor free if you can only publish modified versions as text editors -- not as manuals or tetris games or news-readers or web browsers? This is absolutely a *critical* point. This is perhaps the essence of many of the complaints being made about the GFDL: it effectively restricts reuse to a narrow class of reuses, while free software licenses do not. The issue of whether this is important may, in fact, sum up the fundamental point of disagreement between Debian and RMS. Glad we're actually getting somewhere in regards to understanding each other. :-)
Re: GPL preamble removal
Brian Sniffen: Thanks for the response -- I hadn't noticed that phrasing before. But if I give *you* a copy of Sniffmacs under the Sniffen GPL, wouldn't you then be bound only to give others the SGPL, not the GGPL with its Preamble? Now we get into a subtle point of copyright law. This is how I believe it works: If work B is a derivative work of work A, then to make a derivative work of work B (unless you carefully avoid all the parts derived from work A), you need licenses granted by the copyright holders of work B and work A. If Sniffmacs is work B and GNU emacs is work A, then in order to make a derivative of Sniffmacs, I need a license to work B (Sniffen GPL), which does not require preamble inclusion. But I also need a license to work A, and the license to work A specifies the inclusion of a copy of the GNU GPL. The GPL grants you, the recipient, a separate license for each particular work. Term 6 is the term which propagates each individual license to the recipients of all modified works. Normally this sort of thing isn't an issue in free software. I only know about it because I looked at one point into the issues of making a sequel to a book which had characters used under license from two other books. (You have to get separate licenses from all three authors.) IANAL, of course
Re: GFDL
I am not sure that it is, but the FSF seem to be suspicious of the free press movement. I don't know what that message said, or who wrote it, but it does not speak for the FSF. If the free press movement means indymedia, I am sympathetic to it, but the FSF has no opinion about it.
GFDL
If the whole docu would be DFSG-free, than there would be no cause to remove polical statements. According to Don Armstrong, a non-modifiable text cannot under any circumstances be considered DFSG-free, so it would have to be removed from the manual. Others have (it appears) said the same thing. Having seen a lot of rigid dogmatism here recently, I can hardly expect Debian not to be rigidly dogmatic on this issue too.
Why documentation and programs should not be treated alike
The main difference between a program and documentation is that a program does something, while documentation is passive; By this argument, source code to a program (of the sort which must be compiled to run) is not a program. That's a pedantic approach to the issue. I'd say a source program does do something (after you compile it). And can therefore, in your opinion be encumbered by unlimited numbers of Invariant Sections (presumably in 'mandatory comments') while remaining free, as long as they can be removed from the actual executable binary, I suppose. I think that nontechnical invariant comments do not make a program non-free, but not for those reasons. The reason is that this is a packaging requirement that doesn't really restrict you from making the program substantively behave as you want it to. Furthermore, a manual in any markup format (LaTeX, HTML, info, texinfo) is not passive: it does something, namely generating the actual manual in the intended-to-read format (printed, visible on screen in 'info' or 'mozilla', etc.) So manuals in any markup format -- including all the GNU manuals -- are thus akin to programs, and should be judged by those criteria. That's focusing on form rather than substance. A manual typically has source code which contains markup, and that is formally analogous to the source code of a program. But in substance the two cases are completely different. In the compiled form of a program, you can't see anything important about it. If even the comments are missing, you can't understand the important aspects of the program. Thus, access to the real source is essential for a program to be considered free. In the compiled form of a manual, as long as there is no DRM to stop you from reading it, everything that matters is plain to see. You see the contents, and you even see the fonts and indentation that were selected by the markup. The markup commands, which you don't see, and any comments in the markup, are far less important than what you do see. If you can read the published manual, what you see is everything that really matters. This is why the GFDL does not require complete corresponding source code for a published manual. It's easier to change the manual if you have this, but no disaster if you don't: you just have to write your own mark-up, which is pretty straightforward. The requirement for a transparent copy is so that you don't have to keyboard the whole text again in order to publish a modified manual. Even that is not impossible, but it's a bigger pain than writing mark-up afresh. (I think the right thing to do is to distribute the complete corresponding source code.) For manuals, there is a real danger that the source will be in a format that free software cannot read, and thus useless. The same danger *does* exist for programs, and happens often: a 'free' program written in an interpreted language with no free interpreter or translator is effectively non-free in exactly the same way. Yet there is no similar clause in the GPL. These are two different kinds of problems, two different issues. A program in a language with no free interpreter is nonetheless transparent if the language is documented and the source is legible. To be non-transparent, it would have to be obfuscated (and then it would not be the real source code, so the GPL would reject it). Conversely, the GFDL does not require the transparent copy to be processable by a free text formatter. To write a program in language A can be very different from writing it in language B; it is not really the same program. But whatever text you want to write, you can write it in any word processor or text formatter, and it is the same text. And any word processor can store the text in a transparent format. Thus, it is too much to insist that everyone program (or write markup) in languages with free implementations, but any manual can easily be published in a transparent format. Another difference is that DRM systems to stop people from accessing documents are a real threat to our freedom, and we need to try to push against them in any way we can. Not a difference. They're being applied to programs too. Not in the same way, though. DRM is often used to stop you from reading the contents of a document, and could be used to restrict even a free document. When DRM is put in programs, typically those are non-free programs, or else they restrict running modified binaries on a certain machine. They are both important issues, and what to say about DRM in GPL version 3 is a hard problem, but it wouldn't be anything like the DRM clause of the GFDL. Literate programming styles encourage documentation to be extracted directly from program source code, and documentation to be embedded directly in program source code. I agree with you that it is a drawback to be unable
Re: What does GFDL do?
While you are free to state the terms by which the GFDL should be interpreted for GNU documentation, this is not always the case. We have in the past seen cases where copyright holders have interpreted seemingly unambiguous statements in a pathological fashion (see Pine, for instance) - in the GFDL case, the wording does not make it clear that it is the intention that the license may be bound as a separate volume. If this is how you wish the license to be interpreted, clarification of the license would be helpful. I think it is clear that a printed work can consist of multiple volumes, but clarification might not hurt. I will think about it.
Re: A possible GFDL compromise: a proposal
But what if an Invariant Section was the only part of the document that fell foul of the law? I guess nobody could distribute that version, so it might be non-free. However, all free software and free documentation licenses share this problem. You could simply add code for a DeCSS program, and that would make the modified version illegal in the US. So the existence of such a possibility cannot be a criterion for criticizing a license. I have read statements =66rom you saying that while you cannot indorse Debian because it including non-free on its FTP servers, you have stated that Debian gives better considerations to users' rights by separating non-free software from the Debian System. As the GFDL allows for text that is legally, morally or ethically objectionable shouldn't we, Debian, not mark a GFDL work as different also (given that such material can not be modified)? A distinctive marking of some other kind might be reasonable.
GFDL
FYI, that's not going to convince anyone. We could all speculate about what might or might not convince certain other persons, but doing so is attempting to speak for them, so let's not do it.
GFDL
But I think that would not be free, because this behavior is substantive, not mere packaging. It's not the same as just printing an informative message about something nontechnical. You often refer to the inclusion of Invariant Sections as a mere packaging issue. To us, a packaging issue is how software gets packed to distribution and installation on someone's system and has little to do with the content that gets installed (e.g. Invariant Section are content, not packaging). We are talking about two different kinds of packaging. When I speak of a packaging requirement I'm talking about a requirement that applies to the form of a program or other work, but not the substance. This a different kind of packaging from the making of Debian packages containing the programs and other works. I'm sorry if this matter of terminology caused any confusion.
GFDL
It's annoying but it can be dealt with. The distinction I, personally, was trying to make is that that's a finite, known, limited amount. You didn't respond to the point that the amount for the GFDL is not a maximum amount at all, just a current amount. I see the distinction, but I don't think it makes a significant difference, since in any real case it is a given amount. The GFDL allows arbitrarily large amounts of invariant text. Do you agree that, say, 1000 pages of invariant text would be non-free? I am not sure. I would consider 1000 pages unacceptable in practice, unless the manual itself is much bigger. That much makes publication of a modified manual as a manual unfeasible. But I hesitate to say that it would be non-free. Would a 1000-page license be automatically non-free? I'd probably refuse to use software with such a long license, since I would not want to read the whole license, and I would not bother checking whether it had any non-free requirements. But I hesitate to say it would be non-free just because of its length. I would not release a reference card under either the GFDL or the GPL, because both of them are long enough that the requirement to distribute them along with the reference card is burdensome. But surely this doesn't imply they are non-free licenses. With the GFDL'ed reference card, since the Invariant Section text is the majority of the text, I'd be doubtful that it could qualify as Secondary at all: it may be the main topic by sheer volume. So it may not even be distributable. The invariant sections don't define the main topic, because interpreting them as the main topic is inconsistent with the GFDL's requirement that they be secondary. Further Invariant Section problem: I can't use parts of the GCC manual in an essay on the funding of free software For the manual to be free, you must be able to publish a modified version of the manual. In other words, a modified manual. Being able to use some of the text for something of a different kind, such as an essay about the funding of free software, is something above and beyond the call of duty for a license.
GFDL and incompatibility
My point is precisely that a GFDL manual *cannot* be incorporated into *ANY* free software project. And this is *different* from the old documentation license, which did not have that problem. I have never considered the question of whether the GFDL is a free software license. The question seems purely academic, since it is (1) not meant as a license for programs, and (2) clearly an annoying license to use for programs. So I don't know if I would agree this is true. What I can say is that the question has no practical significance. If I have a manual for FOO, I might want to merge it with FOO. Whether that is possible does have practical significance. As I've explained, this cannot be a criterion for whether the manual's license is free, since merging may be forbidden due to incompatibility even with licenses that Debian agrees are free; also, there are other ways to get the job done when merging is impossible. But at least the question is a real question. But if we cannot merge it with FOO, why in the world would we care whether theoretically we could merge it with some other hypothetical program BAR? That question is in meaningful in a theoretical sense, but I don't see a need to ask it. However, the point is that the simple license, was always compatible with at least one free software license. For example, one could easily distribute software under the simple license itself. I don't think anyone ever did so. In practice, the issue is not significant, since you can distribute the manual along with the software, and make the software access the manual in whichever way you want. Is that how Emacs gets its doc strings? The text in the manual is usually not suitable for a doc string, and vice versa. I don't copy text from the Emacs manual into a doc string, even though the FSF as copyright holder for both could do so.
Re: GFDL and incompatibility
Richard Stallman [EMAIL PROTECTED] writes: The text in the manual is usually not suitable for a doc string, and vice versa. I don't copy text from the Emacs manual into a doc string, even though the FSF as copyright holder for both could do so. The problem is that you can't even re-edit it into a doc string. Anything that's a derivative work is out-of-bounds. The GFDL forces a particular implementation of program-with-documentation, and that's already a bug.
Re: Why documentation and programs should not be treated alike
Richard Stallman wrote: The main difference between a program and documentation is that a program does something, while documentation is passive; By this argument, source code to a program (of the sort which must be compiled to run) is not a program. That's a pedantic approach to the issue. I'd say a source program does do something (after you compile it). And can therefore, in your opinion be encumbered by unlimited numbers of Invariant Sections (presumably in 'mandatory comments') while remaining free, as long as they can be removed from the actual executable binary, I suppose. I think that nontechnical invariant comments do not make a program non-free, but not for those reasons. The reason is that this is a packaging requirement that doesn't really restrict you from making the program substantively behave as you want it to. Glad you're consistent about that. You've even almost convinced me. :-) However, I think GFDL Invariant Sections in manuals are worse than that, and are non-free, because they do really restrict you from making the manual say substantially what you want it to, by requiring it to also say certain other things. Whether I agree with those things or not is irrelevant. (Just as the ls --hangman requirement restricts the way a program can behave.) Further, the GFDL requirements are *not* written as packaging requirements. They are written as content requirements. Perhaps a thorough rewrite would make this packaging interpretation clear and self-evident? It isn't right now. Anyway, the only packaging requirement specifically accepted by the Debian project is distribution in patch-file format (and that's discouraged). There's no blanket exemption for packaging requirements in Debian, perhaps unlike at the FSF. If you think there should be, amend the Social Contract or the DFSG. Furthermore, a manual in any markup format (LaTeX, HTML, info, texinfo) is not passive: it does something, namely generating the actual manual in the intended-to-read format (printed, visible on screen in 'info' or 'mozilla', etc.) So manuals in any markup format -- including all the GNU manuals -- are thus akin to programs, and should be judged by those criteria. That's focusing on form rather than substance. A manual typically has source code which contains markup, and that is formally analogous to the source code of a program. But in substance the two cases are completely different. In the compiled form of a program, you can't see anything important about it. If even the comments are missing, you can't understand the important aspects of the program. Thus, access to the real source is essential for a program to be considered free. You can see what it *does*, just not how it does it. This is very similar to seeing the compiled form of a manual, if you care at all about markup. In the compiled form of a manual, as long as there is no DRM to stop you from reading it, everything that matters is plain to see. You see the contents, and you even see the fonts and indentation that were selected by the markup. The markup commands, which you don't see, and any comments in the markup, are far less important than what you do see. If you can read the published manual, what you see is everything that really matters. Ever seen a Postscript file? It's *all there*, and it's a thoroughly documented format, but it's quite hard to see. Anyway, this highly subjective judgement as to what really matters is a matter on which sensible people can easily disagree, and we do. It's also quite irrelevant to debian-legal, whose job is *not* to determine what really matters. If you want to argue about that, go to debian-project and propose that the Debian Social Contract be changed. This is why the GFDL does not require complete corresponding source code for a published manual. It's easier to change the manual if you have this, but no disaster if you don't: you just have to write your own mark-up, which is pretty straightforward. Says you. I find it less straightforward, personally, than reimplementing many types of programs from scratch! (This is because I'm not very good with markup languages.) The requirement for a transparent copy is so that you don't have to keyboard the whole text again in order to publish a modified manual. Why not just require source? I guess you prefer to require that the manual be available as a text file than that it be available in its original source format. I don't really understand or agree with this. Even that is not impossible, but it's a bigger pain than writing mark-up afresh. (I think the right thing to do is to distribute the complete corresponding source code. For manuals, there is a real danger that the source will be in a format that free software cannot read, and thus useless. The same danger *does* exist for programs, and happens often: a
Re: GFDL
Richard Stallman wrote: Being able to use some of the text for something of a different kind, such as an essay about the funding of free software, is something above and beyond the call of duty for a license. This is clearly the key point where Debian and the FSF diverge. I think there is nothing more to be said. Thanks for the clarification of your views.
Re: Re: License requirements for DSP binaries?
Glenn Maynard wrote: On Mon, Sep 22, 2003 at 08:47:26AM +0200, Thomas Hood wrote: IBM distributes the Linux driver and the binaries in a tarball that it says is licensed under the GPL. http://oss.software.ibm.com/acpmodem/ No source code is provided for the DSP binaries. (N.B., past discussions of this issue have reached the conclusion that such software can nevertheless be distributed in main.) If it's licensed under the GPL, and no source is provided, then it can not be distributed at all, not even in non-free, unless there never was source to begin with. (I assume this isn't the case, as you said no source code is provided, not no source code exists.) We should allow it if source code once existed but no longer exists (all the copies of the source code were wiped accidentally at some time in the past). (This has happened with old games and firmware fairly often, and the conclusion has been that the binary is now the only meaningful 'source', because it's the preferred form for modification, out of those forms which exist.) But if IBM *has* any source code for this, it should be distributing it. Someone who cares about the driver should contact IBM about this.
Re: A possible GFDL compromise: a proposal
Do you have numbers to back the claim that it is more widespread? I thought only English had the free/free ambiguity enough to create a market for the more ambiguous term open source. Most of the computer-using world uses English, and the English-language press is most influential. In French and Spanish, the term libre is used most of the time, though there are persistent efforts to introduce open source or codigo abierto. In Italy the English term open source seems to be used more than the Italian software libero. I have seen similar tendencies in some other countries, but I cannot give a detailed report.
