Re: simplest copyleft license for a wiki
On 2003-11-26, Alex Schroeder [EMAIL PROTECTED] wrote: Hm, maybe that is up to the courts to decide. It doesn't look like a copyleft to me, but that's just my first impression. I'm used to this definition from the FSF site: Copyleft is a general method for making a program free software and requiring all modified and extended versions of the program to be free software as well. I think if you want to use non-standard words like copyleft, you should include this definition in the license. I think you should also define free software. The BSD Preservation License would not fit this definition of copyleft. Peace, Dylan
Re: The license of LaTeX2HTML
On 2003-10-25, Brian M. Carlson [EMAIL PROTECTED] wrote: On Sat, Oct 25, 2003 at 10:20:26PM +0200, Roland Stigge wrote: Maybe I should add that some files in latex2html are GPL'ed, which possibly forces us / the maintainer to apply the GPL to the whole package. If some files are GPL, then the whole work must be distributed under the GPL. Unfortunately, this license is incompatible with the GPL; therefore, we cannot distribute it at all. If you cannot resolve this issue with upstream, you should file a bug on ftp.debian.org requesting its removal. Are the GPL files copyright by someone other than the upstream author? If so, upstream is also violating their copyright. Many of the GPL'ed files seem to be copyright by people other than Nikos Drakos, but they also seem to have been written specifically for latex2html, so presumably they have no problem with granting an exception. Peace, Dylan
Re: BSD Protection License
On 2003-10-23, MJ Ray [EMAIL PROTECTED] wrote: Please add your clarifications to your licence text. Assertions here may not be taken into consideration. I'm not sure what current opinion is about legal validity of unsigned emails to a public list. Hmm? debian-legal has frequently accepted unsigned e-mails as clarifications of license texts. I also don't think the original license was at all ambiguous in the clause 3 vs. clause 4 issue: such a license is a grant of permission, and if I grant you permission to do X if Y, and also grant permission to do X if Z, then if you do either Y or Z, then you can do X. If one wanted to tie the two clauses together, then you'd have to add some explicit language linking the two clauses. For instance, take the GPL: Clause 1 grants permission to distribute verbatim copies, which is obviously not free enough for Debian; it's only Clause 3 that grants you permission to distribute modified copies. The situation seems analogous. I think the license is obnoxious and not to be encouraged [perhaps by keeping it out of Debian], but I don't yet see any reason it's not DFSG-free. Peace, Dylan
Re: centericq and MSN support
On 2003-10-23, Brian Ristuccia [EMAIL PROTECTED] wrote: (The fact that end users might use the software for something illegal is irrelevant to whether or not it can be included in Debian. One can use mixmaster for industrial espionage, john to brute-force UNIX password files for the purpose of making unauthorized use of private computers, some half-dozen or more packet sniffers to run illegal wiretaps, GNU shred to destroy evidence, and xvidtune to commit arson[1]. We still distribute those). I believe courts have drawn a legal distinction between products or code that has a reasonable legal purpose and code that has no such legal purpose. Peace, Dylan
Re: centericq and MSN support
On 2003-10-23, Måns Rullgård [EMAIL PROTECTED] wrote: Dylan Thurston [EMAIL PROTECTED] writes: I believe courts have drawn a legal distinction between products or code that has a reasonable legal purpose and code that has no such legal purpose. In the case of MSN, would it be legal to run a private server, using the MSN9 protocol? Or is the protocol patented or copyrighted in some way? If such a server is legal, then a non-authorized client would also have a possible legal use. That could indeed be the case. I don't know enough about the situation to have any further comment; I just wanted to say that the situation is not necessarily analogous. Peace, Dylan
Re: If not GFDL, then what?
On 2003-10-13, Brian T. Sniffen [EMAIL PROTECTED] wrote: The GNU GPL is somewhat awkward for print distribution: it requires either a CD of source in the back or an onerous offer valid for three years. The best alternative I can consider is to distribute the book under the GPL, with the special exception that printed copies may be derived from it, or perhaps a separate license to the publisher. Be careful with the exception: you probably don't want people printing modified copies without also releasing the source. Alternatively, you could provide the publisher with a written offer to provide the source, which they could then print in the back of the book (without providing anything themselves). Peace, Dylan
Re: If not GFDL, then what?
On 2003-10-13, Steve Langasek [EMAIL PROTECTED] wrote: On Mon, Oct 13, 2003 at 03:55:36PM +, Dylan Thurston wrote: Alternatively, you could provide the publisher with a written offer to provide the source, which they could then print in the back of the book (without providing anything themselves). That only works under the stock GPL if the publisher is engaged in non-commercial distribution of the work. Yes, thanks. So to do this you'd have to add an explicit additional permission to clause 3(c), as well. Peace, Dylan
Re: GFDL and Anonymity --- another problem?
On 2003-10-09, Anthony DeRobertis [EMAIL PROTECTED] wrote: Several parts of the GFDL (e.g., 4b, 4i) seem to prohibit anonymous modifications to a document. Quoting 4b: List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, If this requires an actual name, it seems this might fail the Chinese[1] Dissident Test. Surely an entity is lose enough to include, say, a Chinese Dissident Collective created on the spot. Peace, Dylan
Re: MPlayer DFSG compatibility status
On 2003-10-08, Glenn Maynard [EMAIL PROTECTED] wrote: I think the only interesting question is whether a phone call from a non-legal Microsoft employee is enough for Debian to count the patent as enforced. Alternatively, does anyone think there's a chance Microsoft would be willing to state they would not enforce the patent against us? I believe they want this format to be more widely used, no? What if Microsoft publically states that they would enforce the patent against Windows players, but not against Linux players? Peace, Dylan
Re: Japanese font license problem
On 2003-10-08, Fedor Zuev [EMAIL PROTECTED] wrote: In this case, it is very unlikely that TYPEBANK Co. will win a lawsuit in any country. After all, similarity is not implies derivative work. But it is very likely that they will threaten, harass and terrorize everyyone who will ever touch their intellectual property. If I understood the original post correctly, TYPEBANK's font was copied without changes by one group (the LABO123 font), and then modified by two later groups who mistakenly thought the font was available under a free license. So it seems likely that TYPEBANK would win a suit in a country in which fonts are copyrightable, since there's a clear chain of derived works (although IANAL). Peace, Dylan
Re: snippets
On 2003-10-02, Barak Pearlmutter [EMAIL PROTECTED] wrote: - the enormous number of snippets. I would be surprised if fewer than 10% of our source tarballs contain snippets. Maybe a lot more. In the interests of furthering the discussion, can I suggest limiting the discussion further, beyond your definition of snippets? Your definition includes both files not clearly under any license and files under explicitly non-modifiable licenses, which seem like quite different situations to me, and also include many hypothetical files in a wide variety of different packages. I propose that we limit the discussion to the only files that have been explicitly pointed out, namely, the essays (GNU and so forth) in the etc directory of the emacs tarball (and xemacs as well). It is not hard to locate these; they have already been located. There is no question about the license they are under. The license is clearly not DFSG-free. Should these files be removed from the tarball and from Debian? Peace, Dylan
Re: begging the question
On 2003-09-30, Andrew Suffield [EMAIL PROTECTED] wrote: --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 30, 2003 at 08:37:46AM -0600, Barak Pearlmutter wrote: Andrew Suffield [EMAIL PROTECTED] writes: =20 Your thesis contains two contradictory points. Branden has responded to one of them, citing the other, and pointed out the contradiction. That is the entire point of his question. =20 The two points that are in conflict are: =20 1) These works were intentially included in Debian as a result of conscious choice on the part of developers 2) Identifying these works in order to remove them would be prohibitively expensive in its use of time. =20 These are not in the least contradictory. ... So you are now retracting your original argument, and instead claiming that developers chose to ignore this problem *without* investigating the details? In future please state your two-line arguments instead of using eight-line vague analogies. No, he's saying that developers were aware of the issue in general terms, but not the specific files. (So they didn't investigate the details, but also didn't ignore the problem.) In the absence of input from the developers in Debian at the time, I find this whole discussion fairly pointless; I also think it's irrelevant. Debian should do the right think now. Peace, Dylan
Re: snippets
On 2003-09-29, Barak Pearlmutter [EMAIL PROTECTED] wrote: (2) No practical problems have arisen from allowing snippets to be included. No one has proposed any gedanken practical problem. OK, here's one: what if the Japanese government wants to make a completely localised version of emacs? They would be unable to, because they would not be able to translate the GNU Manifesto, which does not yet have an official translation into Japanese. They could probably prepare a summary in Japanese, but that is different from giving a translation. You might argue that the GNU Manifesto is tangential to emacs and not necessary to run the program, but that then raises the question what it is doing in the package in the first place. To the extent to which such a snippet adds to the package, it should be possible to make it accessible to all users. [To forestall one objection: obviously the translators would make it clear that it was an unofficial translation. I believe a restriction in the license to this effect would be accepted as DFSG-free.] For another example, consider the Free Software Needs Free Documentation essay, currently distributed as an invariant part of the GDB manual. [This is not removable, so does not fit your definition of a snippet, but certainly could be distributed as a snippet.] It contains an outdated statement about the documentation of Perl (saying that it is non-free). One thing a maintainer would want to do would be to add an editorial note mentioning that this is no longer true. I can imagine many of your other examples of snippets becoming outdated in similar ways. Peace, Dylan Thurston
Re: snippets
On 2003-09-29, Mathieu Roy [EMAIL PROTECTED] wrote: OK, here's one: what if the Japanese government wants to make a completely localised version of emacs? They would be unable to, because they would not be able to translate the GNU Manifesto, which does not yet have an official translation into Japanese. They could probably prepare a summary in Japanese, but that is different from giving a translation. They can provide a translated version. They only must add the original text along, which is not a real burden with this kind of documents (it does not change the usability). No they can't: the permission notice at the top of /usr/share/emacs/21.3/etc/GNU on my system says: - Copyright (C) 1985, 1993 Free Software Foundation, Inc. Permission is granted to anyone to make or distribute verbatim copies of this document, in any medium, provided that the copyright notice and permission notice are preserved, and that the distributor grants the recipient permission for further redistribution as permitted by this notice. Modified versions may not be made. - Note that permission to make modified copies (including translations) is explicitly not granted. Conceivably make a translation falls under a fair use like statute in some countries, but I don't know of any. Peace, Dylan
Re: snippets
On 2003-09-29, Mathieu Roy [EMAIL PROTECTED] wrote: Dylan Thurston [EMAIL PROTECTED] a tapoté : On 2003-09-29, Mathieu Roy [EMAIL PROTECTED] wrote: OK, here's one: what if the Japanese government wants to make a completely localised version of emacs? They would be unable to, ... They can provide a translated version. They only must add the original text along, which is not a real burden with this kind of documents (it does not change the usability). No they can't: the permission notice at the top of /usr/share/emacs/21.3/etc/GNU on my system says: - Copyright (C) 1985, 1993 Free Software Foundation, Inc. Permission is granted to anyone to make or distribute verbatim copies of this document, in any medium, provided that the copyright notice and permission notice are preserved, and that the distributor grants the recipient permission for further redistribution as permitted by this notice. Modified versions may not be made. - Hum, this is apparently very specific to the manifesto... As long as I know, it's the only text that have such copyright note in all www.gnu.org. I do not know why. It may be historic but it sounds problematic, indeed. All the files listed in Bug #207932 have essentially equivalent licenses, and a few that I checked have the equivalent licenses on the web site, as well. But what happens when the manifesto is included in a GFDLed manual, which clearly allows translation, as long as the original text is provided? That's why I gave the second example in my earlier message, of a practical reason why you would, in practice, want to modify such a document, beyond just making a translation (while retaining proper attribution). To get back to your example, would it lower the usability of emacs if the Japanese government is unable to provide the GNU manifesto in japanese? It would only lower the interest of this text being shipped with emacs to japanese people, IMHO. I'm not sure I follow what you say, but I see two possibilities: a) It would lower the usability Emacs, in which case there is a real obstacle to Debian users' freedoms (in that I can not take the text, translate it into Japanese, and share it with my friend who does not speak English) b) It does not lower the usability, in which case it has no business being in the package. Personally, I think it's a great essay and would love to share it around (including making it more visible in the Emacs packaging); I'm just disappointed that RMS will not let me share it with my friends (and so, I maintain, it is not eligible for inclusion in Debian). Peace, Dylan
Re: snippets
On 2003-09-29, Richard Braakman [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2003 at 10:01:19AM -0400, Jeremy Hankins wrote: Burden of proof arguments are, at best, very trick to make -- I suggest you not rely on it. Certainly I don't buy it in this case. Unless you can actually point to someplace that says this is current practice, I don't think you have a basis for saying that it is actually a conscious practice at all. Well... you would have to claim that the people who drafted and discussed the Social Contract, and the 90 who voted for it, were unaware of the GNU Manifesto and its presence in the emacs packages. This is an extraordinary claim. The document was, if anything, better known then than it is now (at least if you divide by the size of the free software community). I certainly knew about it long before I got involved with Debian. Had all 90 people aware of/thought about the non-modifiability of the GNU Manifesto? For myself, I read the GNU Manifesto in the emacs distribution long before Debian existed, but I don't think I thought much about the fact that it was non-modifiable until recently. Good point, though. Peace, Dylan
Re: snippets
On 2003-09-29, Richard Braakman [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2003 at 10:01:19AM -0400, Jeremy Hankins wrote: * If the answer to the above is no, should we distribute them anyway, simply because we don't have them in a free form? Hi. I think my first reply to this mail didn't get to my actual point. I think your question here is the wrong way around. These snippets are present in the stuff we package. The question is whether they're worth removing, not whether they're worth distributing. What are the advantages of keeping them? ... What are the advantages of removing them? ... I don't see a convincing case here for removing them. Agreed that on the face of it there isn't much gained on a practical level by removing these snippets. However, can you go back and answer your same questions for code snippets? For comparisons sake, the code should be: * Non-modifiable but removable; * Completely incidental to the main purpose of the package (maybe it shows a clever about box, or provides some amusing extra feature like the waving-man-in-the-menu that was apparently consider for the original Mac, or is an entirely separate program which is humorous added value along the lines of sex.6); * Bug-free; and * Close to the upstream author's heart. What's the convincing case for removing this, if any, and if you would remove it, how would you distinguish from the text snippets case? (Apologies that this is hypothetical, but I hope the examples above are plausible enough that you can answer the question.) Peace, Dylan
Re: A possible GFDL comporomise: a proposal
On 2003-09-29, Fedor Zuev [EMAIL PROTECTED] wrote: On Sat, 27 Sep 2003, Nathanael Nerode wrote: Fedor Zuev wrote: First, try to answer to several simply questions. FYI, these are *my* answers, not necessarily everyone's answers. 0) Is printed Emacs Manual in bookstore a software or hardware? The lump of paper and ink is hardware. Including the various splotchesof ink resulting from printing press problems. But the 'text of the manual',that abstract entity embodied in the manual, is software. 1) Is Emacs Manual recorded on CD-Audio a software or hardware? The bits are software, the lump of plastic is hardware. ... 8)Is Debian logo written on [cover of] the same CD-ROM software or hardware? Neither, really, but... The printed cover with its actual copy of the logo,possibly with some dirt, etc., is hardware. The logo as a copyrightable entity embodied on the cover is software. ... Song written on CDDA is a software, whereas the song written on a analog magnetic tape (exactly the same object from the copyright|licensing perspective) is not a software. Right? I'm not sure how you're deriving this distinction between information-stored-digitally and information-stored-analogly from Nathanael Nerode's answers: to me, his answers seem consistent with the interpretation that all information is software, independent of its physical manifestation. Perhaps you're mistaking his answers for those in another post? Peace, Dylan
Re: a DFSG/GNU FDL quick reference webpage
On 2003-09-27, Manoj Srivastava [EMAIL PROTECTED] wrote: I have occasionally received requests in private mail for some links to a document summarizing Debian's position on the GNU FDL as it relates to the DFSG. I think we need to have a position statement, issued under the Debian constitution section 4.1.5. ... Please visit URL:http://people.debian.org/%7Esrivasta/Position_Statement.xhtml Any comments, feedback, suggested wording, and proof reading appreciated. I'm not sure going point-by-point through the text of the license is the best way to proceed; I feel like the main point gets a little lost. For instance, the DRM issues, which RMS has said the FSF will address (eventually), happen to come up first, while I feel the heart of the disagreement is over the invariant sections. At least, I would have some executive summary at the beginning. Peace, Dylan Thurston
Re: committee for FSF-Debian discussion
On 2003-09-29, Anthony DeRobertis [EMAIL PROTECTED] wrote: On Sunday, Sep 28, 2003, at 14:30 US/Eastern, Brian T. Sniffen wrote: A good candidate would also be familiar with debian-legal's analysis of the GFDL. Any of N Nerode, D Armstrong, or A DeRobertis would I am neither a developer nor a NM applicant (yet); however, I would be happy to serve. Does anybody else find it amusing that none of the three names above are Debian developers? Peace, Dylan
Re: snippets [was Re: Respect for Upstream Authors and Snippets of Interest]
On 2003-09-28, Barak Pearlmutter [EMAIL PROTECTED] wrote: If we decide to go on a crusade against them, it would be a really big deal for a couple reasons: - Debian is absolutely *rife* with such snippets. - This is because upstream tarballs are absolutely rife with them. - Scanning our sources for them would be a gargantuan undertaking. - They'd keep sneaking back in. All of these apply to ordinary bugs much better than to snippets. The number of bugs in a typical upstream tarball vastly exceeds the number of snippets, for instance, and are much harder to find.. For those keeping score, I've omitted these two: - It would be a major change in practice. - No other free software organization eschews such snippets. I disagree with the premises of those two, as well. For instance: no other free software organization edits out the non-free fonts from XFree86 or the non-free firmware from the linux kernel; and this seems like a relatively minor change, as changes in Debian go. Peace, Dylan
Re: Respect for Upstream Authors and Snippets of Interest
On 2003-09-28, Barak Pearlmutter [EMAIL PROTECTED] wrote: About the README offer you allude to, do you really think an upstream author's statement: Copyright blah blah blah ... Distributed under the GNU GPL v2 ... Source licenses for inclusion of this code in proprietary programs are available from the author for $10,000 plus 2% of gross sales. is modifiable? Removable sure. Maybe appendable. But modifiable? How can it be changed? Do you think Debian could just change the 2% to a 0.5%? Maybe give a discount to non-profits? When we talk about code being modifiable, that's what we mean: the ability to change it in arbitrary ways. Here, no changes are in fact possible, however you read the license and such. I would take it at its word: it is licensed under the GPL. Of course, Debian would not misrepresent the upstream author (and it may well be illegal for other reasons, unrelated to copyright), so we would not change the text of the upstream author's message; but we could, for instance, freely prepare a translation (while stating that it is a translation). I'm sure there are some examples of packages currently in Debian with a README originally written in Japanese where we do just that. Note that a translation is a derived work and would be illegal if the README were under the standard all rights reserved copyright. Peace, Dylan Thurston
Re: snippets [was Re: Respect for Upstream Authors and Snippets of Interest]
On 2003-09-28, Barak Pearlmutter [EMAIL PROTECTED] wrote: - No other free software organization eschews such snippets. I disagree with the premises of those two, as well. For instance: no other free software organization edits out the non-free fonts from XFree86 or the non-free firmware from the linux kernel; and this seems like a relatively minor change, as changes in Debian go. I'm not sure I follow your reasoning there. Your email address implies that you are associated with a math department, so let me phrase this in mathematical jargon: a proof of this form A - B A - C Therefore: B and C are the same is not valid. I am not claiming that non-free firmware or non-free fonts in XFree86 are the same as unmodifiable snippets, only that your point above (No other free software organization eschews such snippets) does not serve to distinguish them. (Well, the FSF would eschew those bits in the kernel or XFree86 as well, but they don't actually do the work of separating them out.) But in any case, I think I missed making my larger point: in the section I quoted, you were arguing that we should avoid taking out snippets because it is a lot of work. To me, that is not an argument: either it's wrong or it's right (per the DFSG/courtesy to authors) to include snippets, and if it's wrong we should remove them when we notice them. If it's very wrong to include snippets, we should in addition go through the major work of identifying them all, but that doesn't follow from just the assertion that they violate the DFSG. Compare this with the situation with non-free code. It is nearly certain that there is some code that violates the DFSG in main; do you want to do an audit of all packages to root it out? I'm much more interested in the arguments why it's a good idea in the first place to include the snippets than in these arguments about how much work it would be to remove the unmodifiable snippets. Peace, Dylan
Re: License requirements for DSP binaries?
On 2003-09-26, Edmund GRIMLEY EVANS [EMAIL PROTECTED] wrote: Back to the DSP binaries: I remember that at one point there were DSP binaries included in the Linux kernel source. Is that still the case? AFAIK, this is one good reason that Debian does not distribute pristine kernel sources: the various binaries have been removed from the upstream kernel sources before packaging. Peace, Dylan
Re: coupling software documentation and political speech in the GFDL
On 2003-09-26, Bruce Perens [EMAIL PROTECTED] wrote: The conflict is around the need professed by FSF to hitch political speech to the cart of software documentation, and the fact that Debian, while it may have been designed in part to achive a social or political goal, was designed to deliver software rather than political speech. Sure, that's a nice analysis. What do you propose to do about it? Debian would be quite happy to distribute modifiable political speech (with suitable provisions for protecting the author's integrity), but the FSF has not shown any interest in considering that possibility; and most DDs posting here seem quite firm in the view that unmodifiable political speech is not allowed. Peace, Dylan
Re: Respect for Upstream Authors and Snippets of Interest
On 2003-09-27, Barak Pearlmutter [EMAIL PROTECTED] wrote: Based on long-standing Debian tradition and practice, this [removing non-modifiable texts] is decidedly and demonstrably not the case! Don and others were perhaps writing in haste. It is long-standing tradition; however, whether it should continue is another question. I haven't seen many people offering a principled defense of the practice. I would be very surprised if any DFSG-free text were removed from a Debian package. To my knowledge Debian has not only never removed a snippet from the source we distribute, but includes such snippets in the binaries, typically in ...-doc.deb. One example of this is GNU Emacs, which includes a bunch of such snippets, all of which are included---right now---in /usr/share/emacs/21.2/etc/. All of them are removable: sex.6 (which is of questionable taste), Please see the discussion Bug #154043. sex.6 has no copyright statement, and so can reasonably be supposed to be covered under the copyright of the whole package. GNU, CENSORSHIP (which is dated into such irrelevance that its inclusion is arguably embarrassing), LINUX-GNU (whose first sentence misleadingly reads The GNU project started 12 years ago), ... Already filed as bug #207932, marked as sarge-ignore (per the release manager's stated policy). If you want to offer a principled reason why this is not a bug, I'm eager to be convinced (although IANADD, so you don't need to convince me). COOKIES (whose relevance, copyright status, and humor value is unclear), Same situation as sex.6. Peace, Dylan
Re: solution to GFDL and DSFG problem
On 2003-09-27, Peter S Galbraith [EMAIL PROTECTED] wrote: Zedor Fuev [EMAIL PROTECTED] wrote: I will both consent and interests of users and unoriginal. You can believe that personally You do not use any more abstract important cases, this list software is not be counted copyrightable. Please for the document by European copyright regime; which, can be; governed by here, in GPL covered literary work, with any compatible language you. I'm sorry, but I can't parse this, nor the remainder of your post. Look at the name. Evidently someone is making a joke in poor taste about people whose native language is not English. Peace, Dylan
Re: Bug#207932: Respect for Upstream Authors and Snippets of Interest
On 2003-09-27, Rob Browning [EMAIL PROTECTED] wrote: In any case, presuming debian-legal becomes satisfied that I don't need to do anything about these files, I'll either mark this bug wonfix, or more likely, close it. Of course. When I filed the bug, I was under the impression that debian-legal had a concensus, but I may have acted too soon. Peace, Dylan
Re: A WDL.
On 2003-09-18, Thomas Bushnell, BSG [EMAIL PROTECTED] wrote: Eben Moglen has told RMS that it's ok for us to do the Unicode trick: to alter it into some other form, and then that new form is entirely unrestricted by the license. And then, if we like, convert back to the original form too, which remains unrestricted. Wasn't the FSF going to actually do this? Has it happened? Peace, Dylan
Re: A WDL.
On 2003-09-17, Wouter Verhelst [EMAIL PROTECTED] wrote: The question is: will requiring those markings make the license non-free? I think it's more likely to be considered free if you require functionality rather than specific wording. Compare this clause from the GPL: c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. ... with the requirements in the GFDL that you leave text unmodified, and, e.g., title your Acknowldgements section with exactly that word. I think such a requirement (to provide either a particular piece of text, or a pointer to it) could be free, but I'm not sure. (And IANADD.) Peace, Dylan
Re: A possible GFDL compromise: a proposal
On 2003-09-16, Joe Wreschnig [EMAIL PROTECTED] wrote: Walter Landry [EMAIL PROTECTED] writes: Richard Stallman [EMAIL PROTECTED] wrote: To the readers of this message: if you are a Debian developer and you do, or perhaps might, support including manuals covered by the GFDL (without expecting it to change) in Debian, please write to me and tell me. (I am not subscribed to debian-legal and could not handle the volume of mail.) But before you send it, please see if I have sent a further message to debian-legal saying enough! Your question has already been posed, and the answer is found here http://lists.debian.org/debian-devel-announce/2003/debian-devel-annou= nce-200308/msg00017.html =20 No, the question was (carefully?) biased, ruling out several options. Several options that are irrelevant to the question of whether or not the GFDL is DFSG-free. We've been over this many times. ...which is not what RMS asked above. debian-legal clearly believes that the GFDL does not meet the DFSG. Passing the DFSG is the *only* way anything can get into Debian. If you want something else to get into Debian, you need to propose definitions or guidelines on -project as a GR. Right. So RMS is asking for anyone who supports such a GR to e-mail him. I agree with Thomas Bushnell that this is a rude thing for him to ask, however. Peace, Dylan
Re: A possible GFDL compromise: a proposal
On 2003-09-14, Thomas Bushnell, BSG [EMAIL PROTECTED] wrote: Perhaps people who aren't native English speakers have learned the wrong definitions? I think it's safe to say that even native English speakers may differ on the definition of software, so speaking of wrong definitions is probably not helpful. However, in this case: a) There is no sensible alternative definition that I have seen proposed (and no other grounds for judging non-programs within Debian); b) Bruce Perens, the principle author of the DFSG, has clarified that it was intended to apply to everything on a Debian CD. So I think it's clear which definition is controlling here. There are clear ways to change the situation: start a discusion on debian-project, followed by a GR. I find it strange that this issue continue to comes up on debian-legal, which is clearly not the place to discuss changing the DFSG, or deciding which bits on the CDs the DFSG should apply to. Peace, Dylan Thurston
Re: getting personalities out of the FSF-Debian argument
On 2003-09-11, Branden Robinson [EMAIL PROTECTED] wrote: If we were to elect a person to serve in this role, I suggest we permit people to self-nominate for a period, and then the Developers can elect one using the procedure described in the Debian Constitution. ... Depending on the intentions, this may be a bit heavier than needed: if we just want someone to represent the concensus of debian-legal, without making binding commitments, couldn't there just be an informal process of acclamation? (Incidentally, if RMS can't keep up with all the messages addressed to him, then I must wonder why *my* messages addressed to debian-legal are a problem in particular. But I digress.) Let me add my name to the list of people who would be disappointed to see you stop posting on this subject. Peace, Dylan
Re: getting personalities out of the FSF-Debian argument
On 2003-09-11, Jeremy Hankins [EMAIL PROTECTED] wrote: Manoj Srivastava [EMAIL PROTECTED] writes: On Mon, 8 Sep 2003 23:38:16 -0700 (PDT), Bruce Perens [EMAIL PROTECTED] said: I am hoping that I can deal with both organizations _as_ organizations. I think this very premise is shaky. No one person can really represent the Debian project when iot comes to the DFSG and the social contract -- not even the DPL has power delegatged to him to change fundamental issues about the project. The only decision can be made is through a general resolution of the voting membership. Would it be useful for debian-legal to designate a point-man, as it were, who could summarize discussions here and send the result to the FSF? It would introduce quite a delay in any back-and-forth, but that seems unavoidable, and it would certainly cut down on the amount of text the FSF side would have to read while maintaining transparency. For precedent for this, see the excellent (informal) work Jeff Licquia did in communicating Debian's concerns to the LaTeX project, reported in http://lists.debian.org/debian-legal/2003/debian-legal-200304/msg6.html In the earlier discussions, Frank Mittelbach had expressed in inability to keep up with all the messages addressed at him, much like RMS has done this time around. OTOH, the LaTeX project had expressed considerable willingness to change, much more than I've seen from RMS, who seems completely inflexible on the core issue of invariant sections. Peace, Dylan
Re: OT Re: A possible GFDL compromise: a proposal
On 2003-09-10, Branden Robinson [EMAIL PROTECTED] wrote: I'm guessing that you feel all of my questions to RMS have been rhetorical. They haven't been. For instance, I asked him whether Debian ceasing to distribute non-free software (and not providing reference to it in the installer, and similar measures) was a sufficient, rather than a necessary condition for the GNU Project's endorsement. I never received a clear answer to that, and I still don't know the answer. I fail to see how the question could be rhetorical, since a reasonable reader could plausibly imagine both affirmative and negative answers to the question. Maybe the GNU Project has other criteria they would need Debian to satisfy, or maybe they wouldn't. On this particular question, I think you do need to read between the lines a little, but the answer seems to be no. According to RMS, if Debian dropped the GNU documentation and removed non-free software, the GNU project would refer to Debian, but the reference could not be wholeheartedly positive. That doesn't sound like an endorsement to me, but at this point it becomes a semantic game: I think RMS' intentions are clear. Peace, Dylan
Re: Preferred license for documentation
On 2003-09-10, Edmund GRIMLEY EVANS [EMAIL PROTECTED] wrote: John Goerzen [EMAIL PROTECTED]: I should add that I want a license that guarantees that all receipients of modified versions get the full original rights. (Similar to the GPL rather than BSD in that respect.) Then use the GPL, version 2 only. This doesn't satisfy his desire to avoid derivative works being released in a format that is only readable by proprietary software. Peace, Dylan
Re: Bug#181493: SUN RPC code is DFSG-free
On 2003-09-08, Thomas Bushnell, BSG [EMAIL PROTECTED] wrote: Have you asked the glibc team (the actual upstream) what they think? Or the FSF? I would start that way. I sent a short note to the FSF on Sunday (as a private individual, interested in Debian) setting out the situation and asking what if they had more information. I have not heard back yet. Obviously it makes sense to coordinate any replacement of the RPC code with the glibc team, if it turns out to be necessary. Peace, Dylan
Re: Some licensing questions regarding celestia
On 2003-09-09, Don Armstrong [EMAIL PROTECTED] wrote: On Mon, 08 Sep 2003, Steve Langasek wrote: Also, the UCITA has been happily rejected by a fair number of the states where it was originally proposed and is being disputed elsewhere, so it's not much of a precedent. True. I was merely using it to point out the direction that statute seems to be headed. There are clauses of UCITA that I really dislike, and I'm glad it hasn't been made law everywhere. But it does embody a substantial amount of current legal thought. The UCITA is officially dead. On August 1, the NCCUSL disbanded the UCITA standing committee was discharged and they decided to not expend any additional Conference energy or resources in having UCITA adopted. See http://www.nccusl.org/nccusl/DesktopModules/NewsDisplay.aspx?ItemID=56 http://[EMAIL PROTECTED]/happening.html So the question of whether software licenses that claim to be leases are actually valid remains a question for the court. OTOH, a license like the GPL does not claim to be a lease in any way; I don't see how it could be interpreted that way. Peace, Dylan Thurston
Re: Changing a license of a unmaintained software
On 2003-09-06, Edmund GRIMLEY EVANS [EMAIL PROTECTED] wrote: Scott James Remnant [EMAIL PROTECTED]: Not true, the UK has a set of rules as to what constitutes sufficient authority to be bound by the contents of a document. The Electronic Communications Act 2000 extended these to include digital signatures, such as those created by PGP, if the signer so wished it to be interpreted it that way. This contradicts what I have been told. In any case, surely it is well known that it is possible to make a contract without any form of writing, and any relevant circumstance may be used as evidence that a contract was made, unless specifically excluded by rules such as hearsay. ... Posessing a digitally signed e-mail from the author would have (under UK law) the same power as holding a written letter signed by the author. That's bullshit, I think. But let's not bother discussing it any further. ... A signature and a seal are the same thing. I disagree strongly, but let's not waste time on it any more. Are you aware that it is extremely rude to reply to a message containing references to specific UK laws, call it bullshit and disagree strongly, but neglect to perform your own research and not want to bother discussing it or waste time on the issue? If you're really not interested, then this message served no purpose; if you are interested, you should respond with something of more substance. Did you look up the law, for instance? (I did look at the Electronic Communications Act at http://www.hmso.gov.uk/acts/acts2000/2007.htm, and it does seem to say just what Scott Remnant said. But I didn't look closely.) Peace, Dylan
Re: GNU/LinEx, Debian, and the GNU FDL
On 2003-09-05, Richard Stallman [EMAIL PROTECTED] wrote: The GNU Project has never endorsed Debian, because ever since we first considered the question, the Debian servers have been distributing and recommending non-free packages. I think this practice is entirely wrong, but I did not try to change it with vilification and pressure. Instead, for several years I talked with some friendly Debian developers to promote a Debian decision to change the practice. ... If at some point Debian distributes main from a server that doesn't include or refer people to non-free software and documentation, the GNU Project could point to that server as a place to get an entirely free version of the GNU system. ... I'd like to mention that over the time I've been using Debian, it seems to have been getting steadily better on this score. For instance, for a while a default install included non-free packages in the apt sources list; then there was a configuration question asking whether non-free should be included; and now I believe the question has been removed entirely, meaning that users do not get non-free unless they know to ask for it and go out of their way to do so. And the situation may well continue to get better, with the possibility of new GRs to banish non-free further. Peace, Dylan Thurston
termcap status?
While filing a bug on the non-free essays included with emacs21 (bug #207932), I came across the file etc/termcap.src, which includes the following disquieting text: # COPYRIGHTS AND OTHER DELUSIONS # # The BSD ancestor of this file had a standard Regents of the University of # California copyright with dates from 1980 to 1993. # # Some information has been merged in from a terminfo file SCO distributes. # It has an obnoxious boilerplate copyright which I'm ignoring because they # took so much of the content from the ancestral BSD versions of this file # and didn't attribute it, thereby violating the BSD Regents' copyright. # # Not that anyone should care. However many valid functions copyrights may # serve, putting one on a termcap/terminfo file with hundreds of anonymous # contributors makes about as much sense as copyrighting a wall-full of # graffiti -- it's legally dubious, ethically bogus, and patently ridiculous. # # This file deliberately has no copyright. It belongs to no one and everyone. # If you claim you own it, you will merely succeed in looking like a fool. # Use it as you like. Use it at your own risk. Copy and redistribute freely. # There are no guarantees anywhere. Svaha! # This cavalier attitude seems rather dangerous. Is this file at all used anymore? Is there any action necessary? Peace, Dylan Thurston
Re: A possible GFDL compromise
In article [EMAIL PROTECTED], John Goerzen wrote: I didn't post it yet because I'm not yet sure in my own mind what the right guidelines are. Despite the assertions of some, I do not think that just accepting GFDL 100% is the right thing to do here. I see the following scenarios: 1. I'm a Free Software user. I am using Emacs, a large Free system that requires documentation to learn by any means. But that documentation is missing or obsolete because of GFDL. I cannot make use of this Free package. 2. I'm a Free Software developer and want to make a derivative program, but can't because it requires documentation, and I disagree with the GNU manifesto and can't adapt it, and don't have the time to rewrite the manual from scratch. As a developer myself, and a believer in the principles of the free software movement, I'm inclined to conclude that #2 is the larger problem in the long run. I wasn't necessarily so inclined two weeks ago. Regardless, I still maintain that documentation is not software and does need separate guidelines. If you do end up coming to the conclusion that the GFDL (with invariant sections) would not meet your standards for free documentation, you should make sure to include an example of some license that would be judged differently under your proposed free documentation guidelines and the DFSG. (Do you have such an example in mind already?) Peace, Dylan Thurston
Re: SURVEY: Is the GNU FDL a DFSG-free license?
In article [EMAIL PROTECTED], Branden Robinson wrote: Part 1. DFSG-freeness of the GNU Free Documentation License 1.2 Please mark with an X the item that most closely approximates your opinion. Mark only one. [ X ] The GNU Free Documentation License, version 1.2, as published by the Free Software Foundation, is not a license compatible with the Debian Free Software Guidelines. Works under this license would require significant additional permission statements from the copyright holder(s) for a work under this license to be considered Free Software and thus eligible for inclusion in the Debian OS. [ ] The GNU Free Documentation License, version 1.2, as published by the Free Software Foundation, is a license compatible with the Debian Free Software Guidelines. In general, works under this license would require no additional permission statements from the copyright holder(s) for a work under this license to be considered Free Software and thus eligible for inclusion in the Debian OS. [ ] The GNU Free Documentation License, version 1.2, as published by the Free Software Foundation, can be a license compatible with the Debian Free Software Guidelines, but only if certain restrictions stated in the license are not exercised by the copyright holder with respect to a given work. Works under this license will have to be scrutinized on a case-by-case basis for us to determine whether the work can be be considered Free Software and thus eligible for inclusion in the Debian OS. [ ] None of the above statements approximates my opinion. Part 2. Status of Respondent Please mark with an X the following item only if it is true. [ ] I am a Debian Developer as described in the Debian Constitution as of the date on this survey. --Dylan Thurston
Re: Inconsistencies in our approach
In article [EMAIL PROTECTED], Nathanael Nerode wrote: OK. How about a GR saying We will not accept anything non-free in main, except for the preamble of the GPL. ... ... I bet a lot of people would be satisfied by the following more general statement as a GR. This seems to correspond to the viewpoint I've seen taken about license texts. License texts, copyright notices, warranty disclaimers, and other legal notices, are not a particularly desired part of any software distribution. ... Is the Preamble to the GPL a legal notice? Peace, Dylan
Re: Inconsistencies in our approach
In article [EMAIL PROTECTED], Jakob Bohm wrote: Here is my classification, which handles this better: A piece of information, whether in analog, digital or other form, is a program if it is intended to directly control the actions of a computer, other than by simply holding a pure description of its other contents. ... A piece of information, which is not a program and whose entire contents is primarily intended for human consumption is either computer documentation or non-computer literature, depending on its subject. I have no idea how to apply this definition: you use directly control and primarily intended in ways that are exceedingly unclear. The way you use these definitions later makes it seem to me that any interactive program must be considered primarily intended for human consumption... What about: Interactive fiction? Screensavers? Arcade games? Emacs? Have you looked at the Gallery of CSS Descramblers http://www-2.cs.cmu.edu/~dst/DeCSS/Gallery/ and thought about its consequences? Peace, Dylan
Re: GNU FDL and Debian
In article [EMAIL PROTECTED], Thomas Bushnell, BSG wrote: Dylan Thurston [EMAIL PROTECTED] writes: To be precise, the reference you cited (thanks!) makes it clear that RMS considers the free in free software to apply only to the technical functionality of the work, whether the work is a program or documentation: he writes The problem is that the requirement to add a political essay *is* a restriction on the technical part. The technical part has one little bit that reaches out and grasps onto the nontechnical essay. And that one little grommet to which the nontechnical essay is attached is an uneditable part of the technical part. Err, who are you arguing against? I do not espouse the position above. You do a good job arguing against it, but it is unlikely that RMS will read what you wrote... (I'm also not someone you need to convince.) Peace, Dylan
Re: GNU FDL and Debian
In article [EMAIL PROTECTED], MJ Ray wrote: ... Both FSF and Debian agree that FDL-covered works are not free software, ... To the best of my knowledge, this is not correct: RMS seems to argue that a manual published under the FDL is free in the free software sense, since you can make any functional changes you want. (I disagree with RMS, and I don't know it matters so much.) Peace, Dylan
Re: GNU FDL and Debian
In article [EMAIL PROTECTED], MJ Ray wrote: Dylan Thurston [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], MJ Ray wrote: ... Both FSF and Debian agree that FDL-covered works are not free software, ... To the best of my knowledge, this is not correct: RMS seems to argue that a manual published under the FDL is free in the free software sense, since you can make any functional changes you want. That is not the same thing at all. I am sure that my statement is accurate, but I cannot justify it from material I can find to quote. I think it's pretty clear from http://lists.debian.org/debian-legal/2003/debian-legal-200305/msg00640.html that RMS doesn't consider FDL-covered works to be free software or even that such a request is reasonable. Probably I shouldn't have put that statement quite that strongly, though. Sorry. There are two paths, near each other: 1. Ask for things to be under free licences and define free for each type of content individually; 2. Ask for everything to be free software. FSF seems to take path 1, Debian seems to take path 2. To be precise, the reference you cited (thanks!) makes it clear that RMS considers the free in free software to apply only to the technical functionality of the work, whether the work is a program or documentation: he writes I use that general criterion to evaluate the freedom to modify, for software and for manuals. However, software and manuals are used differently, so the licenses that meet the criterion for software are not necessarily the same as those that meet the criterion for manuals. For something that has no technical functionality, like a political essay, he wouldn't use the term at all. (Again, I disagree with his interpretation, and hope Debian rejects it.) Peace, Dylan Thurston
Re: migrating away from the FDL
In article [EMAIL PROTECTED], Mathieu Roy wrote: ... Based on this, I believe that RMS would say that a program with an unremovable, unmodifiable, 10,000 word Ode to my goldfish and no other restrictions would be free software, although inconvenient. I haven't seen anyone from Debian defend that position yet. If you want to know what rms consider as free software and what he do not consider as free software, please take a look at http://www.gnu.org, especially http://www.gnu.org/philosophy/license-list.html You do not have to guess, to believe, what position he may defends because it's already explicitely stated. I've read those, of course. More relevant to these hypothetical licences is http://www.gnu.org/philosophy/free-sw.html , which (if read carefully) also supports my position above. However, I am not RMS, and I can't apply the algorithms he would use to judge freeness, so there is a certain amount of guessing, since I know of no softwareq distributed under this hypothetical ode-ious license. Peace, Dylan
Re: migrating away from the FDL
In article [EMAIL PROTECTED], J.D. Hood wrote: I believe that RMS would say that a program with an unremovable, unmodifiable, 10,000 word Ode to my goldfish and no other restrictions would be free software, although inconvenient. I haven't seen anyone from Debian defend that position yet. I don't think that RMS would say that the documentation+ode document was free. I think he would say that the goldfish ode was ... erm ... a red herring. An Invariant Section must be a Secondary Section, ... You go on to show that the documentation+ode could not be distributed under the GFDL; I don't see how that has any bearing on whether or not it is free. RMS would be the first to agree that not all free software need be distributable under the GPL, GFDL, or any other particular license. Peace, Dylan
Re: migrating away from the FDL
In article [EMAIL PROTECTED], Wouter Verhelst wrote: In fact, I have been considering one point the GNU project has pointed out by creating the FDL: the fact that software on the one hand and 'normal' writings on the other hand are two completely different things. I believe that many Debian Developers agreed with the DFSG because they are the Debian Free Software Guidelines, not the Debian Freeness Guidelines, or sth similar. However, since I'm currently still forming my opinion on that subject, I'd rather not discuss it -- at least not yet. By 'normal' writings, do you include documentation? If so, please note that Richard Stallman does _not_ advocate different standards of freedom for documentation and for software, according to, for instance, http://lists.debian.org/debian-legal/2003/debian-legal-200305/msg00593.html Let me quote the relevant paragraph: Free documentation, like free software, refers to specific freedoms. It doesn't mean that you can do absolutely whatever you want to do. ... It means you can redistribute the work, change it (functionally), and redistribute modified versions. It is ok to have requirements on how you can do this, provided they don't prevent you from substantively making the functional changes you want to make. Note the provisos functionally and substantively. Based on this, I believe that RMS would say that a program with an unremovable, unmodifiable, 10,000 word Ode to my goldfish and no other restrictions would be free software, although inconvenient. I haven't seen anyone from Debian defend that position yet. Peace, Dylan (IANADD)
Re: Proposed: Debian's Five Freedoms for Free Works
In article [EMAIL PROTECTED], Adam Warner wrote: Branden, perhaps the term information disclosure would better suit you/us than privacy? That is we propose a DFSG-free licence cannot mandate information disclosure of anything but the information forming a distributed and derived work. But surely privacy is exactly when you have when information disclosure is not forced on you? Could you please elaborate on the difference? Peace, Dylan
Re: Proposed: Debian's Five Freedoms for Free Works
In article [EMAIL PROTECTED], Branden Robinson wrote: 5) The freedom to retain privacy in one's person, effects, and data, including, but not limited to, all Works in one's possession and one's own changes to Works written by others. ... The point is that my usage of your Free Software does not entitle you to access to or any rights in my improvements to your software unless I distribute the Software back to you specifically. So do you intend to exclude the MPL with this? Peace, Dylan
Re: Proposed: Debian's Five Freedoms for Free Works
In article [EMAIL PROTECTED], Thomas Hood wrote: 1) The freedom to use the Work for any purpose. 2) The freedom adapt the Work to one's needs. Access to the form of the ^to work which is preferred for making modifications (for software, the source code), if applicable, is a precondition for this. 3) The freedom to redistribute copies of the Work. 4) The freedom to change the Work for any purpose[1], to distribute one's changes, and to distribute the Work in modified form. Access to the form of the work which is preferred for making modifications, if applicable, is a precondition for this. What's the difference between change ... for any purpose (#4) and adapt ... to one's needs (#2)? If they mean the same thing then one of them is superfluous. It they mean different things then the difference should be made clearer. One clear difference is that the FSF finds the FDL license to be free on their terms, since it can be adapted to fit any substantive modifications to the program (adapt to one's needs), while Branden (and many others from Debian) would reject the FDL, since there is text which is unmodifiable and unremovable (it cannot be changed for any purpose). I think this follows from the wording difference; I don't think it needs any clarification. (And I like the change.) On the other hand, it will certainly get confusing to have two slightly different but nearly identical lists of freedoms around. But maybe that's OK. Peace, Dylan, NADD
Re: Proposed: Debian's Five Freedoms for Free Works
In article [EMAIL PROTECTED], Gregory K.Johnson wrote: ... But B needn't disclose this offer; B could intentionally make itself ineligible to transfer A's offer by conducting its own distribution commercially; ... I'm not sure what you're getting at, but under the terms of the GPL, B is not allowed to distribute object code at all without fulfilling one of the conditions of clause 3. The one (minor) bug (in which some recipient of object code might not have full access to the source) is if A gives B the object code, with a written offer; B waits for nearly 3 years, and then passes on the object code together with the offer. But I have no idea what this is relevant to. Peace, Dylan
Re: Is this license DFSG-free, part 2 - Word from upstream
In article [EMAIL PROTECTED], Nicolas Kratz wrote: OK, I'm dropping this. I don't see any way to get upstream to release the software under a free license, as the copyright holder is indeed not the author, but the university. You shouldn't necessarily give up, if the upstream author (the professor) is cooperating; she just needs to speak to her university. Depending on the university, this could be easy or hard. Peace, Dylan
Re: The debate on Invariant sections (long)
In article [EMAIL PROTECTED], John Holroyd wrote: On Sun, 2003-05-25 at 18:03, Richard Stallman wrote: There are free software licenses that have restrictions that I find annoying and inconvenient. One is the old BSD license. I worked for several years to convince Berkeley to remove the advertising clause, which I called obnoxious. If the Ku Klux Klan or George Dubya Bush had released a program with the old BSD advertising requirement, I might have thought twice about using it, because I would not want to advertise them. But it is still a free software license. But why, if you found the old BSD license to be so inconvenient, are you promoting a license which mandates even greater inconveniences upon the end user? Presumably he blieves that restrictions like those in the BSD license and the GFDL are matters of inconvenience, not of Freedom, and so there is no _moral_ reason not to impose these restrictions, merely practical considerations, which he obviously feels are outweighed by other reasons. Indeed, http://www.gnu.org/philosophy/bsd.html is rather different from almost all the other essays on the GNU website, since it makes only practical arguments, not moral ones. rms has also explained his reasons for imposing these restrictions: in [EMAIL PROTECTED], he wrote: It was clear from an early stage that companies might package parts of GNU with non-free software and would present the non-free software to the users as something legitimate and desirable. (This problem is getting bigger, not smaller: today, nearly all packagers of GNU/Linux distribute non-free software with it and try to argue it is a good thing.) So we had to search for ways to make sure that our message saying non-free software is wrong would at least be present in the GNU packages that they redistribute. ... I disagree with his position (I believe that Freedom is vitally important for many things, including software and political essays), but I see his point of view. Peace, Dylan Thurston
Re: The debate on Invariant sections (long)
Richard Stallman [EMAIL PROTECTED] wrote: But what if I encounter an Invariant Section saying that Social Security is wrong and that old or diseased people should be left alone and not helped by a public service? If I cannot remove this political statement, I cannot really regard the manual as free. And I would not want to distribute such statement, if I produce a modified version of the documentation. I disagree with those statements, and I would think twice about redistributing a manual in which the author says those things. At the same time, I don't think this would mean that said manual is non-free. They are different issues. Oh! I hadn't fully absorbed the following, but it seems then that rms believes that the restriction like that on the Emacs manual (that you must redistribute certain extraneous pieces) does not violate freedom 3 of the FSF's Free Software Definition: * The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this. (whether or not the work in question is documentation), while I believe the Debian people decided early in the discussion that a similar restriction on software would violate point 3 of the DFSG: 3. Derived Works The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. Actually, I'm a little unclear on the latter point. To what extent are non-functional restrictions OK for Debian? For instance, the GPL's clause 2c (message at an interactive prompt) is uncontroversial, but the much longer message that the reiserfs utilities printed seemed to be more questionable (if it were required by the license, and aside from the fact that it was incompatible with the GPL). Or is the question whether the restrictions in the GFDL are truly non-functional? (I note that FSF's freedom 3 is more focussed on improving the program, i.e., functionality, while DFSG 3 is stated more broadly.) Peace, Dylan Thurston
Re: The debate on Invariant sections (long)
On Fri, 23 May 2003 12:01:12 -0400, Jeremy Hankins wrote: Frankly, this whole episode saddens me tremendously. I have the utmost respect for you and the work you've done, but I simply can't agree with you on this issue. It has always been very comforting to know that you were out there, fighting for free software, and refusing to compromise. That's gone now, however this issue works out. While I agree with the stance that this documentation is not, in fact, Free, I'd like to point out that the GFDL does not reflect any change in RMS's stance: the Emacs manual has always been licensed with invariant sections, for instance. Richard Stallman's idea of Freedom might differ from yours, but it hasn't changed very much. Peace, Dylan pgpnvv4X3AyQN.pgp Description: PGP signature
Re: The debate on Invariant sections (long)
MJ Ray [EMAIL PROTECTED] wrote: No you don't care: you don't use Emacs. I use Emacs, but if part of Emacs has become not free software, Debian must not hesitate to act to fix it. It's a shame and massively annoying, but it's consistent with what Debian says in the social contract. Worst case, we still have XEmacs, right? No, actually. The XEmacs documentation is licensed under the old license with invariant sections. It would have to go to non-free along with the Emacs documentation. Peace, Dylan pgpiYiVAahNP8.pgp Description: PGP signature
Re: [OT] Droit d'auteur vs. free software?
On Mon, 12 May 2003 14:50:28 -0400, Glenn Maynard wrote: On Mon, May 12, 2003 at 07:45:51PM +0200, Arnoud Galactus Engelfriet wrote: The motivation for making them unrevokable is to prevent authors from being forced to accept unconditional surrender of their works. Then they could be made to look like total So the only way to prevent this is to remove my right to do it at all? That's ludicrous. Rights are not preserved by revoking other rights. Whatever you may think of the specific merits of the droit d'auteur system, please bear in mind that every legal system gives you rights you cannot barter away. For instance, no modern legal system lets you sell yourself into slavery, and I think that that is a good thing. So the question is which rights are fundamental and irrevocable and unable to be sold, not whether there are such rights. Peace, Dylan pgpDnbje69AMD.pgp Description: PGP signature
Re: Legal questions about some GNU Emacs files
On Sat, Apr 26, 2003 at 08:08:01PM +0200, J?r?me Marant wrote: Hi, According to Dylan Thurston (see #154043), some files shipped with GNU Emacs could be considered as non-free. One of them is /usr/share/emacs/21.3/etc/LINUX-GNU. The problem seem to come from the footer which mentions: Copyright 1996 Richard Stallman Verbatim copying and redistribution is permitted without royalty as long as this notice is preserved. Also in /usr/share/emacs/21.3/etc/WHY-FREE Copyright 1994 Richard Stallman Verbatim copying and redistribution is permitted without royalty as long as this notice is preserved; alteration is not permitted. What do you people think of this? Just one more comment: the versions of both of these two essays available on gnu.org (at http://www.gnu.org/gnu/linux-and-gnu.html and http://www.gnu.org/philosophy/why-free.html) have a slightly different license: Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. Notably, without royalty is missing. Peace, Dylan pgpoUr5bNviFp.pgp Description: PGP signature
Re: Knuth statement on renaming cm files and Licence violation.
Martin Schr??der wrote: On 2002-09-06 18:59:45 -0400, Dylan Thurston wrote: On Fri, Sep 06, 2002 at 03:35:17PM -0700, Thomas Bushnell, BSG wrote: The names could only be restricted if they are trademarked, which they are not. Computer Modern might be trademarked (I don't know), It is, as indicated in the text I quoted and you snipped. It's a trademark of Addison-Wesley. Uh? METAFONT is a TM of Addison-Wesley. What makes you think Computer Modern is a TM of Addison-Wesley? Quite right; my mistake. I think if Computer Modern were a trademark it would doubtless have been mentioned on the copyright page I quoted. --Dylan pgpLghKvDtuHE.pgp Description: PGP signature
Re: Knuth statement on renaming cm files and Licence violation.
On Wed, 4 Sep, Brian Sniffen wrote: Sadly, I don't own a copy of Computers Typesetting. Can you quote the full copyright page, and give a general indication of the contents of Volume E? Somewhat surprisingly, no-one has done this completely yet. Computers Typesetting, Volume E, Computer Modern Typefaces, is a nicely typeset version of the complete source code to the Computer Modern fonts, typeset in the literate programming style with diagrams of the characters and explanatory notes. I would consider it a canonical distribution of the Computer Modern typefaces. Here is the complete copyright page. The most relevant section (the fourth paragraph) was already posted by Martin Schr??der. --- The quotations on pages 7 and 351 have been excerpted from the Electra file in the Dwiggins Collection of the Boston Public Library. METAFONT is a trademark of Addison-Wesley Publishing Company. TeX is a trademarke of the American Mathematical Society. The programs for Computer Modern are in the public domain, and readers may freely generate and hand-tune their own fonts using the algorithms of this book. However, use of the names is restricted: Any fonts whose names cmr10 or cmbx12 or ... are identical to the standard font names of this book should be fully compatible with the fonts defined here; i.e., fonts with the same names are supposed to have precisely the same character coding schemes and precisely the same font metric files. Library of Congress Cataloging-in-Publication Data Knuth, Donald Ervin, 1938- Computer Modern typefaces. (Computers Typesetting ; E) Includes indexes. 1. Type and type-founding--Data processing. 2. Printing--Specimens. 3. METAFONT (Computer system). 4. Computerized typesetting. I. Title. II. Series: Knuth, Donald Ervin, 1938-. Computers typesetting ; E Z253.K568 1986 686.2'2544 86-1235 ISBN 0-201-13446-2 Incorporates the final corrections made in 1992. Copyright (c) 1986 by Addison-Wesley Publishing Company, Inc. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publishers. Printed in the United States of America. ISBN 0-201-13446-2 4 5 6 7 8 9 10 11 12 13-HA-9998979695949392 -- (The ... there is really in the original text.) (By the way, volumes B and D are about the TeX and METAFONT programs, respectively. They presumably have similar copyright pages, but I haven't checked.) The statement about the programs for Computer Modern is suprisingly vague for something that was presumably vetted by a lawyer. Let's see it again: The programs for Computer Modern are in the public domain, and readers may freely generate and hand-tune their own fonts using the algorithms of this book. This place Computer Modern in the public domain, and furthermore explicitly grants some of the rights Debian needs (although it leaves out the right to redistribute). However, use of the names is restricted: This is a slightly odd statement, since (AFAIK) names cannot be restricted in the ways that follow. The crucial issue seems to be whether this statement (and what follows) are terms of the grant of permission (above), or merely a request with no force in law. Any fonts whose names cmr10 or cmbx12 or ... are identical to the standard font names of this book should be fully compatible with the fonts defined here; i.e., fonts with the same names are supposed to have precisely the same character coding schemes and precisely the same font metric files. To back up the notion that this is merely a request, I note the words should and supposed. (I also note that there is no mention of specific _filenames_, merely the name of the _font_; and that there is some freedom to modify fonts under the same font name.) I think that, for the fonts to be distributable by Debian under this copyright notice, the statement about public domain has to be taken seriously, since otherwise there is no permission to distribute. Does Debian need legal advice on whether this statement actually places the files in the public domain? Or does it make more sense to approach Knuth directly? If we do approach Knuth, the letter should be carefully worded. Best, Dylan Thurston pgpdiA0RxI0W9.pgp Description: PGP signature
Re: Knuth statement on renaming cm files and Licence violation.
On Fri, Sep 06, 2002 at 03:35:17PM -0700, Thomas Bushnell, BSG wrote: However, use of the names is restricted: This is a slightly odd statement, since (AFAIK) names cannot be restricted in the ways that follow. The crucial issue seems to be whether this statement (and what follows) are terms of the grant of permission (above), or merely a request with no force in law. The names could only be restricted if they are trademarked, which they are not. Computer Modern might be trademarked (I don't know), It is, as indicated in the text I quoted and you snipped. It's a trademark of Addison-Wesley. but cmr10 certainly is not. Right. And, if it were trademarked, trademark restrictions never apply to functional elements. ... like the file name 'cmr10.tfm'. (Just making everything explicit.) --Dylan pgpqH7RLjqHMA.pgp Description: PGP signature
[hobby@plan9.bell-labs.com: Re: MetaPost manual]
This is the response I got from John Hobby wrt the two MetaPost manuals. (He also sent the sources, for an older version of LaTeX; I'll get them working with a modern LaTeX and forward both the new and old version.) Are his conditions fine, or do I need to ask for more clarification? (It seems that he gives conditions as preferences, rather than legal requirements.) [Background: we currently ship these manuals in tetex-doc, without source.] Best, Dylan Thurston - Forwarded message from [EMAIL PROTECTED] - Delivery-date: Sun, 14 Apr 2002 18:04:05 -0400 Subject: Re: MetaPost manual From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] X-Spam-Status: No, hits=6.6 required=10.0 tests=NO_REAL_NAME,THE_FOLLOWING_FORM,GAPPY_TEXT,NO_MX_FOR_FROM version=2.11 Enclosed are the sources for the Metapost manual--the sources for the other document will be sent separately. Do you want to be more precise about the terms in which you release them? I only want it to remain clear that I am the author of A User's Manual for MetaPost and Drawing Graphs with MetaPost and I am allowing them to be freely distributed electronically. I am not going to prohibit minor changes and corrections, but I don't want a bunch of competing versions to appear. I have authorized certain translations and I gave Alan Hoenig permission to use a few pages worth of material in his book, but I would still like to be consulted in such cases. By the way, although I seldom do so myself, it is fine with me if people want to typeset the (unofficial) MetaPost logo using all caps and Knuth's METAFONT logo font. pgp6Ibz4VudlM.pgp Description: PGP signature
Re: MMIX License
On 31 Mar 2002, Joe Drew [EMAIL PROTECTED] wrote: On Sun, 2002-03-31 at 11:25, Pablo S. Torralba wrote: I have been reading the license, that I send attached, and I cannot figure exactly why this decision was made. This license doesn't explicitly allow distribution of binaries produced from modified source files; it seems to me that therefore it fails section 4 of the DFSG. The last time this came up (in the thread from November 1999 starting at http://lists.debian.org/debian-legal/1999/debian-legal-199911/msg00121.html ) it was generally agreed that this was probably an oversight and that we should contact Donald Knuth, but we didn't want to wait 3 months for a response. Since it's been over 2 1/2 years, I think we can probably wait an additional few months... I'm happy to write a letter on this subject, but are there other issues we want to address other than binary modification? I note that the Makefile doesn't seem to have a license; do I need to ask about that? From the current package, that seems to be the one file that we actually modify. Best, Dylan Thurston pgpPAOPJopKHC.pgp Description: PGP signature
Re: Preprints/Reprints of Academic Papers in Packages
On Sat, 16 Mar 2002, C.M. Connelly [EMAIL PROTECTED] wrote: Many packages contain preprints or reprints of academic papers as part of their documentation. In many cases, there is no ``source'' available for these documents -- they are distributed as PostScript or PDF files. ... My feeling is that as ``historical documents'' -- frozen documents describing some early state or underlayment of the software, and not day-to-day documentation -- we shouldn't worry that much about not having the source for these documents. Others may disagree, believing that we need to have source for everything that we distribute. I originally raised this issue wrt the file /usr/share/doc/texmf/metapost/base/mpman.ps.gz in the tetex-doc package. This is a preprint distributed by Bell Labs, and so is an academic preprint, but the abstract explains This document serves as an introductory user's manual. AFAICT, this is the principal reference manual for MetaPost. If one wanted to modify the MetaPost language in some way, you would probably also want to modify this manual. I think it is definitely in Debian's interest to have the source for this academic paper. I'm about to go ask John Hobby if he's willing to release the source, but in general I think Debian should insist on source, even for academic papers. Note that one of the largest archives of academic papers on the web, http://arxiv.org, insists on TeX source. From http://arxiv.org/help/faq/whytex.html: Why submit the TeX source? 1. TeX has many advantages that make it ideal as a format for the archives: It is plain ASCII, it is compact, it is freely available for all platforms, it produces extremely high-quality output, and it retains contextual information. (It is thus more likely to be a good source from which to generate newer formats, e.g. MathML [namely HTML, or more specifically XML, which handles mathematics correctly -- note that the MathML people plan a LaTeX to MathML translator, but dvi/ps/pdf lack the necessary document structuring concepts]. Possession of the source thus provides many additional options for future document migrations (none of us really expect dvi, ps, pdf, etc., to be the final word). These are good reasons for wanting source in general, independent of any need for modification. Best, Dylan Thurston pgpoGnynpMxKp.pgp Description: PGP signature
[dpt@math.harvard.edu: kernel-source-2.4.17: Source code for 'drivers/net/acenic_firmware.h' not included]
I filed this bug on kernel-source-2.4.17, and the maintainer told me
(reasonably) to discuss this on debian-legal. This is another instance
of a binary driver included in the kernel without source. The source
for this driver was apparently available at one time; however, (as
documented below) the source no longer seems to be available. I don't
know what conditions the source code was originally released under.
What do people think?
Does anyone know anyone who uses this driver/knows where to get the
source?
Best,
Dylan Thurston
- Forwarded message from Dylan Thurston [EMAIL PROTECTED] -
From: Dylan Thurston [EMAIL PROTECTED]
To: Debian Bug Tracking System [EMAIL PROTECTED]
Subject: kernel-source-2.4.17: Source code for 'drivers/net/acenic_firmware.h'
not included
X-Reportbug-Version: 1.41.14213
Package: kernel-source-2.4.17
Version: 2.4.17-1
Severity: serious
Justification: Policy 2.1.1 (the DFSG)
drivers/net/acenic_firmware.h contains the following:
#ifdef CONFIG_ACENIC_OMIT_TIGON_I
#define tigonFwText 0
#define tigonFwData 0
#define tigonFwRodata 0
#else
/* Generated by genfw.c */
static u32 tigonFwText[(MAX_TEXT_LEN/4) + 1] __initdata = {
0x1003,
0x0, 0xd, 0xd, 0x3c1d0001,
..lots of hex digits omitted..
There is no 'genfw.c' distributed with the kernel source. I found a
version of 'genfw' in Perl at
http://map.web.cern.ch/Atlas/project/cern/ep-atr/alteon/firmware-tools/,
but AFAICT this is just a tool for extracting the firmware from an ELF
file, and I didn't see the actual source there.
There is also information at
http://www.cs.unm.edu/~maccabe/SSL/frag/tools/make.html, but it refers
to a CVS archive which does not seem to be publically accessible.
This seems like just an oversight, but it is a violation of the GPL at
the moment.
Best,
Dylan Thurston
[EMAIL PROTECTED]
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux lotus 2.4.17 #1 Tue Jan 15 22:42:20 UTC 2002 i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages kernel-source-2.4.17 depends on:
ii binutils2.11.92.0.12.3-5 The GNU assembler, linker and bina
ii bzip2 1.0.1-14 A high-quality block-sorting file
ii fileutils 4.1-9GNU file management utilities.
- End forwarded message -
pgpSPnbTjSYo2.pgp
Description: PGP signature
Re: license requirements for a book to be in free section
On Thu, 31 Jan 2002 11:15:45 +0100, Sven wrote: On Tue, Jan 29, 2002 at 07:17:03PM -0800, Thomas Bushnell, BSG wrote: Sven [EMAIL PROTECTED] writes: The question is that we will block this package from enterring debian because of a clause which may, maybe, also have blocked other packages which we would not like being removed. But again, it can be dealt with at another time. If you know of any, we should discuss them. Are you saying the rule is being applied unfairly? If so, we need to have the details so they can be discussed. Sorry, i have not time to investigate, but i am sure many of the documentation we have cause problems, and we didn't look into it too much, because, well, it is documentation and not software. Also i guess this was the reason about some mails a while ago which looked into documentation issues and licences. Also i think many of our documentation may fail DFSG 2, about source code issuses. For instance, many (most) of the documents included the tetex-base package fail DFSG 2, and many don't have explicit licenses. Bug #131191. I'm sure there are many more such problems throughout Debian. Best, Dylan Thurston pgpixEJidaLyl.pgp Description: PGP signature
arial.ttf still shipped!
reopen 85072
severity 85072 serious
thanks
Subject: freeamp: arial.ttf still shipped!
Followup-For: Bug #85072
Package: freeamp
Version: 1:2.1.1-2
Severity: Serious
Justification: Policy 2.1.1
According to the logs, this should have been fixed several months ago.
However, I recently checked, and the files
/usr/share/freeamp/themes/{EMusic,FreeAmpClassic}.fat both contain
a file arial.ttf with a decidedly non-free copyright statement
and no permission to distribute. The following text is in the file:
Typeface A9 The Monotype Corporation plc.
Data A9 The Monotype Corporation plc/Type Solutions Inc. 1990-1992. All
Rights ReservedArialA8 Trademark of The Monotype Corporation plc registered
in the US Pat TM Off. and elsewhere.Monotype:Arial Regular:Version 2.50
(Microsoft)Arial
In addition, I am suspicious of helr.ttf, inside of
/usr/share/freeamp/themes/{FreeAmp,Relatable}.fat. I couldn't
find a copyright statement for this file; what is its provenance?
Please do not distribute the package in its current state with Woody.
Best,
Dylan Thurston
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux petunia 2.4.16 #2 Fri Dec 21 16:12:08 EST 2001 i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages freeamp depends on:
ii libc6 2.2.4-7 GNU C Library: Shared libraries an
ii libgdk-pixbuf2 0.13.0-1 The GdkPixBuf library.
ii libglib1.2 1.2.10-3 The GLib library of C routines
ii libgtk1.2 1.2.10-9 The GIMP Toolkit set of widgets fo
ii libmusicbrainz11.0.1.final-1 Second generation incarnation of t
ii libstdc++2.10-glibc2.2 1:2.95.4-0.011006 The GNU stdc++ library
ii libttf21.4pre.20011029-1 FreeType 1, The FREE TrueType Font
ii libvorbis0 1.0rc2-1 The OGG Vorbis lossy audio compres
ii xlibs 4.1.0-11 X Window System client libraries
ii zlib1g 1:1.1.3-18compression library - runtime
Free way to decompress LZW archives?
I recently came across some data published as a .LZW archive which I want to process. It seems that the standard program for dealing with the archives, lha, is non-free. I found a web page documenting the format; is there any obstruction to producing a free compressor/decompressor? Has anyone tried to convince the authors to free their program? And what is the actual copyright on the lha program? The 'copyright' file in the package just lists the authors, and the README file is in Japanese. There's an old, English readme file giving permission to distribute; is that still current? Thanks, Dylan Thurston
Re: Free way to decompress LZW archives?
On Tue, Jul 24, 2001 at 11:17:27PM -0600, John Galt wrote: On Wed, 25 Jul 2001, Dylan Thurston wrote: I recently came across some data published as a .LZW archive which I want to process. It seems that the standard program for dealing with the archives, lha, is non-free. I found a web page documenting the format; is there any obstruction to producing a free compressor/decompressor? Has anyone tried to convince the authors to free their program? http//www.cpe.surrey.ac.uk/support/faq/gif_lzw.htm Probably impossible. lha is under the Sperry patent. The Sperry patent should sunset RSN: it was granted in 1985, 16 years ago. http//www.uspto.gov/web/offices/pac/doc/general/whatis.htm shows how long a patent is for--20 years. Until 2005, don't bother trying: you'll only be looking at a jail term. Just to be clear: the term is now 20 years from time of first application, right? When was the patent applied for? Anyway, thanks for the pointers! I'll try to convince the source to change their file formats. Thanks, Dylan Thurston
