Re: Bug#227159: ocaml: Worse, the QPL is not DFSG-free
On Jul 9, 2004, at 11:14 AM, Sven Luther wrote: On Fri, Jul 09, 2004 at 05:54:05AM -0400, Brian T. Sniffen wrote: Package: ocaml Version: 3.07.2a-2 Followup-For: Bug #227159 The compilers are also distributed under the QPL, which is And ? What is the problem ? Even RMS and the FSF is not claiming that the QPL is non-free, just that it is incompatible with the GPL, but since it is not linked with GPLed code, this is no problem. The problem comes from these three clauses: 3b. When modifications to the Software are released under this license, a non-exclusive royalty-free right is granted to the initial developer of the Software to distribute your modification in future versions of the Software provided such versions remain available under these terms in addition to any other license(s) of the initial developer. 6b. You must explicitly license all recipients of your items to use and re-distribute original and modified versions of the items in both machine-executable and source code forms. The recipients must be able to do so without any charges whatsoever, and they must be able to re-distribute to anyone they choose. 6c. If the items are not available to the general public, and the initial developer of the Software requests a copy of the items, then you must supply one. That is, I owe two fees to the initial developer of the software. First, I give him a license to distribute my modifications in future versions of the software, and to use that code in non-free derivatives of the software. Second, if he asks for it I also supply a copy even if I have not distributed them to anyone. This is a fee as described by DFSG #1. Additionally, 6b requires that I license my modifications to others under a *more* permissive license than the QPL. Those to whom I give my items (presumably meaning my modifications) must be licensed to distribute modified copies without charge, and the QPL imposes a charge. Since I can't distribute my modifications under the same terms as the license of the original software, this also fails DFSG #3. On the other hand, perhaps my understanding of the DFSG is flawed. I've CC'd this to debian-legal, in the hopes that they can clarify. Also notice that RMS himself participated in the discussion about the ocaml licence and approved it. The ocaml license does meet the FSF's four freedoms, but I do not think it meets the DFSG. The emacs files is another issue, and upstream was receptive to it, i just have to follow up on this to make them act or something. On the other hand, the new INRIA license looks awfully promising -- mostly because of its GPL upgrade clause. Perhaps you can just get -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?
Henning Makholm [EMAIL PROTECTED] writes: Scripsit Anthony DeRobertis [EMAIL PROTECTED] On Jan 21, 2004, at 21:27, Henning Makholm wrote: It is not clear to me that this text talks about APIs at all. It seems to be about the *internal* structure of a database, which - in my opinion at least - has very little to do with an *interface*. It talks about SQL Data Structures. It finds that those are copyrightable. I'm not sure why that wouldn't apply to, say, C data structures, as used in an API. SQL data structures (it is not clear what exactly is the technical item this ruling speaks about, but nevermind) is a way of getting a job done. C data structures used in an API is a way of communicating to existing code which job you want done. And the quesion, by the way, concerned Lisp APIs. I don't think you can copyright the cons cell. It concerned E-Lisp APIs. If you call cons or even unwind-protect, that's clearly not copyrightable. But if you call gnus-agent-cat-downloadable-faces, that's an internal function call -- anything that was a Method of Operation would be (interactive). -Brian
Re: Non-free package licenses and replacements
Mathieu Roy [EMAIL PROTECTED] writes: For the RFCs, if Debian cannot live with different degree of freedom depending on the nature of the software it brings (RFC are not programs, and by nature, there is no point in being able to modify freely a standard like RFCs) Nonsense. You know well that there is no consensus on that -- and there are several reasons to derive a new work from an RFC: new RFCs, new standards for private use, guidelines on standards-based programming for the Internet... -Brian
Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?
Sven Luther wrote: On Mon, Jan 12, 2004 at 01:00:54PM -0500, Jeremy Hankins wrote: Sven Luther [EMAIL PROTECTED] writes: uncertain about whether you should disable the automatic generation of .elc files. Why ? We clearly are not violating the GPL by doing so, so where is the problem. If the situation is perfectly clear and uncontroversial to you, either you don't know what you're talking about, or everyone else is confused but you. I put my money on the former. Saying you disagree is one thing, saying any other perspective is clearly wrong is silly. Come on, we don't distribute binaries of it, so how could this break the GPL ? Simple: Debian distributes Emacs and this elisp file. Futher, it distributes a mechanism for combining them and causing them to interoperate. Thus, any Debian Distribution installation of both is a derived work of both Emacs and this elisp file. The components must be available under the terms of the GPL, so that individual component -- the elisp file -- must be available under the terms of the GPL. The DFSG issue might be a different story, but even there, i am not sure it is correct though, since the GPL cause problem at link time, not at binary distribution time. And nothing is stopping us to distribute binaries of the .el compiled by a non-GPL lisp compiler or something. Good luck finding a non-GPL'd compiler for a dynamically scoped Lisp with bindings similar to Elisp. There .elc are, if we distribute them, not linked with any GPLed code, and we never ditribute anything that might link this code with GPLed code, since this linking is always performed at link time. Of course, i may be wrong, or misunderstand the way emacs and its lisp compilers work, but if so, please provide explanation to me. Upstream is not some random emacs .el author, but the ocaml author, who did his phd thesis on writing the ocaml virtual machine, so he will not be impressed by poor assertions about these issues. So i would rather have strong arguments than careless asserted assumptions. There are no lawyers providing legal advice here. You could ask [EMAIL PROTECTED], which often is answered by a lawyer. Alternately, you could structure the request in terms of politeness, as it's been suggested here -- that the author of Emacs thinks all Elisp code should be GPL-compatible, that it's not entirely clear he could legally enforce this, but that it seems the polite thing to do. Notice that when faced with similar issues about the ocaml-nums library, whose legal property did get lost in the Dec-Compaq-Hp migration, he promprly reimplemented the stuff in a free way. So I think talking to the upstream is a good idea. Sure, but on more serious ground than this. Notice that the bugreport claims that RMS thinks that ..., not that it is actually true. Ok. So, for the sake of argument, assume he's dead wrong, but thinks so nonetheless. We should still, imho, behave as if he's correct, given that he/FSF owns copyright on emacs. This is what we normally do: give the copyright holder generous (and sometimes unreasonable) benefit of the doubt in terms of what rights they have and can enforce. Deciding what to do here doesn't involve taking a position on whether RMS is right or wrong (thank god!). Well, sure, but this would not help me convince upstream. Do you really think the upstream authors are so rude? (Of course, this is not to be confused with the policy of ignoring patent issues until we have reason to believe they're being enforced. That's a completely different issue.) Oh, so we will chip a DRI version which include the nice enable S3TC compression if the card support it ? After all, the graphic hardware manufacturer already paid for a licence, and i doubt you can patent a pair of bits to set in a graphic card register or so, still the DRI project is being cautious, while waiting for over 6 month now that S3/via respond to their inquiries. You are not making a clear comparison here. He also thinks that GNU documentation is free, which we don't, so i clearly would like to have a more solid case before i go to upstream about this. If you want an argument to present to upstream you might try contacting the FSF for a position on the subject. Mmm. I might, but as it is debian packaging issues, i thought it was the natural place for this kind of discussion. It appears at least as much to be a general issue of GPL-compliance. -Brian Now, if nobody here knows about this, then please tell me so, and i will ask the FSF. Friendly, Sven Luther -- Brian Sniffen [EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?
Sven Luther wrote: On Mon, Jan 12, 2004 at 02:12:13PM -0500, Brian T. Sniffen wrote: Sven Luther wrote: On Mon, Jan 12, 2004 at 01:00:54PM -0500, Jeremy Hankins wrote: Sven Luther [EMAIL PROTECTED] writes: uncertain about whether you should disable the automatic generation of .elc files. Why ? We clearly are not violating the GPL by doing so, so where is the problem. If the situation is perfectly clear and uncontroversial to you, either you don't know what you're talking about, or everyone else is confused but you. I put my money on the former. Saying you disagree is one thing, saying any other perspective is clearly wrong is silly. Come on, we don't distribute binaries of it, so how could this break the GPL ? Simple: Debian distributes Emacs and this elisp file. Futher, it distributes a mechanism for combining them and causing them to interoperate. Thus, any Debian Distribution installation of both is a derived work of both Emacs and this elisp file. The components must be available under the terms of the GPL, so that individual component -- the elisp file -- must be available under the terms of the GPL. Yep, but whatever you say, the GPL is a licence which applies on distribution only, not use. Indeed. And you are pointing out that we distribute Emacs and this elisp file together, more closely intermingled than mere aggregation would imply. The DFSG issue might be a different story, but even there, i am not sure it is correct though, since the GPL cause problem at link time, not at binary distribution time. And nothing is stopping us to distribute binaries of the .el compiled by a non-GPL lisp compiler or something. Good luck finding a non-GPL'd compiler for a dynamically scoped Lisp with bindings similar to Elisp. Well, it should be easy to write one, at least one which would parse and use the incriminating files. That creation after the fact does not change whether the elisp file was created as a derivative work of Emacs. There .elc are, if we distribute them, not linked with any GPLed code, and we never ditribute anything that might link this code with GPLed code, since this linking is always performed at link time. Of course, i may be wrong, or misunderstand the way emacs and its lisp compilers work, but if so, please provide explanation to me. Upstream is not some random emacs .el author, but the ocaml author, who did his phd thesis on writing the ocaml virtual machine, so he will not be impressed by poor assertions about these issues. So i would rather have strong arguments than careless asserted assumptions. There are no lawyers providing legal advice here. You could ask [EMAIL PROTECTED], which often is answered by a lawyer. Alternately, you could structure the request in terms of politeness, as it's been suggested here -- that the author of Emacs thinks all Elisp code should be GPL-compatible, that it's not entirely clear he could legally enforce this, but that it seems the polite thing to do. Ok, but then, there is also the matter of respect of the author of said .el files, no ? Well, sure. We should confine our actions to the intersection of the wishes of the two authors. Notice that when faced with similar issues about the ocaml-nums library, whose legal property did get lost in the Dec-Compaq-Hp migration, he promprly reimplemented the stuff in a free way. So I think talking to the upstream is a good idea. Sure, but on more serious ground than this. Notice that the bugreport claims that RMS thinks that ..., not that it is actually true. Ok. So, for the sake of argument, assume he's dead wrong, but thinks so nonetheless. We should still, imho, behave as if he's correct, given that he/FSF owns copyright on emacs. This is what we normally do: give the copyright holder generous (and sometimes unreasonable) benefit of the doubt in terms of what rights they have and can enforce. Deciding what to do here doesn't involve taking a position on whether RMS is right or wrong (thank god!). Well, sure, but this would not help me convince upstream. Do you really think the upstream authors are so rude? What has that to do with anything ? Look how silly this argument sounds ? Imagine me telling the upstream author that he should please change the licence of his files, because RMS may feel offended ? Be serious please. This is debian-legal, not debian-please-stay-polite. I think it's taken for granted that Debian will try to be polite. Requests for change are much nicer than threats of legal action. We don't need a clear threat of a lawsuit to act -- a polite request is enough. Such is true of most polite people, isn't it? I don't think it's silly to imagine that the upstream author of this elisp file would change the license under which he distributes it when the author of the elisp parser for which he wrote the file requests such. He also thinks that GNU documentation is free, which we don't
Re: DFSG Freeness of Patent Reciprocity Clauses
Nathanael Nerode wrote: Brian Sniffen wrote: Would the following be considered Free by anybody here? If You institute litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory copyright infringement, then any licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. Yep, I think it's Free, and here's why. If you allege that the Work contains copyright violations, you are implicitly alleging that the license for the Work does not grant a valid license. Not at all -- it grants a perfectly valid license to some of the work, but part of the work is mine. As a result, I'm the *only* person who can legally copy the work. For example, consider that I'm RBN, a large Utah-based software company (formerly Volcano, formerly RBN). If I point out that the Linux kernel contains some of my copyrighted code, then all the licenses on others' code (BSD, GPL, etc) certainly permit me to copy that code (providing I comply with their other restrictions, of course -- so I can copy the code in a Free way). Others cannot do so without a license grant from me, so I sue to stop them. Accordingly, you shouldn't be using the Work under that license *anyway* (you believe that the license is invalid!). Explicitly revoking the licenses revokes only those rights you have claimed that you don't have. No, it punishes me for attempting to enforce my legal rights. I never forfeited my claim to those rights, certainly not by suing to enforce them! Explicitly revoking the licenses imposes a non-Free restriction on what I can do. -Brian -- Brian Sniffen [EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: DFSG Freeness of Patent Reciprocity Clauses
Don Armstrong wrote: If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.[2] My personal feeling is that these clauses amount to a useage restriction, and thus may fail DFSG #5 and #6. I currently see an acceptable argument being made for the Apache form of the reciprocity clause (claims restricted to the work itself) to be free[3], but I don't beleve the OSL form of this clause is, as it is overbroad. What are others opinions on this? First, that any license which says that, as a condition of use, you may not take particular other acts is non-Free. For example, a license which prohibits reverse-engineering is non-Free, as is a license which prohibits use by practicing Scientologists. Similarly, a license which prohibited any involvement in a patent lawsuit would be non-Free --- no patent lawyer could use the software. A license which prohibited registering software patents would be non-Free. A license which prohibited any copyright infringement suit against any author of the work would be non-Free. Second, the above argument extends to licenses which do not impose a condition of use, but instead are revoked when particular actions are taken. I'd be interested to see where on the slope above others begin to disagree. If these patent-termination clauses are Free, are copyright-termination? An interesting correllary, which thankfully hasn't appeared, is the presence of copyright reciprocity clauses. I would imagine a reasonable debian policy on reciprocity clauses like the above would apply equally well to copyright reciprocity as it would to patent reciprocity. On that point I strongly agree: all restrictions on freedom should be treated the same. Software Patents are terrible policy and should be fought... elsewhere. Here, the only concerns should be Free Software and its users. Would the following be considered Free by anybody here? If You institute litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory copyright infringement, then any licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. I hope not. -Brian -- Brian Sniffen [EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: SRFI copyright license
Don Armstrong wrote: On Mon, 29 Dec 2003, Jakob Bohm wrote: The main trick is to distinguish between the original full text SRFI (the document) and the free software (document that excerpts or derives from the document). Sure, but if you take that tack, the prohibition of modification of the document becomes, in effect, a no-op. You can take excerpts of the document, modify them, slap some more changes on them, and then call it SRFI foo. According to this theory, it's no longer the document. I think this line of reasoning mistakenly blurs the line between technical and social restraint. The license bans modification of the document, and is written in a generic way so as to be applicable to any single SRFI. So when applied to an SRFI, what is the document? The given SRFI. The license clearly allows you to derive works, as long as you do not change the SRFI itself. That leaves an unfortunately fuzzy, but still clearly small area which you shouldn't touch -- and which nobody has a reason to touch anyway: conflicts with the original document. There's no good reason to release a new SRFI 86 instead of an SRFI 286 which references and quotes SRFI 86. So what's ruled out by this license? Well, calling a derivative work of SRFI 86 SRFI 86, or otherwise making something that appears to be a modified SRFI 86 would probably count. I can't see anything else as forbidden. Is your real problem, Don, the vagueness of the identity problem for documents? When is one document the same as another? When is one a modification of another, and not a separate document? Not that all of this matters, given the strange grant of permission for derivation. I didn't notice that weirdness in my first replies, sorry. -Brian
Re: popular swirl...
Ben Reser wrote: On Tue, Dec 30, 2003 at 10:28:10PM +0100, Jörgen Hägg wrote: Somehow the swirl on this page seems familiar... :-) http://www.elektrostore.com/ (The picture is here: http://www.elektrostore.com/Bilder/electro_loga.gif ) Hell that's not just familiar that's a blatent rip. Lest anyone doubt that they copied it here's a 2 minute mod to the Debian logo in gimp that produces rougly the same image: http://ben.reser.org/irc/openlogo-nd-50-rot-blue.png I rotated the logo and rotated the color map. Looks like they rotated it a little more than I did or cut off part of the tail, but it is pretty darn obvious that it's from the same source. This has come up before. SPI was asked to look into the trademark violation involved. IIRC, the proprietor of elektrostore was contacted and dismissed the complaint -- saying there wasn't any proof Debian had come up with the swirl either, and it could come from a font or something -- that maybe Debian and the web designer he paid got it from the same source. -Brian -- Brian Sniffen [EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: SRFI copyright license
Don Armstrong [EMAIL PROTECTED] writes: On Wed, 24 Dec 2003, Lionel Elie Mamane wrote: Every SRFI contains a reference implementation, and bears this copyright notice: Copyright (C) /author/ (/year/). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Scheme Request For Implementation process or editors, except as needed for the purpose of developing SRFIs in which case the procedures for copyrights defined in the SRFI process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the authors or their successors or assigns. This document and the information contained herein is provided on an AS IS basis and THE AUTHOR AND THE SRFI EDITORS DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Is a scheme implementation that includes the reference implementation DFSG-free (providing the rest of the implementation is, obviously)? No, unfortunatly, because irregardless of the FAQ, the license is contradictory, and seemlingly violates DFSG #3. [Unless there is a provision which I am missing to license the actual implementation of a reference implementation separately... Could you provide reference to the procedures for copyrights defined in the SRFI process?] I strongly disagree: the license is just saying that you can't publish a derivative work of SRFI X as SRFI X, and are otherwise free to derive works. Looks like an ideal license for standards documents, really, which does everything this community has been asking for. Moreover, there's nothing in this document that gives you the right to modify outside of creating derivative works that comment on or otherwise explain it or assist in its implementation. [You could argue, I suppose, that any dirivative work explains the work its derived from, but if that's the tack to take, why not just say it?] I would think assist in its implementation would cover most software, but... yeah, it would be nicer if it were made more broad. In the case of scsh, which includes some of these reference implementations, upstream's opinion is that what the license means is the copyright needs to remain intact, not the code cannot change. I'm personally not convinced of that, but it's possible I can be swayed. Don Armstrong
Re: Plugins, libraries, licenses and Debian
Anthony DeRobertis [EMAIL PROTECTED] writes: On Dec 14, 2003, at 22:18, Brian T. Sniffen wrote: For someone to later pair it with Emacs has no creativity, so that packager hasn't earned a copyright, but the pairing is under copyright Yes, but if there is no copyright generated by the pairing, then it must be a 'mere aggregation.' I didn't say there's no copyright generated by the pairing -- just that the pairing can't be separated from the writing of the plugin. The plugin author, in the course of writing and testing his plugin, must have assembled the combination of host+plugin in a persistent form. -Brian
Re: Plugins, libraries, licenses and Debian
Anthony DeRobertis [EMAIL PROTECTED] writes: On Thu, 2003-12-11 at 15:16, Brian T. Sniffen wrote: That would seem to fit much better than derivative work, yes. However I do wonder whether the combination of host and plugin constitutes an original work of authorship? There seems to be little creativity involved. Sure there is -- but it's performed by the person who wrote the plugin, as he sculpts the interface to fit to the host, and to provide useful functionality to it -- not merely by itself. Copyright law (at least in the US) recongnizes that a creative effort can go into selecting, arranging, etc. the pieces of a compilation. If there is sufficient creativity in doing that, the compilation gets a copyright which is seperate from the copyrights of each of the works inside the compilation. Right, but since the plugin author clearly intended it to fit with and accompany the host, there's no creativity on the part of the combiner. And we're well back into argue it in court territory. -Brian
Re: Changes in formal naming for NetBSD porting effort(s)
Branden Robinson [EMAIL PROTECTED] writes: I have little patience for superstitious beliefs, and less still for people who claim to be defending the tender feelings of the ignorant. But why use names correlated with evil when other options are available which interfere less with Debian's goals? I doubt knowledgeable and thoughtful adherents to the Christian religion -- the kind who can actually attend a seminary and not flunk out -- find the names I proposed particularly offensive. If any such people are reading these lists, we can always ask them. I recognize Forneus and Orobos -- Naberius I'd have to look up. In any event, for any name that doesn't raise trademark issues (and thus potentially jeopardize the entire project), I'd say the choice remains up to those who are actually doing the work -- and that would be the Debian *BSD porters. Street names from Berkeley have appeal, and few fundies assign Manichean properties to asphalt. -Brian
Re: Plugins, libraries, licenses and Debian
Anthony DeRobertis [EMAIL PROTECTED] writes: On Sun, 2003-12-14 at 15:34, Brian T. Sniffen wrote: Right, but since the plugin author clearly intended it to fit with and accompany the host, there's no creativity on the part of the combiner. And we're well back into argue it in court territory. If it isn't creative, it can't be a derivative work either. Both require creativity. But it *is* creativity on the part of the author of the plugin, since in addition to saying I'll write a gaussian blur tool, he said I'll write one that works in Emacs! For someone to later pair it with Emacs has no creativity, so that packager hasn't earned a copyright, but the pairing is under copyright -- that of the original author on the host, that of the plugin author on the plugin, and that of the plugin author on the combination. -Brian
Re: Plugins, libraries, licenses and Debian
Arnoud Engelfriet [EMAIL PROTECTED] writes: Anthony DeRobertis wrote: On Dec 9, 2003, at 13:38, Arnoud Engelfriet wrote: However, what I'm saying is that if you bundle the existing host and the existing plugin into a composite work, you may have created a derivative work. Just like if I put an existing photograph next to an existing text to produce an illustrated article. I think that process is much better described by: A ''compilation'' is a work formed by the collection and assembling of preexisting materials or of data that are selected, coordinated, or arranged in such a way that the resulting work as a whole constitutes an original work of authorship. The term ''compilation'' includes collective works. That would seem to fit much better than derivative work, yes. However I do wonder whether the combination of host and plugin constitutes an original work of authorship? There seems to be little creativity involved. Sure there is -- but it's performed by the person who wrote the plugin, as he sculpts the interface to fit to the host, and to provide useful functionality to it -- not merely by itself. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Plugins, libraries, licenses and Debian
Arnoud Engelfriet [EMAIL PROTECTED] writes: Brian T. Sniffen wrote: Arnoud Engelfriet [EMAIL PROTECTED] writes: Anthony DeRobertis wrote: A ''compilation'' is a work formed by the collection and assembling of preexisting materials or of data that are selected, coordinated, or arranged in such a way that the resulting work as a whole constitutes an original work of authorship. The term ''compilation'' includes collective works. That would seem to fit much better than derivative work, yes. However I do wonder whether the combination of host and plugin constitutes an original work of authorship? There seems to be little creativity involved. Sure there is -- but it's performed by the person who wrote the plugin, as he sculpts the interface to fit to the host, and to provide useful functionality to it -- not merely by itself. Yes, the plugin most definitely is an original, creative work. It does not seem to qualify under the definition of compilation quoted by Anthony above, though. If I take an existing host program and an existing plugin, configure the host to automatically load the plugin, and then bundle both into a single package, have I created such a compilation? It doesn't matter, since you are almost certainly not the copyright holder: the plugin author would have created that package much earlier. You're not doing anything creative, it's true -- just following his implied instructions. The package is the result of collection and assembling of two preexisting materials. However, what is the reason for qualifying the resulting work as an original work of authorship? The definition seems to suggest that the _compilation_ must be original, not its parts. I think I'm agreeing with you, but I'm not convinced I entirely undersstand where you're going with this. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Plugins, libraries, licenses and Debian
[EMAIL PROTECTED] (Måns Rullgård) writes: Andrew Suffield [EMAIL PROTECTED] writes: On Wed, Dec 10, 2003 at 03:31:40PM +0100, M?ns Rullg?rd wrote: All that seems rather obvious to me, so why write it down? Would there be another possible interpretation otherwise? If that's the case, why not mention programs that allow only one specified version? In law, anything which is not written down is neither obvious nor true. That's how contracts and licenses have always worked. I know that is how law works. I just find it strange, that the GPL is so explicit on this point, and yet doesn't bother to clarify at all what a derived work might be, just to take an example. Maybe it was because the author himself actually could figure out the bit about the license version, but didn't more of a clue than anyone else about the parts that really matter. Then again, maybe there was some other reason. No, that's because the GPL is designed to work well in a variety of legal climates, and each different jurisdiction spells out the definition of Derived Work in its own legal code. I think you might get more insight into the whys and wherefores of the GPL and software licensing in general if you began by looking for an answer, instead of guessing at one. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Plugins, libraries, licenses and Debian
[EMAIL PROTECTED] (Måns Rullgård) writes: Edmund GRIMLEY EVANS [EMAIL PROTECTED] writes: Måns Rullgård [EMAIL PROTECTED]: I know that is how law works. I just find it strange, that the GPL is so explicit on this point, and yet doesn't bother to clarify at all what a derived work might be, just to take an example. I suppose the idea is to have the GPL apply as broadly as possible. Anyone who wants a clarification of derived work that is valid for their position in the space-time continuum should visit a law library. The problem is that all such definitions are based on the notion that a work is either something tangible, or a performance act. They simply don't apply well to computer programs. A work becomes copyrightable when it is fixed in a tangible form -- so yes, it is the persistent bits of a computer program, the bits on the disk, not the algorithm or the stack frames as it runs -- which are copyrightable. Where's the problem with this, exactly? Please provide examples. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Plugins, libraries, licenses and Debian
Anthony DeRobertis [EMAIL PROTECTED] writes: On Dec 9, 2003, at 08:25, Arnoud Engelfriet wrote: That doesn't follow. If we assume linking at runtime means creating a derivative work before runtime, then we can conclude only that the plugin is a derivative work of the plugin host. It is the host that loads the plugin into its memory, not vice versa. So it is the host that does the linking. A derivative work MUST be based on a pre-existing work. Title 17 USC Sec. 101 is very clear on that. The host was written before the plugin. It thus can't be a derivative work of the plugin. But the combination of the host and the plugin is a derivative of the plugin -- or is a compilation containing the plugin, or is a mere aggregation containing the plugin, depending on the intent of the author of that combination. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: [POSITION SUMMARY] Re: Plugins, libraries, licenses and Debian
Anthony DeRobertis [EMAIL PROTECTED] writes: I have thus, even with STENOG included, satisfied the terms of the INVERT license. Now, there is a potential problem. Remember that scripting language mentioned before? If someone were to write a script that used both INVERT and STENOG, and then distribute that script, there might be a problem. But that's an issue for another thread. This is no different from perl/python/whatever modules under different licenses. I think this is a quite reasonable summary of the situation. I will point out that further distributors who wish to distribute AIE and INVERT will essentially be bound by the GPL with regards to AIE, even though it is under the MIT/X11 license: they received it under the terms of the GPL, not under the terms of the X11 license. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Plugins, libraries, licenses and Debian
Andrew Suffield [EMAIL PROTECTED] writes: On Mon, Dec 08, 2003 at 01:36:46PM -0500, Brian T. Sniffen wrote: The KDE folks have, from what I've seen, been quite careful with licensing issues. That sentence made me snarf. Do people not remember the history of KDE and Debian? Of course. The KDE people have been careful about licensing as I am careful about dog poo: both of us step carefully around the offending item and leave it behind as quickly as possible. But it rarely hurts to be polite. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: [POSITION SUMMARY] Re: Plugins, libraries, licenses and Debian
[EMAIL PROTECTED] (Måns Rullgård) writes: [EMAIL PROTECTED] (Brian T. Sniffen) writes: Anthony DeRobertis [EMAIL PROTECTED] writes: I have thus, even with STENOG included, satisfied the terms of the INVERT license. Now, there is a potential problem. Remember that scripting language mentioned before? If someone were to write a script that used both INVERT and STENOG, and then distribute that script, there might be a problem. But that's an issue for another thread. This is no different from perl/python/whatever modules under different licenses. I think this is a quite reasonable summary of the situation. I will point out that further distributors who wish to distribute AIE and INVERT will essentially be bound by the GPL with regards to AIE, even though it is under the MIT/X11 license: they received it under the terms of the GPL, not under the terms of the X11 license. *If* the program is derived from the plugin, which it isn't, since the program existed first. Besides the GPL says this: I wasn't clear about what I meant, I'm sorry: when distributing AIE+INVERT, INVERT is under the GPL, AIE+INVERT is a derivative work of INVERT, and so must be treated as under the GPL, and so AIE, in the context of AIE+INVERT, must be treated as under the GPL. These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. Yes, if you pull AIE out separately and distribute it alone, you don't need to provide source. BTW, what's up with gnu.org? -- Måns Rullgård [EMAIL PROTECTED] -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: [POSITION SUMMARY] Re: Plugins, libraries, licenses and Debian
Andrew Suffield [EMAIL PROTECTED] writes: On Tue, Dec 09, 2003 at 11:10:05AM -0500, Anthony DeRobertis wrote: Now, there is a potential problem. Remember that scripting language mentioned before? If someone were to write a script that used both INVERT and STENOG, and then distribute that script, there might be a problem. But that's an issue for another thread. Actually, it's closer than you think. Any product [arbitrary definition] that requires all three components is a derivative work of all of them; that will almost certainly violate one or more of the licenses. Hmm, that's actually interesting. We have an emergent licensing constraint that is a property of none of the works involved, but only appears when they are put together. I don't think we can even discuss the DFSG-freeness of such a constraint in any meaningful way. Since Debian distributes an Operating System (base, essential, etc) and a number of additional packages (optional, contrib, non-free) from which a user might wish to build an Operating System, I think it's quite reasonable to discuss the Freeness of such a constraint: it logically isn't Free by DFSG #1 to #9, but is (I think) under DFSG #10: the GPL and BSD licenses are explicitly Free.
Re: Plugins, libraries, licenses and Debian
[EMAIL PROTECTED] (Måns Rullgård) writes: [EMAIL PROTECTED] (Brian T. Sniffen) writes: I don't know the details of who writes the SSL support for Konq or how it's done, nor do I have any machines with Konqueror on them in front of me right now, so I can't comment on that. Ah, found it -- Debian KDE list, late July 2002: Konqueror doesn't link against OpenSSL. It runs a separate process (kcm_crypto, it looks like), which links against openssl... but does so in a way that *doesn't* invoke OpenSSL's advertising clause. Thus, the GPL prohibition on additional restrictions isn't invoked, and what KDE's doing is fine. And *that* wasn't done just to get around the legalities? Oh, sure it was -- but to get around the legality of obnoxiously having to advertise for others, as opposed to the legality of sharing and sharing alike. If Eric Young advertised all OpenSSL-using software I'd be a lot more tolerant of its license. -Brian
Re: Plugins, libraries, licenses and Debian
[EMAIL PROTECTED] (Måns Rullgård) writes: [EMAIL PROTECTED] (Brian T. Sniffen) writes: What I'm trying to find out is, whether or not it's allowed to write a plugin, using GPL,d libraries, for a program with MIT license, for which there also exists plugins using OpenSSL (or anything GPL-incompatible). If you want a simply answer, the answer is: No (insert disclaimers here) as others have pointed out. As someone said, writing is always allowed, it's distribution that's restricted. That's not quite what I said, and has a critical difference. I said writing *the plugin itself* is allowed. Writing the combined work of the framework, the OpenSSL-using-plugin, and the Readline-using-plugin is not allowed by the GPL. If that's the case, we should put the entire KDE development team in jail. KDE is licensed under GPL, and uses both GPL stuff and OpenSSL. It also uses Java and Netscape plugins, which are very much non-free. Why would we put them in jail? They haven't done anything criminal. KDE is also manifestly not a single work: I use konquerer but no other part of it, for example. The KDE folks have, from what I've seen, been quite careful with licensing issues. Can you provide any specific examples of single works incorporating pure-GPL work and linking against OpenSSL? The rest of the discussion is only appropriate if you want to understand why that is. But it has to do with intent, sneaky ways one might try to get around the GPL, how provable your position is in court, and (perhaps most importantly) how deep your pockets are. I use plugins for purely technical reasons. If, as a side effect, otherwise incompatible libraries can be used, it's all the better for the users of the program. Ask yourself this: is what you're doing in compliance with the wishes of the authors of the various pieces of software you're using? I don't know what the authors wish, I'll have to ask them. They've told you in the license. You can ask for a new, broader license, but remember in the case of GPL'd works that this requires permission from *all* the authors. -Brian
Re: Plugins, libraries, licenses and Debian
[EMAIL PROTECTED] (Måns Rullgård) writes: [EMAIL PROTECTED] (Brian T. Sniffen) writes: What I'm trying to find out is, whether or not it's allowed to write a plugin, using GPL,d libraries, for a program with MIT license, for which there also exists plugins using OpenSSL (or anything GPL-incompatible). If you want a simply answer, the answer is: No (insert disclaimers here) as others have pointed out. As someone said, writing is always allowed, it's distribution that's restricted. That's not quite what I said, and has a critical difference. I said writing *the plugin itself* is allowed. Writing the combined work of the framework, the OpenSSL-using-plugin, and the Readline-using-plugin is not allowed by the GPL. If that's the case, we should put the entire KDE development team in jail. KDE is licensed under GPL, and uses both GPL stuff and OpenSSL. It also uses Java and Netscape plugins, which are very much non-free. Why would we put them in jail? They haven't done anything criminal. When I run Konqueror to visit secure sites, both QT (which I obtained under the GPL) and OpenSSL are loaded in the same address space, which is enough to create a derived work, according to the FSF. You said yourself that even writing code capable of doing this was illegal. I certainly did not. emacs ~/src/qt/* ~/src/openssl/* loads all that code in the same address space, but is not illegal. I said that creating a single work which does that probably violates the license of the GPL'd code. I don't know the details of who writes the SSL support for Konq or how it's done, nor do I have any machines with Konqueror on them in front of me right now, so I can't comment on that. KDE is also manifestly not a single work: I use konquerer but no other part of it, for example. Any typical use of my program would use only a few of the available plugins. What's the difference? That you're making a single work which benefits from the generosity of the authors who released their code under the GPL, but don't seem willing to abide by the rules they set for derivation from their code. The KDE folks have, from what I've seen, been quite careful with licensing issues. In case you hadn't noticed, I'm trying to be, too. You seem to be looking for a way to do what you want while claiming it's within the bounds the authors set. Can you provide any specific examples of single works incorporating pure-GPL work and linking against OpenSSL? KDE is distributed as a few huge tar files, obviously intended to be used together. Someone said that was enough to make the GPL apply to all of it. Who? Where? That looks much more like mere aggregation to me. Ask yourself this: is what you're doing in compliance with the wishes of the authors of the various pieces of software you're using? I don't know what the authors wish, I'll have to ask them. They've told you in the license. They haven't told me their intent with choosing that particular license. That's not *what* they want you to do, that's *why* they want what they want. -Brian
Re: Plugins, libraries, licenses and Debian
[EMAIL PROTECTED] (Brian T. Sniffen) writes: I don't know the details of who writes the SSL support for Konq or how it's done, nor do I have any machines with Konqueror on them in front of me right now, so I can't comment on that. Ah, found it -- Debian KDE list, late July 2002: Konqueror doesn't link against OpenSSL. It runs a separate process (kcm_crypto, it looks like), which links against openssl... but does so in a way that *doesn't* invoke OpenSSL's advertising clause. Thus, the GPL prohibition on additional restrictions isn't invoked, and what KDE's doing is fine. -Brian
Re: Plugins, libraries, licenses and Debian
[EMAIL PROTECTED] (Måns Rullgård) writes: The thing is that, in my case, some very good functionality is provided by plugins using GPL'd libraries. I want to make sure I can distribute those plugins, at least as source. For reasons that should be obvious, I'd rather not touch the GPL. The only problem is when you start loading both GPL plugins and GPL-incompatible plugins. Here, your license is irrelevant; it's the plugin licenses that are in conflict. A permissive license shouldn't add any new problems, at least. There is a plugin that uses OpenSSL... You want to distribute a package which makes takes advantage of code others have written and distributed under the GPL. Part of the deal they offered you was that you could use their code, but in exchange there would be no restrictions on what you distribute but the GPL's. You *also* want to have functionality in your package from Eric Young's SSLeay. Part of the deal under which he lets you use his code is the requirement that you advertise for him. You can't distribute a package which combines all of this and satisfies all of these requirements. You have to either forgo the functionality offered by one of these otherwise generous authors and write it yourself, or find a way to do it that doesn't involve the copyrights of these authors. Distributing it as separate packages -- *really* separate packages, clearly not a single work which happens to be in multiple volumes -- is OK. Getting an OpenSSL license exception from all the authors of the GPL'd libraries could work. Or you could use the GNUtls package, which is LGPL'd (though the OpenSSL compatability layer itself is GPL'd). -Brian
Re: Plugins, libraries, licenses and Debian
[EMAIL PROTECTED] (Måns Rullgård) writes: Steve Langasek [EMAIL PROTECTED] writes: This now gets into the hazy realm where it's best not to go - a court could decide either way. The argument is, approximately, that by shipping the whole lot together you are creating a derived work that violates at least once of the licenses. Certainly you can concoct a case where this is plausible (wrap them all up in one .deb with a default configuration that uses both) - and it is not at all clear where to draw the line. There are legitimate arguments in both directions (the counter-argument is approximately It's not derivation, it's collation). I have a CD that contains lots of GPL stuff, as well as OpenSSL (it's a Slackware CD). I downloaded it as an iso file from some ftp server. Apparently, an iso9660 format filesystem containing tar files of GPL and GPL incompatible software is allowed. Where is the fundamental difference if the format of the wrapper is changed from iso9660 to tar, and the internal files are shared objects instead of tar files? The intent of the distributor in how the individual program bits should be used together, and the feasibility of using them separately. (I.e.: there is *no* fundamental difference between iso9660 and tar for these purposes.) So what prevents two independent plugins, each usable on it's own, from being distributed together? That the user could possibly load both at the same time, creating a derived work? This derived work would only exist in the computers memory during the execution of the program, and would almost certainly not be distributed. Well, first off, creation of derived works -- even if you never distribute them -- is restricted by copyright as well. Second, the intent of the preparer: if I hand you a disk with OpenSSL and GNU Readline on it, as a distribution of excellent Free Software libraries, that's fine. If I hand you those intending them to be used with some other program, that's not fine. It isn't a technical restriction, it's a legal restriction on the social behavior of persons. -Brian
Re: Source only opensource licence.
Franck [EMAIL PROTECTED] writes: Hi, We are currently working on a web-developpement tool for a private company. The people who fund the project are okay to give opensource a try, but they insist on some restrictions. (for the business model to be sucessful). The licence would not be so bad. The only restriction is about the redistribution of binaries wich would be restricted. Windows binaries distribution would be forbidden, but GNU/Linux (as well as GNU Hurd and BSDs) binary distribution would be okay without restriction. From the GNU/Linux point of view, the licence is like GPL. Only windows and other non free operating system would be restricted. For them, the licence is like QMail's licence. Except it's not like the GPL: you can't compile a Windows binary on the Linux platform, or incorporate code from this project in others. I think the best choice from a Free Software point of view would be two licenses: one that offers the no-binary-distribution license to everyone, and a separate license to distribute binaries which run only on GNU/Linux, GNU/Hurt, NetBSD, OpenBSD, or FreeBSD systems. There's also a technical issue -- as Wine and similar projects advance, the distinction of Windows binary and Linux binary gets much more narrow. It will eventually disappear, and this copyright and license will persist. This is why I recommend two licenses, one of which is unambiguously free (but restrictive: the source only license) and contains no references to particular OSs. Good luck. -Brian From what I understand, we can't do what Trolltech is doing with QT because : - This is an end user tool, not a library. - The codebase between GNU/Linux and Windows will be mostly the same since gtkmm will be used for the GUI. We would like to write the most open-source friendly licence based on the above terms, and we are open to any suggestion. Dual licencsing is an option if we find a way to make evrything working.
Re: Preparation of Debian GNU/Linux 3.0r2 (II)
Don Armstrong [EMAIL PROTECTED] writes: On Sat, 22 Nov 2003, Anthony DeRobertis wrote: In the United States, fonts can't be copyrighted. Only font programs (e.g., the PostScript code used to produce the glyph) can be. So there can be no copyright on bitmap fonts, and using a bitmap font, a printout, or even tracing over an image on screen is perfectly legal. I'm not sure that Fiest v Rural Telephone can lead us down this road. Assuming the font is a work of authorship (which many large or relatively large bitmap and TT fonts are) claiming a copyright on it is an entirely reasonable thing to do. Can someone who holds that non-trivial bitmap fonts [eg. fonts larger than ~4x5 pixels] cannot be copyrighted please walk through the rational for their position? [Ideally including case law citations.] (I mean, copyright almost surely applies to works of art primarily made up of fonts... things like Charles Demuth's The Figure 5 in Gold) Sure, but not to the font used. From http://almashriq.hiof.no/ddc/guidelines/copyright/part3.html 3.9) Are fonts copyrighted? First, let's distinguish between a font and a typeface. A typeface is the scheme of letterforms (which is really what you're probably talking about), and the font is the computer file or program (or for that matter, a chunk of metal) which physically embodies the typeface. A font may be the proper subject of copyright, but the generally accepted rule is that a typeface embodied in the font is not (see Eltra Corp. v. Ringer, 579 F.2d 294, 208 U.S.P.Q. 1 (4th Cir., 1978), and the House of Representatives Report on the Copyright Law Revision, 94-1476, 94th Congress, 2d Session at 55 (1976), reprinted in 1978 U.S. Cong. and Admin. News 5659, 5668). The letterforms themselves are not copyrightable under U.S. law as a typeface. 37 CFR 202.1(e). A font is copyrightable if it adds some level of protectable expression to the typeface, but that protection does not extend to the underlying uncopyrightable typeface itself (see 17 U.S.C. 102(b)). In essence, a font will be protectable only if it rises to the level of a computer program. Truetype and other scalable fonts will therefore be protected as computer programs, a particular species of literary works. Bitmapped fonts are not copyrightable, because in the opinion of the Copyright Office, the bitmap does not add the requisite level of originality to satisfy the requirement for copyright. So, to summarize this point, a typeface is not copyrightable. While a scalable font might be copyrightable as a program, merely copied the uncopyrightable typeface, and creating your own font, either scalable or bitmapped, is probably not an infringement, assuming you did not copy any of the scalable font's code. Two warnings: First, even if typefaces can't be copyrighted, they can be patented under existing design patent laws. 35 U.S.C. 171. Copying a typeface and distributing such a font, while not a violation of copyright, might be an infringement of the patent. Second, Congress has been considering design protection legislation for many years (most recently, the 102nd Congress' H.R. 1790) which, if passed, would protect typeface design. If such a bill is enacted, the above opinion will be obsolete and incorrect. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Preparation of Debian GNU/Linux 3.0r2 (II)
GOTO Masanori [EMAIL PROTECTED] writes: At Fri, 21 Nov 2003 09:01:39 -0500, Brian T. Sniffen wrote: I'm confused -- and don't read Japanese. But let me get one thing straight: what Hitachi distributed were strictly bitmap fonts, right? No metafont, truetype, or postscript font outlines, just bitmaps? Well, it's complicated issue. It's no wonder some readers are confused. Alternately, let me ask three simple questions: 1. Were the hitachi fonts bitmaps? Yes. Then Hitachi has no copyright on the fonts -- at least not in the US, though Japanese law may be different. Because bitmaps are the only possible representation of the font at that resolution, there's no creativity, and thus no copyright. 2. Were the kochi fonts bitmaps? No and Yes. OK. Then the kochi license matters. Truetype code is read as *programs* by the courts, and so receives copyright protection. The original watanabe font is converted from bitmap to truetype, and such converted font is remarkably similar to the original. In addition, kochi font has both truetype and bitmap information. Bitmap information is used as truetype hinting information for displaying specific small font size (12,14,16dot) for CRT. 3. Are the watanabe fonts bitmaps? No and Yes. Original watanabe font is bitmap, but ttf-watanabe-* font is converted to truetype as I described above. Kochi used truetype version, but it may use even bitmap information. If the answer to any one of those three questions is yes, Debian's fine distributing them. So it can not distribute straightforwardly... Regards, -- gotom
Re: simplest copyleft license for a wiki
Alex Schroeder [EMAIL PROTECTED] writes: emacswiki.org uses the FDL at the moment; I'd like to move away from the FDL to a very simple license I can understand in two minutes, and I want to allow people to upgrade to the FDL, the GPL, the Creative Commons ShareAlike (CC SA) license, the XEmacs manual license, or any other copyleft license when they copy text from the wiki. At the moment it is possible to convert the entire wiki into a big monolithic HTML file, which can be distributed by other channels. Furthermore, code samples from the wiki might be useful additions to both the Emacs and the XEmacs manual. I'm looking for some advice concerning the wording of the following license. The goal is to keep this license as short as possible while still making it a copyleft license upgradable to any of the other licenses. 1. You have the right to copy, modify, and/or distribute the work. 2. You must grant recipients the same rights. 3. You must inform recipients of their rights. 4. When you distribute the work, you must provide the recipients access to the preferred form for making copies and modifications, for no more than your costs of doing so. 5. Recipients must place identical restrictions on derivative works. 6. You may change the license to any other copyleft licsense such as the GPL, GFDL, CC SA, or the XEmacs manual license. I don't think you want to say You can change the license -- perhaps you want to say You may also choose to receive this under the terms of any other copyleft license, such as the GNU GPL, CreativeCommons ShareAlike, or XEmacs Manual License. But even then, you're going to have two problems: consider, for example, the BSD Preservation License -- it's a copyleft which prohibits any use of copyleft licenses in conjunction with the work, so the ability to derive commercial works is always preserved. Is that something you want to count as a copyleft? Also consider that derivative works under the GFDL or GPL will not be mergeable with the root: those changes won't be useful to you. Restated, the two problems, with solutions, are: 1. Any copyleft license is a very broad and fuzzy set. It's not appropriate for a legal document. Pick some small number of copyleft licenses (1 is nice) you like, and make it available under those. 2. Most copyleft licenses are not compatible with each other, because they treat the requirements of the other license as non-free. Because you're writing mostly about Emacs, I'd suggest sticking with something GPL compatible, so you can have source code trivially on the Wiki: that limits you pretty much to the GPL or MIT/X11 licenses. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Preparation of Debian GNU/Linux 3.0r2 (II)
GOTO Masanori [EMAIL PROTECTED] writes: At Fri, 21 Nov 2003 08:35:10 +, Andrew Suffield wrote: [1 text/plain; us-ascii (quoted-printable)] On Fri, Nov 21, 2003 at 09:52:01AM +0900, GOTO Masanori wrote: At Thu, 20 Nov 2003 22:36:40 +0100, Osamu Aoki wrote: One of More-clearly-free alternative scalable Japanese fonts is kochi-mincho/kochi-gothic in sid/sarge. Many Japanese use this font rather than Watanabe font. If this alternative contains the necessary glyphs, then I do not see that much of a problem with removing the Hitachi fonts. Exactly. We just has to make sure HITACHI's claim was not the primary reason to do so. HITACHI is just a noise. So you just ignore original font author's claim. Is it good attitude? If their claim was bogus? Yup, it is. Paying attention to bogus claims isn't just silly, it sets a very bad precendent. Yeah, if we recognize it's just bogus, then we don't discuss seriously and don't consume our precious time. Original author (Hitachi, who were infringed), and kochi upstream author (who infringed without knowing) already discussed and their conclusion was that it was not just bogus. Kochi upstream author, Yasuyuki Furukawa, wrote details [1] at his web site (in Japanese). [1] http://www.on.cs.keio.ac.jp/~yasu/jp_fonts.html I'm confused -- and don't read Japanese. But let me get one thing straight: what Hitachi distributed were strictly bitmap fonts, right? No metafont, truetype, or postscript font outlines, just bitmaps? Alternately, let me ask three simple questions: 1. Were the hitachi fonts bitmaps? 2. Were the kochi fonts bitmaps? 3. Are the watanabe fonts bitmaps? If the answer to any one of those three questions is yes, Debian's fine distributing them. -Brian
Re: [fielding@apache.org: Review of proposed Apache License, version 2.0]
Branden Robinson [EMAIL PROTECTED] writes: On Fri, Nov 14, 2003 at 07:45:04PM -0500, Brian T. Sniffen wrote: In the current patent-litigation context, a large stable of patents to cross-license is considered a vitally important corporate defense strategy. *shrug* That's not our problem. President Bush considers a missile defense shield a vitally important military defense strategy. That doesn't mean he's right, or that he deserves our support. There's a difference between lack of support, which I endorse, and active opposition. A license which has a cost to anyone holding a software patent, as the currently proposed Apache license, is non-free. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: [fielding@apache.org: Review of proposed Apache License, version 2.0]
Henning Makholm [EMAIL PROTECTED] writes: Scripsit Branden Robinson [EMAIL PROTECTED] On Fri, Nov 14, 2003 at 07:43:01PM -0500, Brian T. Sniffen wrote: There is also no way to be sure that the next minor upstream Emacs release will still be entirely free software, and Debian has been bitten by this before. So why not move everything to non-free which is not under a GPL, version 2 only license? That the GNU FDL is not DFSG-free tells us nothing about the DFSG-freeness of *any* other license. Um, the GFDL was not a part of that debate at all. Brian was responding to some opinions I had about Apache's apparent intent to knowingly include patent-encumbered algorithms in their product. He was saying, by a fairly usual reductio-ad-absurdum argument, that he did not find my reasoning convincing. Even though I still think my point was valind, I don't find his counterargument hysterically absurd. I try to be only hysterical *or* absurd, and never both at once. Fire hose. My original intent was to express this opinion: that software should not be put into main or non-free based on its potential future freeness, but on its freeness today. If that state changes, it can be moved -- though this is unlikely, since most free licenses cannot suddenly become non-free licenses (patent grants justify that most). Aardvark. By retaining absurdity, I hope to avoid hysterics. v.42bis High-Security Streaming Pants. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: possible licensing issues with some scsh source files
Andrew Suffield [EMAIL PROTECTED] writes: On Tue, Nov 18, 2003 at 10:39:56AM +0100, Daniel Kobras wrote: We're currently trying to sort out the non-free status of scsh within Debian. Most of the issues are unambiguous, however, I'd like to see some more opinions on the following two clauses contained in a couple of source files. scsh-0.6.4/scheme/big/sort.scm: ;;; 2. Users of this software agree to make their best efforts (a) to return ;;;to the T Project at Yale any improvements or extensions that they make, ;;;so that these may be included in future releases; and (b) to inform ;;;the T Project of noteworthy uses of this software. Harmless. My best effort consists of waving a gerbil at my workstation and hoping something along those lines happens. (If this were an actual requirement, rather than a vague request, it would be a problem. I strongly discourage people from writing noise like this into licenses though - put it in the README where it belongs.) Best Effort is a term with specific legal meanings. obligation to attempt to meet a goal using every reasonable means available, isn't a perfect definition, but it's close. In particular, it doesn't consider the costs or consequences of those actions to you: even Chinese dissidents can send e-mail, so they have to do so. This is not a Free license. ;;; 3. All materials developed as a consequence of the use of this software ;;;shall duly acknowledge such use, in accordance with the usual standards ;;;of acknowledging credit in academic research. This is close to some things that would be a problem, but with no real constraints on what form acknowledgement must take, harmless (usual standards of acknowledging credit in academic research is a readable citation that is sufficient to find the origin, for anybody who cares enough to do so). This is, at worst, reducible to the BSD advertising clause. It's not reducible to a copyright notice in the binary: if I'm giving a talk about a program I wrote for a professor, I'm obligated by academic honesty to mention inspirations and contributions *in the talk*. So I would read this clause as requiring acknowledgement of inspiration and origins in advertising material, sales pitches, and documentation. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: [fielding@apache.org: Review of proposed Apache License, version 2.0]
Glenn Maynard [EMAIL PROTECTED] writes: On Mon, Nov 17, 2003 at 06:02:12AM +, Andrew Suffield wrote: Finally, it is totally unacceptable to tie this into a software copyright license, such that accepting the license affects the status of your own patents. That's non-free however you look at it. Your own patents are only affected if you contribute code that uses them. If I distribute modifications to a GPL work, the status of my own copyright is affected, too. That first sentence is not true. Specifically, the candidate Apache license says: 5. Reciprocity. If You institute patent litigation against a Contributor with respect to a patent applicable to software (including a cross-claim or counterclaim in a lawsuit), then any patent licenses granted by that Contributor to You under this License shall terminate as of the date such litigation is filed. [snipped] If I use Apache, and have a significant cost to switch my operations away from Apache, then I dare not sue any Apache contributor who infringes on my patents: if I do so, I lose my licenses to use Apache. If there were a list of relevant patents, this might be at least a *little* more reasonable. But given that, for example, IBM has contributed to Apache, I cannot sue IBM for patent infringement without losing my license to use Apache. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: [fielding@apache.org: Review of proposed Apache License, version 2.0]
Glenn Maynard [EMAIL PROTECTED] writes: On Mon, Nov 17, 2003 at 08:19:01AM -0500, Joe Moore wrote: Here's a bit from a hypothetical software license: In addition, by using this software, you grant to the Original Author a non-exclusive right to use, modify, and/or distribute any work of which you own copyright, for as long as you use or distribute The Program. Clearly, no one would argue that this license is a Free Software license. It requires a significant cost (all of your copyrights) to use the software. However, this is essentially what the reciprocal patent clause is requiring. As part of the Apache license, you must agree not to sue any contributor for any of your software patents, for as long as you continue to use Apache. The only problem I see here is return fire: if I'm holding patents as a defense strategy, I want to be able to use them to return fire if an Apache contributor decides to attack me with his own patents, unrelated to Apache. I can't decide if that makes it non-free, or is just an ugly loophole in the license. So an Apache contributor who owns patents on parts of Apache can force Apache users to either license him their unrelated patents at no cost, or give up their right to use (his patents in) Apache. The two paths provided, then, are payment or arbitrary revocation of the license. That's non-free. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: [fielding@apache.org: Review of proposed Apache License, version 2.0]
John Goerzen [EMAIL PROTECTED] writes: On Mon, Nov 17, 2003 at 10:43:01AM -0500, Glenn Maynard wrote: However, this is essentially what the reciprocal patent clause is requiring. As part of the Apache license, you must agree not to sue any contributor for any of your software patents, for as long as you continue to use Apache. The only problem I see here is return fire: if I'm holding patents as a defense strategy, I want to be able to use them to return fire if an Apache contributor decides to attack me with his own patents, unrelated to Apache. This is only useful if you do not have a valid defense for the problem already. In other words, it is only useful as a strong-arm tactic to let your own company effectively ignore patents of others. After all, if the lawsuit filed against you has no merit, you don't need a patent portfolio to defend against it. So, its only real purpose is to let the patent holders thwart the patent law. I don't like that one bit. If the lawsuit filed against you has *no* merit, that's true. But in practice, given the current broken state of the American patent law system, it's much, much cheaper to countersue and work out a quick settlement -- even if both patents on both sides are bullshit -- than to slog through the courts. This isn't nice, it isn't good, it isn't right -- but it isn't Debian's fight, or Apache's, and this isn't the right way to solve it. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: [fielding@apache.org: Review of proposed Apache License, version 2.0]
Glenn Maynard [EMAIL PROTECTED] writes: Added license@apache.org to this subthread, since my final question is directed to them. Please CC debian-legal on replies. On Mon, Nov 17, 2003 at 11:36:10AM -0500, Brian T. Sniffen wrote: This isn't nice, it isn't good, it isn't right -- but it isn't Debian's fight, or Apache's, and this isn't the right way to solve it. Which fight are we talking about here? The fight against patents is certainly Apache's fight. Their strategy (require a patent grant for all contributions) seems like a potentially useful way to fight back. The patent grant (4b) seems to be the key part of this strategy. Other than the mixing of patent and copyright, it seems few people have issues with it. I'm not sure if there's a separate fight behind the reciprocity clause (#5). Is it there as another defense mechanism, or is it there to make 4b more palatable to patent holders? The fact that the license can be revoked over unrelated squabbles between users and authors appears to be an attempt to make software patents impractical and useless. If it only made software patents *on Apache* useless (the second clause of S5), I'd think it reasonable. That would parallel what the GNU GPL does for copyrights for example. What's currently there attempts to use the usefulness of Apache to buy non-enforcement of software patents elsewhere, which I believe is inappropriate for Free Software. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: [fielding@apache.org: Review of proposed Apache License, version 2.0]
John Goerzen [EMAIL PROTECTED] writes: On Mon, Nov 17, 2003 at 11:36:10AM -0500, Brian T. Sniffen wrote: If the lawsuit filed against you has *no* merit, that's true. But in practice, given the current broken state of the American patent law system, it's much, much cheaper to countersue and work out a quick settlement -- even if both patents on both sides are bullshit -- than to slog through the courts. This isn't nice, it isn't good, it isn't right -- but it isn't Debian's fight, or Apache's, and this isn't the right way to solve it. But it is. This is a real problem. Let's say I own a manufacturing company and I am looking for a solution to deploy online shopping services -- this is going to be critical to my business in the future, and a webserver will be a critical part of it. As a manufacturer, I own patents on various manufacturing processes that let me maintain a chance of competing against much larger companies. Now, let's say that somebody that contributed to Apache (with this type of patent grant) decides to violate my patent on mouse trap assembly. I am now stuck between a rock and a hard place: I can either see my product illegally copied by someone else, or defend my patent and see my e-commerce suite come crashing down. Either way, I'm screwed. Exatly: that's what I've been saying: the clause of the candidate Apache license seeking to make software patents unusable is not Free, and not even a good idea. The this in my last sentence was referring to that clause. I don't see how you, or anyone else, can possibly claim that this is acceptable even for proprietary software, much less Free Software. It directly violates DFSG's no discrimination clause, in that people that exercise their legal rights are discriminated against. Now, s/mouse trap/software/ and you have exactly the situation comptemplated by the license proposal. We appear to be in violent agreement. I agree that software should not be patentable at all. But I disagree that people should be prevented from exercising the same rights as everyone else just because they run Apache. If the proposed Apache license becomes DFSG-free, people will no longer be able to trust that Debian is a Free operating system. They will now have to review every legal action taken against any company against all software they use from Debian (which could be in the thousands) to see if this will terminate some rights somewhere. That is ludicrous. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: [fielding@apache.org: Review of proposed Apache License, version 2.0]
Henning Makholm [EMAIL PROTECTED] writes: From: Henning Makholm [EMAIL PROTECTED] Subject: Re: [EMAIL PROTECTED]: Review of proposed Apache License, version 2.0] To: debian-legal@lists.debian.org Date: 17 Nov 2003 23:01:38 + Resent-From: debian-legal@lists.debian.org Scripsit [EMAIL PROTECTED] (Brian T. Sniffen) 5. Reciprocity. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that a Contribution and/or the Work, without modification (other than modifications that are Contribution(s)), constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Contribution or such Work shall terminate as of the date such litigation is filed. That's certainly better. It still has a problem in the following scenario: 1. I start using Apache. 2. I develop a new process -- let's say an encryption algorithm, like RSA -- and patent it. 3. Somebody contributes an implementation of my algorithm to Apache. This somebody has patents on critical parts of Apache. Now I'm screwed: I can't sue Apache for illegally using my work without my permission, or I'll lose my license to their code. I don't see that. If is only the grants under this License *for* that Contribution or such Work that terminate. If you does not use the version of Apache with your work in it, then your license to the version you do use does not self-destruct as a consequence of your suit. You may be screwed if you only discover the violation after you yourself have converted your website to use an Apache version that itself contains the violation. In that case you will need to backport the new features you need to an older Apache that does not contain your patent (and which thus has a license that will not self-destruct). Whoah. You're right, I missed that. OK, that might actually be Free. I'm not sure, and I'll need to think about it hard. It also seems to be a fine enough point that it invites situations akin to Pine: a malicious or just confused copyright^H^H^H^H^H^H^H^H^H patent holder might interpret it differently. -Brian
Re: Proposed Apache license patent/reciprocity issues
Sam Hartman [EMAIL PROTECTED] writes: MJ == MJ Ray [EMAIL PROTECTED] writes: MJ On 2003-11-15 04:14:44 + Walter Landry [EMAIL PROTECTED] MJ wrote: It only revokes the patent license, not the whole license. Since Debian, to a large extent, only concerns itself with patents that are being enforced, it was considered fine [1]. There was even a comment praising the patent stuff [2]. Basically, if there was a patent being enforced then Debian might start worrying about these clauses. MJ I think I can buy this. We evaluate the licence as if it MJ contains no patent grants and see if that minimal state still MJ meets the DFSG. The licence must only revoke the non-essential MJ grants in this case and not the entire licence. I also buy this. I believe that the needs of the free software community are best met by patnet strategies that make it more expensive and difficult to enforce patents. And so to the extent we can do so while still being consistent with the letter of the DFSG, we should be sympathetic to such attempts. Erm. If you said software patents, you'd be more in line with my own beliefs. As it is... the needs of the free software community would be best met by making all sorts of things more expensive and difficult. I don't think licenses which prohibit voting Republican are Free, and I don't think licenses which prohibit exercising other legal right unrelated to the software in question are Free. In particular, licenses which become non-free when I bring up an unrelated law-suit are not Free. -Brian We do not want to get in the position of evaluating the validity of patents and I do not think we want to penalize people for granting patent licenses to the community as a hole even if those licenses have strange strings attached.
Re: [fielding@apache.org: Review of proposed Apache License, version 2.0]
Andrew Suffield [EMAIL PROTECTED] writes: The argument proposed was attempting to say No company is ever going to grant free patent licenses; I pointed out the argument applies equally to software (it's the same one that proprietary software advocates have been making for about 20 years, claiming that free software can't work), and companies *do* grant free software licenses. They can grant free patent licenses for the same reasons. And, as it happens, companies do grant free patent licenses: it's common practice when working on a standard which must be approved by a standards body with a RF policy: typically, the patent is licensed for any use which implements that standard. This is an interesting restriction on modification-and-use: you can modify the program to use the patented technology outside the scope of the standard, but you can't compile and use that code without infringing on the patent. I *think* the result can be Free Software, but I'm not entirely convinced: it seems that the standard is included by reference in the patent spec. This is made even worse in cases where the standard isn't freely available, so you don't even have the text of the patent license unless you pay for the standard. That's probably not Free Software. But for the case of Apache, for example, it's enough for every contributing company to grant a universal license to their patented technology for use in web browsers, and for the ASF to refuse contributions to the mainline Apache from anyone who doesn't agree. Yes, this means unscrupulous or even just secretive companies can fork Apache and integrate their proprietary, patented technology. That would be unfortunate. But the freedom to do that is a necessary freedom. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: [fielding@apache.org: Review of proposed Apache License, version 2.0]
Henning Makholm [EMAIL PROTECTED] writes: Scripsit [EMAIL PROTECTED] (Brian T. Sniffen) And, as it happens, companies do grant free patent licenses: it's common practice when working on a standard which must be approved by a standards body with a RF policy: typically, the patent is licensed for any use which implements that standard. A patent license that applies only to implementations of a specific standard is not free (as in free speech). Can you explain this to me? I see free software, and some external limits on how you may use certain modifications of it. This is an interesting restriction on modification-and-use: you can modify the program to use the patented technology outside the scope of the standard, but you can't compile and use that code without infringing on the patent. I *think* the result can be Free Software, I think it is clear that it is not. Well, it's certainly not *clear*, or we wouldn't be having this discussion. But I'm entirely convinceable -- go ahead and try? But for the case of Apache, for example, it's enough for every contributing company to grant a universal license to their patented technology for use in web browsers, and for the ASF to refuse contributions to the mainline Apache from anyone who doesn't agree. If ASF makes public an intention to include in upstream Apache patented code that cannot be used in X servers, desktop calculators or Forth compilers, then we can never be sure that the next minor upstream release will still be free software. Of course the Debian maintainer for apache *may* choose to audit each new upstream release to see if non-free patents have crept in, but I would advise moving it to non-free right away to avoid future trouble. There is also no way to be sure that the next minor upstream Emacs release will still be entirely free software, and Debian has been bitten by this before. So why not move everything to non-free which is not under a GPL, version 2 only license? -Brian
Re: [fielding@apache.org: Review of proposed Apache License, version 2.0]
Henning Makholm [EMAIL PROTECTED] writes: The argument proposed was attempting to say No company is ever going to grant free patent licenses; I pointed out the argument applies equally to software And I point out that it doesn't. If the company patent their invention at all, it must be because they intend to restrict people from using it (or at least keep an option open for using the patent to restrict what people do). If they do not intend that, why would they apply for a patent at all in the first place? In the current patent-litigation context, a large stable of patents to cross-license is considered a vitally important corporate defense strategy. (it's the same one that proprietary software advocates have been making for about 20 years, claiming that free software can't work), No, it has nothing to do with that argument.
Re: [fielding@apache.org: Review of proposed Apache License, version 2.0]
Henning Makholm [EMAIL PROTECTED] writes: Scripsit Brian T. Sniffen Henning Makholm [EMAIL PROTECTED] writes: And I point out that it doesn't. If the company patent their invention at all, it must be because they intend to restrict people from using it (or at least keep an option open for using the patent to restrict what people do). If they do not intend that, why would they apply for a patent at all in the first place? In the current patent-litigation context, a large stable of patents to cross-license is considered a vitally important corporate defense strategy. Yes, but a patent could not be part of such a portfolio if if were licensed freely to the general public. But it could be part of such a portfolio if it were licensed for use in otherwise-free software only, or for use in implementing specifications with RF policies. -Brian
Re: [fielding@apache.org: Review of proposed Apache License, version 2.0]
Glenn Maynard [EMAIL PROTECTED] writes: On Sat, Nov 15, 2003 at 12:58:39AM +, Henning Makholm wrote: In the current patent-litigation context, a large stable of patents to cross-license is considered a vitally important corporate defense strategy. Yes, but a patent could not be part of such a portfolio if if were licensed freely to the general public. ... unless it's licensed with a condition that if you sue them, the patent grant is withdrawn. That seems to be the purpose of the reciprocity clause. It seems the intent is to require a patent license (under 4b), while still allowing those patents to be used defensively (against other patents). At least on its face, it seems like a useful compromise: companies often legitimately won't want to give out unrecovable patent licenses, since they need them to defend against other, hostile patent holders. Still undecided. I can sympathise both with attempts to find defenses against patents (of which free software has scarce few), and to do so in a way that doesn't force others to weaken their own patent defenses. My employer just hosted a lawyer to tell us all about the Dangers of F/OSS (Free or Open Source Software). His talk was largely FUD, but one of the few pieces which found purchase with management was Patent Litigation Fear: that if we were using Mozilla (the MPL has a similar clause) anywhere in the company, or even worse had standardized on it, and got into a patent lawsuit with any Mozilla contributor, we could lose our license to use Mozilla, or to distribute code which derived from Mozilla. That's just too scary to risk: if somebody else really does violate one of our (non-software, even) patents, we have no recourse without first switching to some other code base. Yech. That pretty much seems like a usage restriction: it restricts us from doing things in private, based on our attempts to exercise *unrelated* legal rights. -Brian
Re: Legality of .DEBS in Medialinux.
Marco Ghirlanda [EMAIL PROTECTED] writes: Knoppix should be distributing the source from the same location that you would get the CD, so its still compliant with the GPL. Really I couldn't find the sources of Knoppix anywhere. http://developer.linuxtag.net/knoppix/ looks like a good place to start. That's a result of googling for Knoppix source and taking the first hit. There's a link to that from the index file of a Knoppix CD. The fact seems that it is necessary for correct application of the GPL, but it is not respected so much indeed. So I have to publish for every *.deb a *-src.deb? Well, you have to publish the source in some convenient format -- a bunch of tar.gz's is fine, for example. The real issue comes when you are handing out or selling binary only cds. Those need to have a written offer for source valid for three years (for the GPL) I would point to the Debian Source, is it right? No. You need to provide it yourself -- you can't point to something which might fold up and vanish tomorrow. It has to be *you* providing the source, not you pointing to somebody who does. There's an exception to this, but it only kicks in if you're doing non-commercial distribution AND you received a written offer for source yourself. Debian provides no such offers. , or the source needs to be available at the same time for no extra cost. This I don't understand. Seems like I have to create an ISO with only the sources. Is there a program who download the sources for a given list of packages? 'xargs -ifoo apt-get source -d foo' -- the source debs are all sitting in one directory, it's not hard to programatically assemble their names and fetch the ones you want.. Not to seem un-ethical, but if MrKnoppix doesn't do this, why should I do it (I mean publish the sources cd) that I am a much smaller and derivative project? Klaus Knopper does do this. He's actually put a lot of thought into making sure that he, and those who redistribute his CDs, have a good way of complying with the GPL. Check the archives here, it was discussed this past summer. Or, check out The Man Himself at http://mailman.linuxtag.org/pipermail/debian-knoppix/2003-April/002425.html. As I said, Knopper's done his homework to help with this sort of situation. Anyway I'm still considering this possibility, cause Medialinux was born as a project for the students of our school, but it looks like it has many possibilities more... I'm just very sorry I have to tell to my users that they will not use this to look at their payed DVD, 'cause they have to pay for the software again. I wish someone here could help you with that, but the way copyright and patent laws are written right now, it would be very risky to do so. And that I need the double of the space on the server (that in our case is hosting us for free, in pure Linux tradition) to put also the sources. Hardly. Source is typically much smaller than the binary. Thanks so much, Marco Ghirlanda
Re: Legality of .DEBS in Medialinux.
Henning Makholm [EMAIL PROTECTED] writes: Scripsit Lucas Nussbaum [EMAIL PROTECTED] Marco Ghirlanda [EMAIL PROTECTED] wrote: This I don't understand. Seems like I have to create an ISO with only the sources. no. What you can do is add written offer to provide the sources to whoever ask for them, and, additionnally, point to Knoppix sources, Debian sources, and Christian Marillat's sources. The number of people directly asking you for the sources should be quite low ... However, most people would probably find it easier simply to offer the source code from the same FTP server in parallel with the binaries. It does not have to be ISO images [1]; separate files for each package should be fine. That way one does not have to bind oneself to keeping a 3-year backlog of old sources. (Why Knoppix does not do this, but it's their prerogative to do it the hard way if they choose to). Knoppix doesn't do that so they can have a written offer reusable by those who redistribute the CD. That's important for a project whose primary method of distribution is CDs at conferences. -Brian
Re: Legality of .DEBS in Medialinux.
Don Armstrong [EMAIL PROTECTED] writes: [Marco: The primary function of this list is to discuss licenses and the legal ramifications of those licenses. As none (or almost none) of us are lawyers, we cannot give legal advice. The following is not legal advice either.] As far as we know, packages in main are legal to distribute pretty much everywhere. You may need to remove the encryption parts in certain countries, although I don't think that applies to Italy. You also should remember to distribute source where you are required to do so -- for all GPL'd packages you get from Debian, for example, you must distribute the source. However, as most of us are not attorneys, and as such, not allowed to practice law in Italy, you should probably consider approaching someone knowledgeable in the laws of your locality who can give you more detailed and accurate information regarding the laws and how they interact with software. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: GPL flaw?
in the GPL community had used the twenty offending lines, they would have to remove...those twenty lines. The remainder of the codebase would still be GPLed. That's already the case, because of how combined and joint works are treated under copyright law. -Brian Thoughts? Perhaps I've misinterpreted the GPL, or missed some portion of a clause that applies. It would be nice to know that this isn't an issue. :-) -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Advices on choosing a documentation license for an upstream project
Arnaud Quette [EMAIL PROTECTED] writes: [@ -legal: please cc me on reply as I'm not subscribed] Hi folks, We (Network UPS Tools project) are currently looking at creating a complete documentation set using docbook, for output formats and i18n reasons. That's great. Thanks. This improvement in the upstream will, by side effect, (re)create a nut-doc package in Debian. Knowing that: - NUT is a pure GPL project, thus we need a _free_ documentation licence, - GFDL seems to be to doc what GPL is to source code, so it seems the good choice for our aim, - the current consensus on -legal is that GFDL isn't DFSG compliant in its current form (from what I've read in the Debian Statement about GFDL and -devel), - Debian is our GNU/Linux reference distribution for several reasons, and we don't want nut packages to be split between main and non-free! - however, if choosing GFDL, the RM won't consider it as an RC bug (so not blocking for sarge/future stable), The RM won't consider existing GFDL documents to be RC bugs. New GFDL documents might or might not be approved, and in the interests of minimizing later headaches, I'd suggest avoiding that license. Non-free documentation almost certainly will be RC at woody+2. - the FSF steps about modifying GFDL might not occur before long (a year seems, according to RMS main focus on GPL V3) So, what are your advices about choosing a _free_ documentation licence for NUT? Well, given you talk about being a pure GPL project, why not put your documentation under the GPL as well? Even if you were writing in plain text or in a WYSIWYG program, it's a reasonable choice. But given you're writing in docbook, with a very clear source-compiled-to-object mapping, the GPL is a great choice for a free documentation license. It has the added advantage of being GPL-compatible: that is, you *and the recipients* can freely move data between the program and the documentation. This makes writing and examples easy and productive. -Brian Thanks for your constructive advices, and please, don't start any flamewar as it's not the aim of this mail. Arnaud Quette --- DD (nut, wmnut, knutclient) Upstream developer Team of NUT ... --- References: - NUT upstream: http://www.exploits.org/nut/ - NUT Sid packages: http://packages.debian.org/cgi-bin/search_packages.pl?keywords=nutsearchon=namessubword=1version=unstablerelease=all - Debian Statement about GFDL: http://people.debian.org/~srivasta/Position_Statement.xhtml -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Invariant name in hello's debian/rules file
Robert Millan [EMAIL PROTECTED] writes: Hi! Trying to distress a bit the recent *cough* discussion in -private, I think it's a good moment for rising my point in -legal (where it should be). I recently found this in the debian/rules file for GNU Hello (which, it is well known, has been copied to death into hundreds of other debian packages). # Sample debian/rules file - for GNU Hello. # Copyright 1994,1995 by Ian Jackson. # I hereby give you perpetual unlimited permission to copy, # modify and relicense this file, provided that you do not remove # my name from the file itself. (I assert my moral right of # paternity under the Copyright, Designs and Patents Act 1988.) # This file may have to be extensively modified The license states that you can't remove the name from the file itself. I'm sure this is not what Ian intended, but one could add this line all over the file: # Ian Jackson and then it can't be removed. It all gets very confusing if we apply the same reasoning as for GFDL's Invariant sections. What do you people think? It's small and does not appear a practical inconvenience -- unlike the GFDL's Invariants. I think as long as one occurrence of Ian Jackson appears in that file, it hasn't been removed -- if you see what I mean. It's still there, after all. Also, if you are distributing a file in which Jackson retains copyright, you have to include the line Copyright 1994,1995 by Ian Jackson anyway. So it requires nothing more than copyright law does. If you are cutting the file down enough that this becomes an inconvenience, there's probably no copyright in those snippets. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: If not GFDL, then what?
Anthony DeRobertis [EMAIL PROTECTED] writes: On Mon, 2003-10-13 at 22:01, Brian T. Sniffen wrote: Let's say Alice's installer uses secret-sharing or error-correcting codes to meld the program and the documentation, then produce separate works from them. Like tar czf? Not quite what I had in mind: I was considering something clearly a program and using, not merely aggregating, the two works: something which would invoke the FSF's ridiculous assertion that dynamic linking is modification. Let's say Alice distributes them as an InstallShield(tm) program, or as a shar-style archive: an installer program which installs the documentation and the useful program. Certainly nobody can make such an installer -- which is a derived work -- except Alice. which is a derived work is quite questionable. It'd probably be a mere aggregation --- certainly just as much as a ext3 filesystem. So given that, no, I don't mean anything like a tar file or a filesystem: I mean something more like a closure which returns other works. How are tar and shar different, legally? None, I'd bet. I don't think taking an archive file, and including an unarchiver (InstallShield) is any different, either. This is why I was careful not to describe it as an archive file and an unarchiver: it is a program which produces output; that output is a copy of a copyrighted work. There isn't a clear data section; rather, the useful program (which Alice originally wrote and Bob modified) and its documentation are organic parts of it. Perhaps it links against Alice's program and the documentation. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: If not GFDL, then what?
Joe Moore [EMAIL PROTECTED] writes: Anthony DeRobertis said: On Mon, 2003-10-13 at 10:47, Joe Moore wrote: Many technical books come with a CD of examples from the book, or similar material. A copy of the source could easily be distributed on that CD.* * The book could not legally be sold without the CD, since the seller would not be fulfilling the reqs of the GPL. The publisher couldn't legally sell the book without the CD (or 2(b) notice); however, anyone else could buy a copy from the publisher, remove the CD, and resell it. See the first sale doctrine. But the reseller would be distributing a modified GPLd work (without source), so would be bound by the terms of the GPL. (Unless removing the CD does not create a work based on the Program subject to the GPL's terms.) Copyright law doesn't stop modification -- at least in the USA, or other places where the First Sale Doctrine applies. It's quite impractical to actually modify software, but the GPL doesn't stop me from scribbling on the hard drive of this machine and then handing it to you. What the GPL talks about is a modified copy -- a derivative work. Since the reseller is doing no copying, but merely acting on physical objects -- not making any creative or artistic changes -- I suspect what he's doing is compliant with the GPL, especially if the particular author says it is. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Packaging Swiss Ephemeris Free Edition for Debian GNU/Linux
Jaldhar H. Vyas [EMAIL PROTECTED] writes: On Tue, 14 Oct 2003, Alois Treindl wrote: On Tue, 14 Oct 2003, Jaldhar H. Vyas wrote: Personally my suggestion would be to adopt the dual QPL/GPL scheme just like Trolltech. Yes, except for one additional situation: We find more and more that software is developed not for distribution, but for inhouse use in commercial companies, e.g. to power a web application which makes money via web services. We would like this usage to be considered commercial, i.e. requiring a paid license. I am not sure that the GPL serves us here. Someone using Swiss Ephemeris unde the GPL could run it in some webservice, without ever paying anything, or ever ublishing anything back for the open source community. I have not looked at the QT license in that respect. Are you aware of that situation is covered in a way favourable for QT? My understanding is that the GPL is currently unclear on the topic of web services and this is going to be addressed in an upcoming GPL v3. I don't know about the QPL. I am taking the liberty of ccing your message to debian-legal as the people there are more knowledgeable on such subjects. I think it's pretty clear that Mr. Treindl does not want Swiss Ephemeris to be free software: freedom to exploit the software for commercial benefit is a necessary component of Debian's definition of Freedom. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: If not GFDL, then what?
Brian M. Carlson [EMAIL PROTECTED] writes: On Sat, Oct 11, 2003 at 04:18:39PM -0500, Branden Robinson wrote: On Sat, Oct 11, 2003 at 05:00:16PM +, Brian M. Carlson wrote: I would recommend the GNU General Public License, version 2. This accomplishes your goals, and it is unequivocally free. I have equivocated on its freeness before, with respect to clauses 2a) and 2c). I apologize. I didn't remember reading that when I wrote my message. I did not mean to misrepresent your opinion or anyone else's, only to represent my own. Also, I see no reason the author can't dual-license under the GNU GPL and and the GNU FDL. It might be easier to get the publisher to go along with that if they've already bought into the rhetoric that the GNU GPL is an inappropriate license for printed documentation. The author asked for a recommendation. I offered one which met the specified criteria. 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. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: If not GFDL, then what?
Mark Pilgrim [EMAIL PROTECTED] writes: Doug Winter wrote: On Sat 11 Oct Mark Pilgrim wrote: Here is what I would like to do: 1. Give away my book for free. 2. Force translations and all derivative works to remain free. 3. Force my editor's contributions to remain free. 4. Allow Apress to publish the book commercially. 5. Put the book in Debian main. What license would you recommend for that? One license you may wish to consider is the Creative Commons Attribution License: http://creativecommons.org/licenses/by/1.0/legalcode It appears to fulfil all of your requirements, afaict, except perhaps being suitable for main. With all due respect, I already have a license that fulfills requirements 1-4 but not 5: the GFDL. The GFDL fulfills 1 only if the book is written in something the FSF recognizes as an open format. It does not permit free translation if there are invariants, so it does not meet #2. The GFDL is not a copyleft, so it certainly does not meet #2 and #3. Don't believe me? Examine the following: Alice distributes a program, under the GPL, and a documentation package for that program under the GFDL. Because she is the copyright holder, she distributes them together. Nobody else can redistribute this as a single integral package, of course. Now Bob takes this package and modifies the program to include a new feature and some bug fixes, as well as some material X. He also modifies the documentation to include information on the new feature and an invariant section calculated to offend Alice, or shame her to distribute, such as a cover text stating Written by Bob. Alice claims authorship, but lies.. He distributes the improved program under the GPL and the improved documentation under the GFDL. Alice is guaranteed to be able to use the bug fixes and new feature added by Bob: she can simply disregard material X, no matter what it is. She cannot use the material in Bob's documentation, though, without importing repugnant or false statements. Bob has succeeded in taking the documentation proprietary. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: If not GFDL, then what?
MJ Ray [EMAIL PROTECTED] writes: On 2003-10-13 19:58:58 +0100 Brian T. Sniffen [EMAIL PROTECTED] wrote: Alice distributes a program, under the GPL, and a documentation package for that program under the GFDL. Because she is the copyright holder, she distributes them together. Nobody else can redistribute this as a single integral package, of course. I'm not convinced by this step in the reasoning. If they are merely aggregated, surely others can distribute them in the same packaging? Let's say Alice distributes them as an InstallShield(tm) program, or as a shar-style archive: an installer program which installs the documentation and the useful program. Certainly nobody can make such an installer -- which is a derived work -- except Alice. If they are a single work under two incompatible licences, can anyone else distribute it at all, even split? Certainly, as long as he has separate licenses for the two parts from Alice. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: If not GFDL, then what?
Peter S Galbraith [EMAIL PROTECTED] writes: Brian T. Sniffen [EMAIL PROTECTED] wrote: MJ Ray [EMAIL PROTECTED] writes: On 2003-10-13 19:58:58 +0100 Brian T. Sniffen [EMAIL PROTECTED] wrote: Alice distributes a program, under the GPL, and a documentation package for that program under the GFDL. Because she is the copyright holder, she distributes them together. Nobody else can redistribute this as a single integral package, of course. I'm not convinced by this step in the reasoning. If they are merely aggregated, surely others can distribute them in the same packaging? Let's say Alice distributes them as an InstallShield(tm) program, or as a shar-style archive: an installer program which installs the documentation and the useful program. Certainly nobody can make such an installer -- which is a derived work -- except Alice. Or as a Debian package? Are you arguing that we can distribute GFDL and GPL contents in the same package? You'd be the first... Did you mean can't here? My expectation is that the FSF treats a Debian package as more of a portmanteau document than as a program, and so would call this mere aggregation. Let's say Alice's installer uses secret-sharing or error-correcting codes to meld the program and the documentation, then produce separate works from them. -Brian
Re: Licensing requirements ???
going to like: if you want to distribute code which uses the contributes generously made available to you by the MySQL developers, you have to comply with their licensing terms by making your source code available to whom you give a binary. You may wish to consider using a different database. Even if you do use PostgreSQL, which is under a BSD-like license, you'll have to include source for all of the GPL'd software -- if you're not making any changes to GPL'd software, a Debian source CD set will cover this. -Brian Please, bear with me, because I am in unfamiliar water, and I want to do what is right. Nevertheless, I do want to understand the rules, and not pay by extortion, as per other popular licensing models ; -- Best Regards, mds mds resource 877.596.8237 - Dare to fix things before they break . . . - Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Swiss Ephemeris Public License
Don Armstrong [EMAIL PROTECTED] writes: On Fri, 10 Oct 2003, Jaldhar H. Vyas wrote: If you do not meet the requirements in the SEPL, for example if - you develop and distribute software which is sold for a fee higher than a reasonable copy charge - or/and you develop and distribute software which is not published under an Open Source or equivalent license you must purchase the Swiss Ephemeris Professional Edition under the Swiss Ephemeris Professional License. These clarifications are a bit troubling (and from my reading don't extend from the license.) The licenses restriction of #1 only applies to the source code of SE, not all of the compiled and source programs distributed by a company as alluded to by #1. I'm not quite sure if they intend for the license to actually mean #1, or if they just weren't clear. #2 has the same problem of seeming to apply to all works distributed by a person or entity, which isn't something delinated in the license. [Eg, if you distribute any software which isn't under an OS license (say you provide software under contract to someone) you need a Professional License.] Those are in what's essentially the How to use this license section, directed at those thinking of distributing their own independently developed software under the SEPL. I haven't looked closely at the data-transfer part. -Brian
Re: MPlayer DFSG compatibility status
Gabucino [EMAIL PROTECTED] writes: Glenn Maynard wrote: One version of VirtualDub could read ASF files, and that was quickly removed. That was back in 2000, and I just checked: the news entries appear to have fallen off the site. There is a significant part to these patent enforcement stories: they all happen on Win32 platform. Microsoft has never enforced media patents on Linux market, as far as I know. That's irrelevant if they actually own the patent: the goal is not to avoid getting sued, it's to avoid breaking the law. If you've found a violation of the DFSG in xine, please file a serious bug against xine-ui or libxine1, as appropriate. -Brian
Re: committee for FSF-Debian discussion
[EMAIL PROTECTED] (Bruce Perens) writes: A good candidate would also be familiar with debian-legal's analysis of the GFDL. This would only be the case if we had to prove that invariant sections are outside of the DFSG. I don't think we will have to argue about that, it's pretty obvious. But I can keep the people mentioned on call in case it comes up. Sure, but the Invariant Sections are hardly the only problem -- not only do we have people who apparently truly believe Invariant Sections are OK in documentation, but there are also issues with cover texts, mass distribution, the DRM clause, and the definition of transparent forms. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: GFDL
Mathieu Roy [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Thomas Bushnell, BSG) a tapoté : Richard Stallman [EMAIL PROTECTED] writes: If you want to criticize the FSF based on things you can imagine we might do, I am sure you can imagine no end of nasty possibilities. The only answer necessary to them is that they are false. You are criticizing Debian based on things you can imagine we might do, and have imagined no end of nasty possibilities. When we tell you they are false, you just continue saying them. - Several persons of Debian stated on that list that they would drop any political text of GNU in GNU packages they may maintain. Mathieu, you're lying. Provide citations of any Debian Developer doing so -- provide citations of a non-Developer saying so and I'll downgrade you to mistaken. What I *have* seen is assertions that removable-but-not-modifiable text should be removed, as it is not DFSG-free. - But even if Debian do not drop the GNU political/philosophical/... texts from the packages, what will do the other distro, way more popular than Debian, which does not even recognize the collection of software they ship as GNU/Linux? What distribution is more popular than Debian? I thought Debian was the largest in most markets of interest... but I wouldn't worry about Red Hat, if I were you. I'd worry about Microsoft. Gosh, they might distribute the Emacs manual without including RMS' political essays. They could use it to document... wait, they'd be distributing Emacs, and making the GPL available to users, and a dozen news organizations would report that Microsoft was distributing Free Software and link to the FSF web site. What's the problem, again? -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: snippets
Richard Braakman [EMAIL PROTECTED] writes: 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? - The time and effort that would be spent on locating and removing them and maintaining a repackaged source archive can instead be spent on writing code and fixing bugs. - We maintain better relations with upstream authors, who presumably would like their heartrending emails to accompany their work. - We can keep more source archives pristine. What are the advantages of removing them? - We save some bytes in the archive. - If a snippet turns out to be problematic, we won't have to spend effort on removing it because we already spent that effort. - We might convince some authors to write modifiable snippets instead. You neglect Debian is 100% Free Software as an advantage of removing them, which is why you don't see a convincing case: I don't see a convincing case here for removing them. It is not uncommon to be unconvinced when all convincing arguments have been neglected. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: A possible GFDL compromise: a proposal
Richard Stallman [EMAIL PROTECTED] writes: You have previously suggested we should consider whether documentation is free, based on the four basic freedoms as specified on http://www.fsf.org/philosophy/ . That includes 'the freedom to run the program, for any purpose'. Since a manual can't be run, I'll interpret that as 'the freedom to use the manual, for any purpose'. So, by your own terms (unless you want to state that my interpretation is incorrect), a manual is not free if you can only use the manual as a manual, and not as something else. Freedom zero is not about modification, not for programs or manuals. The analogue of running a program, for a manual, is to read it. I strongly disagree. The analogue of running a program, for a manual, is to write it or to teach from it. In order to have freedom with respect to a manual, I must be able to apply it to purposes beyond those which the original author intended. -Brian
Re: coupling software documentation and political speech in the GFDL
Dylan Thurston [EMAIL PROTECTED] writes: 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. Bear in mind that Debian does distribute freely modifiable political text, for which the original author is *dead*, and yet his original words are still copied about substantially unchanged: the book of Amos, for example, in package bible-kjv-text. I think RMS fear that we would somehow change his essays is severely unfounded. Additionally, his argument is misleading in ways which prevent counterargument: there's no way we could change his essays. We might derive works from his essays, though it is unlikely they would be noticeably similar to his essays. -Brian
Re: committee for FSF-Debian discussion
[EMAIL PROTECTED] (Bruce Perens) writes: The following persons have agreed to serve on a committee regarding the FSF - Debian discussion: Eben Moglen, Attorney for the Free Software Foundation. Henri Poole, Board member, Free Software Foundation. Benj. Mako Hill, Debian. I am seeking another candidate from the Debian side. A good candidate would be able to approach the discussion with a constructive and dispassionate attitude. 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 serve well -- Branden Robinson would, I suspect, be objectionable to the FSF, and Thomas Bushnell is a GNU developer as well. Is Mr. Hill a frequent reader of debian-legal? I know I have not seen him posting here. -Brian
Re: A possible GFDL compromise: a proposal
Mathieu Roy [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Brian T. Sniffen) a tapoté : 1. Is this MP3 file software or hardware? This is one is definitely worse: you explicitely point out which definition of the word software you think is the most usual, by asking to refer to this definition. Well, yes: I'm being upfront about in which domain I'm placing the question. Simply asking Is this MP3 software? doesn't give any meaningful data, because you can't control for bias on the part of the individual. Well, what you call controlling for bias is in fact controlling the data. I didn't say my question controlled for bias: I said you failed to do so, and presented several alternative questions which explicitly pulled the answer into certain domains. Have you some background in sociology? Minimal. Have you? I've got some statistics experience, though. You know, there's are interesting books that explain some acceptable methodology to follow when doing interviews and wanting meaningful data (in a little bit scientific and honnest way). There certainly are. For instance, controling for bias should be done once you already collected the data, not during this collection of _raw_ data, if you do not want to alter too much the _raw_ data. Well, yes: Is this MP3 software? seems to be a correct question: it does not propose any definition of software to follow, so the questioned one must answer by explaining partly what he considers to be software. Well, no. A good question to ask is: Give me some examples of software. Try to span the range of what 'software' might include. Is this corner case software, answer quick now, no long consideration or checking references is a horrid question. -Brian
Re: What does GFDL do?
Richard Stallman [EMAIL PROTECTED] writes: 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. I'm particularly worried that if you open the door to asymmetric volumes, you will encourage bad behavior: if you allow a tough, laminated cardstock reference card to be Volume I, while the license and invariants are on onionskin paper in Volume II, most recipients will simply throw those latter parts away: they'll be treated as small print of no concern to the reader. In order to get what you want -- more exposure for the political ideas of documentation distributors -- you're going to have to explicitly restrict the ways that multiple volumes can be constructed. It runs so counter to the apparent goals of the GFDL that all of us assumed you intended for this to be forbidden. -Brian
Re: A possible GFDL compromise: a proposal
Carl Witty [EMAIL PROTECTED] writes: Software is not a controversial word in English (roughly inverse of hardware in one sense). Some people advocate a bizarre definition of it in order to further their agenda. If you're going to define common words just because someone objects to the normal meaning being used, you'll get some bozo that objects to the word social and claims it only applies to the welfare state. That's clearly ungood. Software is a controversial word in English. In an informal survey, two out of two people surveyed (my officemate and myself) agreed that we would not, by default, call an arbitrary collection of bits software (the particular example in the survey question was an MP3 file); but that we would agree to use a different definition of software than the one we are accustomed to in certain contexts. But your question, Is this MP3 file software? is itself biased. Consider the alternatives: 1. Is this MP3 file software or hardware? 2. Can an MP3 file be Free Software? -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: GFDL
Richard Stallman [EMAIL PROTECTED] writes: If the whole document would be DFSG-free, than there would be no cause to remove political statements. According to Don Armstrong, a non-modifiable text cannot under any circumstances be considered DFSG-free, It *might* be possible to construct something which meets your definition of non-modifiable and yet is patchable enough to meet the DFSG. I don't think this is a good idea, but it might be the only way to keep the current Emacs etc. manuals in Debian. so it would have to be removed from the manual. Others have (it appears) said the same thing. But yes, the original poster, when he said If the whole docu would be DFSG-free meant that if the Emacs manual were distributed under any Free Software license -- for example the GNU GPL -- Debian would happily distribute it with political statements intact. Having seen a lot of rigid dogmatism here recently, I can hardly expect Debian not to be rigidly dogmatic on this issue too. This discussion has been neither rigid nor dogmatic: Debian has a clearly documented procedure for changing its policies, and you have been invited to initiate it. We have often explained our reasoning to you and other GNU members who asked. We have asked for your reasoning and been rebuffed. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: A possible GFDL compromise: a proposal
Mathieu Roy [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Brian T. Sniffen) a tapoté : Carl Witty [EMAIL PROTECTED] writes: Software is not a controversial word in English (roughly inverse of hardware in one sense). Some people advocate a bizarre definition of it in order to further their agenda. If you're going to define common words just because someone objects to the normal meaning being used, you'll get some bozo that objects to the word social and claims it only applies to the welfare state. That's clearly ungood. Software is a controversial word in English. In an informal survey, two out of two people surveyed (my officemate and myself) agreed that we would not, by default, call an arbitrary collection of bits software (the particular example in the survey question was an MP3 file); but that we would agree to use a different definition of software than the one we are accustomed to in certain contexts. But your question, Is this MP3 file software? is itself biased. Consider the alternatives: 1. Is this MP3 file software or hardware? This is one is definitely worse: you explicitely point out which definition of the word software you think is the most usual, by asking to refer to this definition. Well, yes: I'm being upfront about in which domain I'm placing the question. Simply asking Is this MP3 software? doesn't give any meaningful data, because you can't control for bias on the part of the individual. -Brian
Re: License requirements for DSP binaries?
Florian Weimer [EMAIL PROTECTED] writes: On Tue, Sep 23, 2003 at 08:25:44PM -0400, Nathanael Nerode wrote: 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). So it's okay to ignore the DFSG in this case? That isn't ignoring the DFSG, it's just using the GPL's definition of Source: the preferred form for modification. If I use the Gimp to make an image and delete the intermediate xcf files, the only remaining source forms are the raw inputs and the output. It's important to retain a proper attitude towards this sort of decision: the intent of the humans involves really matters. Whether they really had the source and now don't, and why that is, matters a great deal. It's a very blurry line. Why can't we do that for, say, GFDL manuals? Lack of source is not an issue with the GFDL, non-modifiability is one of several. -Brian
Re: A possible GFDL compromise: a proposal
Richard Stallman [EMAIL PROTECTED] writes: I don't think it needs to be possible to use text from manuals in a program. A manual is free if you can publish modified versions as manuals. 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? You have to be free to publish modified versions of the program as tetris games and news-readers and web browsers, since those are different programs, but a manual is a different kind of thing entirely. It is to much to ask that it should be feasible to conveniently publish a modified version of the program as a manual. But this is done! It *is* feasible to publish a GPL'd work as a manual. It's even more feasible to do what I'm discussing, which is to take a GPL'd manual and derive a program from it. I'm sorry for not making that clear enough in what I wrote originally -- too much rhetoric and too little meaning. So here it is more clearly: I can take a GPL'd text editor, such as GNU Emacs, and derive a tetris game or a news reader or a web browser from it. I can even derive a manual from it. Such a book could be very interesting to read, walking a technically savvy reader through the bulk of Emacs' code. Because the GPL is a copyleft, all of these derivative works will be Free Software. I think the manual will also meet your definition of Free Documentation -- right? I can take a GPL'd manual and derive a program from it -- this part is clear enough that I don't think I need to write more. I cannot take a GFDL'd manual and derive any sort of Free Software program from it. I do not think it is too much to ask that it should be feasible to conveniently publish a modified version of the manual as a Free Software program. The GPL, for instance, does not permit this in a way that is good for publication of books on paper. And yet there are GPL'd books on paper, and their publishers make money from them. Would Harry Potter be a good choice to put under the GPL? No, probably not. Would On Lisp? Well, I'd love to be able to make slides and lecture notes from it... or use some of the big-enough-to-be-copyrightable code snippets. It has significant functional content. The more you talk about this, the more I come to guess that a primary motivation behind the codified, centralized GFDL is the desire to make things convenient for publishers of printed books. Why not provide the manuals for GNU software under a dual license: GNU GPL for those who wish to treat the manuals like software programs, and GNU FDL for those who wish to print books from the manuals. The FSF has sufficient respect that it can, by example and explicit suggestion, convince most people to dual-license their similar works -- and controls the copyright on all of those manuals anyway, so can make sure things are done right at the source. This has all of the benefits of the GFDL for publishers of printed works: they can add their value-add contributions and publish, licensing to their readers only under the GFDL. This has all the benefits of the GPL for publishers and users of software: they can combine the manuals with other work in the Copyleft Commons of the GPL, and can derive Free Software from the manuals. Software programs would probably be distributed only under the GPL, as the GFDL is awfully inconvenient for programs. This has all the benefits of the GPL and the GFDL for the FSF and the Free Software community, as the FSF's example would encourage most people to dual-license their manuals under the GPL and the GFDL. It avoids the problems you alluded to with a conversion clause, which destroys the benefits for publishers. -Brian
Re: Unidentified subject!
Richard Stallman [EMAIL PROTECTED] writes: Your casual suggestion to pick whichever seems better leaves out the object: better for whom? For the Free Software community? For the Free Software Foundation, whose goals are quite different? That is a cheap shot, because it reflects only your decision to be nasty. Excuse me? I've been trying to conduct a polite conversation. I certainly haven't made a decision to be nasty or started taking cheap shots: the FSF's goals are indisputably different from those of the members of the Free Software community. The FSF's goals are its attempt to fulfill the *best interests* of the community -- this is one of the best arguments for the GPL and copyright assignment to the FSF, that it will work towards the long-term interests of Freedom, not for the wants and goals of the current members of the community. I could make the same kind of cheap shot by saying Better for whom? For the Free Software community? Or for Debian, whose goals are quite different? And certainly, Debian's goals are different from those of the FS community: Debian's goals are its users *and* Free Software. I choose not to do this, but others do it to me. You have done this several times in this thread. For example: The Free Software Foundation built the free software community, years before Debian was started, This is at least much of a nasty cheap shot as what I said. And you've done it before. The FSF has done wonderful things for the Free Software community, but it is false to claim it had sole responsibility for the community. (Frankly, I didn't even think about better for whom. I certainly didn't imagine it meant Better for the FSF. In the FSF we avoid these gray areas, so we would never be the ones deciding.) You mean you *ignore* those gray areas. As a reminder, we're talking about gray areas between program and documentation. The emacs manual contains both. TeX is both. The FSF has signed off on both as being Free -- one as documentation alone, the other as software alone. Debian avoids those grey areas by insisting everything be treated as software: it's not a perfect approach, but it gets the abstract philosophy out of the way and gives more time for producing a Free OS. It's the FSF, not Debian, which has chosen to introduce a classification system, separating Software from Documentation. Many of those on this list have asked about your reasons for doing so, and we've never gotten a clear response -- some allusions to convenience for printers, I think, and that's all. But given you've defined this split, and you want Debian to follow your lead in this, it seems only reasonable for you to provide a good guideline... telling us that *we* should pick whichever seems better doesn't help much with that, so your suggestion that Debian permit restrictions on documentation which it would not permit for software is so far unconvincing. Cheap shots like this are another reason why I have decided not to discuss the matter further. Wonderful to hear. Debian's pulled its too-passionate-to-talk-reasonably members off this discussion and sent in cooler heads; who will the FSF be sending to talk to Debian, now that you're too upset to continue? I dare not speak for even all the readers of debian-legal, but I for one am eager to continue discussing this with the FSF. -Brian
Re: Starting to talk
Mathieu Roy [EMAIL PROTECTED] writes: The point is whether every software IN DEBIAN needs to be free. That is indeed the question. I think personally that it is harmful to do so and harmless to let that essays where they are, since they do not interfere with the program and documentation usability. What do you think? Saying it's not DFSG-compliant is not an answer. Sure it is: the DFSG applies to all software in Debian: programs, documentations, and digitized lunchmeat. If you want to change that, get the Social Contract amended, because nobody here can be an honest Developer and intentionally behave in a way contradictory to that Contract. A good way to start that amendment process would be to begin work on construction a set of guidelines for free documentation. I put a bit of work into such on this list -- in late August, I believe -- but stopped when it was clear that I wanted freedoms to modify and such which made the DFSG a good fit. Apart from MJ Ray, which think that any document should follow the Free Software rules, software or not, nobody against the GFDLed text inclusion clearly stated his point of view. People are complaining about this discussion being endless. But they just have to say what they are thinking good or bad for Debian in this case, not just what is their interpretation of a text. Right, in this case -project is maybe a more appropriate place, but it is here where the discussion started. Many, many of us -- Branden Robinson, Nathaniel Nerode, me, Anthony DeRobertis, Peter G. -- have clearly said to you and to Fedor Zuev that we think all software should have to meet the same qualifications to be called Free Software, that the DFSG and the FSF Free Software Definition are both good approximations of those qualifications, and that the Debian OS should contain only Free Software. You haven't wanted to hear that, but from where I'm sitting it's pretty clear. You've also made your position -- that the manuals are useful, and so should be in Debian despite not meeting the DFSG. If you feel strongly enough about that to put work into solving the problem you see -- and you certainly seem willing to put in a bunch of conversation here -- I invite you to propose a set of guidelines for identifying free documents, or to admit that you have no such set of guidelines and merely want useful FSF works included in Debian, regardless of the freedoms these grant Debian's users. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: GPL preamble removal
Nathanael Nerode [EMAIL PROTECTED] writes: Brian T. Sniffen wrote: OK. I have a copy of Emacs here, licensed to me under the GNU GPL2. I have made some modifications to it, and updated the changelogs and history notes. I wish to give it to a friend. Section 2b requires that I distribute my new program, Sniffmacs, under the terms of this License, GPL2. Can I give my friend Sniffmacs, together with the Terms and Conditions section of the GPL, retitled as Sniffen GPL? As far as I can tell, this meets the requirements for creating a new license based on the GPL, and meets the requirements for distributing GPL'd software. Keith Dunwoody wrote: I believe the answer is no. The appropriate part of the GPL is section 2b. Keith is wrong; the appropriate part is actually section 1. ...and give any other recipients of the Program a copy of this License along with the Program. In this context, this License means the unmodified text of the GNU GPL, presumably including the preamble; there really isn't any other interpretation. So you can distrbitute Sniffmacs under the Sniffen GPL, but you have to distribute a copy of the original GNU GPL with it, kind of defeating the purpose... 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? -Brian
Re: What does GFDL do?
Don Armstrong [EMAIL PROTECTED] writes: On Sun, 21 Sep 2003, Richard Stallman wrote: There's a critical difference here. The GPL can accompany the reference card. The invariant material must be in the reference card. I explained months ago, and again last week, why this is not so. I must have missed that explanation. Can you provide a reference to it? From a relatively strict reading of the license, however, I see no indication of a method which you could distribute the reference card with the license and invariant sections not merely accompanying, but affixed. Perhaps you or someone else could walk through and explain the verbiage of the license that allows one to do this? The explanation used in the past was that the license could be in a separate volume of the document: so I could distribute a hardy plastic-coated titanium reference card, and accompany it with a small-print onionskin on which is printed the GFDL and any invariant sections. If I distribute in quantity, of course, I have to include a CD with a transparent format of my work, despite the fact that---since I used Framemaker to design the card---this is not the source and is an awkward position from which to begin producing such a card. [The closest I came was removing a single document from a collection of documents, but then you have to follow the rules applying to verbatim copying, which doesn't seem to grant us anything usefull.] Don Armstrong -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: What does GFDL do?
Richard Stallman [EMAIL PROTECTED] writes: If the GPL were used, it would have to be accompanied by 6 pages of additional invariant material. That is still bigger than the reference card. Do you object to the GPL on these grounds? There's a critical difference here. The GPL can accompany the reference card. The invariant material must be in the reference card. I explained months ago, and again last week, why this is not so. Hunh. Perhaps, if the DRM and Transparent Format issues are resolved, the Emacs Manual can go in Contrib with a dependency on the invariant sections in a separate volume of the document in non-free. Would that satisfy your interpretation of the GFDL? A similar issue has come up recently on -devel[2] regarding single files downloaded out of a tarball or a cvs repository. Hopefully it's clear that making the license available by reference is sufficient to allow people to download single files from a cvs repository. Making the license available by reference does not satisfy the GPL. The GPL must accompany the GPL-covered materials. Access to the program as a collection of files, in such a way that the user might copy just part, is acceptable as long as you do not encourage people to copy less than the whole that includes the GPL. So do you believe that Debian is violating the GPL by not including a copy of the GPL with each GPL-licensed package, but instead having a common-licenses directory containing the GPL on every Debian system? I understand that these are questions with complicated answers, and I appreciate your efforts to answer them. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: PennMUSH license concerns.
Ervin Hearn III [EMAIL PROTECTED] writes: Concern has been expressed on the debian-devel list about license status of PennMUSH and its legitimacy. PennMUSH was relicensed under the Artistic License as of version 1.7.6p0 in November 2002. Aspects of PennMUSH's code have been drawn from, of course, it's TinyMUD roots as well as its 'sibling' codebase, TinyMUSH (2.0, 2.2, 3.0). I spoke with the PennMUSH source maintainer and one of the developers/upstream authors, Alan Schwartz (aka Javelin), about any information regarding how the relicensing was handled and the concerns expressed about it. This is what he said in response: TinyMUSH 2.0, whose authors relicensed all their code in 1995 to a BSD license, so that's clean. We also contacted the TM 2.0 authors (Joseph Traub and Glenn Crocker) and got their agreement anyway. The next bit is TinyMUSH 2.2, which their devteam (Jean Marie Diaz, Lydia Leong, Devin Hooker) all agreed to relicense under Artistic (from 2.2.5, I believe), and I have their email saying so. Then there's the PennMUSH copyright holder (me, Talek, Raevnos), and we all agreed. So Penn's clean. TM 3.0's dev team also switched to Artistic (as did tinymux, I believe) at the same time. I don't know anything about 2.2.4unoff, which we've never incorporated code from to my knowledge. He has also stated that he did track down all authors which followed TinyMUD, which was cleanly licensed under the BSD license, to get their approval, and has emails from them granting permission. I would appreciate any comments regarding whether concerns about PennMUSH's legitimacy under the Artistic License are valid, and legal obstacles for its inclusion as a Debian package. Nice work. It sounds like there are only two minor issues: * First, you *do* mean the Clarified Artistic License, right? The original is a bit of a mess in some parts. * Second, the copyright file should preferably include that whole history, including statements from all the copyright holders relicensing their work. Especially note the difference between You may distribute my work under the CAL and I licence my work to you under the CAL. If the e-mail exchange must be kept confidential, a statement from Mr. Schwartz to this effect and listing the various copyright holders who have given permission will do. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: There was never a chance of a GFDL compromise
Don Armstrong [EMAIL PROTECTED] writes: On Mon, 22 Sep 2003, Richard Stallman wrote: But if they were only removable without being modifiable, then yes, removing them would be the only way to include the accompanying documentation while still ensuring that all bits in Debian guarantee the freedoms that we require. Not long ago, people were trying to reassure me that if invariant sections were removable, nobody would remove them. I guess not. If they[1] did, they spoke erroneously. However, what they almost surely said is that if the sections were DFSG Free, we would (probably) not remove them, and it's likely that we wouldn't modify them either. Indeed -- observe the treatment of the KJV Bible, which many Debian developers disagree with even packaging, but which exists as Free Software in Debian: modifyable by Debian's users. I see no reason to believe the political essays of the FSF would receive worse treatment, were they equally free. This reinforces my conclusion that it is essential for these sections to be unremovable as well as unmodifiable. To serve the ends of GNU, perhaps. But it doesn't seem to serve the needs of the larger Free Software community. More to the point, they are removable from Debian, and are apparently likely to be so removed. Functionally equivalent documentation will be written to replace them, presumably forked from the last DFSG-free manuals. So I find your apparent justification for Invariant political tracts -- that without them being Invariant sections tied to the documentation, they won't get enough air time to promote Free Software -- somewhat confusing. It appears they'd get more exposure, not less, from being Free as in Software. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: A possible GFDL compromise: a proposal
Richard Stallman [EMAIL PROTECTED] writes: I don't think that section titles are a problem--it would not be hard to put them in a program. In a *binary executable* ?!?! That's what I'm talking about here. I am not sure if you are right; this might be impossible or it might be easy. I have never thought about what this requirement means for a binary executable, because the question is not important. I don't think it needs to be possible to use text from manuals in a program. A manual is free if you can publish modified versions as manuals. 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? Many free documentation licenses won't permit use of the text in GPL-covered free programs, and practically speaking, this means I can't use them in any of the programs I might want to use them in. Whether the manual's text could be used in a free software package with a license that qualifies as free software, but is not one I'd want to use, is just academic. Not to Debian it isn't academic: single license conflicts, such as BSD-with-advertising-clause with GNU GPL, happen all the time in the free software world. A *universal* license conflict, such as this, is not something I have ever seen for Free Software. -Brian
Re: Unidentified subject!
Richard Stallman [EMAIL PROTECTED] writes: None of these differences correctly classifies Hello as both a program and documentation, as far as I can tell. Hello is an example program. Yes... and thus both program and documentation. It is difficult to deal with such grey areas and I assume that it requires a case-by-case review. I have never found it difficult. When it's hard to decide, neither choice is really wrong, so pick whichever seems better. TeX is both program and documentation, as are essentially all literate programs. Entries to the various Obfuscated Programming Contests are both program and documentation. These are all gray areas... and more importantly, are members of *both* the set of programs and the set of documentation. So *either* choice is wrong. It is more correct to say that all of these are software (i.e. non-hardware), and we should make sure that all software is free. Your casual suggestion to pick whichever seems better leaves out the object: better for whom? For the Free Software community? For the Free Software Foundation, whose goals are quite different? Debian has to answer: For the Debian Users and for Free Software. -Brian
Re: Unidentified subject!
Anthony DeRobertis [EMAIL PROTECTED] writes: On Friday, Sep 19, 2003, at 19:43 US/Eastern, Brian T. Sniffen wrote: I, um, think he meant me, given I *did* say there is a violation of DFSG 2, since binary-only distribution is not permitted. Ah! Yeah, that must be what I meant... I'm curious: Considering the GPL prohibits binary-only distribution under section 3, do you still hold that position? GPL 3b and 3c deal with that quite nicely. Debian, for example, distributes its GPL'd software by offering the source on the same medium. -Brian
Re: Unidentified subject!
Anthony DeRobertis [EMAIL PROTECTED] writes: On Thursday, Sep 18, 2003, at 11:24 US/Eastern, Brian T. Sniffen wrote: Also, the requirement to distribute a transparent form appears to violate DFSG 2, since it does not permit distribution in source code as well as compiled form. Brian, I'm not sure how that follows. Could you elaborate? AFAICT, the requirement to distribute in transparent, e.g., source, form is quite similar to the requirement from the GPL, version 2, which we all consider free (per DFSG 10, if nothing else). The GPL allows me to distribute *just* a binary, with the requirement that I offer the source as well. It also allows me to offer just source. The GFDL does not allow me to distribute *just* a non-Transparent form. -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: A possible GFDL compromise: a proposal
Mathieu Roy [EMAIL PROTECTED] writes: Josselin Mouette [EMAIL PROTECTED] a tapoté : Le ven 19/09/2003 à 17:39, Mathieu Roy a écrit : However, Debian has a pretty clear definition, according to supposedly Bruce Perens's statements. According to this clear definition, the official Debian Logo should go in non-free. We don't ship the official (jar+swirl) Debian logo in main. If you find it in a package, please report a serious bug against it. Good point. However, does not it mean that Debian recognize that in some case some software (in the large sense) can be non-DFSG and still acceptable? Acceptable for packaging in Debian? No, of course not. Acceptable for other purposes? Sure. I'm a bit puzzled if you are about to claim that you truly _require_ to be able to modify the GNU Manifesto while, at the same time, not giving the right to anyone to print an Official Debian Logo on a tshirt is something completely fine for you. Nobody has suggested that the New York Times make its online edition Free Software, as cool as that would be. Similarly, RMS is within his rights and has a reasonable argument for keeping the GNU Manifesto proprietary, non-free, and closed. I don't agree with it, but it's clearly a point on which reasonable people could disagree. There's no reason to think that such should be packaged by Debian, though. And, finally, if I correctly understood this page, if I get an official Debian CD, with this Logo as cover, I'm not able to provide a copy of this official Debian CD unless I completely follow a process documented at www.debian.org. For instance, if www.debian.org is not available to me (server down, no internet connectivity) and that I forgot the exact process, I'm not legally able to make that copy to a friend with the official logo. Well, it sounds as annoying than being forced to have 3 pages in a manual that anyway nobody is forced to read. And that's funny to claims that this logo is not part of main while it's the cover of the CD containing main. But sure, once printed, it's no longer software (in whatever sense of term). Well, there's an Intel Inside logo on the machine which holds this copy of Debian. The physical packaging is an accident performed on a copy, and a legitimate separate work, much like the covers and dustjackets of books. So in fact, a text/document have to be free only if it's on a computer? Is it the point? No. Debian is committed to distributing free software. Free books and free hardware are somebody else's problem. They all need to be solved eventually, but this one is the problem being addressed right here and right now. If Debian was making hardware (books!) in the future, it would be ok for Debian to provide, itself, along the with CD, proprietary manuals or even the GNU manifesto? At that point, the Social Contract would have been amended to reflect that Debian would no longer be 100% Free Software. It greatly depends on what the new contract said... if it said 100% Free, then no, the licence for the swirl would have to change, and Debian could start publishing books. Is it important to be able to modify a text only when this text is typed on the computer? All the reasons mentioned about how it's important to be able to modify a non technical text in the manual are only valid when the manual is not printed? Of course not. But why does this matter to you? It's very hard to understand for someone that consider computers as just tools. For me, printed or not, a Program must be Free Software, the technical parts of a manual must be Free Software. I quite agree with you. Fortunately, Debian only ships software... It saves time. (PS: I think that the purpose of this non-DFSG logo is perfectly sensible.) -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: A possible GFDL compromise: a proposal
Mathieu Roy [EMAIL PROTECTED] writes: And, finally, if I correctly understood this page, if I get an official Debian CD, with this Logo as cover, I'm not able to provide a copy of this official Debian CD unless I completely follow a process documented at www.debian.org. I forgot one thing: you can copy the data on the CD, but not the packaging art. The packaging art is clearly not software -- it's not even digital -- so this is much less of an issue. -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Unidentified subject!
Brian W. Carver [EMAIL PROTECTED] writes: Anthony DeRobertis writes: I understand that; in fact, I was one of the many people who pointed out that problem. But that's not what Brian said --- he said that there is a violation of DFSG 2 since it does not permit 'distribution in source code as well as compiled form'. That's what I'd like a clarification of. Actually, if you look at my original message again, I was quoting another list member there. I chose to quote him because I wasn't sure I understood what he was talking about either! For further clarification we may have to go back to the original source. (Sounds appropriate given the topic... ;) Brian -- I, um, think he meant me, given I *did* say there is a violation of DFSG 2, since binary-only distribution is not permitted. -Brian
Re: A possible GFDL compromise: a proposal
Richard Stallman [EMAIL PROTECTED] writes: TeX allows us to make any changes we like provided we distribute the changed source as a patch file, and provided we change the name if the result doesn't pass the Trip test. Yes, but my point is that the original TeX source code must be included in the source distribution, and you cannot change it. This is not allowed for a GFDL manual, is it? The GFDL allows you to make any changes you like in the technical substance of the manual, just as the TeX license allows you to make any changes you like in the technical substance of TeX. This is not true. There is no way for me to create a work of free software which is a derivative work of the Emacs Manual. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Unidentified subject!
Richard Stallman [EMAIL PROTECTED] writes: The argument for that is that there are many such manuals and they would be useful to include, and the DFSG can be interpreted to accept it. The arguments appear to be: 1) There are many GFDL manuals. 2) The many GFDL manuals would be useful to include. That's two parts out of the three I mentioned, and the third part is crucial. The DFSG doesn't directly say anything against the requirements of the GFDL. I sent another longer message explaining why. As a matter of fact, it does. The DFSG directly forbids Invariant Sections, which violate DFSG 4: the license restricts even source code (the transparent form) from being distributed in modified form. Additionally, because Invariant Sections must be Secondary, the GFDL's implementation violates DFSG 6. There is *no* work of free software which can be created as a derivative work of a GFDL-licensed manual with invariant sections. Also, the requirement to distribute a transparent form appears to violate DFSG 2, since it does not permit distribution in source code as well as compiled form. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Robinson, Nerode and other free beer zealots was: A possible GFDL compromise
MJ Ray [EMAIL PROTECTED] writes: F On 2003-09-18 01:43:22 +0100 Fedor Zuev [EMAIL PROTECTED] wrote: I am sorry. As I already said, I just can't explain the subject more comprehensible than I already did. So, if you still can't learn the difference between free as speech and free as beer, I have not any cure to help you. One more time, as plainly as can be: I know the difference between those meanings of freedom. I have not seen you provide any references or citations where Robinson, Nerode and other[s] use free/gratis as a reason for the FDL not fulfilling DFSG. Do you have any? Mr. Zuev is using what might be charitably called the Soviet system of freedom, or with harsh accuracy called Orwellian Freedom. In this system, it is alright to prohibit particular behaviors so long as the soul is free. For example, it's OK to prohibit hate speech, because such speech is never useful, and hearing such speech inhibits the free action of others. It's also OK to ban false speech, for similar reasons. This sort of philosophy tends to produce societies of crystal beauty and glassy fragility. There is no tolerance for error on the part of the enforcers, or for creativity beyond that of the lawgivers. The wild, hairy, quarrelsome sort of Freedom which includes the freedom to be wrong, silly, or useless has much greater tolerance for error. Robinson, Nerode, and others -- and count me among them! -- promote this more anarchic sort of Freedom, which is built from a lack of restrictions on individual behavior and a hope that it'll all work out in the end. The FSF has always been about taking freedom from persons to give it to the people -- this is why there have been jokes that the goals of the FSF may not be compatible with those of a free society. In some cases, that's a reasonably good trade to make. The GPL, for example, fails to grant some privileges to recipients of copyrighted works, in exchange for creating a more free society. Though the GFDL behaves similarly, I see a pretty clear line between them: in a world where all works are available under the GPL, everyone will be free. In an all-GFDL world, the mishmash of invariant sections mean that people will still not be free, and we might be further from freedom than we are now. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: A possible GFDL compromise: a proposal
Florian Weimer [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Brian T. Sniffen) writes: The GFDL allows you to make any changes you like in the technical substance of the manual, just as the TeX license allows you to make any changes you like in the technical substance of TeX. This is not true. There is no way for me to create a work of free software which is a derivative work of the Emacs Manual. If it's software, it can easily extract the relevant parts of the manual while it's running. Think of Emacs and its Info viewer. You are countering a point I have not made. First off, software is still software even when it is not executing at the moment -- the pieces of software I am most glad to have are those I rarely run, but use as educational texts themselves: TeX, for example. Second, and perhaps more relevantly, I don't mean Write software which displays the Emacs manual -- I mean software where the creative features of the algorithm depend critically and derive from the Emacs manual, or which links against the Emacs manual. As I said, I want to make a derivative work of the Emacs manual which is Free Software. For example, let's say I want to distribute all the sample code in the Emacs manual as a library of code. There's no way for me to make that library Free Software, by either the FSF's or Debian's definitions. And any work into which I link that library will also not be Free Software. As a second and more contrived example, say I wish to use my new English-to-Elisp Compiler to generate code based on the text of the Emacs manual. Maybe it's good code, maybe it's crap, but I still can't distribute the result as Free Software, only as an opaque form under the GFDL. As a third example, let's switch over to the GDB manual. It has several example runs in it. Let's say I want to use them for a regression-testing suite for GDB. Because they define the test cases, they are essentially code: even if I write a very general regression tester which reads the example pages in -- like the Info viewer in Emacs -- what I'm doing is much more like linking to a program library than displaying text. So that, too, is prohibited by the GFDL. As a fourth example, perhaps I would like to take the Emacs Manual and treat it as a basis for a literate programming work: I will derive from it a work which is both the documentation for my new Sniffmacs editor and the source code. The binary for that program, being a derivative of the Emacs manual, cannot be Free Software: it must be distributed only under the GFDL. All of these are examples of legitimate derivative works of Free Software which cannot be created from GFDL'd works. Notice that none of these are mere issues of license conflict: the only fixed license in here is the GFDL. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: A possible GFDL compromise: a proposal
Richard Stallman [EMAIL PROTECTED] writes: I would appreciate if in future you would restrict you comments to the need for the Invariant sections within the GFDL. The issue at hand for Debian is whether to include GFDL-covered manuals in the Debian GNU/Linux system. I am sticking to that issue. Under the current GFDL 1.2, with the anti-DRM clause, there is essentially no chance of that. So the real issue at hand is the future evolution of the GFDL, and whether it can get to a point where the FSF if happy with its purpose and Debian is happy with its methods. And that disconnection between purpose and methods really is what this is about: the FSF is concerned about getting to a state where all computer programs are free, and is willing to restrict freedoms in the interim to get there. Debian is concerned about acting in a free manner itself, ensuring its users have Free Software, and figuring everybody will eventually come along. If offered GFDL'd software which came with an Invariant section on the evils of free software and the virtues of Shared Source, Debian would reject it. It is a violation of Debian's principles to distribute your invariant sections solely because they come from the FSF or because they express opinions we may like. This appears not to be even a practical impediment to political communication. You will observe, for example, that Debian is among the most well-known GNU/Linux distributions, despite having no advertising budget. It is known for quality, for ease of administration, and for freedom -- even though its political documents, such as the Social Contract and DFSG, are under licenses which allow derivative works and freedom of distribution. Debian haven't even had recommendations from you or the FSF to get this far. Given the combination of both this success at distributing political statements as free software -- with all the same freedoms which are attached to Emacs or Linux -- and that the FSF apparently has never tried distributing its political documents in a free way, nobody here is likely to believe you that it will have bad effects. From the experience seen here, no more people will strip your essays than would anyway, in violation of the license. It is understandable that you are afraid to release your essays as free software, because you fear your competitors will take advantage of this: many companies are afraid to release their programs as free software, because they fear their competitors will take advantage. You've succeeded in convincing people to risk Freedom by example and by argument in the past -- why do those examples and arguments not apply to the GFDL? But now I've drifted off topic. As far as the GFDL and the DFSG: it is essentially impossible that Debian will ship anything with an anti-DRM clause akin to the GFDL. If it were phrased inclusively as You must permit further copying by anyone who can read a copy, that would be fine. The exclusive phrasing currently there, which prohibits any method which inhibits copying, is unacceptably broad and non-free. It is similarly the case that Debian is vanishingly unlikely to distribute invariant political text, excepting only metadata such as the terms and conditions of licenses for Debian's software. To do such would violate Debian's agreement with its users: that they may freely modify any software their receive for their own use. -Brian Additionally, my last several messages to rms or [EMAIL PROTECTED] have been bounced by mx30.gnu.org. Is it not on speaking terms with me, or simply having a bad month?
Re: Software definition, was: A possible GFDL compromise
Mathieu Roy [EMAIL PROTECTED] writes: It's pretty clear. You may claim that the Academie Française and all the French people use a corrupted definition of Logiciel (it's not that the etymology would says). But the French language is made by the French and by the Academie Française. But if they Academie defined some word to be a synonym for both apple and food, they would be unambiguously wrong. Similarly, to define some word as a synonym for both program and software is misinterpreting the *English* language. In English, program carries denotation of executability, while software often but not always carries a connotation of executability, but never has such denotation. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: A possible GFDL compromise
Anthony DeRobertis [EMAIL PROTECTED] writes: On Saturday, Sep 13, 2003, at 03:47 US/Eastern, Andreas Barth wrote: I can't understand why, if (and only if) you interpret this delivery as binary and also deliver the free source code on a free medium, so that everyone can create their own DRM medias as they like. At least for the GPL, I don't think thats allowed. That delivering only on such a medium is not ok according to GPL, is obvious. It's also obvious that such a medium is not nice. GPL 6 doesn't say that you may place restrictions on some copies, as long as your provide an unrestricted copy as well. Instead it says you may place no restrictions. You are being misleading. It actually says in part: 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. [continued] So if I give somebody a DRM binary and an unencumbered copy of the source and build scripts, I'm fine. I don't think you can enforce DRM on GPL software. There are plenty of circumstances where this might be useful: say, a player application and a set of keys. Some not-very-useful keys are in the source, and some very useful keys are on the DRM medium. Alternately, many of the TCPA tools will make good use of this situation. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: A possible GFDL compromise
Anthony DeRobertis [EMAIL PROTECTED] writes: On Monday, Sep 15, 2003, at 12:15 US/Eastern, Brian T. Sniffen wrote: GPL 6 doesn't say that you may place restrictions on some copies, as long as your provide an unrestricted copy as well. Instead it says you may place no restrictions. You are being misleading. It actually says in part: 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. [continued] So if I give somebody a DRM binary and an unencumbered copy of the source and build scripts, I'm fine. Huh? How does that follow? He is unrestricted in his exercise of his rights under the GPL: he can copy the source, modify it for his purposes, and distribute it. I don't think you can enforce DRM on GPL software. There are plenty of circumstances where this might be useful: say, a player application and a set of keys. Some not-very-useful keys are in the source, and some very useful keys are on the DRM medium. I said I don't think you can enforce DRM _on_ GPL software, not _with_ GPL software. That is, you can't enforce you may not copy this, may only run it once, etc. on a GPL program. Actually, you *can* freely enforce restrictions on running the software using technical methods: the act of running the program is not covered by the GPL after all. You need to give people the legal right and technical ability to modify that out of the software, but you don't need to give them the technical ability to run the result. A universal DRM scheme, as promoted by MS for Longhorn+2, would achieve this nicely -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
