Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Sat, Aug 21, 2004 at 01:29:51PM -0400, Brian Thomas Sniffen wrote: Richard Braakman [EMAIL PROTECTED] writes: On Thu, Aug 19, 2004 at 02:09:52PM -0400, Brian Thomas Sniffen wrote: * I can't fork the code, even distributing as patches. There's no way for me to make XEmacs, which is FSF Emacs + code by people who won't transfer copyright to the FSF. This part I find particularly interesting, because I see the freedom to fork as fundamental. I don't understand your reasoning, though. Can you explain what would go wrong if I tried to create an XOcaml? INRIA downloads it and incorporates the neat features into the proprietary version, which they sell to others. How does that stop you from forking the code? Are we using different meanings of fork, perhaps? If I fork a project, I don't mind if the original maintainers then give up their branch and use mine. In fact, it validates my decision. Richard Braakman
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 02:09:52PM -0400, Brian Thomas Sniffen wrote: There were demands that I point at the DFSG, and I did so. Now you want a practical example. Here's some attempts at one: [...] * I can't fork the code, even distributing as patches. There's no way for me to make XEmacs, which is FSF Emacs + code by people who won't transfer copyright to the FSF. This part I find particularly interesting, because I see the freedom to fork as fundamental. I don't understand your reasoning, though. Can you explain what would go wrong if I tried to create an XOcaml? (Note that the source+patches problem itself is addressed by DFSG#4, though obviously not in the way I would like.) Richard Braakman
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Fri, Aug 20, 2004 at 05:20:46PM +1000, Matthew Palmer wrote: On Thu, Aug 19, 2004 at 03:30:13PM +0200, Sven Luther wrote: On Thu, Aug 19, 2004 at 08:19:19AM -0400, Joe Moore wrote: That certainly makes the QPL more attractive to me, as a non-original-author. But I'm afraid I don't understand why any original author would use it. Indeed, so by arguing that way, we could bring this clause to be modified by the upstream author, could we not ? You think that taking the concerns of debian-legal to OCaml upstream would cause you to lose credibility with them, but tricking them into changing the licence by saying the licence means something that it doesn't wouldn't lose you any credibility? Why are you assuming trickery and bad faith? That really sets back your own credibility. Pointing out unintended consequences is a time-honored way of getting authors to change their licenses. That you don't *agree* with Sven's interpretation doesn't mean you get to accuse him of dishonesty. Richard Braakman
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 09:55:26PM -0400, Walter Landry wrote: This is where I disagree. Requiring modifiers to license changes as free for everyone to make proprietary is not free. I don't know of any other licenses in main that have that requirement. OpenSSL, perhaps. It has a BSDish license followed by: * The licence and distribution terms for any publically available version or * derivative of this code cannot be changed. i.e. this code cannot simply be * copied and put under another distribution licence * [including the GNU Public Licence.] Since the license permits binary-only distribution, you have to allow this for derived works you publish as well. Richard Braakman
Re: Proposal for clarification of DFSG.1
On Mon, Nov 03, 2003 at 05:17:06PM +0100, Henning Makholm wrote: In short, we accept you may not sell this program alone clauses, but only if they have loopholes big enough to make them completely ineffective in practice. By the way, I think this phrasing in the DFSG is no accident. It's designed to let the Artistic License pass. The AL says You may not charge a fee for this Package itself and then goes on to give permission for including it in a larger distribution. Richard Braakman
Re: Licensing requirements ???
On Thu, Oct 09, 2003 at 08:03:35PM -0500, Michael D Schleif wrote: Basically, since we are _not_ modifying source to any software, I had always thought that this is a slam-dunk. However, once I read that MySQL page, I have doubts. Am I misinterpreting it? You should be aware that that page misuses the word commercial. Apparently they divide the world into GPL and commercial, and define commercial as: your application is not licensed under GPL or compatible OSI license approved by MySQL AB. This is different from how the rest of the world uses the word commercial. The MySQL page probably assumes that the FSF position is correct, which is that an application that links to a GPLed library is a derived work of that library. They also seem to be claiming that simply using a GPL-compatible license isn't enough; you have to get it approved by MySQL AB too. That part goes farther than the FSF does. If you're dealing with the MySQL libraries specifically, then your options are probably to either take them at their word or ask a copyright lawyer. Richard Braakman
Re: Licensing requirements ???
On Thu, Oct 09, 2003 at 02:01:36PM -0500, Michael D Schleif wrote: Also, in order to manage problems and maintain SLA's, this software is to be sold as an integral piece of a system -- somewhat of a blackbox. In other words, their customers will pay one basic price, and receive an installed hardware server, on which Debian and software are installed turnkey. Hmm, there's one point here that others haven't mentioned yet. The SLAs should not forbid the customers from making modifications to the GPLed software, because that would contradict section 6 (You may not impose any further restrictions on the recipients' exercise of the rights granted herein.). However, the GPL does allow this: You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. You can presumably put whatever conditions you like on that warranty protection, and on whatever service you offer with it. I'm not sure how this interacts with any contracts surrounding the hardware. Would it be okay if you say you can modify the software as much as you like, but you're not allowed to run modified software on this device? I could discuss that for weeks :-) Richard Braakman
Re: Bug#212895: Official Logo is not DFSG Free (with patch)
On Sat, Oct 04, 2003 at 01:39:32AM -0400, Glenn Maynard wrote: People have asked why isn't the official use logo DFSG-free? on d-legal in the past, and there was a resulting discussion. I'm sure it's happened on other lists, too. As far as I remember, the conclusion has always been It should be; we're inappropriately using copyrights to enforce a trademark restriction. We could instead leave the logo unencumbered by copyright, so that people can derive their own logos from it, while enforcing our trademark, so that people aren't allowed to use it to create confusion between their work and ours. Richard Braakman
Re: License review for lsblibchk
On Tue, Sep 30, 2003 at 10:44:38AM -0700, Matt Taggart wrote: +LIBCHK END USER LICENCE+++ BY RETRIEVING THIS DISTRIBUTION OF LIBCHK, YOU ARE CONSENTING TO BE BOUND BY THIS AGREEMENT. IF YOU DO NOT AGREE TO ALL OF THE TERMS OF THIS AGREEMENT, DO NOT INSTALL THE PRODUCT, AND DESTROY YOUR COPY. A false statement followed by a command. That's not exactly what I expect from a license, which is supposed to PERMIT things. Regardless of its enforceability, I don't think we should package this software if its authors firmly believe that a user who types apt-get install libchk thereby agrees to an agreement he hasn't seen yet. They're trying to restrict use as well as distribution. Richard Braakman
Re: solution to GFDL and DSFG problem
On Tue, Sep 30, 2003 at 12:02:21PM -0700, Thomas Bushnell, BSG wrote: It's not level. Esperanto is much easier for those who already know the language. The only level playing field would be to choose a language that *nobody* already speaks fluently. Perhaps, say, Klingon? Nope, Klingon isn't free. Though it might become free if enough people learn the language and then someone writes a new dictionary based on what those people speak. That might be a worthwhile project! :) Richard Braakman
Re: snippets
On Mon, Sep 29, 2003 at 10:01:19AM -0400, Jeremy Hankins wrote: Burden of proof arguments are, at best, very trick to make -- I suggest you not rely on it. Certainly I don't buy it in this case. Unless you can actually point to someplace that says this is current practice, I don't think you have a basis for saying that it is actually a conscious practice at all. Well... you would have to claim that the people who drafted and discussed the Social Contract, and the 90 who voted for it, were unaware of the GNU Manifesto and its presence in the emacs packages. This is an extraordinary claim. The document was, if anything, better known then than it is now (at least if you divide by the size of the free software community). I certainly knew about it long before I got involved with Debian. [practical problems] That doesn't seem too hard. Outdated info is one example already suggested -- out-of-date references to charitable orgs, or addresses, etc. Or what about a case where the snippet is written in the first person, and the project changes hands? It would likely be desirable to rewrite it referring to the original author. In such a case we can always drop it from the package. Rewriting it might be better, but our options are to drop it now or to keep it while it's relevant. Is there any advantage to dropping it _before_ it becomes outdated? Would anyone start to rely on the presence of a particular snippet, for example? Let's split the question in two: * Should snippets be unmodifiable? Does it serve any purpose for the community? There's first the question of whether modifiable snippets are an option. I'd like to have some more examples than the GNU Manifesto and the hypothetical one, actually. Is the emacs etc directory the only source of real snippets? Richard Braakman
Re: snippets
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. I don't see a convincing case here for removing them. -- Richard Braakman There's still time to save Europe from software patents. EuropeSwPatentFree - http://EuropeSwPatentFree.internautas.org
Re: A possible GFDL compromise: a proposal
On Sat, Sep 20, 2003 at 08:32:55PM -0700, Thomas Bushnell, BSG wrote: Richard Stallman [EMAIL PROTECTED] writes: But Debian contains essays, logos, and licenses that cannot be modified. These are not programs; are they software? The essays and logos in question are in fact not part of Debian. I think Richard Stallman was referring to essays such as /usr/share/emacs/21.3/etc/WHY-FREE (emacs21-common 21.3+1-3) Verbatim copying and redistribution is permitted without royalty as long as this notice is preserved; alteration is not permitted. -- Richard Braakman There's still time to save Europe from software patents. EuropeSwPatentFree - http://EuropeSwPatentFree.internautas.org
Re: A possible GFDL compromise: a proposal
On Sun, Sep 21, 2003 at 05:27:39PM +0100, MJ Ray wrote: On 2003-09-21 15:41:02 +0100 Roland Mas [EMAIL PROTECTED] wrote: If by that you mean we should add an explicit We define software as everything non-hardware clause to our policy, then I'll agree with you. The logical conclusion of that process is defining all words in it, then defining all words used in the definitions and so on, which is clearly absurd. No, that's not a logical conclusion. It's a fallacy, specifically the slippery slope fallacy. If we add a definition of software because it is (apparently) subject to different interpretations and a source of controversy, then we can add a definition for just that one word. There's no evidence that all other words in the document lead to such controversy, and no reason to suppose that we'll have to define them too. I invite you to study these pages: http://www.cuyamaca.net/bruce.thompson/Fallacies/slippery.asp http://gncurtis.home.texas.net/slipslop.html http://www.wikipedia.org/wiki/Slippery_slope The first one is particularly relevant because it describes exactly what you're doing here: The Slippery Slope fallacy mimics the pattern of the reductio ad absurdum argument. It postulates the truth of an opponent's position, and then tries to make the case that the opponent's position would lead to unacceptable consequences. The Slippery Slope fallacy is illegitimate, however, because the consequences claimed are not actually logical consequences of the opponent's position. Rather, the opponent's position is connected to the unacceptable consequences by some other means. Sometimes the argument postulates a (usually improbable) causal sequence of events that would lead from the opponent's position being accepted to the unacceptable consequences. Other times the argument turns on a psychological continuum, i.e. that we will slowly become accustomed to things that we currently find unacceptable. (Such psychological continuums do exist, but movement is rarely only in a single direction, so movement to an unacceptable extreme is never inevitable.) -- Richard Braakman There's still time to save Europe from software patents. EuropeSwPatentFree - http://EuropeSwPatentFree.internautas.org
Re: A possible GFDL compromise: a proposal
On Sun, Sep 21, 2003 at 08:52:27AM -0400, Peter S Galbraith wrote: The swirl should be made free, since it's packaged. The bottle has another purpose and is _not_ packaged. Actually, I think both should be free in terms of copyright. We should use trademark law for trademarks, and not try to use copyright for that. We've been telling this to software authors for years :-) Fortunately, SPI is now taking steps to correct this problem, so as far as I'm concerned we're done with it on debian-legal. The procedure for coming up with a trademark license is currently being discussed on debian-project. -- Richard Braakman There's still time to save Europe from software patents. EuropeSwPatentFree - http://EuropeSwPatentFree.internautas.org
Re: A possible GFDL compromise: a proposal
On Fri, Sep 19, 2003 at 11:06:34PM +0200, Mathieu Roy wrote: The GNU Documentation under discussion _is_ in the category of political/philosophical/historical texts. Only these texts can be invariant in the GFDL. Could you explain in what way the Distribution section of the emacs manual is a political/philosophical/historical text? It contains many statements of fact which can easily become outdated and untrue: If you have access to the Internet, you can get the latest distribution version of GNU Emacs by anonymous FTP FTP is on its way out, and might be entirely replaced by HTTP in another decade. You can also order copies of GNU Emacs from the Free Software Foundation on CD-ROM. Presumably this will become on DVD at some point, or some other CD-ROM replacement. I remember when this part talked about tapes. (The Foundation has always received most of its funds in this way.) This can change at one stroke when Bill Gates dies and leaves all his money to the FSF. An order form is included [...] I'm not quoting this one in full because of its length, but it contains a URL and a postal address. Apparently the FSF should never move again. Donations to the Free Software Foundation are tax deductible in the US. This can change at the whims of the IRS. How is any of this political or philosophical? Granted, it may become historical, but that would be a bug and not a feature. Are we going round in circles here? Apparently it was needed to one more time remind which kind of text can be invariant. Indeed. a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) political/philosophical/historical is only part of it, the GFDL also mentions commercial position regarding the subject or related matters, whatever that is. Maybe the postal addresses fall under that category. When you look at which kind of text IS marked invariant in the manuals under discussion, you'll find that the FSF has a much broader idea of Secondary Sections than the one you're using in your arguments. -- Richard Braakman There's still time to save Europe from software patents. EuropeSwPatentFree - http://EuropeSwPatentFree.internautas.org
Re: A possible GFDL compromise
On Sat, Sep 20, 2003 at 12:22:59PM +0900, Fedor Zuev wrote: Discussion, AFAIK, was not about fair use in general (which is very vague concept and yes, in this vague form exists only in US and, maybe, China), but exactly about quotation of small strings from manual in help strings, menu item descriptions and similar objects. That's not quotation, that's re-use. Quotation would be if the help string said The Emacs manual says that this thingamajig will toggle the frobnicator. If you use This thingamajig will toggle the frobnicator directly as the help string then you're not quoting anything, you're re-using some text from the Emacs manual. A single line like this would be too small to matter, but Emacs has thousands of thingamajigs to document. Richard Braakman
Re: A possible GFDL compromise: a proposal
On Sat, Sep 20, 2003 at 06:47:31PM +0200, Mathieu Roy wrote: And you are sure that this phrase is part of an Invariant section? Yes. (2x) When you look at which kind of text IS marked invariant in the manuals under discussion, you'll find that the FSF has a much broader idea of Secondary Sections than the one you're using in your arguments. Can you be more specific? An example perhaps? I gave you one: the Distribution section of the Emacs manual. That's what I was quoting from. Emacs 21.3+1-3, to be precise. -- Richard Braakman There's still time to save Europe from software patents. EuropeSwPatentFree - http://EuropeSwPatentFree.internautas.org
Re: [OT] Re: A possible GFDL compromise: a proposal
On Thu, Sep 18, 2003 at 10:43:08PM -0400, Anthony DeRobertis wrote: On Thu, 2003-09-18 at 20:37, Andrea wrote: Yes, I'm traditionalist. Software is anything that can be treated as a sequence of bits in a computer. Documentation is software. Ham sandwiches aren't. :) ... at least until the replicator is invented. ... and if that happens, we're going to need a Free Food Foundation anyway. -- Richard Braakman There's still time to save Europe from software patents. EuropeSwPatentFree - http://EuropeSwPatentFree.internautas.org
Re: Attribution-ShareAlike License
On Fri, Sep 12, 2003 at 02:18:10PM +0200, Wouter Verhelst wrote: Wouter (who wonders whether his mail about that subject has gone unnoticed on the otherwise so active -legal) I just thought it was far too long. I think that about most new licenses :( Richard Braakman
Re: Some licensing questions regarding celestia
On Mon, Sep 08, 2003 at 07:54:35PM -0700, Don Armstrong wrote: On Mon, 08 Sep 2003, Rick Moen wrote: Moreover, the enforceability of shrinkwrap licences has been heavily contested and is in ongoing doubt, as they have tended to be ruled to be contracts of adhesion (i.e., lacking in meaningful privity of contract). Certainly. But the mere application of the standards of contracts to them is indicative of case law considering them as contracts, which is why I brought those citations up. Um. Shrinkwrap licenses are essentially different from free software licenses, because they RESTRICT rather than PERMIT. You keep ignoring this difference. A contract would be the only way to impose restrictions beyond those specified by copyright law, so the shrinkwrap licensses were examined to see if they qualified as contracts. There's no need to examine the GPL that way. Richard Braakman
Re: A possible GFDL compromise: a proposal
On Tue, Sep 09, 2003 at 04:30:21PM +0200, Andreas Barth wrote: Oh, does Debian have a position on use of Emacs? Sorry, I'm likly going to fail adopting that. It used to have one. The Debian position was that Emacs (along with TeX) was a piece of infrastructure of the Debian operating system. That got edited out of the Policy Manual by nefarious agents. Now the Debian position is that Emacs is not important. Richard Braakman
Re: old and new GNU documentation licenses, and the some of the manuals to which they apply
On Mon, Sep 08, 2003 at 09:11:16AM +0100, Andrew Suffield wrote: On Sun, Sep 07, 2003 at 07:16:51PM -0500, Branden Robinson wrote: * GAWK: The GNU Awk User's Guide; Edition 2, for the 3.0.3 (or later) version of the GNU implementation of AWK. This manual's new license is: Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the Invariant Sections being GNU General Public License, the Front-Cover People who like to bitch about the GPL being non-free take note: *this* time it really is. Contemplate the differences. I also find it hard to bend my mind in such a way that a copy of the GPL is a section that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters). How is this a Secondary Section? (Here's a test: after gawk moves to GPLv3, is it important to keep a copy of the GPLv2 in the documentation? Would you add the GPLv3 as an Invariant Section? If so, why?) Richard Braakman
Re: Some licensing questions regarding celestia
On Sun, Sep 07, 2003 at 01:49:12AM -0700, Don Armstrong wrote: 17 USC 106 (3) lists four ways for a copy to be distributed. 106. Exclusive rights in copyrighted works: Subject to sections 107 through 122, the owner of copyright under this title has the exclusive rights to do and to authorize any of the following: (3) to distribute copies or phonorecords of the copyrighted work to the public by sale or other transfer of ownership, or by rental, lease, or lending; Rental and lending are pretty much out of scope for software, licenses preclude sale, so what we're pretty much only discussing lease of the software, subject to the terms of the license. Um, you missed or other transfer of ownership. The recipient gains ownership of a copy (and sometimes this is an actual sale, where money changes hands), and gets a license to make and distribute further copies under certain conditions. Richard Braakman
Re: old and new GNU documentation licenses, and the some of the manuals to which they apply
On Mon, Sep 08, 2003 at 10:46:33AM -0500, Branden Robinson wrote: You may want to send these questions to RMS. He is not subscribed to -legal, as far as I know. I'm just musing about the issue now :) Eventually I might mail him a big list, pointing out which current Invariant Sections don't seem to be Secondary Sections. I'd like to make it a complete list, though, so that I'll only need his attention once. Richard Braakman
Re: Some licensing questions regarding celestia
On Mon, Sep 08, 2003 at 01:46:35PM -0700, Don Armstrong wrote: On Mon, 08 Sep 2003, Richard Braakman wrote: Um, you missed or other transfer of ownership. I didn't see it being applicable to software licences in general. It looks very general to me, covering all transfers of ownership like it does. The recipient gains ownership of a copy (and sometimes this is an actual sale, where money changes hands), and gets a license to make and distribute further copies under certain conditions. Sure, but we're generally not talking about sale or transfer of ownership in the context of free software licenses, because the license limits what you can do with your copy. That is, I often can't take my copy, modify it, and resell the binary to someone else like I could do with any other tangible copyrighted work. Huh? That's a restriction imposed by copyright law, not by the license. Unless you're talking about a modification-in-place, without making any copies in the process. That's a very rare event when talking about electronic media. Yes, you can draw funny pictures of RMS on the tapes you bought from the FSF, and then resell them. Richard Braakman
Re: easier answer for changing a license of a unmaintained software
On Sat, Sep 06, 2003 at 04:59:13PM -0700, Mark Rafn wrote: Please don't forget the original question: what minimal work must someone do to get an upstream to relicense a work. Yes, and the original answer: get a digitally signed email and don't show it to anyone. We're now discussing why that doesn't work. You need a public statement with many witnesses. Richard Braakman
Re: Bug#181493: SUN RPC code is DFSG-free
On Sun, Sep 07, 2003 at 11:31:19AM -0400, Anthony DeRobertis wrote: Yeah, because there is *no* difference whatsoever between: We're sorry, upstream did not make clear to us the full licensing terms of their software. Now that we have found out, we've fixed it as quickly as possible. and Yeah, upstream didn't tell us before, so we shipped it then and since we did before, we're just going to ignore our principles and ship it for another two years. Hope you don't mind! If you do, either write a free replacement or 'shut the fuck up.' Oh, and there is a legal difference between unknowingly infringing on a copyright and knowingly infringing on one. You do realize that all stable releases are archived? Once a package is out in a stable release, we don't ever stop distributing it. And since this code is already in the current stable release, making a new one with the same code does indeed not intensify the problem. Richard Braakman
Re: Changing a license of a unmaintained software
On Sat, Sep 06, 2003 at 08:54:37PM +0100, Scott James Remnant wrote: Electronic Communications Act 2000 7. - (1) In any legal proceedings- (a) an electronic signature incorporated into or logically associated with a particular electronic communication or particular electronic data, and (b) the certification by any person of such a signature, shall each be admissible in evidence in relation to any question as to the authenticity of the communication or data or as to the integrity of the communication or data. admissible in evidence is not very meaningful if that evidence can immediately be shown to be useless. For example, by demonstrating in court how to forge exactly that signature by downloading the private key from a public archive and using it. Richard Braakman
Re: Inline text not URLs for licenses (was: Re: Is the OSL DFSG free?)
On Wed, Sep 03, 2003 at 01:36:30PM -0400, Anthony DeRobertis wrote: For these reasons, I believe we should ask for license texts, and other relevant, small documents, to be posted inline instead of being linked. I'll add one: it's just much easier to discuss a license when it's there to be quoted from. This seems to be a social effect. In theory it's not much trouble to look up a license text and copy it into your reply, but in practice a text seems to be discussed much more thoroughly if it was posted in the original mail. Richard Braakman
Re: Is the Nokia Open Source License DFSG compliant?
On Mon, Sep 01, 2003 at 10:09:00AM -0400, Walter Landry wrote: 3.2 Availability of Source Code. Any Modification which You create or to which You contribute must be made available in Source Code form under the terms of this License either on the same media as an Executable version or via an accepted ^^ Electronic Distribution Mechanism to anyone to whom you made an Executable version available; and if made available via Electronic Distribution Mechanism, must remain available for at least twelve (12) months after the date it initially became available, or at least six (6) months after a subsequent version of that particular Modification has been made available to such recipients. You are responsible for ensuring that the Source Code version remains available even if the Electronic Distribution Mechanism is maintained by a third party. So if Debian puts the source and binaries up on its ftp site, it is required to keep the source there for at least 12 months, and at least 6 months after a particular version. We can speculate about whether this is DFSG-free or not, but it certainly can't be distributed by Debian. Debian does not keep around the source to all of the old versions for at least six months. This problem is in the MPL too. So far we've been assuming that on the same media also covers FTP sites that host both source and binaries, and that this clause only kicks in if you distribute binary-only versions offline. One thing I haven't thought of before is that, apparently, you *must* supply an Executable version. If you supply only the source then you must keep it available for 6-12 months. That's probably a bug in the wording. Hmm, it also seems that you _must_ publish source code even if you only intend to use a modification privately. None of this might matter because as far as I can tell, 2.1(a) grants enough permissions to render the rest of the license meaningless. I don't think the MPL was ever properly reviewed here :( Richard Braakman
Re: SURVEY: Is the GNU FDL a DFSG-free license?
On Thu, Aug 28, 2003 at 10:47:45PM +0100, MJ Ray wrote: On 2003-08-28 21:51:41 +0100 Wouter Verhelst [EMAIL PROTECTED] wrote: Op do 28-08-2003, om 20:02 schreef MJ Ray: Ye gods! Who knew that software was such a contentious word? Agreed. Perhaps we should... ... Oh, wait. I already suggested we'd do so. ...and I said yes, but you should do it properly and define all the words, just to be on the safe side. Got anything new to say, or is the day stuck again? If someone proposes to go out for a walk because it's such a nice day, do you say yes, but we should do it properly and run a marathon? Richard Braakman
Re: Decision GFDL
On Thu, Aug 28, 2003 at 01:22:10PM -0400, Walter Landry wrote: You do realize that we are distributing GFDL manuals as part of Debian right now? The release manager isn't deciding that any more than anyone else is. If you must point a finger at someone, point it at the package maintainers. The consensus on GFDL'd manuals emerged long after those manuals were put in. The appropriate bugs have been filed, and I would point my finger at the Release Manager for allowing documented release-critical bugs to get into the released version. These bugs are *already* in the released version. The Release Manager would simply be permitting another release which still has them. The alternative would be to delay the release. Delaying a release because of bugs which are already present in the previous version is silly. Users would still be using the previous version during the delay, so they won't be any better off. The package maintainers have a different alternative, namely fixing the bugs. If sarge was releasing a year ago, I would agree with you. There was not the same kind of consensus, and we still had hope that the FSF would see the light. Now there is a strong consensus, and the chance of the FSF seeing the light has been reduced to zero. Moreover, there is still plenty of time to rip out documentation. So, do it. If I understand the schedule right, the deadline is September 15th for gcc (minus testing delay) and October 1st for most of the others (again, minus testing delay). Richard Braakman
Re: A possible GFDL compromise
On Fri, Aug 29, 2003 at 05:44:58PM +0900, Fedor Zuev wrote: For the majority of people outside of this list software is the synonym of computer programs. I do not see any need to change it. If you show such a person a CD with the game Terminus on it, and ask them to describe what's on it, what will they say? First they'll say Terminus, of course, but if you then ask and more generally? I suspect most will say software. I suspect they will NOT say software, manuals, graphics, sound effects, and digitized speech. They'll include all that in software. Richard Braakman
Re: documentation eq software ?
On Fri, Aug 29, 2003 at 08:05:58PM +0200, Mathieu Roy wrote: Please point out which parts of Emacs documentation are invariant. If I'm not mistaking, these parts express some personal feelings. Personals feelings are not something that can be enhanced by someone else. Did you bother to check? The invariant sections are: The GNU Manifesto Distribution GNU GENERAL PUBLIC LICENSE All of these express things other than personal feelings, in many cases things which very obviously may need future changes. For example, both the Distribution section and the GPL contain addresses which have changed before and will probably change again. The Distribution section is completely factual. The GPLv2 is well-known, but will apparently have to be included in the emacs manual forever and ever, even long after emacs itself has moved on to GPLv10. The Manifesto has collected some footnotes over time. Do you still see no potential for enhancement? The FSF is in the privileged position of being able to change these sections when they need to be changed, and they're claiming that no-one else will ever need to. Richard Braakman
Re: A possible GFDL compromise
On Fri, Aug 29, 2003 at 10:29:55AM -0600, paul cannon wrote: Sort of the tentacles of evil thought exercise. This is what I was always worried about when seeing that phrase. Sort of seems like a back door being reserved. Could this even happen? I doubt it. If someone tried it, it could be challenged under GPL lause 9: 9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Since the GPL spends a fair amount of text on explaining the copyleft concept, it's clear that effective-public-domain is not similar in spirit. This would disqualify the GPLv4 from being a revised version under clause 9, and it should be obvious that a license statement that says GPL v2 or any later version means later versions as defined in GPL v2. Richard Braakman
Re: MBSOPPRAPP02 found VIRUS= I-Worm.Sobig.f.txt (Kaspersky) virus
On Fri, Aug 29, 2003 at 03:52:09PM -0700, Maxi Stubbs wrote: This was mailed to me are you saying I have this virus? My virus protection say I do not. I am just concerned, I am getting returned mail of addresses I don't have in my book. Could you help me please? If you're getting such a notice, it generally means this: 1. Someone who has your address in his address book has this virus, known as Sobig.F. 2. This virus spread to the person who sent you the notice. This particular virus spreads via email and always fakes the email headers, and in this case it used your address as the faked sender. 3. The person who sent you the notice is using a broken virus scanner, which sends a scary warning notice to the wrong person, in this case you. (I call the scanner broken, because it managed to recognize the virus as Sobig.F, which is KNOWN to use a fake sender, so it should have known better than to mail you about it.) Note that you're not even involved until step 3, so there's nothing you can do about it except complain to the person in step 2. I get dozens of such notices a day, and I've given up on complaining about them. Your mileage may vary. You're asking debian-legal@lists.debian.org for help, but I doubt this notice was mailed to you from debian-legal. We don't use broken virus scanners. From the mail you quoted: The message is currently Purged. The message, Your details, was sent from [EMAIL PROTECTED] and was discovered in IMC Queues\Inbound located at Reunion.com/REUNION/OPTIMUS. Do you have any idea what IMC Queues or Reunion.com is? They're probably the ones who bothered you. You can examine the headers of the notice you got to see where it came from. (Fortunately, those are generally not faked.) The returned mail you're getting is for the same reason: the virus spreads (from someone else's machine) with your address in its headers, and confused mail servers try to bounce it back to you. Richard Braakman
Re: SURVEY: Is the GNU FDL a DFSG-free license?
On Thu, Aug 28, 2003 at 11:35:16AM +0100, MJ Ray wrote: Why have we another sudden influx of people who haven't read any of the history on this? (Rhetorical. I think we can guess.) I'll answer it anyway: it's because our conclusions are reaching a wider audience, which means we have more people to convince. If you get impatient, I suggest collecting some of the FAQ-like documents that were posted and referenced here (Nathaniel's was pretty good), and turning those into a single document for new people to read. (I'd do it myself if I weren't too lame.) Richard Braakman
Re: A possible GFDL compromise
On Thu, Aug 28, 2003 at 01:55:43PM +0800, [EMAIL PROTECTED] wrote: Heh. I just now realized, that false accusation that GFDL puts additional restrictions to the user is the root of major part of all that anti-GFDL hype. We've been discussing it for years now. I would hardly call that hype. Richard Braakman
Re: GNU FDL makes difference files useless
On Thu, Aug 28, 2003 at 03:22:47AM +0100, Scott James Remnant wrote: the difference is in the trailing whitespace, but that's irrelevant. No, it's relevant. In the section you quote: L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. it says unaltered in their text and in their titles. It says nothing about preserving formatting or markup. Richard Braakman
Re: Decision GFDL
On Thu, Aug 28, 2003 at 03:07:00AM -0400, Walter Landry wrote: Richard Braakman [EMAIL PROTECTED] wrote: On Wed, Aug 27, 2003 at 02:19:06PM -0700, Joe Buck wrote: I don't think the line that there is consensus on debian-legal will wash, unless you overrule the sarge release masters and take the manuals out now. I don't mean to pick on you, I've just seen a number of similar statements. I hope people realize that the release team is saying This is not release critical, and not This is not a bug. I had a terrible time trying to get people to understand the difference, when I was release manager :) I didn't realize that the release manager could decide to ignore the Social Contract if it is inconvenient. A more appropriate way to fix it would be to simply eliminate the documentation. People could then file bugs complaining about the lack of documentation even in non-free, and these bugs may or may not hold up the release. Weirdness. The appropriate reply to what you said is exactly the paragraph that you quoted from me. What am I supposed to say now? You do realize that we are distributing GFDL manuals as part of Debian right now? The release manager isn't deciding that any more than anyone else is. If you must point a finger at someone, point it at the package maintainers. What the release manager has decided is that the release must not be delayed for this issue. I think that's a prudent decision, considering that it's already taken two years and there's no guarantee of a quick resolution. It may or may not be relevant that woody already has some GFDL manuals in it. I can't decide, myself. It does seem silly to consider a bug release-critical if the current stable version of the package has the exact same problem. Richard Braakman
Re: SUN RPC code is DFSG-free
On Wed, Aug 27, 2003 at 03:51:53PM +0200, Henning Makholm wrote: Um, where in the world can *ideas* be copyrightable? Utah :-) Richard Braakman
Re: A possible GFDL compromise
On Wed, Aug 27, 2003 at 03:14:42PM -0500, Branden Robinson wrote: I would only suggest s/text/content/, so that non-texual material (illustrations and so forth) are also unambiguously covered. Hmm. It's a good idea, but I would suggest s/text/document/ instead. content is overused by our enemies, the ones who want to take the products of the human mind and sell then like sausages :) Generic free content freedoms should probably apply to things like musical performance as well, and I don't see these fitting very fell for that. Richard Braakman
Re: Re: Decision GFDL
On Wed, Aug 27, 2003 at 02:19:06PM -0700, Joe Buck wrote: I don't think the line that there is consensus on debian-legal will wash, unless you overrule the sarge release masters and take the manuals out now. I don't mean to pick on you, I've just seen a number of similar statements. I hope people realize that the release team is saying This is not release critical, and not This is not a bug. I had a terrible time trying to get people to understand the difference, when I was release manager :) One thing I'm curious about and which I'm too sleepy to investigate now: were any of these manuals already under the GFDL in woody? Richard Braakman
Re: A possible GFDL compromise
On Mon, Aug 25, 2003 at 01:30:08PM +0200, Jacobo Tarrio wrote: O Luns, 25 de Agosto de 2003 ás 13:35:21 +0900, Fedor Zuev escribÃa: Documentation in not a software. There is no any one-way transformation from the source to the binary. All problems with distribution and modification of documents is a legal, not technical problems. That doesn't matter. To make a derivative of some program, you would normally need some human-readable source code. To make a derivative of a manual (for example, a translation or a summary), you only need the text. But to make a new edition with some spelling errors fixed, you definitely need the source. (I'm not sure what you're trying to say here. Are you claiming that translations and summaries are all you'll want to do with documentation?) Richard Braakman
Re: A possible GFDL compromise
On Sun, Aug 24, 2003 at 06:26:07PM -0400, Nathanael Nerode wrote: In any case, your argument for Invariant Sections applies just as well to programs as it does to manuals! Would you consider a hypothetical program license to be free if it allowed 'off-topic' text which must be present unmodified in source and object code of all derived versions, and must be displayed (perhaps through a command-line option) by every derived program? Maybe you would, in which case you're consistent. I wouldn't. Heh, you choose an interesting example there. c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) Richard Braakman
Re: Freaky copyright laws [was: SUN RPC code is DFSG-free]
On Sun, Aug 24, 2003 at 10:39:02PM -0500, Branden Robinson wrote: I thought basically every place outside the U.S. was like that. Several times when the U.S. Supreme Court decision of _Feist v. Rural Telephone Service Co._ has come up, it's been ridiculed by some Europeans. Can you substantiate that? I don't remember any such ridicule. Richard Braakman
Re: [DISCUSSION] SURVEY: Is the GNU FDL a DFSG-free license?
On Sun, Aug 24, 2003 at 12:39:04AM -0500, John Goerzen wrote: Yet we do routinely apply the DFSG to interpreted scripts where there is *no* differentiation between source code and compiled form. Not really; it's just that the compiled form is often transient. How is this different from documentation? Most people don't read HTML or SGML directly, they use an interpreter. But anyway, documentation is not source code. That is my main quibble. It looks like source code, smells like source code, and behaves like source code. Some documentation is flat text, but usually only if it's very small. Most documentation is provided in source form (html, docbook, TeX, texinfo) and distributed in compiled form (text, ps, pdf, dvi, info, html). Sometimes the source and compiled forms are identical (usually html). Usually the compiled form still needs an interpreter to be useful. So far I don't see any difference between this and programs. We cannot just magically say, well gee, our DFSG only covers things with source code, and this Emacs manual is a thing that we want to apply the DFSG to, therefore it must be source code. That is incorrect reasoning. You must first establish that there is source or compiled work, and *then* apply the guidelines for source or compiled works to it. The Emacs manual has clear source and binary forms. What do you think makeinfo does? If you want to modify it, do you patch the info files or the texinfo files? Richard Braakman
Re: [DISCUSSION] SURVEY: Is the GNU FDL a DFSG-free license?
On Sun, Aug 24, 2003 at 06:22:13PM +0200, Wouter Verhelst wrote: On Sun, Aug 24, 2003 at 03:25:48PM +0300, Richard Braakman wrote: On Sun, Aug 24, 2003 at 12:39:04AM -0500, John Goerzen wrote: Yet we do routinely apply the DFSG to interpreted scripts where there is *no* differentiation between source code and compiled form. Not really; it's just that the compiled form is often transient. How is this different from documentation? Most people don't read HTML or SGML directly, they use an interpreter. The difference being that HTML or SGML *can* be read reasonably easy without an interpreter. While I will accept that there may be people who are able to read a compiled binary by doing something like 'cat /usr/bin/foo', I suspect that most people on this planet are not able to do so. The same is not true for HTML or SGML. I don't understand what analogy you're using here. John Goerzen was comparing documentation to interpreted scripts and I was responding to that. Now you're taking my response and talking about compiled programs. If you want to do that, then the equivalent from the documentation world would be a PDF file. Most people don't read those without an interpreter. (Interpreters of documentation languages are normally called renderers, but the essence of their task is the same. And if you've ever seen a VT100 terminal play Towers of Hanoi, you'll know what I mean.) Richard Braakman
Re: SUN RPC code is DFSG-free
On Sat, Aug 23, 2003 at 06:50:19PM +1000, Anthony Towns wrote: However as it stands, the license passes the DFSG at least as well as, eg, the Artistic license does. I humbly submit that only the GPL and BSD licenses pass the DFSG as well as the Artistic license does. 10. Example Licenses The GPL, BSD, and Artistic licenses are examples of licenses that we consider free. Richard Braakman
Re: SURVEY: Is the GNU FDL a DFSG-free license?
On Thu, Aug 21, 2003 at 12:09:54AM -0500, Branden Robinson wrote: === CUT HERE === Part 1. DFSG-freeness of the GNU Free Documentation License 1.2 Please mark with an X the item that most closely approximates your opinion. Mark only one. [ X ] The GNU Free Documentation License, version 1.2, as published by the Free Software Foundation, is not a license compatible with the Debian Free Software Guidelines. Works under this license would require significant additional permission statements from the copyright holder(s) for a work under this license to be considered Free Software and thus eligible for inclusion in the Debian OS. [ ] The GNU Free Documentation License, version 1.2, as published by the Free Software Foundation, is a license compatible with the Debian Free Software Guidelines. In general, works under this license would require no additional permission statements from the copyright holder(s) for a work under this license to be considered Free Software and thus eligible for inclusion in the Debian OS. [ ] The GNU Free Documentation License, version 1.2, as published by the Free Software Foundation, can be a license compatible with the Debian Free Software Guidelines, but only if certain restrictions stated in the license are not exercised by the copyright holder with respect to a given work. Works under this license will have to be scrutinized on a case-by-case basis for us to determine whether the work can be be considered Free Software and thus eligible for inclusion in the Debian OS. [ ] None of the above statements approximates my opinion. Part 2. Status of Respondent Please mark with an X the following item only if it is true. [ X ] I am a Debian Developer as described in the Debian Constitution as of the date on this survey. === CUT HERE === Richard Braakman pgpK3B0RMd74Y.pgp Description: PGP signature
Re: Is the GNU FDL a DFSG-free license?
On Fri, Aug 22, 2003 at 01:28:29PM +0200, Joerg Wendland wrote: The point is, I think that there are circumstances where having invariant sections are _necessary_. When I am writing a report with a conclusion that contains my very personal opinion, I as the author do not want anybody to change that section, write anything into it that I do not agree with. The readers of that modified version will think it is my opinion they are reading thouhg it is not and may be even contrary to mine. What does that mean? When I am free to say what I want (freedom of speech, one of our highest goals!) I do want to keep to my words and do not want anybody to put words in my mouth I would never say. You skip over the biggest problem with invariant sections, which is that they're not removable. In your scenario, you're requiring everyone who uses any part of your report to also include your very personal opinion about the original version. And here I thought it was very personal :) Why would you require this? Richard Braakman
Re: A possible approach in 'solving' the FDL problem
On Fri, Aug 08, 2003 at 10:38:34AM -0400, Brian T. Sniffen wrote: But now you're telling me it distributes Software, Documentation... anything else in there? Configuration files, templates, icons, menu entries, sound effects, change logs, message catalogs... Sheesh, that's complicated. I used to think that my packages contained just software :) I'll do the Debian Free Menu Entry Guidelines, and I can help with the Debian Free Sound Effect Guidelines. Does anyone want to take some of the others? We have a lot of work ahead. Richard Braakman
Re: A possible approach in 'solving' the FDL problem
On Tue, Aug 12, 2003 at 04:43:41PM -0400, Anthony DeRobertis wrote: Please understand that the readers of -legal have been subject to no less than half a year (or are we at a year now...?) of GFDL discussions, Almost two years now. http://lists.debian.org/debian-legal/2001/debian-legal-200110/msg00126.html Richard Braakman
Re: a minimal copyleft
On Mon, Aug 04, 2003 at 08:49:07PM +0100, Andrew Suffield wrote: This is why, when using the GPL for things which are not clearly program source code, you must always specify what the preferred form for modification is (append it to the license declaration, which should be just below the copyright declaration). Umm, but you should be careful not to make this a part of the license, because then you'd end up with many little twisted GPLs, all different. You can state what you, as the author, consider to be the preferred form. This clarifies the situation and gets everyone on the same page, without interfering with the work's use in situations where the preferred form changes. Richard Braakman
Re: License evaluation sought
On Fri, Aug 01, 2003 at 09:08:37PM +0200, Tore Anderson wrote: may be sold), but using it in things like commercial adventure game collections without asking is just playing dirty. I'm fairly sure that the license does not actually accomplish this. Presumably it refers to clause 3: 3) You may not charge a fee for the game itself. This includes reselling the game as an individual item. However, this is easy to get around by anyone who wants to. Buy this nifty screensaver and get an adventure game FREE! Clause 3 squeaks by as DFSG-free only because it is ineffective :-) I think it would be very hard to write a clause that would forbid selling of adventure game collections, but permit selling Debian distributions which contain lots of adventure games. And even if you manage it, that will make the license non-free. (Well, more non-free.) Given how little real difference there is between the cases I named, it might be worthwhile to find out what the author finds objectionable about commercial adventure game collections. It might be possible to isolate just that. Is he assuming that all such collections will be binary-only, for example? Richard Braakman
Re: Additional restriction to LGPL
On Wed, Jul 30, 2003 at 08:58:02PM +0100, Neil McGovern wrote: [Big snip, I'll keep the two statements for contrast] If you modify this library, you have to make sure that the powered by HAWHAW copyright link below the display area is kept unchanged. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. http://www.gnu.org/copyleft/lgpl.html Any ideas if this is allowed or not? That depends primarily on whether HAWHAW includes LGPLed code from other sources. I'm not going to go into it in depth here (so I hope that other debian-legal denizens will also respond :), but I have a few questions and comments. 1. Is this display area a copy of the work? That depends on what the library does. 1a. If the library is modified to such an extent that it no longer has a display area, what should happen? (Again, depends on what it does, but I can imagine taking a couple of functions from it for use in some other library.) 2. The requirement to keep a specific notice text and link unchanged and in a specific place is much stronger than You must give prominent notice. 2a. Is this requirement intended as an extra license clause? In that case the work is not compatible with the normal LGPL, and the authors must be careful not to share code. They also can't apply extra license clauses if they inherited code that doesn't have that clause. 2b. Is this requirement intended merely as a clarification? In that case I think it fails to clarify, and it would be better to quote the LGPL directly, or say that the LGPL requires such a notice and the Powered by HAWHAW link meets that requirement. 3. From Debian's perspective, if this is an extra license clause, does that make the package non-free? Note that we've discussed a similar clause in PHP-Nuke, but that one referenced the GPL, clause 2c, so the issues are different. Richard Braakman
Re: translations under Creative Commons license?
On Wed, Jul 30, 2003 at 05:58:52PM -0400, Michael D. Crawford wrote: So, are you suggesting that freedom would be better served if the GNU manifesto provided for modification? Note the manifesto's license: Careful. You're likely to get your thread hooked into a discussion that's been going on for about three years now. Don't go there unless you really mean it. Suppose the Manifesto were a free document. That would allow Microsoft's PR flacks to update the Manifesto to exhort the user to protect corporate rights to intellectual property, and illustrate how respecting End User License Agreements stimulates not only the nation's, but the world's economy. If Microsoft wished to create a Corporate Domination Manifesto, should they not be free to re-use parts of the GNU Manifesto? If Microsoft wished to create an incompatible variant of C, should they not be free to re-use parts of gcc? In both cases, the end products would be free, but the effect is undesirable. In both cases, you can worry about the potential harm of allowing such bad usage, or anticipate the potential benefit of allowing good usage. Why would you make a different decision for a manifesto than for a compiler? Note: If you're worrying about Microsoft creating a corporate domination manifesto and *calling* it The GNU Manifesto, then you should be aware that you can't stop them with copyright law. They're free to write one and call it that. All you can do is stop them from re-using parts of the real GNU Manifesto if they do that -- and that doesn't take a non-free license, since you can just require that derived works be given a different name. I'm aiming to do the same thing with music, and I don't want the record industry to put words in my mouth. Neither do I want to allow that of people who might be well meaning but incompetent. You sound a bit like the author of qmail :-) He's concerned about what well-meaning but incompetent people might do with his software, too. Richard Braakman
Re: Advice on Drip (ITP #156287)
On Mon, Jul 28, 2003 at 11:38:37PM +, Robert Millan wrote: Such support is, however, disabled in this package because enabling it would violate the DMCA and possibly other laws. Is this a claim we want to make? I thought it hadn't been settled yet. Richard Braakman
Re: Bug#156287: Advice on Drip (ITP #156287)
On Wed, Jul 30, 2003 at 01:49:48AM +, Robert Millan wrote: (A) is primarily designed or produced for the purpose of circumventing a technological measure that effectively controls access to a work protected under this title; I've always wondered what effectively means here. Since you can create an exact, working duplicate of a DVD without breaking CSS, does it effectively control access? Richard Braakman
Re: Implied vs. explicit copyright
On Thu, Jul 24, 2003 at 03:43:19PM +0200, Henning Makholm wrote: [...] I still think it would be hard for the defendant to convince a court that he was ignorant of the *de facto* convention that people put (c) in computer programs to assert their copyright. Actually, the convention is Copyright (c), which meets the requirements anyway because of the explicit Copyright. I've never seen anyone put (c) by itself without the Copyright. (This is also why I'm wondering why this is being argued about at all. Just write Copyright (c) or just Copyright and be done with it. If you really want to save keystrokes and write just (c), then don't come crying to me if you don't get punitive damages :-) Richard Braakman
Re: migrating away from the FDL
On Sun, Jul 20, 2003 at 08:06:51PM +0200, Wouter Verhelst wrote: Op zo 20-07-2003, om 13:06 schreef Andrew Suffield: A monarchy is an autocracy where (under normal circumstances) the monarch inherits their role, usually by blood relation or marriage. Well, seen the fact that RMS has always been the 'chief' of the FSF, this is still possible ;-) Not in the usual way, since RMS has promised not to reproduce. But he could still do the Roman thing and adopt an heir. Richard Braakman
Re: GFDL - status?
On Sun, Jul 13, 2003 at 03:59:00PM -, MJ Ray wrote: You disagree that the documentation part of a GFDL-covered work is acceptably licensed? Yes. It is encumbered with invariant sections. That clearly doesn't meet DFSG#3, and it doesn't qualify for the exception in DFSG#4. I do not talk about the work as a whole, which seems clearly not to be. If it were _possible_ to just ignore the invariant sections when considering the documentation, then we wouldn't be having this discussion. Their stickiness is precisely the problem, since it encumbers documentation that would otherwise be free. Related points that I consider interesting and relevant to what happens next are: is there any legal basis for distinguishing programs from other literary works? There seems to be; several European laws make specific exceptions for computer programs. They don't define computer program, as far as I know. From other electronically stored works? What about fonts? Encoding tables? Is DFSG sufficiently general? If it's electronically (YM digitally?) stored, then I say it's software. I see no reason to make this word a synonym for computer programs, and in practice I see people refer to a large variety of digitally stored data as software. (For example, does the MirrorMagic package contain software, documentation, sounds and graphics? Or is the whole thing just software?) Richard Braakman
Re: Defining 'preferred form for making modifications'
On Sun, Jun 15, 2003 at 10:41:24PM -0700, Thomas Bushnell, BSG wrote: Richard Braakman [EMAIL PROTECTED] writes: On Sun, Jun 15, 2003 at 05:15:14PM -0400, Sam Hartman wrote: Why? What real-world problem does this solve? Have we actually run into situations where it was not obvious in a particular instance what the preferred form for modifications was? I know of one thorny problem in this area: many graphics are distributed as .png or .jpg files, even though their creator probably used a richer format like .xcf. Is it not obvious that the preferred form is .xcf? It is preferred, but does that make the other formats non-free? Often the .xcf is simply not available anymore, not even to the creator. The strength of the preference for it depends on the complexity of the image and on the exact format (lossy jpeg? blurred png? reduced palette?). It's an area where reasonable people might disagree. There are also variations in usefulness of a .xcf file. Does it have all the layers still separate, or have some of them been merged and smoothed? Combining those layers into the final image is often part of the creative process and is usually not automated. At least, not the way I do it :) Richard Braakman
Re: Defining 'preferred form for making modifications'
On Sun, Jun 15, 2003 at 05:15:14PM -0400, Sam Hartman wrote: Why? What real-world problem does this solve? Have we actually run into situations where it was not obvious in a particular instance what the preferred form for modifications was? I know of one thorny problem in this area: many graphics are distributed as .png or .jpg files, even though their creator probably used a richer format like .xcf. IIRC, there was also a case of a ROM image that was released into the public domain, but the source for it no longer existed. I don't remember enough details to search for it, though. Richard Braakman
Re: A single unified license
On Sat, Jun 14, 2003 at 01:31:05AM -0400, Anthony DeRobertis wrote: On Fri, 2003-06-13 at 22:02, Walter Landry wrote: d) Accompany it with information as to how to obtain, for a charge no more than the cost of physically performing source distribution, corresponding source. (This alternative is allowed only for noncommercial distribution) Looks quite a bit like (b). I think the key difference is that (d) does not require the distributor to make any kind of commitment. It would be acceptable to say Here's a Debian CD. You can find corresponding sources at http://debian.org/;. That's a lot easier than Here's a Debian CD. And here's my solemn promise to provide source CDs for this Debian version to anyone who asks for the next three years. Please wait while I go buy a CD burner. (Note that 2(c) is not an option here because Debian doesn't use 2(b).) I think 2(d) reflects what people already do in practice. It may even dispel some of the misinformation and misunderstanding surrounding the GPL, by making it clear that this alternative is NOT allowed for commercial distribution. Richard Braakman
Re: GDB manual
On Tue, May 27, 2003 at 08:45:41AM -0400, Richard Stallman wrote: To call a program or a manual non-free is a serious accusation, and it needs more grounds than inconvenience alone. I think this is a fundamental difference between the way you evaluate freedom and the way Debian does. Debian sometimes sees licenses with clauses like these: Send me a postcard if you like this software. If you distribute this software, you must pet a cat. You may modify this software, but all bugfixes must be sent to the author. All of these are fairly minor restrictions on use, distribution, or modification, but Debian has uniformly classified them as non-free. This is done for both practical and moral reasons. Practical, because while a restriction might be minor in the context of one package, it is difficult to deal with an archive of 1 packages that all might have different little restrictions. Moral, because there is no clear line between suffering an inconvenience and paying a price. (Consider that sending a postcard costs money.) There is also the hard-to-classify reason that any inconvenience can have unforeseen consequences. For example, someone who is allergic to cats will have a hard time complying with the second license, which is probably not something the author has thought about. Now, just to see if we're on the same page: do you consider clauses like the one above to be inconvenience alone, or reasons to consider a license non-free? Do you distinguish between the examples? (I deliberately chose one for use, one for distribution, and one for modification). The invariant section is a requirement on packaging of modified versions of the technical material, and that is an area where tolerance is called for. I think Debian agrees with that area of tolerance. For example, many licenses require specific attribution or changelog activity when a modified version is prepared, and that is not seen as a problem. In fact, DFSG#4 allows a considerable amount of inconvenience there, though DFSG#4 is controversial. (It's the one that allows licenses to require that all modifications be distributed as original source plus diffs.) However, I see a distinction in kind between that area and what the GFDL requires. The GFDL's restrictions mostly apply to the finished product which the user sees and interacts with, rather than (like the GPL) applying mostly to accompanying materials. This makes them much more like functional restrictions in my view. There's a somewhat similar situation in software, namely a license which says You may modify the software, but you must retain the part that puts an advertisement for the author in its user interface. Debian has also considered those to be non-free, though a similar requirement to put an advertisement in accompanying materials (such as the BSD license required) was accepted. Richard Braakman
Re: GDB manual
On Sat, May 24, 2003 at 07:19:33PM -0400, Richard Stallman wrote: It addresses the issue that was raised here before. Someone said that the GDB manual had marked a section invariant which was not secondary. As indeed it had. A Sample GDB Session (among others) was marked Invariant. The issue was raised here in december 2001. Thomas Bushnell then brought it to your attention: I asked RMS about the GDB manual. It has two invariant sections, one of which is a where to obtain GDB section; the other is an introductory tutorial to using GDB. I asked RMS why the latter of these needed to be invariant. He replied that it shouldn't be invariant and he'll ask the relevant maintainer to fix it. (15 Dec 2001, Thomas Bushnell, http://lists.debian.org/debian-legal/2001/debian-legal-200112/msg00394.html) A few weeks later it was fixed: RMS reports that a new upstream GDB release has been made (5.1.0.1) which fixes the copyright problem on the GDB manuals. I've filed an RC bug against the gdb package urging an upgrade. (14 Jan 2002, Thomas Bushnell, http://lists.debian.org/debian-legal/2002/debian-legal-200201/msg00227.html) (I'm skipping over the resolution of the Stabs Types and Stabs Sections Invariant sections in the gdbint manual, which were fixed in the same time frame.) I'm surprised that you have forgotten. Richard Braakman
Re: The debate on Invariant sections (long)
On Mon, May 19, 2003 at 10:54:36AM -0400, Richard Stallman wrote: You raised one point that I am concerned about: * Debugging with GDB; GDB version 5 May 2000[1] [1] This manual is an interesting case because it started out with no invariant sections at all, but later adopted the GNU FDL and marked non-Secondary Sections as Invariant[3], which RMS said was not permitted[4]. I will investigate this, and if a non-Secondary section has indeed been marked as invariant, I will make sure that is corrected. To forestall confusion... This has already been investigated and corrected. The GDB manual used to have A Sample GDB Session marked Invariant, and the stabs manual which accompanied it had Stabs Types and Stabs Sections marked Invariant. This was brought to the FSF's attention (including yours, I thought!) during our previous round of discussion about the GFDL, and was corrected soon afterward. Richard Braakman
Re: new-maintainer vs patents.
On Tue, May 20, 2003 at 03:16:19AM -0500, Branden Robinson wrote: On Mon, May 19, 2003 at 12:56:38PM -0400, Joey Hess wrote: Who is Branden supposed to send the royalty checks for patent #4,197,590 to again? (That's the XOR cursor patent.) Huh? What? XOR cursor? What's that? I haven't read the patent (legalese gives me headaches), but I know that XOR is an abbreviation for eXclusive Overwrite Rights, a variant of DRM. It enforces an author's moral rights by not allowing non-approved cursor shapes to be used to point at protected intellectual property. When a user moves a cursor over a window containing protected content, the display manager sends the cursor shape to microsoft^W the content vendor's representative for inspection, and disallows the motion until it receives approval. This way, serious documentaries are protected from being seen with banana-shaped cursors hovering over them, and similar abuses of the content provider's reputation and artistic integrity. To the best of my knowledge, the X server still lacks this important functionality. Hint: do not reply to this message. :-P Huh? What? -- Richard Braakman to troll, v.: to explore, in an electronic forum, the subtle distinction between being an idiot and pretending to be an idiot.
Re: LPPL and non-discrimination
On Thu, May 08, 2003 at 11:35:07AM +0200, Henning Makholm wrote: Uh... does Covered Code include modifications that third parties make? If so, then we have a problem. 1.3. Covered Code means the Original Code or Modifications or the combination of the Original Code and Modifications, in each case including portions thereof. (Note that this came up during the initial discussions about the NPL; I don't know if those discussions were held on debian-legal, though.) It might not be a very big problem. The NPL is per-file, not per-program. I checked some files in mozilla looking for NPL-licensed ones, and all the ones I found were triple-licensed NPL/GPL/LGPL. I didn't do the scripting work needed for a thorough scan, though. Richard Braakman
Re: LPPL and non-discrimination
On Wed, May 07, 2003 at 09:52:46AM -0400, Peter S Galbraith wrote: Didn't the QPL used to have this exact feature? It was considered free at the time, wasn't it? The NPL (Netscape Public License; parts of Mozilla still use it) has this feature. Check out part V of the Additional Terms: V. Use of Modifications and Covered Code by Initial Developer. V.1. In General. The obligations of Section 3 apply to Netscape, except to the extent specified in this Amendment, Section V.2 and V.3. V.2. Other Products. Netscape may include Covered Code in products other than the Netscape's Branded Code which are released by Netscape during the two (2) years following the release date of the Original Code, without such additional products becoming subject to the terms of this License, and may license such additional products on different terms from those contained in this License. V.3. Alternative Licensing. Netscape may license the Source Code of Netscape's Branded Code, including Modifications incorporated therein, without such Netscape Branded Code becoming subject to the terms of this License, and may license such Netscape Branded Code on different terms from those contained in this License. (The Section 3 referred to in V.1 is about distribution of modified versions; it also contains the copyleft clauses.) The NPL makes me want to add a License must not be overly verbose clause to the DFSG... Richard Braakman
Re: GFDL Freeness and Cover Texts
On Fri, May 02, 2003 at 12:20:04AM -0400, Michael D. Crawford wrote: I don't have any invariant sections in any of them, but each of them specifies a brief back cover text: This contains material from the Linux Quality Database at http://linuxquality.sunsite.dk;. Is that a problem? It might become a problem if your site ever moves. I think this is what Walter meant with cover texts that are misleading. Fortunately, unlike with Invariant Sections, at least *you* have authority to change the cover text. That doesn't help if you can no longer be contacted, though. People do drop off the net sometimes :) Also, while I have your attention, I would also like to say that I would welcome any translations of these articles to other languages. The Open Source Development Lab has already translated the two kernel testing articles to Japanese. In that case, if you do go with the GFDL, you should use version 1.2. Version 1.1 is problematic with translations. Richard Braakman
Re: [OT] Droit d'auteur vs. free software?
On Fri, May 02, 2003 at 05:48:23PM +0200, Henning Makholm wrote: Stupidity does not create rights. (Opposite in some other parts of the world where one can become rich simply by being too stupid to imagine that coffee might be hot). Can we put this legend to rest? I realize this is off-topic, but I hate seeing such claims go unrefuted. 1. The coffee in question was *much* hotter than coffee is normally served. It was far too hot to be drinkable, which is not something you'd expect. 2. The lady in question didn't deliberately spill coffee over herself because she thought it wouldn't be hot. She accidentally squeezed the mug while trying to get the lid off. This has nothing to do with stupidity. 3. If the coffee had been at normal temperature, she would have gotten some blisters and an embarrassing memory. Instead, she got third-degree burns and needed reconstructive surgery. 4. The corporation that served the coffee was aware that the temperature was a problem, and had quietly settled 700 burn claims in the previous decade. 5. All she initially asked for was enough money to pay for the medical bills. The jury awarded punitive damages because they considered the corporation to be willfully putting its customers at risk. The Association of Trial Lawyers of America has a page about the case: http://www.atlanet.org/consumermediaresources/tier3/press_room/facts/frivolous/McdonaldsCoffeecase.aspx Richard Braakman
Re: various opinions on Debian vs the GFDL
On Wed, Apr 30, 2003 at 06:26:07PM +0200, Henning Makholm wrote: Scripsit Stephane Bortzmeyer [EMAIL PROTECTED] Is it a consensus on debian-legal that a GFDL work *without* any Invariant or Cover is indeed free and has no problem being distributed in main? I believe so. There is some fudging about the precise definition of opaque and transparent formats, but I'm not aware that anyone thinks they would be showstoppers in and of themselves. Actually, I do. I hope this is just a bug in the license that the FSF is willing to rectify, though. The definition of a Transparent copy is so implementation-specific that a sound file can never be part of a GFDLed document. I think this is a significant restriction on modification. Richard Braakman
Re: VisualBoyAdvance license
On Thu, Apr 24, 2003 at 09:29:14PM +, [EMAIL PROTECTED] wrote: From the license: Permission to use, copy and distribute VisualBoyAdvance in binary form, for non-commercial purposes, is hereby granted without fee, providing that this license information and copyright notice appear with all copies. See the COPYING file for the GNU Public License that also affects this program. These conditions directly contradict the GNU General Public License, which is presumably the one they mean. So the big question is, in what way does it affect the program? Do they mean that this program is dual-licensed, under both the GPL and this paragraph? In that case the program is free software and it can go into Debian. Or do they mean that *both* licenses must be satisfied? In that case the license statement is contradictory, because the GPL doesn't allow imposing a non-commercial purposes requirement. We can't distribute that software at all. I think this paragraph makes the dual-license possibility unlikely: VisualBoyAdvance is freeware for PERSONAL USE only. Commercial users should seek permission of the copyright holders first. I downloaded their source[1] and poked around in it looking for copyright statements. Most of the files have Copyrigh(c) 1999-2002 Forgotten ([EMAIL PROTECTED]) and a GPL license blurb. This makes it somewhat strange that there's a completely different license in COPYRIGHT.TXT with the same name on it. [1] http://belnet.dl.sourceforge.net/sourceforge/vba/VisualBoyAdvance-1.5-src.tar.gz My best guess of the situation is that this Forgotten person put his code under the GPL without realizing that this conflicted with the Snes9x license that was on the code he was adding to. Files like src/tvmode.cpp have both the Forgotten GPL blurb and the incompatible Snes9x license at the top. More disturbing is the file src/win32/wavwrite.cpp, which has the GPL blurb followed by this: //- // File: WavWrite.cpp // // Desc: Wave file support for loading and playing Wave files using DirectSound // buffers. // // Copyright (c) 1999 Microsoft Corp. All rights reserved. //- I think we shouldn't get anywhere NEAR this package until it's had a careful license review. Richard Braakman
Re: query from Georg Greve of GNU about Debian's opinion of the F DL
On Wed, Apr 16, 2003 at 10:52:55AM +0200, Georg C. F. Greve wrote: The GFDL offers the users and distributors such as Debian a higher degree of legal security, however, as someone who has not used the possible measure of invariant section will have a much harder time suing for violation of his or her moral rights than someone using a license that didn't offer such measures. I find this argument unconvincing, for two reasons. First, Invariant sections don't actually accomplish this. Only Secondary Sections can be marked Invariant. Other sections, i.e. the meat of the document, cannot be so marked under the GFDL. Therefore, using the GFDL says nothing about the author's claims to moral rights on the majority of the document. Second, documentation is often just as functional as the programs it describes, and this goes both ways. Consider TeX, where the documentation and the code were created as a single work. Consider also how protective Donald Knuth has been of TeX's rendering algorithms. I don't see why the code-part-of-TeX should be treated under entirely different rules than the book-part-of-TeX, and I don't see how you could seriously claim that there are no aesthetic components to the way TeX lays out documents. I don't see this critical difference that makes Invariant Sections necessary for documentation but leaves the GPL just fine for code. Richard Braakman
Re: Proposed statement wrt GNU FDL
than English are poorly supported The GNU FDL defines special roles for several kinds of sections (such as History and Dedications), but refers to these sections by their names in English. A document under the GNU FDL will have to include a section with the title History, regardless of the language it's written in. [...] 4) Update the GNU FDL to allow the removal of unmodifiable sections. This should probably be Convince the FSF to update ...? Otherwise it's strange to include it in a list of things the reader can do. It took me a while to work out what you meant. While this does not prevent documents covered by the GNU FDL being non-free, it allows you to extract the non-free components from the document, leaving just the juicy DFSG-free goodness. s/extract/remove/ here. Extract implies that the non-free components are the ones you keep. Open Questions ~~ We want to do a FAQ as well. Should the documentation = software thing be justified there? How about the practical examples we have? What other practical examples are there? I'd say yes and yes. The justification can be done by practical examples. (For example, the emacs manual being part of the emacs interface, literate programs, and rendering code embedded in documents and fonts). Examples I've seen so far: Wikipedia / FOLDOC controversy Emacs reference card What are we going to do about all the documentation with clearly non-free licenses, or that lack clear licenses? This seems to include things like the Debian Manifesto, that's part of doc-debian. Frankly, I wouldn't mind distributing a nonmodifiable GNU Manifesto (as part of the emacs package or even in doc-debian) as long as it's not bolted to something useful like the emacs manual. Do we really want to recommend Creative Commons Licenses? They've very long and legalistic -- even the do what you want, but keep my name license is disgustingly complicated, to the point where it's not obviously DFSG-free. I don't think we should recommend those, since we don't have any experience with them yet. I also think that free software licenses should be comprensible to programmers in order to be useful; by the same token, free documentation licenses should be comprehensible to technical writers. What else needs to be covered? Why Invariant Sections Are Bad :) - The problem of excerpts - People can hijack documents by modifying them and then adding Invariant Sections that the original author finds unpalatable. From that point on, they can use the original author's improvements, but not the reverse. This creates exactly the kind of one-way wall that copyleft is supposed to prevent. (If you're happy with this, you might as well use the MIT license.) - Invariant Sections can become outdated, and there's no way to update them. Even adding a note saying they're obsolete is not allowed. We also need a point-by-point rebuttal of the FSF's response page about the GFDL feedback, but that's not something I'm going to think about today. Richard Braakman
Re: query from Georg Greve of GNU about Debian's opinion of the F DL
On Wed, Apr 16, 2003 at 01:59:37PM -0400, Peter S Galbraith wrote: If the manifesto marked as invariant? I didn't know that! It doesn't seem to be in the visible info text, but the top of each of the info files has a GFDL blurb. I grepped for Invariant in my emacs-21 info files. The main manual lists The GNU Manifesto, Distribution and GNU GENERAL PUBLIC LICENSE as Invariant Sections. There are also some smaller manuals that list none. That's 930 lines of material, about 46 kB. Richard Braakman
Re: motion to take action on the unhappy GNU FDL issue
On Wed, Apr 16, 2003 at 03:09:17PM -0500, Branden Robinson wrote: I propose that we: * draft a comprehensive critique of the GNU FDL 1.2, detailing section-by-section our problems with the license (Branden, didn't you construct such a critique a while ago? I remember reading one.) * draft a FAQ regarding why we differ with FSF orthodoxy on this issue * draft a document advising users of the GNU FDL how to add riders to their license terms such that works so licensed are DFSG-free, and pointing out alternative documentation licenses that are also DFSG-free Then: * exhaustively identify works in main and contrib using the GNU FDL[1] * contact[2] the package maintainers and upstream authors of each affected source package, and include pointers to the above documents * post a list of affected packages to debian-devel-announce and/or debian-announce, so that no one is surprised by whatever later actions occur * give people some time to consider and act upon the above contact (some may relicense, some will tell us to go pound sand, others won't reply at all) * remove packages from main and contrib whose licenses have not been brought into compliance with the DFSG I second this proposal, with the addition that I wouldn't be opposed to passing a General Resolution at some point before any removals. This is the stuff of which nasty flamewars and misspelled Slashdot headlines are made, hence my unwillingness to do it, but it is clear to me that letting this issue languish in ambiguity isn't good for us or our users. Indeed. In fact, I now have the impression that the FSF was waiting for us to come up with an official statement, while we were waiting for a response from the FSF. The first three steps of your proposal seem to be a good way to resolve that. I think it's also time to get the rest of the project involved. I expect that a lot of people who don't ordinarily care about license details will suddenly become interested when packages like glibc-doc are affected. This probably means all of the issues will be rehashed on debian-devel, so it will be good to have such a FAQ available. (I'm not advocating this rehashing, I'm just speaking from past experience :) Richard Braakman
Re: Revised LaTeX Project Public License (LPPL)
On Thu, Apr 03, 2003 at 02:59:07PM -0800, Walter Landry wrote: Henning Makholm [EMAIL PROTECTED] wrote: But does that possibility make the original software non-free? Your argument seems to be that it is possible to make a derived version that is not free - but that possiblity exists for, say, the BSD license as well. The difference is that you be putting your modifications under a different license. Here, you're not changing the license, you're just modifying the code. I don't know how it relates to the argument at hand, but I think the possibility exists under the BSD license: simply take the source and run it through an obfuscator before distributing it[1]. We wouldn't consider the resulting package to be free, but no license changes were made. It's even possible for outsiders to reconstruct an approximation of the original source code and thus make it free again. I think this has some similarity to the possibility of removing the no-validation option, and undoing such a change will be even easier than restoring obfuscated source. Richard Braakman [1] When I saw the code for the BSD glob() function, I suspected that this has already happened.
Re: Dissident versus ASP
On Tue, Mar 18, 2003 at 10:34:35AM +1000, Anthony Towns wrote: Huh? It seems meaningless to me: if you employ some people to work on your program, you put them under NDA so that they agree not to disclose the source code; if you work with other groups, you do likewise to them. The license would forbid this, just like the GPL's clause 6 would. If necessary, you do the NDAing at arm's length, something like: A changes the program E employs B under a contract that they don't distribute the program or its source, etc E asks A to give B a copy of the program A gives B a copy of the program This would leave A free to distribute the modifications. E isn't covered by the program's license since he never has anything to do with it. I don't think it would be remotely reasonable or enforcable (or in line with giving people more free software) to somehow stop A from giving the program to B, or to stop B from being able to give copies to people who E approves of. If the program were GPLed, it _would_ stop B from being able to give copies to anyone unless the copies were unrestricted. This doesn't seem to be a problem in practice, though IIRC it collided with US export restrictions at some point. I think the end result of your scenario is that only B is restricted. Richard Braakman
Re: Dissident versus ASP
On Mon, Mar 17, 2003 at 07:30:44PM +1000, Anthony Towns wrote: [ASP condition] You should never be forced to give your source changes (and/or rights to use/modify them) to people who merely use your program (but don't already receive copies). Hmm, I wonder if this could be softened so that it _in practice_ has the same effect, but does not put a burden on anyone. This would be similar to the GPL's approach to charging high prices: it's allowed, but in practice it doesn't become a problem because of the GPL's other effects. I'm thinking of a license that extends the proposed DMCA-subversion clauses, in such a way that everyone who has access to the source also has permission to copy it. Then, if you add something similar to GPL's clause 6 (You may not impose any further restrictions...), you get the effect that a network service that uses this software can only keep its modifications secret if all the developers involved agree to keep them secret. This will work for single developers and small groups, as well as for highly motivated groups (such as dissidents who risk their lives if the modifications are published), but rapidly becomes unstable for large groups and corporations. There are two factors that work against this scheme: - The no further restrictions clause would have to butt heads with confidentiality agreements in employment contracts. This may make it unusable in practice. Also, a restriction such as We'll fire you if you publish this code is not necessarily written down anywhere, but could be effective just the same. - If a company makes a lot of money from its service, then this could make even a large group of developers highly motivated to keep the source secret. This assumes that the profit is shared with these developers :) IIRC, similar cases have occurred with the GPL, where all the customers of a software development company decide that it's in their best interest not to publish the software that they paid good money for. Still, an approach like this might slip past Anthony's assumptions and close the ASP loophole indirectly. Richard Braakman
Re: QPL clause 3 is not DFSG-free
On Mon, Mar 17, 2003 at 02:29:12PM +0100, Henning Makholm wrote: [...] because it prevents me from making modifications without granting everyone the right to take them proprietary. However, it is hard to pin this kind of unfreedom to a specific point in the DFSG. Wouldn't this principle also make the OpenSSL license non-free? If you distribute modifications to OpenSSL, you have to allow your recipients to distribute your contributions in binary-only form. I don't think there's any unfreedom involved here. All viral licenses impose some sort of restriction on how you can license derived works (and in fact, some BSD folks argue that this makes all of them unfree). The GPL, the QPL, the NPL, the OpenSSL license, and your sample license all have this property, and it seems strange to me that you would declare the more _permissive_ ones unfree. If the GPL had a loophole (let's call it ASP :-) that made it possible to make GPLed programs proprietary, would it then become unfree according to this principle? Richard Braakman
Re: OSD DFSG - different purposes - constructive suggestion!
On Tue, Mar 11, 2003 at 06:31:05PM +1000, Anthony Towns wrote: On Mon, Mar 10, 2003 at 09:15:22PM -0800, Thomas Bushnell, BSG wrote: We already reject (1), (2), and (3). Why is (4) suddenly not rejected as onerous? Because it's not onerous if someone else covers your costs. In the same way You must give me your sources at cost if you give me your binaries isn't onerous. Actually, I think the GPL would have serious problems if it didn't have 3(a). Having to keep the source around for three years would be a significant burden. What keeps the GPL free is that you have the option to offer sources and binaries together and be done with it, even if the recipient elects to take only the binaries. So yes, You must give me your sources at cost if you give me your binaries is onerous. Richard Braakman
Re: lzw patent search (fwd)
On Tue, Mar 11, 2003 at 09:31:07AM -0600, Drew Scott Daniels wrote: Hmm, did they just tell me that there were other patents to scare me? Maybe they meant the IBM patent on LZW :-) Have you seen http://cloanto.com/users/mcb/19950127giflzw.html ? (The GIF Controversy: A Software Developer's Perspective) It has a paragraph about this. Apparently LZW has been patented multiple times, a tribute to the skill and thoroughness of the patent office. Richard Braakman
Re: PHP-Nuke: A calling for votes
On Mon, Mar 10, 2003 at 08:55:24AM -0800, Mark Rafn wrote: I disagree with #1 and #2. And, in fact, I belive that the PHPNuke author's interpretation of GPL 2c is so bizarre that it's not actually GPL-licensed software anymore. Actually, it's possible that the author is not interpreting GPL 2(c) at all. At least, I haven't seen him refer to it. He just states that the footer is required. We have? Many of us don't like 2c, but I haven't seen anyone claim that the common interpretation is unfree. *raises hand* I won't say it's non-free in Debian's sense, but it's one of the reasons I no longer use the GPL on my own work. (Sorry, David, I told you earlier that 2(a) was the reason, but in discussions here I found others...) I like it even less now that someone pointed out that 2(c) automatically kicks in when code from noninteractive programs is added to (or modified to) interactive programs. Until I saw that, I thought that I could ignore it for my own programs just by not making them emit such a notice. The reason I don't like it is that such a requirement can really get in the way when making programs usable in a low-bandwidth or tiny-display environment. And both those qualities tend to occur together when dealing with handheld devices. And since programs often need to be specialized for such an environment, that then becomes the most ordinary way of running the specialized version. My rule of thumb is that if you ever find yourself in a situation where the technically ideal solution is blocked by software licensing, then you're not dealing with free software. This is my version of freedom 0. (You could always get around software licensing by reimplementing the software in question... but that's why I don't consider it free software.) The GPL skirts the edge of this: for example, the requirement to distribute source is ok because you can include a written offer if there's no room for the source. (Even this has its problems, though. If you're launching an interplanetary probe that uses GPLed software, do you have include a source CD? Or carve the offer into the probe's hull? Every byte might count. I'd go for the offer, and hope that Martians will request the source so that we can make them pay for the next probe.) I think 2(a) and 2(c) go over the edge. For 2(a), there are file formats where it's difficult to add a change history. People seem to deal with that by ignoring it. For 2(c), there are situations where there's significant cost to displaying the notice. Sorry for the length, this started out as a short note and then I wanted to explain myself :) No, in the meantime PHPNuke should be moved to non-free, as it is not free based on the author's statements of interpretation. I'd further claim that it's not GPL-compatible, as there are many pieces of GPL software that it cannot be combined with and maintain the page footer requirement. Note that PHP-Nuke inherited its code from an earlier GPLed project. Richard Braakman
Re: PHP-Nuke: A calling for votes
On Sun, Mar 09, 2003 at 07:16:07PM +0100, Hugo Espuny wrote: As after trying (yeah!, i mean trying, because is to hard to extract conclusions from such a very large thread) I don't get a clear idea of what you legal gurus think about this matter, i 'm asking you for vote accordingly with your feelings in this matter, so you help me to make my decision as i am not legal guru. No better moment as now we are in elections time :-) Note that this is not so much a legal question as a question of software freedom. The only legal argument that would apply would go like this: 1. The GPL is DFSG-free by definition 2. The author is interpreting GPL 2(c) in a legally valid way 3. Therefore, the condition is also DFSG-free I think that even if step 2 were correct (and I don't see how it could be extended all the way to there must be a footer on every page), then step 3 would become Therefore, we have found a bug in the GPL. This is because I think the question of freedom overrides the text of the GPL. You don't have to be a legal guru to have an opinion about software freedom :) 2) What you can vote: just one of the next options, just once by person. a) Move it to non-free b) Stay at main c) I don't know I think it should be moved to non-free if you're willing to maintain it there, and otherwise removed completely. Richard Braakman
Re: PHP-Nuke: A calling for votes
On Sun, Mar 09, 2003 at 05:27:54PM -0500, Glenn Maynard wrote: Also--a more concrete question--is it safe to distribute (even in non-free) programs which have upstream authors asserting broken interpretations of their license terms? In this case, probably not. I just examined phpnuke's CREDITS file, and grepped around a bit for 'Copyright', and it seems to contain a lot of code copyrighted by other people, and it was based on Thatware, a GPLed project with a long list of contributors. Richard Braakman
Re: OSD DFSG - different purposes - constructive suggestion!
On Sat, Mar 08, 2003 at 07:46:18PM -0700, Barak Pearlmutter wrote: I've edited that nascent DFSG FAQ and put it at http://www-bcl.cs.unm.edu/~bap/dfsg-faq.html I'd appreciate comments. It seems a bit eager about the GPL. I'd much prefer if it gave equal time to the GPL and the BSD camps. Better yet, recommend the two licenses without trying to summarize them (people ARE supposed to read licenses before applying them, after all!), and just state the advantages of using standard licenses: they're better understood by the community, they've been written by actual lawyers, people don't have to spend time figuring them out before using the program or helping with development, and they make it easier to share code between your project and others. Richard Braakman
Re: OSD DFSG - different purposes
On Fri, Mar 07, 2003 at 11:02:41AM -0600, Ean Schuessler wrote: I don't want to quibble over semantics, but I don't think the meanings are as you suggest. The difference in meaning between guideline and definition would seem to be one of accuracy or rigorousness. For Debian's purposes I would say that our guideline is used much more like a definition. I can't see many conditions where we would waive *any* of the guideline's premises. It's tests, and our demand of compliance, is rigid and unforgiving. I think the distinction is in the other direction. What do we do with a license that meets the DFSG in every detail, but is still non-free? Debian would refuse such a license. I asked Russell Nelson what OSI would do in such a case, but I never received an answer. Richard Braakman
Re: PHPNuke license
On Wed, Mar 05, 2003 at 01:50:49PM -0600, Steve Langasek wrote: I'm not sure you've answered the question I meant to ask. Let me try to rephrase: if debian-legal finds that such a requirement from upstream is a legitimate clarification of the GPL (rather than an additional restriction imposed on top of the GPL), do you think it's appropriate for debian-legal to reject a piece of GPL software whose author imposes this restriction, given that the GPL is explicitly grandfathered into the DFSG? You say grandfathered a lot :) I don't agree that DFSG#10 is a grandfather clause. It clearly lists those licenses as *examples* of free licenses, not as exceptions to the earlier guidelines. In effect, it tells us that an interpretation of the DFSG that would rule out the GPL is probably wrong. (However, I think the Artistic License was added to that list by mistake. IIRC, perl is distributed under a dual license because Ian Murdock asked for that, in order to be able to distribute perl as part of Debian. This predates both the DFSG and my involvement with Debian, though, so I don't know the details.) I can't answer your actual question yet, I'll have to think about it some more. In particular, I'd like to see your hypothetical actually resolved one way or another, and then we can look at the arguments that resolved it and see how far they go. I think it is always appropriate to assume the license on a piece of software is exactly what the copyright holder states that it is; if nothing else, this avoids unnecessary lawsuits. If the GPL is involved, we should also make sure that the copyright holder isn't mixing the creatively-GPL code with real GPL code from other sources. Richard Braakman
Re: PHPNuke license
On Thu, Mar 06, 2003 at 04:26:08PM -0800, Thomas Bushnell, BSG wrote: Here's a disastrous consequence. [...] In this context (but not directly on-topic), I'd like to tell about a little service we had running at Wapit, where I worked on Kannel[1]. It was a limited facility for web browsing via SMS. You'd send it a message like www debian.org and it would fetch http://debian.org/, strip out all the tags, and send the contents back to you, in the form of one or more SMS messages. There was a limit of 9 messages for one page, I think. (Example of actual use: you're trying to go to a party, but you've forgotten the route and the host's contact information. You know the host's nickname, however, so you can find their homepage at iki.fi.) Over here an SMS message can only hold 140 bytes, usually holding 160 7-bit characters. If you want more, you have to send more of them, and generally pay for each one. The typical GPL blurb would use up a whole message, costing money (probably around $0.05) and annoying the user. There's lots of other things you can do with SMS, and probably all of them are more useful than this :) We thought of a service for randomly selecting a restaurant to go to with a group of friends, based on various parameters. Other companies have implemented various games, which are definitely interactive. There's a service for particpitating in IRC-like chatting systems, where users use SMS to send and an idle TV channel to read. I think it's clear that the GPL 2(c) requirement is a real problem in such contexts, and the Affero send the whole source requirement is completely impossible. I'll stop here, before I write several more pages about WAP (which uses HTTP directly), and browsing with small-screen low-bandwidth PDAs :-) I think that the GPL 2(c) and proposed 2(d) requirements create significant technical problems in some contexts, and that for that reason they make the software less free. Richard Braakman [1] Kannel is a free WAP and SMS gateway. See http://www.kannel.org/
Re: [Discussioni] OSD DFSG convergence
On Wed, Mar 05, 2003 at 05:08:08AM -0500, Simon Law wrote: I always thought that the FSF's (and RMS's) Four Freedoms were always the basis of the DFSG. I merely thought that the DFSG exists to codify these concepts and make them more concrete. Sort of like a checklist so we don't forget anything. I think the DFSG actually predates the FSF's codification of the Four Freedoms. However, my memory of events from the previous century is somewhat unreliable. What might be a useful thing to do is start adding appendices to the DFSG with examples of how we have interpreted certain sections. (With valid, and invalid arguments in each.) It should be made very clear that these examples are merely to clarify the opinions of debian-legal, and are in no way binding. Indeed. I would welcome such a document, though so far I have not had the energy to create one. It will also be a useful source of inspiration when we get around to proposing changes to the DFSG. Richard Braakman
Re: CLUEBAT: copyrights, infringement, violations, and legality
On Sun, Feb 02, 2003 at 03:44:47PM -0500, Branden Robinson wrote: On Thu, Jan 30, 2003 at 10:30:38AM -0500, Bob Hilliard wrote: Euclid lived and worked in a Greek culture, under Greek laws. The apostles lived and wrote in predominantly Greek cultures, under Roman Laws. I think you're missing my point. If copyrights are natural rights, then ancient Greeks and Romans who authored creative works had those rights irrespective of whether recognition of those rights was codified in the laws governing them. I think I can give a useful example here: the ancient Greeks and Romans also kept slaves. Doing so was acceptable according to their culture and laws, but we still think it was wrong. The difference is precisely that we consider freedom to be a natural right, while copyright is not. Richard Braakman
Re: CLUEBAT: copyrights, infringement, violations, and legality
On Mon, Feb 03, 2003 at 11:49:58AM +1300, Nick Phillips wrote: So, a natural right is whatever is considered a right according to whatever happen to be the morals of the dominant society of the age, whereas the other type of right is whatever is considered a right (or convenient, or profitable...) according to the laws of the dominant society of the age? ;) No, you forgot the crucial distinction between this age and that age :-) Richard Braakman
Re: ImageJ 2 :(
On Thu, Jan 30, 2003 at 04:30:34PM -0500, David Turner wrote: The ImageJ website is at NIH, as is the author's email address. So, it's probably a US Government work, and therefore public domain. Well... public domain in the USA. This has come up on debian-legal before, but I can't find it now. IIRC, the specifics are that the US government can not claim copyright under US law, but this would not prevent them from claiming it in other jurisdictions. Thus, it would be good to get the license clarified anyway. Richard Braakman
Re: Bug#176267: ITP: mplayer -- Mplayer is a full-featured audioand video player for UN*X like systems
On Thu, Jan 30, 2003 at 07:35:49PM -0500, David Turner wrote: Per-project changelogs have always been considered to be compliant with (2)(a) -- nothink says the markings must be in the files themselves. That's news to me. I even asked RMS about it and he said he'd have to think about it. This was a few years ago and I never heard back, so I figured he was still thinking. (This was in the context of suggestions for GPLv3.) So you think that an entry in a separate changelog counts as to carry prominent notices? What do you base that on? Carrying is generally done by the carrier, and I note that GPL 2a specifically refers to the modified files, where everywhere else it speaks of modified work or modified program. Richard Braakman
Re: OSD DFSG convergence
On Mon, Jan 27, 2003 at 02:18:10PM -0500, Russell Nelson wrote: Free Redistribution The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale. Nothing in this prevents a license from requiring click-wrap. [...] Derived Works The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. Nothing in this prevents a license from requiring click-wrap. You can modify the software as much as you want. When you distribute the software, the terms of the license require that you acquire affirmative agreement with the license. Same terms. I think you're trying to have it both ways here. If the license stipulates a need to acquire affirmative agreement with the license as a condition of distribution, then that's a restriction on giving away the software. If the license allows free distribution but specifies that the software must acquire this agreement when it's run, then that's a restriction on distribution of derived works. In other words, a click-wrap license may be able to meet these guidelines individually, but not both at once. Richard Braakman
Re: Bug#176267: ITP: mplayer -- Mplayer is a full-featured audioand video player for UN*X like systems
On Wed, Jan 29, 2003 at 03:43:24AM -0500, Don Armstrong wrote: I'm sure you've read about the libmpeg2 problems I found after 5 minutes of looking through the code.[2] As far as I am aware, they still haven't been fixed. Obviously, if after such a short bit of searching, that such a problem can be found brings a strong suspicion that there are other problems lurking within the codebase. I think you use the wrong example here. That part of the GPL is widely ignored in favour of per-project changelogs. (This is why I no longer use the GPL on my own code, btw.) As an indicator of licensing irregularities it's pretty much useless. Whoever takes it upon themselves to package mplayer for possible inclusion in Debian will most likely have to: 1) convince debian-legal that they have audited the codebase and determined that everything in the codebase is legal for Debian and it's distributors to distribute. I haven't dug up the relevant history, but I gather that it had been claimed before that mplayer's copyright licenses were okay when they weren't. If this is indeed the case, then this is a reasonable requirement. 2) inform debian-legal (and/or the DD's in general) about any patents that mplayer may or may not be infringing upon so an informed decision can be made. I don't think that this is reasonable. Are you prepared to do the same for gcc? It's not possible to be sure that _any_ program is unencumbered by patents. We can only respond to patent threats as and when we become aware of them. Richard Braakman
