Re: The Show So Far
On Tue, Mar 11, 2003 at 09:10:28PM -0500, David Turner wrote: Someone already answered the google question for you -- it saves you the 20k on a Google Search Appliance for your intranet. That's akin to someone releasing the source of a neat, self-contained algorithm from an application. I can use it in my own programs, and improve other, unrelated things with it, or learn from it, or critique it. But it doesn't let me improve the application that it's from at all, since I don't have its source. Likewise, Google releasing source might have lots of other benefits, but it doesn't let me improve Google in any way, and I believe those other benefits are peripheral. Now, we seem to have two related but distinct cases: Google and BarInterface. In the case of Google, their releasing source simply doesn't let me improve Google--period. There's nothing that can be done about this. This applies to most web apps, since the fundamental reason most web apps are web apps is either a) the server takes a lot of resources to run (Google), or b) the server connects a bunch of people together (eg. an IRC server). (case 1) In the case of BarInterface, it *may* be reasonable to run a separate copy of the server on my own system, with my enhancements. This is just about always the case when the example is something that was once a standalone application, and has been converted to ASP/RFC (eg. your GCC example). This is probably the more feared case of this--that someone will take my source, improve it, offer its use via ASP and not let anyone have the source; the fear that it's a means to get around having to give away your improvements. (case 2) I'd say case 2 is the only one that can be reasonably called a loophole, and is the one Thomas is claiming simply isn't a problem. As I said above, I think it's fundamentally impossible to fix #1; releasing source to Google looks neat, but while it shares some nice side effects with releasing GCC's source, it doesn't let me (the user of the program--for the sake of discussion) improve the program (www.google.com), which is the primary, fundamental goal. I do think these two cases should be considered independently. The provide the source to users of a webpage discussion revolves around #1, which I think is distinct, and doesn't help #2 at all. -- Glenn Maynard
Re: the FSF's definition of Free Software and its value for Debian
On Tue, Mar 11, 2003 at 09:50:06PM -0500, David Turner wrote: Each time you distribute the Document (or any work based on the Document), you grant to the recipient and all third parties that receive copies indirectly through the recipient the authority to gain access to the work by descrambling a scrambled work, decrypting an encrypted work, or otherwise avoiding, bypassing, removing, deactivating, or impairing a technological measure effectively controlling access to a work. This, I like--a big DMCA waiver. -- Glenn Maynard
Re: The Affero license
On Tue, Mar 11, 2003 at 10:10:04PM -0500, David Turner wrote: The GPL is finally showing cracks after 14 years (12 for v2). I don't think any license could work for 95 years (assuming no future CTEAs). So, that's why there's the upgrade option. I've always seen the upgrade clause as ensuring that the license is upwards-compatible (so we don't have the OpenSSL contact every upstream author deal come about when GPLv3 comes about), with this bit being handy but very secondary. -- Glenn Maynard
Re: The Show So Far
On Tue, Mar 11, 2003 at 05:30:04PM -0800, Thomas Bushnell, BSG wrote: If this code fragment were then added to a GPL'd program, and distributed, with the intention that people would run it and thus link it with rmi.bar.com's non-free code, in order to produce a program without source, then the result is that the GPL (as it stands *now*) is violated, just as much as if rmi.bar.com distributed an ordinary .so. The argument is that //rmi.bar.com/Bar is a GPL'd program, and this java application (under whatever license; say BSD) makes use of it. Now, it seems clear that this application is, in fact, linking to Bar. What's not clear is distribution: it seems that Bar is never actually being distributed to the user of this application. Since the binary is never distributed, the GPL's source requirements never kick in. Hence the ASP loophole: you can take a program licensed under the GPL, pound it into this type of interface, and you no longer have to distribute anything at all for people to use it. The GPL is dependent on distribution in order for people to be able to get the source. The quine requirement seems like an awful hack to fix this problem, though, for reasons already discussed. -- Glenn Maynard
Re: Barriers to an ASP loophole closure
On Tue, Mar 11, 2003 at 10:53:13PM -0500, David Turner wrote: The GPL places lots of obligations on people in the interests of preserving people's freedom. Placing obligations isn't equivalent to reducing freedom (though they often coincide, and we should be skeptical about obligations that don't preserve freedom). It seems that you both are claiming that licensing the code under the GPL places greater obligations on recipients of the code than not doing so. This is inaccurate -- in the absence of the GPL license, there's no right to distribute source or binaries (modulo fair use, of course). With the GPL, there is. So, distributees can either choose to go with what they had (no right to distribute), or go with something which gives more rights. How this amounts to an obligation is a mystery to me. No, I'm not saying that. Saying you must provide source if you provide binaries is clearly an obligation. However, it's an obligation that is generally agreed to enhance freedom in general, not restrict it (at least as it's implemented in the GPL). It has a cost associated with it, but it's a cost that most of us (at least among the GPL crowd, less so the BSD crowd) agree is worth the freedom it generates. Placing software under the GPL places far more obligations on the recipients than placing it under the 3-clause BSD license, which places a few more obligations than placing it in the public domain (which, as far as I know, places none). This was most directly disagreeing with: That, in itself, makes a good argument for why the author should have no ability to place an obligation on anybody under a Free Software license. -- Glenn Maynard
Re: PHP-Nuke: A calling for votes
GPL, not GLP. (I assumed it was a typo before, but you're consistently spelling it incorrectly.) On Mon, Mar 10, 2003 at 10:15:56AM +0100, [EMAIL PROTECTED] wrote: So now, we can discuss the rest of the matter. But keep in mind the precedent point, please. Could you repeat what the precendent point is? I missed it. (inserted important but omitted quotes) Richard Braakman wrotes: 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 That's my point of view. We have judge Mr.F.Burzi and found him guilty. But he is legally innocent. We have decided this way due to our moral conception of free software. We already have found a bug on GLP, as Richard pointed before. So we need a new version of GLP (at least something positive coming out from this flame). That's just a possible argument; there's no consensus on these points. Most directly, there's no consensus on #2. The opposite, actually; I don't recall seeing anyone actually asserting that this interpretation of the GPL is correct at all. (David, could we get a position on the must attach GPL blurb to every output page interpretation from the FSF, so we can resolve this question?) If #2 is incorrect (and the interpretation is simply bogus), then there are lots of problems (as he's apparently not the sole copyright holder) and the package should probably not be in non-free, either. If it's unclear, and the author is simply stretching the definition in a non-free way, then we want to discourage that interpretation. (However, this is a social reason not to distribute it, not a legal one, and I'd just hope that you're feeling responsible. :) If it's unclear, or if it is, in fact, a reasonable interpretation, then you're probably right in that there's a license bug, too, but we aren't there yet. (#1 is also questionable, but that's a tangent that's been discussed recently--search recent archives for grandfather--so I won't go there.) But in the meantime phpnuke should have the right to stay in main, as it it technically GLP compilant, we liked or not. No software has any right to be in main to begin with. -- Glenn Maynard
Re: PHPNuke license
On Mon, Mar 10, 2003 at 08:54:15AM -0600, John Goerzen wrote: In any case, the user of the software already has rights under fair use to modify it, before even agreeing to the license. http://lists.debian.org/debian-legal/2002/debian-legal-200204/msg00039.html -- Glenn Maynard
Re: OSD DFSG - different purposes - constructive suggestion!
On Mon, Mar 10, 2003 at 11:23:26AM -0500, Brian T. Sniffen wrote: Convince me that in this imperfect world, as we try to make things more transparent, and give people more control and access over the software that affects them, that being able to get access to the sourcecode for www.wherever.com whether they want me to or not is a *bad* thing. * There's less incentive to develop new changes: unless you can afford a stable of developers large enough to deploy new features faster than your competitors can copy them, you gain no competitive advantage from innovation. Software gets developed only to scratch personal itches. This sure sounds like a (poor) argument against open source in general. -- Glenn Maynard
Re: OSD DFSG - different purposes - constructive suggestion!
On Mon, Mar 10, 2003 at 01:37:54PM -0500, Brian T. Sniffen wrote: * There's less incentive to develop new changes: unless you can afford a stable of developers large enough to deploy new features faster than your competitors can copy them, you gain no competitive advantage from innovation. Software gets developed only to scratch personal itches. This sure sounds like a (poor) argument against open source in general. Not at all. Open-source is great for infrastructure software -- Linux, Apache, Emacs. Many companies have private modifications to Linux or Apache which they use internally; some of these get released, some don't. Everybody benefits by contributing to the common good. For example, several network infrastructure companies use Linux on their embedded devices, release kernel changes and improvements, and keep their core technology in-house. It's not that it's under a proprietary license, just that it's not distributed at all. This model works wonderfully for the free software community and for those companies. I'm not disagreeing with this. I'm saying that your argument (top quote) can be applied to open source in general, and we all know it to be false in that case; so how are web apps so different? -- Glenn Maynard
Re: Should the ASP loophole be fixed? (Re: The Affero license)
On Mon, Mar 10, 2003 at 02:58:54PM -0500, David Turner wrote: True, but they also typically had access to copy binaries (and therefore, get source code). The LPPL makes the controversial claim that simply having files on a machine where a few other people could log in and access them in itself constitutes distribution. We believe courts would not uphold this claim, but it is not good for people to start making the claim. I wouldn't say it's distribution, but copying. How does having access to copy a binary imply access to source code? -- Glenn Maynard
Re: OSD DFSG - different purposes - constructive suggestion!
On Mon, Mar 10, 2003 at 03:46:57PM -0500, Brian T. Sniffen wrote: As I said: existing mechanisms of licensing Free Software (e.g. GNU GPL and MIT/X11) provide an impetus for improvement. A compulsory-sharing license, as might bring us closer to BrinWorld, removes much of the financial incentive for such improvement. In such a world, the changes made, used, and later released by IBM, Red Hat, Akamai, Apple... all wouldn't have been made, and our software technology would be that much more primitive. The GPL removes much of the financial incentive for such improvement. After all, you have to provide source and you can't restrict people you sell copies to from giving it away for free, so the entire sales model of selling individual programs on the shelf, and licensing software per-seat, goes completely out the window. I disagree with this argument, of course (as everyone here probably does: it's true that the same sales model doesn't work, but it certainly hasn't stopped innovation), but your argument seems to be exactly the same. Why is this argument valid for web applications where it's clearly wrong for other software? (To be clear, I'm firmly against forced-sharing; the GPL goes far enough. I just don't think this particular argument is valid.) -- Glenn Maynard
Re: Barriers to an ASP loophole closure
On Mon, Mar 10, 2003 at 03:53:31PM -0500, Jeremy Hankins wrote: Free software preserves the possessor's legal liberty to change the software, something that only legal limitation was previously blocking him in. But forced publication at all: how does this increase the user's liberty to change the software? I don't understand this question. Having access to the source is necessary if you want to make changes. Examples of dentists' software aren't relevant (unless you're a dentist), because that'd be outside of the sort of use we want to pick out. What if Google released source code? It'd be neat, but it wouldn't let me enhance the search engine to get better results; all I could do is run a miniature, useless search engine on my system. It's not enhancing my freedom to change the software at all. This applies to most examples of things on webpages that I'd like to change. I'd love to be able to tweak software on lots of different webpages, but in almost every case, them releasing the source wouldn't accomplish this, since I'd have to run a copy locally to use it, and most web apps aren't very useful when run locally. This applies to most software on the web. Of course, there are cases of web apps that can be run just as well on my local webserver, but I think they're a small minority. (It's this group that you're describing in your other examples, but I think it's the less significant category.) -- Glenn Maynard
Re: PHPNuke license
On Mon, Mar 10, 2003 at 02:36:51PM -0500, David Turner wrote: Indeed, in the current version, it is *perfectly clear* that mere modification triggers (2)(a) and (2)(c). If it did not, why would (2)(b) specifically mention distribution? Even if it's agreed that the current language restricts modifications that aren't distributed[1], it's far from clear whether this was the intent, or that it's useful. What's the point? It seems like a restriction that has no benefit to freedom at all. Why do I need to date changes for a program I'm not distributing? Of course, if I make changes and don't date them, I might have trouble later on if I change my mind and want to distribute them; but that'd be my own fault. The license certainly can't protect me from my own laziness. [1] The fact that there's active debate over this should be proof enough that it's not perfectly clear. Why not get an official position on this, don the sombrero and settle it, so we can at least stop debating the wording? -- Glenn Maynard
Re: PHP-Nuke: A calling for votes
On Sun, Mar 09, 2003 at 09:04:48PM +0100, Hugo Espuny wrote: I don't see that a vote is either necessary or relevant here. It doesn't harm in anyway, and it will help me :-) This is only voluntary. If it's a waste of time, or comes to a false conclusion (as impromptu, ad hoc votes are liable to do), it will confuse and muddy the discussion. (Not that this is necessarily what will happen; I'm just pointing out that it's not a foregone conclusion that a vote can have no negative effects.) There also seems to be a consensus that this interpretation of the GPL is not a valid one (eg. not a reasonable interpretation of the license itself). Interpreting the GPL in strange, logically unreasonable ways weakens the GPL, and weakening the GPL weakens the community as a whole. I suggest that it is irresponsible to aid its dissemination, and that the package should be removed completely. 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? (There's not yet a consensus to these questions, which is why I'm asking them. The only solid consensus right now was expressed in Branden's bug report: that it can't stay in main.) -- Glenn Maynard
Re: OSD DFSG - different purposes - constructive suggestion!
On Fri, Mar 07, 2003 at 05:49:28PM -0500, Joe Moore wrote: 2. the Chinese Dissident. It has been suggested that this test be referred to as simply as the Dissident test. /me grumbles about wasting time with excessive PC noises, rejects this suggestion and continues to call it the same thing -- Glenn Maynard
Update to [mod_ldap for proftpd is now post-card licensed (proftpd 1.2.7+)]
So we could go straight with proftpd 1.2.8. The release currently in sid will be updated as a consequence. The license problem unfortunately applies to woody release, also. Maybe should we propose an update for this in r2? IMHO we could consider to add a note in its README.Debian. Unluckily, 1.2.11 is not functionally the same as 1.2.10, so a patch should be avoided... Hints? Ask him to retroactively license the old version under the GPL as well, and you only need to update the copyright file. -- Glenn Maynard
Re: PHPNuke license
On Thu, Mar 06, 2003 at 03:32:46PM -0800, Thomas Bushnell, BSG wrote: The GPL'd library (readline) *is* interactive, so the exception *does* apply. Like I mentioned, that was just a poor example; pick any clearly uninteractive GPL-licensed library. -- Glenn Maynard
Re: PHPNuke license
On Wed, Mar 05, 2003 at 12:08:28PM -0600, John Goerzen wrote: programming A term describing a program whose input and output are interleaved, like a conversation, allowing the user's input to depend on earlier output from the same run. In each run, PHPNuke receives a single request and sends a single result. There is no interleaving. Now, you could argue that with session cookies, etc. that makes all the difference, but unless PHPNuke is broken without them, I don't think that argument works. It's just another case of a word that's difficult to define precisely: to include everything we subjectivally consider interactive, especially considering the fact that we don't all agree on what's interactive, and that some of us can't quite make up our mind. A license needs to pick its own definition (which is dangerous, since it's likely to miss cases the license author didn't think of, which is why technical definitions are bad in licenses[1]) and use it. Here, the GPL is ambiguous and all we can do is go with what the copyright holder says, which is that PHPNuke is interactive. [1] In other words, I'm stressing that whatever the solution to this is (wrt the license), it is *not* to try very hard to define interactive; it will fail and probably make a big mess of odd interpretations in the process. -- Glenn Maynard
Re: PHPNuke license
On Wed, Mar 05, 2003 at 12:45:55PM -0600, Steve Langasek wrote: I would recommend that users of the GPL who find this requirement ugly begin adding an additional exemption to 2(c) to their own works. Branden, if I'm not mistaken, this would constitute an additional permission and is therefore acceptable in your book? I'm not sure this would help. In order to remain GPL-compatible (as I understand it), the exemption must be severable, and if it's severable, people can still add the notice and make it sticky. It would be a statement that the original author doesn't *want* such a notice (and it would be rude to add it against his wishes), but such a notice can be made without touching the license. -- Glenn Maynard
Re: PHPNuke license
On Wed, Mar 05, 2003 at 08:43:52PM +0100, Henning Makholm wrote: This also goes for programs that have never been interactive before (and so never had a notice). If, say, I modified CVS such that it entered an interactive mode when run without arguments, I believe I'd be required to add a 2(c) notice. if the Program itself is interactive but does not normally print such an announcement Er. You made it interactive; now it's interactive but doesn't normally print such an announcement, so the exemption kicks in. Are we talking about a licensing race condition here? If that were the case, we'd be forced to put GPL blurbs in anything that made use of any GPL libraries at all, eg. Readline. -- Glenn Maynard
Re: PHPNuke license
On Wed, Mar 05, 2003 at 04:20:12PM -0500, David Turner wrote: But why should they need to see licensing information for software when they're not bound by the licenses? I don't think they need to see it, but that they need to *be able to* see it. So, I do think the current (2)(c) is slightly flawed (although, as the discussion has revealed, it's quite hard to exploit the flaw, if you adopt sane definitions of interactive). As a user, I would be interested. As a user, I would also be interested in seeing the ircd.conf of the IRC server I'm connected to, but the license shouldn't require that, either. :) I'm just emphasizing that some people would be interested in that doesn't seem to be enough reason to require it to be there. Now, it's no bother to me if a license requires that it be available in some way if the program is substantial (eg. as long as this doesn't include every bit of software used; BSD4 again), but that's just because although it strikes me as unimportant and mostly unnecessary, it's mostly harmless and not something I'd bother to take issue with. (Making it *visible* to all users, as the GPL2 requires, is a different issue; it's substantially louder than that and I'd dislike it being applied to make the information available where it's really not needed.) I think we're just hitting concepts of users that aren't exactly clear, and probably weren't considered at all when the GPL was written. After all, the GPL says when run, and IRC users certainly aren't running the IRC server when they connect to it; only Bob did that. But they might be if, instead of an ircd, it were an ftpd hooked up through inetd. Do you think that users are bound by the ftpd copyright under the inetd case, but not under the daemon case? If not, I don't think this extremely subtle distinction is worth making. (I can't even decide solidly whether that's running any more or less than a forking daemoned FTP, much less come up with a strict definition.) In any case, I don't think we can come to any safe conclusion of whether it's correct to interpret 2c to include displaying the GPL blurb on the main page of PHPNuke output. I think we *can* -- I think displaying on the console, or in the comments, would be fine. OTOH, I think that if a copyright holder interprets it differently, their interpretation should dominate -- just as in the PINE case, this might make their software non-free. What I meant was that we can't come to a conclusion of whether 2c includes this type of blurb at all (people not bound by the program's copyright clicking links and getting its output), not the actual mechanism. We can't agree on what interactive is, or whether they are running it. The GPL is ambiguous here. My own interpretation has been that 2c is intended to show licensing information (etc) to the person bound by the copyright, and that excludes this case; but the GPL doesn't really say. I think we ought to ask them to change it because the footer thing is definately outside of (2)(c), but the front page thing is definately DFSG-free (by grandfathering if nothing else). I disagree for two reasons: First, it's encouraging them to adopt an uncommon and somewhat questionable interpretation of the GPL. It's definitely an improvement over their current (s/somewhat/extremely/ questionable) interpretation, but I don't think it's a good idea to recommend questionable interpretations at all. Second, we don't have a consensus that a requirement to put a banner/blurb/logo on the main page is DFSG-free. Let's not jump to making suggestions that we're not sure about yet. (I think it's best to ignore the grandfathering business when determining whether something like this *should* be DFSG-free; if we decide that something *shouldn't* be DFSG-free but may be according to the grandfathering interpretation of DFSG#10, then something needs to be fixed.) (I also acknowledge that this may be largely intellectual if upstream is likely to completely ignore us, but I think figuring out problems like this--especially ones that involve odd interpretations of the GPL--is worth the time, even if the software in question isn't. This discussion has been more useful to me than PHPNuke is ever likely to be. :) -- Glenn Maynard
Re: PHPNuke license
On Wed, Mar 05, 2003 at 09:17:22PM -0600, Steve Langasek wrote: The notice requirement is part of the license. The only way to give others the freedom to NOT add such a notice when making a non-interactive - interactive transition with your code is through a license exemption (any statement that has the power to override this part of the license is essentially also part of the license). I'm not convinced of this. If I take a library and turn it into an application, it's now an application that doesn't normally print that announcement. It feels like a race condition--the whole turning into an application business happened at the same time as turning into one that doesn't print the announcement, and you seem to be reading the notification requirement as kicking in between the two events, such that the exception can't be used. If your interpretation is correct, then it would seem to also apply to using GPL libraries; using GNU Readline in an application is the same (to the GPL) as turning it into an application (or copying and pasting its code into an application), so every app that uses Readline would need to have this notification. (There are lots of programs that don't.) (Er. Read application here as interactive application.) -- Glenn Maynard
Re: PHPNuke license
On Wed, Mar 05, 2003 at 10:13:18PM -0600, Steve Langasek wrote: Then perhaps we have a license bug here. The text of 2(c) *only* provides an exemption if the Program itself is interactive but does not normally print such an announcement. This means that if either the Program itself is non-interactive or the Program normally prints such an announcement is true, you must comply with 2(c) for interactive works based on the Program. I don't see that any other reading is possible. If the program is uninteractive, you don't need the announcement. If you then turn the program into an interactive one, it's now an interactive program that does not normally print such an announcement. I'm just not seeing the problem. David, does the FSF have an opinion on this? For example, does the FSF take issue with people using GPL-licensed libraries with GPL-compatibly licensed software without adding a GPL blurb? (Which I believe would be a side-effect of Steve's interpretation, though I'm not entirely sure.) (I'm dropping the readline example, since readline might be argued to be interactive itself, and that just confuses things; but I can't think of another GPL-licensed library by the FSF off of the top of my head.) -- Glenn Maynard
Re: PHPNuke license
On Tue, Mar 04, 2003 at 01:37:10PM -0500, Don Armstrong wrote: I've been thinking a bit about this license and 2c in general. I'm not particularly happy about 2c because it restricts the ability of programs to be used in specific ways. I can't yet codify what I feel is wrong with it, and what I would do to change it, but I hope to be able to do so in a few days. I like my programs' output to be extremely spartan by default--show a single-line command-prompt and nothing else, eg: 03:31pm [EMAIL PROTECTED]/4 [~] ftp ftp The GPL prevents me from turning another program (eg. GDB) into one which has such a clean default interface. (The default interface is important to me because that's what most users see--most people don't spend their time figuring out how to disable GPL blurbs, and I want programs to present the best interface by default.) -- Glenn Maynard
Re: PHPNuke license
On Tue, Mar 04, 2003 at 12:50:13PM -0500, David Turner wrote: I think that's the claim -- that certain modifications of PHPNuke are forbidden. Okay, just reassuring that we're on the same page. Interestingly, I don't think (2)(c) would forbid a modified PHPNuke to print the copyright notice to a printer (or console) in the server room, instead of on the web page the user sees. The more I look at the clause, the more convinced I am that its sole purpose is to torture me. See, this is exactly my problem: who is it notifying? If it prints the notice to a printer, it's notifying the site administrator.[1] If it prints to HTML, it's notifying the users of the website. The former is reasonable to me, at least as far as the GPL goes. (However, PHPNuke and Apache are clearly (I hope) not being started interactively wrt the site admin, so these notices shouldn't be mandatory.) The latter is the case I dislike. I think of website users using the website (and only very distantly and nebulously are they in any way users of PHPNuke), and the administrator as the user of PHPNuke. (Incidentally, I've always thought of programs like gdb as being interactive, and programs like df and cat--including ones that happen to read data from stdin--as being uninteractive. I don't mind debating these interpretations of interactive here, but it's tangental to the PHPNuke discussion.) Do you say that it's tangential because you think PHPNuke is clearly interactive? Or because, interactive or not, Debian should consider its interpretation of (2)(c) non-free (whether or not it's correct from a legal perspective)? I mean that the idea is that PHPNuke (run by Apache) and sort (in the middle of a shell pipeline) are equally interactive. Neither talks directly to the user; they go through other programs. So, if that argument is bought, then we have two choices: either sort(1) outputting a mandatory GPL blurb on startup is DFSG-free (gross), or PHPNuke outputting a mandatory GPL blurb to HTML is DFSG-unfree. (And, in parallel, either sort(1) outputting a GPL blurb would be mandatory, or PHPNuke outputting one would be optional[2].) Like I said, I havn't been completely convinced of this. (Determination of whether df is interactive is tangental to this, though I'm not uninterested in reaffirming the notion that it is not. Determining the interactiveness of cat in a pipeline would be relevant only if we agreed to the above.) I actually am inclined (after looking at the Foldoc definition pasted in another message in this thread), to agree on df and cat. It's the back-and-forth which defines interactivity. Interestingly, this provides a out for Apache other than the two I listed above, since HTTP is technically stateless... Oops. Once we start using the word technically, we're getting outside the realm that licenses should care about ... [1] ignoring the common case where the system admin and the site admin are two different people and the site admin has no physical access to the machine [2] however, in this case we go back to the WU situation: a copyright holder's strange interpretation rendering a normally free license non-free. This would be annoying, since it would probably be the first time a GPL program was declared DFSG-unfree (and we might hear rumblings from the hopefully small DFSG#10-as-grandfather-clause crowd) ... -- Glenn Maynard
Re: Xbae widget license
On Tue, Mar 04, 2003 at 03:30:36PM -0500, Don Armstrong wrote: Permission to use, copy, modify and distribute this material for any purpose and without fee is hereby granted, I'm concerned that this restricts us (or our cd vendors) from being able to distribute the material for a fee [ie, on cd images and the like.] Does this mean that you can do these things without paying a fee to upstream, or that you can only do these things if you don't charge a fee for doing so? If it was written 'with or without fee' I suppose it would be ok, or if there was some clarification that indicated that a reasonable fee for the medium could be charged. It needs to be able to be sold in aggregate to pass DFSG#1. I am a bit worried about the line: 'that the name of any author not be used in advertising or publicity bla bla'. Debian won't explicitely advertise this widget I guess, so that would be okay? That worried me a bit as well, although what I presume they mean is that you may not use bellcore or the authors names to endorse your product or whatever. Perhaps a clarification from the author would be sufficient here? (The other X style licenses are much clearer in this regard.) This seems to be the same as the 3-clause BSD license's third clause. I believe negative advertising clauses are always OK. (Though, I wonder what would happen if I, having contributed somewhat to a BSD or Xbae-licensed program, were to give permission to Debian to use my world-famous name in its advertising. Since I don't hold sole the copyright of the program I contributed to, I can't simply waive this ...) -- Glenn Maynard
Re: PHPNuke license
On Tue, Mar 04, 2003 at 11:12:06PM +0100, Henning Makholm wrote: Determining the interactiveness of cat in a pipeline would be relevant only if we agreed to the above.) Similarly, cat is able to interact with the user (if we stretch that concept (in)appropriately), it does not interpret its input from the user as commands, so 2(c) does not apply to it. Hmm, right; that narrows it down a bit. I'm still not entirely sure how to apply it to things like PHPNuke, however. What if, instead of reading commands via stdin and keeping state in memory, gdb kept state in a file and read commands via the shell? (gdb b foo.c:12.) It's still running and it still has sessions in the same sense as the real gdb; the technical mechanism is just different, and it's similar to a web script keeping sessions and accepting commands via forms and links. Would the blurb clause apply to this (admittedly odd form of) gdb when it started a new session? Less contrived analogues are welcome. -- Glenn Maynard
Re: GPL 2c objections
I've always wanted a standard-ish environment variable, eg. QUIET_GPL, to turn off GPL notices globally. I havn't bothered since it's less work for me to just set up aliases and rc files as needed to disable it in individual programs than to patch programs and try to convince upstreams to take them. On Tue, Mar 04, 2003 at 02:48:12PM -0800, Mark Rafn wrote: You can work around this, though it's annoying to have to. Have it read an environment variable or config file on startup, and use the spartan output if it's set properly. This points out that in the most normal way is undefined, but I doubt you'd get in any legal trouble over that. I'm referring to wanting to have programs that are clean and quiet by default, not via an environment variable or parameter. I'm speaking as a programmer, who wants programs that behave ideally (in my view of things), and 3c (in some cases) prevents this. In fact, it would make me feel rather foolish to distribute an interactive program, typically used for two or three commands, which outputs a multi-line license blurb each time it's run. # glennftp foo.com / cd foo /foo get fum /foo exit # vs. # glennftp foo.com GlennFTP is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GlennFTP. Type show warranty for details. / cd foo /foo get fum /foo exit # I don't want users to see that mess; I don't want any text at all before the prompt, and I don't want users to have to figure out how to disable it. Of course, I simply don't add these messages to my own programs--but it prevents me from turning existing programs into ones which are quiet by default (and it's freedom to modify other programs that we're interested in). Now, David Turner is mentioning some discussions that might fix this particular problem entirely at some point. The saving grace of 2c, which is frequently missing from other licenses that attempt to force behaviors on modified versions, is that it does not specify exactly what the message is, nor how or where the notice must be printed or displayed. In fact, you could make your derived program spit out a line to syslog which points to the copyright and disclaims warranty. It says you must print or display an announcement. It clearly means that you must tell the user running the interactive program; I think any interpreting of that to mean printing to a place the user is never likely to see it (syslog, or /dev/null) is a stretch and certainly not what was intended. -- Glenn Maynard
Re: PHPNuke license
On Tue, Mar 04, 2003 at 06:53:51PM -0500, David Turner wrote: This, I simply don't think I can agree with. Perhaps a clearer example would be irc.worldforge.org. It lives on a computer owned and operated by Bob. But Bob basically never logs on to IRC. I asked, and the two people currently active said that they were currently using the server, while Bob wasn't (since he wasn't connected then). But why should they need to see licensing information for software when they're not bound by the licenses? It's Bob that potentially needs that information, not the users. Similarly, the license itself (the GPL text) must be made available to Bob, but nothing requires it be made available to the users on IRC. I doubt the warranty disclaimer is relevant to them, either. I think we're just hitting concepts of users that aren't exactly clear, and probably weren't considered at all when the GPL was written. After all, the GPL says when run, and IRC users certainly aren't running the IRC server when they connect to it; only Bob did that. In any case, I don't think we can come to any safe conclusion of whether it's correct to interpret 2c to include displaying the GPL blurb on the main page of PHPNuke output. The GPL doesn't say; it wasn't written with this case in mind, so the only safe thing to do is to ask the copyright holder, and this copyright holder's position is clear (he's interpreting it even more liberally than that). However, PHPNuke's interpretation is broader: it insists that the blurb be in the footer of each page, not just the main page. Even if we can can't determine the above, can we agree that it's not a reasonable interpretation to apply it to the output of each page (akin to outputting the blurb for every command issued to gdb)? I'm not sure where we could go from there; asking them to change it to only the main page is pointless if that's 1: still ambiguous and/or 2: still of questionable DFSG-freeness. Even if that's DFSG-free, it's still probably a bad idea to ask them to change to that if it's still a questionable interpretation of the GPL. -- Glenn Maynard
Re: [Discussioni] OSD DFSG convergence
On Tue, Mar 04, 2003 at 10:36:21PM -0500, Russell Nelson wrote: Why do some people think it's productive to reply to stale email that is no longer a current topic of conversation? [ Thomas, feel free to reply at this point. ] The response you are quoting was made on the same day I received the message it replies to. (There may have been SMTP queuing lag, of course; I've had some of my own mails to Debian lists take a few hours to get back to me over the last week or so.) (The rest of this message doesn't warrant a response.) -- Glenn Maynard
Re: PHPNuke license
On Mon, Mar 03, 2003 at 03:38:48PM -0500, David Turner wrote: Hm, you probably ought to be aware that the PHPNuke people seem to have interpreted it as an authoritative statement from the FSF: http://phpnuke.org/modules.php?name=Newsfile=articlesid=4947 I wish I had been more clear that IANAL and TINLA. Well, you should at least try to set them straight now, although I suspect you won't make much headway; I gather from other remarks that have been made about PHPNuke that its author is the sort that will latch onto any justification for his actions that is offered, and never let go even if the circumstances behind that justification change. Yeah, but I'm not even sure what straight would be here, since there seems to be a lot of disagreement. I would rather have a definitive answer first. I think he just meant that you should try to tell them that your comments weren't authoritative statements from the FSF. I could use a nice Al Samoud missile right now, to go with my anthrax poindexter Cocaine ANZUS ISEC Elvis counter terrorism Serbian smuggle jihad Kosovo Area 51 JPL CIDA North Korea IDEA undercover M-x spook. Now emacs truly does have everything. -- Glenn Maynard
Re: PHPNuke license
On Mon, Mar 03, 2003 at 03:53:22PM -0500, David Turner wrote: Actually, I think Copyright 2003, FSF and others (see file /foo/bar for details) [no warranty] would be an appropriate copyright notice. So, there's a minor problem, but not an unbounded problem. I'm just not sure I see an actual case when this would happen. One issue would be that any shell scripts relying on the output of the programs would have to be changed. This would be enough work to disuade any but the most determined from making this change. In cases other than coreutils, where far fewer shell scripts rely on output, the problem for everyone else is much smaller too. Generally not, if the annoying text was output to stderr (or when on a tty--which it will almost always be when interactive--even more safely but even more annoyingly, to /dev/tty). Even if there is a problem, it's not even on the order of the BSD advertising clause -- it doesn't make the software non-free. And if there is a problem, it's a genuine problem which ought to be fixed. A string of piped commands might output five such notices; a foreach loop might output hundreds. [1] I agree that it's not on the order of the BSD clause; at least we can disable it, though we might have to research how it's done differently in dozens of packages. I believe it's potentially extremely annoying, but (unlike the BSD clause) it generally hasn't been, in my experience. (Hasn't been isn't will never be, though.) Forcing me to mention the copyrights of underlying tools on my webpage (or the existance of underlying tools at all, for that matter; users don't care and can ask if they do, so don't bloat my pages) is orders of magnitude more annoying, though. It's extremely non-free, in the view of, well, my own subjective opinion. [1] Continuing the idea that using these programs in a complicated but user-typed shell string is still interactive; it's probably exactly this problem that the interactive qualification was intended to prevent. However, recalling the context, Branden's argument was, I believe, that if a web session is interactive with respect to the tools generating them, then manual shell scripting is, too. -- Glenn Maynard
Re: PHPNuke license
On Mon, Mar 03, 2003 at 08:08:57PM -0600, John Goerzen wrote: A program in the middle of a pipeline never directly accepts input from the user, nor does it output direcly to the user. Therefore it is not interactive. Bingo. PHPNuks is just that program. Its pipeline looks like: web browser - client network layer - server network layer - apache - mod_php4 - phpnuke - apache - server network layer - client network layer - web browser I was avoiding this argument. After all, gdb goes, for me, gdb - tty - screen - tty - sshd - network layers - putty. Everything goes through layers. I don't think this line of reasoning is useful. -- Glenn Maynard
Re: Bug#182212: ITP: ttf-bitstream-vera
On Sun, Feb 23, 2003 at 08:17:52PM +0100, Jesus Climent wrote: I thought this rendered the fonts useless to Debian acording to DFSG: The Font Software may be sold as part of a larger software package but no copy of one or more of the Font Software typefaces may be sold by itself. Which part of the DFSG? This seems deliberately constructed with passing the DFSG (or the OSD) in mind. -- Glenn Maynard
Re: GNOME Font Copyright
On Wed, Feb 19, 2003 at 03:02:26PM -0500, Jeff Licquia wrote: Apparently, the fonts donated to GNOME by Bitstream are now available. The current beta-test license is clearly non-free, but they are proposing a license for the final release which seems to be DFSG-free. I've included the license text below. Is this DFSG-free? If not, what changes need to be made? It seems that this is a draft, so we might be able to lobby for adjustments. The big problem that glares out at me is the cannot sell by itself clause. I vaguely remember that d-legal considers that to be a silly restriction that has no effect on freeness, but I could be wrong. The Font Software may be sold as part of a larger software package but no copy of one or more of the Font Software typefaces may be sold by itself. Seems to pass the aggregate bit clearly enough. I wonder how it's possible to more than one thing by itself ... -- Glenn Maynard
Re: license for patch?
On Wed, Feb 12, 2003 at 03:14:48PM -0600, Steve Greenland wrote: A completely different, and possibly more important, question: Is Debian actually allowed to distribute djbdns binaries built from patched sources at all? No. See http://cr.yp.to/distributors.html. But the original question was about djbdns-installer, and the patch would be applied after downloading pristine sources from DJB's server. This is okay, because DJB says You are free to download the software from my web server; you then own that copy of the software, and you are free to compile it and run it. (from the same page) But can Debian distribute the patch itself? (After reading the random attacks on the above link, I don't care to read anything else written by that person at the moment.) -- Glenn Maynard
Re: Perl module licensing, the next step
On Sun, Feb 09, 2003 at 04:25:26PM -0600, Ardo van Rangelrooij wrote: I've been contacted by Ann Barcomb (see her message below; below that is her second message to me) about the Perl module license issue. I've put her on the Cc and would appreciate it if you could keep her on the list of recepients. So, what information do we feed back to the Perl community in order for them to fix their licenses. Well, there's arguments on both sides, but doesn't yet seem to be a consensus on whether this is a real problem or not. Clarifying it probably can't hurt, though. This module is available under the same terms and conditions as Perl itself, versions 5.3 through 6.8. Perhaps (taking the GPL as a hint): This module is available under the same terms and conditions as Perl itself, version 5.3 or (at your option) any later version. to prevent any possible license conflicts down the road, and the unnecessary implication that 6.8 should be updated with every release of Perl. -- Glenn Maynard
Re: Perl module license clarification
On Tue, Feb 04, 2003 at 07:16:23PM -0600, Ardo van Rangelrooij wrote: I mean, why should we force them to make a specific choice? They have in already made a choice: to follow Perl. What's wrong with that? I'm really curious as to what specifically and exactly is wrong with this type of license delegation. What happens if Perl changes licenses? How can I tell what license a given version of the module is released under? Perl is currently GPL+ Artistic. This can't be revoked for existing versions, of course, but what happens if--having, perhaps, inhaled substances they shouldn't have--they chose to begin distributing new versions of Perl under a non-free license, and the module author goes along with it? The module as already distributed is still available under the G+A--but how do you know which versions of the module are G+A and which are following the new license (perhaps in the interests of finding the last free version in order to fork it)? There is probably a similar issue with stating that software is licensed under the GPL version 2 or any later version. Isn't that also delegation to another license? Download a GPL program in 25 years; it's clear that you can at still use the program under the terms of the GPL, version 2. (I suspect the reason for this clause is the same as the one that permits LGPL code to be shifted to GPL: to ensure that currently GPL'd code will be upwards license-compatible with future versions of the GPL.) -- Glenn Maynard
Re: mod_ldap for proftpd is now post-card licensed (proftpd 1.2.7+)...
On Fri, Jan 31, 2003 at 03:03:21PM +0100, Henning Makholm wrote: I disagree with the suggestion that the author could be made to realize this merly by mailing him the text of the GPL with a few passages underlined but no further explanation. No argument there. -- Glenn Maynard
Re: mod_ldap licensing issues
On Fri, Jan 31, 2003 at 03:59:37PM +0100, Francesco P. Lovergine wrote: We in Debian need some clarifications about your current license for mod_ldap. We need minimally to move proftpd-ldap in non-free section when 1.2.7 will be uploaded. But this is not a problem of yours surely :). Your problem is another one: you released under I'd hope that John would have some interest in keeping proftpd-ldap in Debian ... GPL and added a send-me-a-postcard condition as an additional constraint. Unfortunately, this (could) appear a violation of GPL licensing. My own suggestion is adopting an ad-hoc GPL-like modified license which contains also the postcard req. Or eventually drop that requirement. The main problem I'm seeing--other than its non-freeness--is that proftpd is GPL, and proftpd-ldap's license is GPL-incompatible. Unless there's something I'm missing (such as a poorly located license exception), that makes it undistributable, and I'd expect that the Debian package would have to either be removed or forked at the latest pure GPL release. -- Glenn Maynard
Re: mod_ldap for proftpd is now post-card licensed (proftpd 1.2.7+)...
On Thu, Jan 30, 2003 at 07:51:27PM +0100, Henning Makholm wrote: Send him a postcard with the appropriate GPL section highlighted. Um, but what is the appropriate GPL section? It is clear to us that what the author is trying to do is not compatible with claiming it is GPL'ed - but the reason *why* it's incompatible is that the GPL contains no postcard requirement. How do you hightlight a section that is no there? 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further ^^ restrictions on the recipients' exercise of the rights granted herein. ^^ You are not responsible for enforcing compliance by third parties to this License. -- Glenn Maynard
Re: mod_ldap for proftpd is now post-card licensed (proftpd 1.2.7+)...
On Thu, Jan 30, 2003 at 09:14:26PM +0100, Henning Makholm wrote: these terms and conditions. You may not impose any further ^^ restrictions on the recipients' exercise of the rights granted herein. ^^ Yes, but that doesn't bind the author (assuming that he has the sole copyrigt on the program). It does in a sense--it prevents people from using the GPL and adding additional restraints; at least according to this interpretation: http://lists.debian.org/debian-legal/2002/debian-legal-200205/msg00062.html Review the text of the GNU GPL and note the many times it makes reference to this License. The GNU GPL is a self-contained license document. A copyright holder is well within his rights to distribute a work under the terms of the GNU GPL and an arbitrary number of alternative terms, but those alternative terms cannot restrict the licensing of the work under the GPL, or the application of the GPL is void. (Branden) which I've referenced on this list several times and never seen challenged. (Direct challenges to him, though, as although I favor this interpretation, I'm not equipped to defend it.) -- Glenn Maynard
Re: mod_ldap for proftpd is now post-card licensed (proftpd 1.2.7+)...
It's strange to me that, in this interests of finding out how many people are using his module, he'd add a restriction that would immediately cause a great number of people to stop using it. On Thu, Jan 30, 2003 at 03:13:02PM +0100, Francesco P. Lovergine wrote: Any hints are welcome :) On a different note, ProFTPD is GPL; is there anything that relieves the LDAP module/code of the requirement of being GPL-compatible? -- Glenn Maynard
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: 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. Is this particularly good advice? It's my understanding that the best (only) way to minimize patent liability short of hiring a lawyer is to avoid knowing anything about potentially relevant patents entirely. -- Glenn Maynard
Re: Bug#176267: ITP: mplayer -- Mplayer is a full-featured audioand video player for UN*X like systems
On Wed, Jan 29, 2003 at 11:33:31AM -0500, Don Armstrong wrote: It's my understanding that the best (only) way to minimize patent liability short of hiring a lawyer is to avoid knowing anything about potentially relevant patents entirely. AFAIK, ignorance of patents doesen't protect you from being prosecuted and/or found liable under them, at least in the US. (Unlike the convergent re-creation of copyrighted works.) If someone else knows differently and can quote caselaw, please do. From http://www.advogato.org/article/7.html: The Court of Appeals for the Federal Circuit (effectively the final word on patent law, since the Supreme Court rarely takes patent cases) has ruled that anyone who is not a patent attorney is not qualified to determine the scope of the claims in a patent, and that it would be unreasonable for you to determine that a particular patent is not applicable to what you are doing unless you first get a legal opinion from a patent attorney. Because, as a matter of law, you couldn't really have believed that you understood the patent (yes, our federal courts can be quite condescending), you will likely be found liable for triple damages if it turns out that you were wrong, and that you really are infringing the patent. Because of this, lawyers routinely advise their clients to avoid reading patents in areas they are working in. The danger posed by the willful infringement doctrine is seen as outweighing any benefit that can be gained from reading patents. (Someone else can go shoveling through caselaw. :) -- Glenn Maynard
Re: OSD DFSG convergence
On Wed, Jan 29, 2003 at 03:46:03PM -0500, Russell Nelson wrote: I'm on the mailing list. Debian policy is to not CC the author. If you guys can't follow Debian policy, how in the WORLD do you think anybody can follow the DFSG, much less your interpretation of it? I am not encouraged by your behavior. It's not something to engender confidence. That's funny. I asked you whether you wanted CCs on mails, since you didn't appear to be replying to mails not CCd to you. I asked thrice, in fact, but you didn't give an answer. The only mails from me you've ever replied to are ones I've CCd, and every time I've skimmed through mails you've responded to, they're all ones CCd, and those not CCd were not replied to. Although this could be coincidental, it is an extremely reasonable conclusion from this that you don't read the list. And now you're complaining about CCs, and trying to use it as a lever for your argument? It's not something to engender confidence. (And trying to compare behavior wrt. list policy that most people don't even know about vs. the DFSG, a constitutional document of guidelines, is meaningless, and you know it. Please stop.) -- Glenn Maynard
Re: Bug#176267: ITP: mplayer -- Mplayer is a full-featured audioand video player for UN*X like systems
On Wed, Jan 29, 2003 at 11:40:32PM +0200, Richard Braakman wrote: Because of this, lawyers routinely advise their clients to avoid reading patents in areas they are working in. The danger posed by the willful infringement doctrine is seen as outweighing any benefit that can be gained from reading patents. Does it bother anyone else that this completely subverts the point of having patents in the first place? Preaching to the choir on this one, I think. :) -- Glenn Maynard
Re: Bug#176267: ITP: mplayer -- Mplayer is a full-featured audioand video player for UN*X like systems
On Thu, Jan 30, 2003 at 02:42:23PM +1300, Nick Phillips wrote: It seems that what you are saying, then, is that we should completely ignore any patent issues until and unless we are prompted to do so by holders claiming that we are infringing. I'm just quoting from an article I read, which was written by someone who knows a lot more about patent law than I do. I believe your interpretation matches the general Debian position on patents. (I do agree that the patent system is a bad joke, but it's a joke at our expense ...) -- Glenn Maynard
Re: OSD DFSG - different purposes
I guess you want CC's. If you won't add an MFT header, at least say you want them; Debian list policy is to not CC people on replies unless requested, and some of us do follow this policy. :) On Tue, Jan 28, 2003 at 12:29:37AM -0500, Russell Nelson wrote: The problem with relying on human judgement is that it can be arbitrary. If Microsoft came to Debian and said Would you accept this software licensed under the Microsoft Public License? would you be able to make a judgement which is not only not arbitrary, but which could be *seen* to be non-arbitrary? If you want to make judgements on things which aren't in the DFSG, how can you not be seen as arbitrary? D-legal decisions are based on rationale: consensus interpretation of the DFSG. Decisions based on logical grounds are not arbitrary. The rationale is freely available in the list archives. People might easily disagree with it, but it's certainly not arbitrary. There has been discussion in the past to set up a minor document that does what you describe: details specific interpretations of the DFSG. There were several arguments against it. (I won't rehash them; does anyone happen to remember one of these threads to find an archive link?) I do think that, for specific interpretations of existing DFSG clauses, having them in a secondary document is better than amending the (currently short and to-the-point) DFSG. -- Glenn Maynard
Re: OSD DFSG - different purposes
On Tue, Jan 28, 2003 at 01:23:04AM -0500, Russell Nelson wrote: I guess you want CC's. If you won't add an MFT header, at least say you want them; Debian list policy is to not CC people on replies unless requested, and some of us do follow this policy. :) Debian list policy is to not CC people on replies unless requested. Yes, that's what I said. You've only replied to the one mail I sent you a CC on, and I was unable to find any replies from you to people who didn't CC you, which led me to the hypothesis that you're only reading CC's. You havn't said whether you actually want CC's or not, however. I'll experiment by not CC'ing this message to you. :) Irony is in fact NOT dead, no matter what anyone may say about it. You see, to determine if something is DFSG-free, you cannot simply read the DFSG. With this fact in mind, and with a straight face, can you reiterate your assertion that the DFSG is to-the-point? It seems more accurate to say that the DFSG is besides the point. The DFSG is to-the-point. It isn't heavily laden with the fine details of application; rather, it expresses Debian's principles of software freedom concisely. -- Glenn Maynard
Re: OSD DFSG convergence
On Mon, Jan 27, 2003 at 11:16:56AM +0100, Lo'oRiS il Kabukimono wrote: and yet the DFSG does not admit the possibility of public-domain unlicensed software. strange, because the game Abuse is public domain and is part of Debian... There's lots of public domain software in Debian; this was never in question. He's questioning whether the DFSG, as written, allows it. It seems to be a question based on the false idea that the DFSG is intended to be taken literally and without interpretation, though. The DFSG is fairly useless without being augmented by human judgement. -- Glenn Maynard
Re: acceptable restrictions on modification
On Mon, Jan 27, 2003 at 06:53:28PM +0900, Oohara Yuuma wrote: The GPL forbids removing code from interactive programs which displays copyright notices. Yes, and in my opinion this is a defect in the license. You mean this? | If the program is interactive, make it output a short notice like this | when it starts in an interactive mode: | | Gnomovision version 69, Copyright (C) year name of author | Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. | This is free software, and you are welcome to redistribute it | under certain conditions; type `show c' for details. This is not a part of GPL terms. Yes, it is. 2c: 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.) -- Glenn Maynard
Re: OSD DFSG - different purposes
Are you reading the list? I'll CC you on this message (deviating, for the moment, from list policy of not CCing without request, and hiding from Branden); if you don't want CCs, let me know. (If you do, you should add a Mail-Followup-To header.) On Mon, Jan 27, 2003 at 04:58:01PM -0500, Russell Nelson wrote: Fair enough, but do you really expect people to study the archives? For example, Google knows nothing about debian-legal RPSL, implying that you never discussed the RPSL. The correct way of finding out if a license is DFSG-free is to ask debian-legal. People frequently do this, even for very simple, BSD-ish licenses (and cases that don't require discussion--the majority--generally get a reply very quickly). A search of the Subject: headers between last July and now shows no instance of RPSL, or Real. http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00448.html RealNetworks is in the subject, and the search on lists.debian.org doesn't find partial matches by default. I don't know why Google doesn't have that indexed. Why not change the DFSG? There have been several good reasons explained for leaving the DFSG as a set of human guidelines, rather than a word-strict block of legalese that attempts to remove all human judgement from the equation. I can't find them at the moment, though, and I'll leave the explanation to someone who can do so better than I can. Even if this was done, DFSG freeness isn't a guarantee that a package will be included in Debian. For example, a game with half a gigabyte of data, all of which is DFSG-free, would most likely not be included in Debian; and software which has no interested Debian developer is unlikely to get into the archive. DFSG-freeness is necessary, but not always sufficient. -- Glenn Maynard
Re: Just the usual rant: Debian VS legal problems (MPlayer, xine, libavcodec)
On Mon, Jan 27, 2003 at 01:33:34AM +0100, Gabucino wrote: xineplug_decode_gsm610.so - xine's gsm610 is GPL, MPlayer's is not? :) Nice. WE say it's GPL. Its original author says it's GPL. Debian-legal says we are all wrong?? :)) Make me laugh. I'm waiting for your comments. You'd receive a much more pleasant reception on Debian lists and elsewhere if you weren't consistently rude, condescending and sarcastic. *plonk* -- Glenn Maynard
Re: OSD DFSG convergence
On Sun, Jan 26, 2003 at 09:35:03PM -0500, Russell Nelson wrote: I'm inclined to believe that your second example is also a minor issue, because if the software is DFSG-compliant in all other respects, it should be possible to legally remove the click-wrap requirement from the code -- just as you can charge someone a fee for giving them GPL software, but you cannot prevent them from giving it away for free once they have it. Why do you think you can unilaterally change the terms of a license? Removing code that displays a license and accepts a yes or no click doesn't change the license at all. If you're allowed to remove this code and redistribute the program without the click-through, then there's no problem; do so. If the license has a clause saying you can't remove the code that forces the user to click through this license--which would legally prevent doing the above--then this requirement itself is DFSG-unfree. Of course, for a click-through license to have any meaning[1], it needs to be required, so it would need to contain such a clause. So, in practice, click-through licenses are DFSG-unfree. A clause in the DFSG making this explicit would be superfluous. [1] assuming they can have any meaning at all -- Glenn Maynard
Re: OSD DFSG convergence
On Sun, Jan 26, 2003 at 09:54:54PM -0500, Russell Nelson wrote: I fail to see how a useful software license could be DFSG-free and have a detrimental click-wrap license. Perhaps you could provide an example? Here's an example, but more to the point, where in the DFSG does it say that a license can't require click-wrap? http://opensource.org/licenses/sybase.php 2.1(c) Whenever reasonably feasible you should include the copy of this License in a click-wrap format, which requires affirmative acceptance by clicking on an I accept button or similar mechanism. If a click-wrap format is not included, you must include a statement that any use (including without limitation reproduction, modification or distribution) of the Software, and any other affirmative act that you define, constitutes acceptance of the License, and instructing the user not to use the Covered Code in any manner if the user does not accept all of the terms and conditions of the License. This places a restriction on modification, failing DFSG #3. See: http://lists.debian.org/debian-legal/2003/debian-legal-200301/msg00057.html (Unless the reasonably feasible or should parts turn this into an optional request, but that's a detail.) -- Glenn Maynard
Re: GNU TLS OpenSSL compatibility layer under GPL, not LGPL
On Thu, Jan 16, 2003 at 05:40:47PM +0100, Simon Josefsson wrote: There is a third option: Make the library use GNU TLS natively, without the OpenSSL compatibility layer. GNU TLS core is LGPL. This is just an argument that the compat layer doesn't need to exist at all, which is basically true; it exists to make switching from OpenSSL easier, not to make it possible. But it doesn't seem to be related to which license it should use. If it's useful for GPL apps, it'd be just as useful for (as Steve mentioned) LGPL libraries. -- Glenn Maynard
Re: Bug#173601: ITP: jpgraph -- OO Graph Library for PHP
On Thu, Dec 19, 2002 at 01:34:22PM -0500, Stephen Ryan wrote: Waitaminnit. Maybe I'm missing something here, but isn't the QPL a Free Software license? I didn't do that much of a careful search, but I googled for QPL DFSG and found a bunch of hits that make it look like the QPL is considered Free. If so, then why shouldn't jpgraph go into main? The commercial clause is no more obnoxious than a GPL/talk-to-me dual license, as it applies only in the case of closed-source use. What am I missing? Is this the same license that was just discussed here? http://lists.debian.org/debian-legal/2002/debian-legal-200212/msg00186.html It seems to disallow private modifications (6c), which, as I understand it, is a DFSG requirement. -- Glenn Maynard
Re: EULA with GPL??
On Mon, Dec 16, 2002 at 11:01:52PM -0800, Terry Hancock wrote: Does section 6 guarantee that the usage right is kept, or is it somehow guaranteed in law, or is there another section which addresses this (I've looked of course, but didn't see anything that seems to do it). Hmm. Thinking about this, I have a question of my own: The GPL doesn't remove my right to sign a contract promising not to do something, and I believe this is a commonplace and legitimate--if annoying--practice that the GPL supports: companies can have employees sign NDAs, preventing them from distributing programs used internally. However, this doesn't seem too different from making me sign a contract agreeing not to request source when receiving a GPL program. I understand that this *isn't* valid. I'm not sure how that differs from promising not to distribute the program; they're both restricting me. Why is the former legitimate and the latter not? (Or am I more confused than I think?) (I don't know if this extends to EULAs, though. They're on shaky ground to begin with.) -- Glenn Maynard
Re: Is this license permittable into debian 'main'
On Mon, Dec 16, 2002 at 02:31:53AM -0600, Joe Wreschnig wrote: However, clause 6 says it only takes effect when distributed, which is kind of confusing. You need to be distributing it, but not to the general public. Do NDAs and things like internal use count as distribution at all? I'm not sure. Either way, it has the time limit problem. -- Glenn Maynard
Re: Is this license permittable into debian 'main'
On Sun, Dec 15, 2002 at 09:57:08PM +0100, Henning Makholm wrote: The QPL - its OSI approved i beleive is it suitable for debian main programs (i beleive so) Yes, it is DFSG-free. c. If the items are not available to the general public, and the initial developer of the Software requests a copy of the items, then you must supply one. I thought the right to make private modifications is required. http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00018.html http://lists.debian.org/debian-legal/2002/debian-legal-200203/msg00152.html Desert island scenarios and so on. (Most of these are you must send changes upstream, and not you must make them available on request, but I don't think there's any real difference.) -- Glenn Maynard
Re: Is this license permittable into debian 'main'
On Sun, Dec 15, 2002 at 11:52:27PM -0500, Joe Drew wrote: I don't see anywhere that this fails the DFSG. Asking that someone must hit such-and-such a web page with changes (and its moral equivalents) I will buy as a violation of DFSG 5; I can't see where being forced to provide source code (under the QPL) when asked fails, though. I don't think being forced to actively send changes (or changelogs) upstream is any different than having to produce source on demand; both discriminate against people who *can't* publically release changes, such as people under NDA. It also places no time limit; see the first paragraph: http://lists.debian.org/debian-legal/2002/debian-legal-200201/msg00010.html -- Glenn Maynard
Re: Is this a free license?
On Thu, Dec 12, 2002 at 06:02:23PM -0500, Jim Penny wrote: So, does that not make qmail free? There is no problem in distributing the unchanged tarball, and we are, after all, simply distributing a patchset that modifies it to support FHS. If I remember correctly, the license of Qmail forbids even patches. -- Glenn Maynard
Re: Documentation licenses (GFDL discussion on debian-legal)
On Wed, Dec 04, 2002 at 11:18:08PM +0100, Javier Fernández-Sanguino Peña wrote: Then please remove the GPL from all debian packages, and make non-free all those that include it. Or can the GPL be modified, can it be changed at will? No. Does it make it non-free: NO. It's a license, and it's generally accepted that immutable licenses and warranty disclaimers are a necessary exception, since Debian isn't comprised entirely of public domain software. I believe it's perfectly clear to everyone that Mark was not referring to license texts; they're irrelevant to the discussion. Invariant sections are non-technical opinions (see http://www.gnu.org/licenses/fdl-howto-opt.html) that reflect the author's opinions. You cannot remove them, _but_ you can add your own (for example to discuss what the original author said). Right, and I certainly don't want to see unremovable opinions in Debian (even if I happen to agree with them). Whether they're technical or not doesn't matter to me. -- Glenn Maynard
Re: EULAs and the DFSG
On Wed, Dec 04, 2002 at 12:21:29AM -0500, David B Harris wrote: I suspect (though I could be wrong) that the the problem is that if it's an EULA, in that the user must agree to it before using the software in question, we have to force them to agree to it before using it. We can't guarantee that. a) I don't know anybody in Debian who would advocate forcing the user to do something that they may or may want to do, and b) even if it was attempted, there would be ways around it. A license having the requirement that a click-wrap license be agreed to before the software is distributed would seem to fail DFSG #1 fairly directly--it's a restriction on distribution. And if they put users through a click-wrap license, but don't require it on redistribution, there seems to be no point. (I've seen some slightly confused Windows installers for GPL programs with a click-through containing the GPL. No real harm in that, I think, but it's unnecessary.) -- Glenn Maynard
Re: Copying/modification/distribution/sale combos and setting terms on use
On Sat, Nov 23, 2002 at 04:20:02AM -0600, J.B. Nicholson-Owens wrote: 1. [EMAIL PROTECTED] has got me wondering if we really should specify that we want to combine copying, modification, distribution, sale into any arbitrary combination (e.g., copying+modification, sale+distribution, copying+modification+distribution+sale). After all, if the UWash lawyers were right about how clauses like these are understood and we need to clarify modification+distribution, why do we not want clear specification on any other desirable combination of these actions? The FSF response about this, I believe, wasn't that this is necessarily the actual court position of a naive reading of x, y, or z; but rather that it's UW's reading (to get out of having previously made the software free) and that it's wise to heed copyright holders' interpretations of their licenses, even if they're strange. However, it seems that x, y, and/or z should close the loophole. I wonder if someone would try to interpret that as saying you must do all of them or exactly one. :) -- Glenn Maynard
Re: click-through EULA vs DFSG
On Sun, Nov 03, 2002 at 12:00:34PM +1300, Nick Phillips wrote: IF THIS SOFTWARE WAS DOWNLOADED FROM A LOCATION OTHER THAN THIS WEBSITE ^^ AND THROUGH THE STANDARD DOWNLOAD URL OR WAS DOWNLOADED USING A METHOD TO ^ AVOID ACCEPTANCE OF THIS AGREEMENT NO RIGHTS SHALL BE GIVEN TO THE USER. Disagree. The above states that if their purpose in obtaining it elsewhere was to avoid agreeing to the license, then they have no rights. It's pointless, yes, but... What about that part? It sounds like they want it to be unredistributable, which is clearly both DFSG-unfree and contradicting the GPL. -- Glenn Maynard
Re: LZW patented file left in .orig.tar source package?
On Fri, Oct 25, 2002 at 09:10:32AM +0100, Edmund GRIMLEY EVANS wrote: Firstly, Debian cannot possibly guarantee that none of the code it distributes infringes on any patent in any country. So users in any case cannot make a good-faith assumption that they are free to use the code in their country. In which case, why throw out code that definitely is patented in the US? Why not just add a comment warning about the problem? http://www.advogato.org/article/7.html : Willful infringement of a patent exposes you to major damages. Ordinarily, when someone is found liable for patent infringement, they are prohibited from continuing the infringing activity, and they are ordered to pay the patent holder damages equal to a reasonable royalty for the use of the patent, or the patentee's lost profits. The law permits judges to increase the monetary damages by up to three times, however, if there is a finding of willful infringement, meaning that the infringer had knowledge of the patent before engaging in the actions which constitute infringement. Something to think about, at least. -- Glenn Maynard
Re: LZW patented file left in .orig.tar source package?
On Wed, Oct 23, 2002 at 02:30:25PM -0500, Jeff Licquia wrote: That doesn't sound right to me. (Though, really, what do I know? All standard disclaimers apply.) I was under the impression that patents are use licenses, and are as such tied to the use you make of the objects covered by them. You can make a car engine that infringes on a particular patent, for example, without a license; you just can't put it in your car and drive around. If that particular configuration of metal just happens to be very good at distributing water to a row of plants in a garden, the patent holder is out of luck regarding my use of the engine as a watering can (unless s/he owns the patent on that use of the engine as well). If I'm right, then the source file cannot be held as violating a patent claim unless it's compiled and executed. I believe Freetype still contains the Apple-patented hinting; it's disabled in the source, with documentation that says enable this only if you have a license to use it. However, that might be at the permission of Apple. I don't know. -- Glenn Maynard
Re: LZW patented file left in .orig.tar source package?
On Thu, Oct 24, 2002 at 02:03:44AM +0300, Richard Braakman wrote: Fortunately this particular problem will go away next summer :) (LZW patent expiration) I'm certainly glad Disney doesn't have as heavy a stake in patents as it does in copyrights ... -- Glenn Maynard
Re: [aspell-devel] Problems with aspell-en license
On Mon, Oct 21, 2002 at 12:55:26AM -0400, Kevin Atkinson wrote: I will remove the DEC word list from my source only if Debian will refuse to include the English word list due to questionable copyright on some of the sources that DEC uses. But If I do I will make a note on the reason why it is removed which will include a statement by me which more or less states that I think debian-legal is being completely anneal about the matter. Relax. I'm only suggesting that, since the wenglish upstream claims to have gone to lengths to keep the worldlist free of copyright, and he's used this wordlist, he might be a good person to ask about this. (Maybe he has a solid explanation of why it's OK; maybe he has an explicit statement from the source of the wordlist.) My experience with debian-legal is that, while they're picky about licenses (for very good reason), they tend to respond to questioned licenses with let's fix it, not let's rip it out, whenever possible. The question of whether wordlists are copyrightable came up before: http://lists.debian.org/debian-legal/2002/debian-legal-200208/msg00288.html There doesn't appear to have been any resolution, though, since it wasn't required at the time. (It may not be now, either.) -- Glenn Maynard
Re: [aspell-devel] Problems with aspell-en license
On Sun, Oct 20, 2002 at 01:30:04AM -0600, John Galt wrote: Actually it isn't a granting of right, but a Testimonial that those rights exist. It means that you have recourse if sued to go after the one making the Testimony for your costs. In Debian, a Testimony that rights exist has usually been enough to cover for a license, but the term license for that is rather ambiguous, I'd agree. The usage of the phrase to the best of my knowledge indicates to me that the person who wrote this is trying to avoid getting sued. If that phrase isn't enough to avoid liability if the best of his knowledge is wrong, he might want to change this anyway. And if it *is* sufficient to avoid liability (eg. it's noncommittal), I'd imagine it wouldn't be much of a Testimony. (At least that's what the text Brian quoted said.) -- Glenn Maynard
Re: [aspell-devel] Problems with aspell-en license
On Sun, Oct 20, 2002 at 01:52:18AM -0600, John Galt wrote: No, it's legal boilerplate. You can't testify to things that AREN'T to the best of your knowlege. At worst it's redundant. Okay. Actually it isn't a granting of right, but a Testimonial that those rights exist. It means that you have recourse if sued to go after the one making the Testimony for your costs. In Debian, a Testimony that rights exist has usually been enough to cover for a license, but the term license for that is rather ambiguous, I'd agree. Kevin, did you (or whoever wrote and is responsible for this) intend this as a testimony? -- Glenn Maynard
Re: [aspell-devel] Problems with aspell-en license
On Sun, Oct 20, 2002 at 04:43:19AM -0400, Kevin Atkinson wrote: Could you be more specific? I am not sure what you are asking. Okay, I read a bit further: it's a third party saying this. In any case, it doesn't seem to matter; I doubt a testimony that it's free for non-commercial use helps Debian much, anyway. You say: However since this Word List is used in the linux.words package which the author claims is free of any copyright I assume it is OK to use for most purposes. /usr/share/doc/wenglish/copyright does claim that it's free of copyright, but README.linux.words.gz contains the same at least for non-commercial purposes paragraph (line ~162). Maybe someone should ask the wenglish maintainer or upstream about this. (Too late at night for me.) -- Glenn Maynard
Re: [aspell-devel] Problems with aspell-en license
On Sat, Oct 19, 2002 at 03:23:45PM -0400, Kevin Atkinson wrote: I am merely quoting the closest thing to a copyright notice for all of the wordlist as generally required by copyright law. RMS basically said the word list meets FSF definition of Free (which should in term meet Debian guidelines). Meeting the FSF's definition of free does not always imply meeting Debian's definition of free, although they usually coincide. That should be all that you need to know. Even if it was true, it still wouldn't necessarily be sufficient to *convince* him (and d-legal) that it's correct. If you want I can add a note that all word lists used are FSF Free to the copyright notice. If a license clarification is needed, I don't believe this will help. -- Glenn Maynard
Re: cdrdao license issues show that cdrtools package is non DFSG, too?
On Thu, Oct 03, 2002 at 11:04:11PM +0200, Andreas Metzler wrote: | This software is under GPL with the following limitations: This alone reminds me of this: http://lists.debian.org/debian-legal/2002/debian-legal-200205/msg00062.html In short (as I understand it), placing software under the GPL with additional restrictions simply doesn't work. Are there any more succinct explanations of this? This problem comes up often, and I don't like pointing people at that particular post as an explanation (much of it being CUPS-specific, and the dual-licensing stuff will confuse people). I can't find anything about this in the GPL FAQ. -- Glenn Maynard
Re: what license is ?
On Thu, Sep 26, 2002 at 11:11:42PM -0500, Jeff Licquia wrote: I don't recall what makes advertising clauses DFSG-free. Unenforcability? It doesn't violate DFSG 9, because it's not making any claims on the other software. The advertising clause kicks in whether you distribute the software by itself, on a compilation CD, or whatever. Now, the advertising clause is GPL-incompatible, which is what I suspect you're thinking of with the additional restriction stuff. But lots of free licenses are GPL-incompatible. Well, if it was enforcable, it'd be a restriction on distribution: #1. I seem to recall people saying that this wasn't a problem since it's not within the bounds of copyright, and unenforcable, and could be ignored for determining DFSG-freeness. (I'm not sure that ignoring a license restriction because it's theretically not enforcable is a good *general* rule, but it seems reasonable enough here.) But I havn't followed a full discussion on this, so I don't know for sure. -- Glenn Maynard
Re: what license is ?
On Thu, Sep 26, 2002 at 02:33:39PM +0200, Samuele Giovanni Tonon wrote: i think that : The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be free software. is different from : All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by Niels Provos. because it doesn't place restriction on the software, but it just say: Hey if you try to sell/send CD's or brochures in which you mention libevent (also stegdetect has the same license), you have to esplicitally say that that sw was made by Niels Provos Read it as as an additional restriction, all additional materials mentioning ... It's still a restriction, and a cumbersome one. I don't recall what makes advertising clauses DFSG-free. Unenforcability? -- Glenn Maynard
Re: Crack license, is it free?
On Mon, Sep 09, 2002 at 05:19:03AM -0400, Zephaniah E. Hull wrote: The give away here may be problematic, however see below: 5. You may charge a reasonable copying fee for any distribution of this Package. You may charge any fee you choose for support of this Package. YOU MAY NOT CHARGE A FEE FOR THIS PACKAGE ITSELF. However, you may distribute this Package in aggregate with other (possibly commercial) programs as part of a larger (possibly commercial) software distribution provided that YOU DO NOT ADVERTISE this package as a product of your own. This is decidedly not DFSG free, it can go in non-free but it can't go in main. What part of this is not DFSG-free? -- Glenn Maynard
Re: Knuth statement on renaming cm files and Licence violation.
On Sun, Sep 08, 2002 at 10:56:47PM +0200, Martin Schröder wrote: Knuth's own page on CT lists only the trademarks of TeX and MF, so perhaps the CM trademark has gone unenforced or been dropped. Since none of the books (and none of the cm files) and no literatur on TeX mention CM as a trademark, I strongly doubt that there ever was one. For the purposes of this discussion, does it matter? -- Glenn Maynard
Re: autoconf/Artistic compatibility
On Tue, Sep 03, 2002 at 01:09:39AM +0100, Stephen Stafford wrote: Is there any incompatibility with using the Artistic license when using an autoconf(GPL) build system? /usr/share/doc/autoconf/copyright: As a special exception, the Free Software Foundation gives unlimited permission to copy, distribute and modify the configure scripts that are the output of Autoconf. You need not follow the terms of the GNU General Public License when using or distributing such scripts, even though portions of the text of Autoconf appear in them. The GNU General Public License (GPL) does govern all other use of the material that constitutes the Autoconf program. -- Glenn Maynard
Re: Bad license on VCG?
On Sat, Aug 31, 2002 at 05:54:07PM +1200, Nick Phillips wrote: 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, You omitted #3, which amends #1, and we're not obviously fine there. I don't know how you can possibly argue that the source we've received is the preferred form for modification when the author says the following: Thus, we have uglified some of the files in the distribution: these are the graph layout modules. These files are not anymore readable for human being, but they are readeable for the compiler. Not readable = not modifiable = not the preferred form for modification. Not the preferred form for modification = we can't distribute binaries. And given the package with which we have been provided, that is the obfuscated C. I think you're the only programmer I've ever seen claim that obfuscated source is a preferred form for modification. It's perfectly clear from the author's text that the obfuscated source is not intended to be modifiable, however. The definition of source is the preferred form of the work for making modifications, selected from those forms which are available to you. You're the one amending selected from those forms which are available to you. The GPL *doesn't say that*. Maybe it's your definition of source, but it's not the GPL's. -- Glenn Maynard
Re: Bad license on VCG?
On Sat, Aug 31, 2002 at 07:08:56PM +1200, Nick Phillips wrote: I knew someone would come up with that. There is however no other reasonable interpretation of the GPL possible. If you take your argument to its logical conclusion then I can immediately prevent you from distributing, say, gcc by going through the sources, improving the comments, and refusing to distribute my new version at all. No. Preferred form for modification is not preferred version for modification. If we both have a copy of unobfuscated GCC source, and yours has better comments, we both still have it in the same form: unobfuscated C. You just happen to have a better version. Your available would undermine the GPL. If I opted not to download source when downloading a GPL binary, and the source becomes unavailable, I could say that the source is not available to me and distribute the binaries. I could do the same if I lost it, and maybe even if I was under NDA. (It's not available! It's secret!) The GPL is designed to prevent you from distributing binaries at all if you can't also distribute source. -- Glenn Maynard
Re: Bad license on VCG?
This is a public discussion, and I'm not interested in having it in private. (as such, replies to other portions omitted) On Sun, Sep 01, 2002 at 12:36:24PM +1200, Nick Phillips wrote: It's moot really, as we almost certainly don't *want* to distribute it as 'free' anyway. I think the real question was whether it can be distributed at all (in non-free). Whether it can or not, I would prefer it not be; I share Jeff's view that behavior such as this is deceptive. -- Glenn Maynard
Re: Bug#156503: M$ true type fonts in non-free?
On Wed, Aug 14, 2002 at 09:37:19AM -0400, Eric Sharkey wrote: The problem with copyright lawsuits is that the opinion of the defendant has absolutely no bearing. What matters is the opinion of the plaintiff, who decides if a suit should be filed, and the opinion of the judge, who decides who wins. I've seen plenty of statements to the contrary on debian-legal; that may be a better place for this. -- Glenn Maynard
Re: TeX Licenses teTeX (Was: Re: forwarded message from Jeff Licquia)
On Thu, Aug 08, 2002 at 12:03:16AM -0400, Boris Veytsman wrote: Thomas, you rightly say that only Debian can interpret DFSG. While I agree with you in that, it seems that now you want to have the power to interpret the word free. This is, in my opinion, a far-fetched It's already been explained in detail that, on Debian lists, the word free is generally understood to mean DFSG-free. Complaining every time someone uses this well-established convention is a waste of time. idea. TeX community used the word free for decades. The example of TeX was one of the sources of inspiration for RMS and FSF, which, in its turn, inspired Debian project. TeX is the grandfather of the free software community. If it is not enough free for you, this is your problem. If it is not free enough for being DFSG-free, I would think it is a problem of Debian, not of a problem of TeX. Debian might well have stricter standards for free software than the TeX community. Which one is wrong is completely irrelevant to the discussion. Saying things like it's your problem, don't bother me about it is counterproductive. You see, it is a honor to be called an author of free software. However, if you do not consider Knuth to be one, I too respectfully decline this honor from you. You know, I'd rather be in the same boat with Don. Software being free depends on its license, not its author. I am not a lawyer, so I cannot claim understanding of intricacies of licenses. However, I think I understand Knuth's lucid writings about his intentions with respect to TeX. He many times said that he wants that after his death TeX version number is frozen at pi, and MF number frozen at e, and absolutely no change is made to them thereafter. It If this is done, then the software is non-free. I don't know if the TeX community agrees, but I think most people--and not just people sharing Debian's views--would agree that software whose license forbids any changes to be made is unambiguously non-free. However, it's certainly not clear that this is the case. You make claims, but you don't support them. From my reading of http://groups.google.com/groups?selm=3c2q2h%24oj1%40sifon.cc.mcgill.ca he doesn't want a modified TeX to be called TeX. is evident for me that he does not want TeX to be gradually improved; rather he visions completely new systems based on TeX ideas and code. Completely new systems based on TeX code? Huh? He wants TeX to be his monument -- these are his exact words. He speaks in the third person? :) -- Glenn Maynard
Re: TeX Licenses teTeX (Was: Re: forwarded message from Jeff Licquia)
On Thu, Aug 08, 2002 at 01:38:27AM -0400, Boris Veytsman wrote: (my reply is a subset of TB's; elided) Completely new systems based on TeX code? Huh? Glenn, if you do not know about such systems, this does not mean that they do not exist, right? Boris, if it's based on TeX code, it's not a completely new system. -- Glenn Maynard
Re: TeX Licenses teTeX (Was: Re: forwarded message from Jeff Licquia)
On Wed, Aug 07, 2002 at 10:40:14PM +0100, Andrew Suffield wrote: I am afraid you cannot do this: since TeX is trademarked, you cannot substitute a new font for it without violating trademark. So the package name gets changed, and a couple lines gets added to the description. Boo hoo. Trivial and irrelevant. Which has been done, already, no? s/tex/tetex/. -- Glenn Maynard
Re: TeX Licenses teTeX (Was: Re: forwarded message from Jeff Licquia)
On Wed, Aug 07, 2002 at 06:26:30PM -0400, Boris Veytsman wrote: So the package name gets changed, and a couple lines gets added to the description. Boo hoo. Trivial and irrelevant. Which has been done, already, no? s/tex/tetex/. Glenn, to say the truth, I am appaled by the low signal/noise ratio on the group. This question was already discussed here and answered by David Carlisle. Why do I need to repeat? He said the package name gets changed. The package name is tetex, not tex, so that's been done. (Package name has a very specific meaning in Debian, and there is no tex package in Debian.) The biggest change the description would need is s/TeX distribution/TeX-like distribution/. You're claiming packaging the TeX software is in violation of the TeX trademark, and you present this as if it's a showstopper for his suggestion, when it's clear that the most you would have to do is a little work with sed. Ok, I am patient. The tetex-* packages distributed by Debian are NOT free TeX-like systems. Instead, they are sets of integrated typesetting tools, including: So the package itself is not TeX, and does not need renaming. Do you need me to repeat this slowly? Okay, I'll be direct. Fix your attitude and adjust your tone. My tolerance for condescension and offensiveness has its limit. Everyone else on this list, despite differences of opinion, miscommunication and frustration, is being civil to one another, even if it takes conscious effort. Please follow suit. -- Glenn Maynard
Re: TeX Licenses teTeX (Was: Re: forwarded message from Jeff Licquia)
On Wed, Aug 07, 2002 at 07:23:24PM -0400, Boris Veytsman wrote: Note that etex, omega and pdftex do not make this claim: [EMAIL PROTECTED]:~$ etex This is e-TeX, Version 3.14159-2.1 (Web2C 7.3.7) [EMAIL PROTECTED]:~$ pdftex This is pdfTeX, Version 3.14159-1.00a-pretest-2004-ojmw (Web2C 7.3.7) [EMAIL PROTECTED]:~$ omega This is Omega, Version 3.14159--1.23 (Web2C 7.3.7) Copyright (c) 1994--2000 John Plaice and Yannis Haralambous I said in my other mail that Debian *could* delete banner from tex and say something like This is deb-TeX. My argument is that this would be of very limited use for the TeX users community. While this community supported and supports new programs like etex, pdftex, omega, etc, I do not think it would support a conscious effort in deleteing the common reference point. The case here is making the TeX distribution in main use a different font by default, due to licensing issues. If the CM fonts are irrepairably non-free, this is unavoidable. However, if this is done, the packages could be set up such that installing the non-free font package would also make it revert cmr10.mf to the real CM font, so installing the renamed TeX plus the non-free package would give you the expected, unmodified behavior. (Presumably whatever font replaced cmr10.mf would have its own name as well, so people who actually want that font wouldn't be affected.) Perhaps that would be less convenient than having CM in the default package, but I don't think it would be of very limited use. I certainly don't think the act of calling the program deb-TeX makes it any less useful to anyone; that's purely cosmetic. -- Glenn Maynard
Re: TeX Licenses teTeX (Was: Re: forwarded message from Jeff Licquia)
On Mon, Aug 05, 2002 at 07:37:22PM +0200, Frank Mittelbach wrote: really, what is behind all this aren't file names but works (plural), and each of such works is supposed not to claim itself as the original (to other related works) after it was modified, eg a font is a work and plain.tex is a work as well as tex.web. Are Postfix and Exim claiming to be Sendmail, by including a /usr/sbin/sendmail interface? No; it's just a filename used for compatibility, because many programs expect it. File renaming requirements are not DFSG-free. Neither DFSG 3 nor DFSG 4 permit them. Only a requirement to rename the *work* is permitted. ...with work not being defined, the word file being used etc etc. ... The DFSG is a set of guidelines; not a set of laws, and not a license. It doesn't precisely define every term used. Some people might not like this, and would prefer to see a completely unambiguous, uninterpretable, legalistic DFSG; but that's not what we have. Branden's interpretation of the sentence in question (The license may require derived works to carry a different name or version number from the original software.) is both the obvious one (IMO), and a practical one: generally speaking, filename restrictions are much more of a burden than restrictions on the actual name of a work, because filenames are functional and the actual name of a work is not. -- Glenn Maynard
Re: ACL - The Ada Community License
On Thu, Aug 01, 2002 at 07:33:53PM +1000, Brian May wrote: Selling the library is not forbidden. Really? You may not charge a fee for this Ada library itself. Allowing a reasonable copying fee but saying that you can't charge for the library itself doesn't, AFAIK, make the license fail DFSG. (The question here was whether this makes it GPL-incompatible.) This discriminates against people who cannot put copyrighted works into the Public Domain. I questioned this, but there was no further discussion. (I'll CC you this reply separately.) -- Glenn Maynard
Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)
On Wed, Jul 31, 2002 at 10:49:32PM +0100, David Carlisle wrote: If pushed, I will concede that this is illogical, and the rule should really be filename limitations make a package non-free It's fine for you as an individual to think that _should_ be the case (I happen to disagree but that's not relevant either) But Debian can't take that position unless it changes its definition of Free by changing its guidelines. Debian very easily *can* take the position that filename limitations violate the DFSG, because it is a limitation on modification not explicitely allowed by DFSG#4. (I agree with the line of thought that it shouldn't be allowed at all; how inconvenient it is is an ugly bag of worms, best avoided.) If you're actually saying that Debian isn't *permitted* to take that position, you'll need to explain further. Debian is well within its rights to interpret its own guidelines. -- Glenn Maynard
Re: ACL - The Ada Community License
On Tue, Jul 30, 2002 at 09:19:29AM -0700, Walter Landry wrote: The written offer for source code is an allowable option under 3(a) of the Ada license. It say that you must make your modifications ... Freely Available. Freely Available, as defined in the license, can include shipping and handling. So again, it doesn't seem to preclude any option offered by the GPL. It's unclear to me what falls under 3 and what falls under 4: it seems as if 3 is for all modification and distribution--it mentions executables--and 4 is for distribution of binaries only. However, 4 seems more restrictive than 3; it doesn't have the freely available option. So, I'm a bit confused. -- Glenn Maynard
Re: ACL - The Ada Community License
On Tue, Jul 30, 2002 at 11:21:38PM +0200, Florian Weimer wrote: 3 You may otherwise modify your copy of this Ada library in any way, provided that you insert a prominent notice in each changed file stating how and when you changed that file, and provided that you do at least ONE of the following: This discriminates against people who cannot put copyrighted works into the Public Domain. Does it? 3a says you must either put it into the public domain *or* otherwise make them Freely Available; it's extremely loose about that definition. Probably too loose; it's not really clear to me what's allowed and what's not. If I distribute binaries to someone, and include a written offer (GPL-style), is that satisfying 3a? It's freely available to the person I'm giving binaries to, but nobody else. (I'd suspect that if this didn't satisfy 3a, it means they expect you to make the changes publically available if you distribute binaries at all; this would violate the desert-island scenario, which might make it non-free.) -- Glenn Maynard
Re: ACL - The Ada Community License
On Tue, Jul 30, 2002 at 09:19:29AM -0700, Walter Landry wrote: Selling the library is not forbidden. The definition of reasonable copying fee is vague enough that it doesn't restrict you any more than the GPL. You can also charge whatever you want for support. This is Debian's interpretation of reasonable copying fee, and why that restriction doesn't cause it to be DFSG-unfree. However, is this also the FSF's interpretation for GPL compatibility? -- Glenn Maynard
Re: forwarded message from Jeff Licquia
On Tue, Jul 23, 2002 at 06:32:57PM +1000, Anthony Towns wrote: Uh, _technically_ you can symlink it (or write a wrapper), but _technically_ you could just mv it, too. But we try to adhere to the spirit as well as the letter of the license, don't we, which would stop us from doing that, don't we? Personally, although IANAL, I'd've expected Nobody's implying Debian wants to do anything like this, of course. that such obvious attempts at avoiding license restrictions wouldn't get you all that far with a judge either. We're not willing to let people use dynamic linking as a way of avoiding the GPL's tentacles, in a pretty similar situation. A third party, who isn't even using Latex (and so not under its license), could create a symlink. IANAL, either, but apparently that's the purpose of trademarks. Anyway, this one seems a moot point; the real problem here seems to be individual components, not Latex. (Presumably, even if they had the resources to trademark individual components, they couldn't trademark article.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Transitive closure of licenses
On Tue, Jul 23, 2002 at 03:58:55PM -0600, Joe Moore wrote: Are all derived works from DFSG-free packages DFSG-free? No. The BSD network stack is DFSG-free. But Microsoft's implementation of it is not. But that's due to them licensing their changes under another, non-free license, not due to the actual feature changes in the code. If I remove any given features from a BSD-licensed program, it remains free. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Towards a new LPPL draft
On Tue, Jul 23, 2002 at 12:58:01PM -0700, Walter Landry wrote: - you must rename the whole of LaTeX in your modified copy AND distribute a pristine copy of LaTeX as well. This is specifically allowed by DFSG #4. The Q Public License uses Branden is asserting that DFSG's patch exception doesn't apply to non-compiled languages, though, due to its at build time wording. (I tend to think that the wording of the entire paragraph is compiled- language-centric, and that patches that are applied at installation- time, without a building as such, is in the spirit of #4. I can sympathise with taking the statement literally, to reduce the scope of a disliked clause, however.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tetex/tex license
On Tue, Jul 23, 2002 at 07:00:39PM +0200, Frank Mittelbach wrote: listing them, would be a nice try but hopeless as you would need to keep track of i would guess more than 1000 individual works that end up in tetex texmf trees. That would not be automatable and as a manual process it would be always wrong. One could and most likely should however mention te licenses of the main parts and perhaps list which licenses you might find. If the licensing is so diverse, poorly understood and poorly documented that it's impossible to maintain a debian/copyright file, it doesn't seem safe to distribute it at all. Don't give up so easily, though. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
