Re: firmware status for eagle-usb-*
Michael Poole [EMAIL PROTECTED]: My opinion is that if someone wants Debian to distribute the firmware, treat it as software, and apply the DFSG to it; otherwise, treat it as outside the Debian system in the respect that the driver should not be considered to depend on the firmware. I think this is consistent with our practice for other things on the far side of a low-level interface. This makes sense to me. I do not think applying a very broad idea of dependency is a good idea: it goes beyond what copyright licenses can require, is not likely to lead to more free firmware, and leads to a bigger patchset having to be maintained for the kernel. Another possible argument is that Debian probably doesn't want to get involved in assessing the freeness and compatibility of components that Debian does not distribute. For example, consider the case of one of Debian's bootloaders depending on the BIOS. There might be a DFSG-free BIOS for some platform, but if Debian doesn't distribute it then Debian probably doesn't want to get involved with testing whether Debian's bootloaders are compatible with it. However, none of this answers the question of under what circumstances a driver can be permitted to suggest rather than depend on a piece of firmware that Debian does distribute (in non-free). For example, what if there are unsubstantiated rumours of the driver in some cases, perhaps with old or prototype hardware that is not generally available, working without the firmware or with some alternative free firmware (that Debian doesn't distribute)?
Re: non-free firmware: driver in main or contrib?
Matthew Garrett [EMAIL PROTECTED]: The social contract uses require, which is a stronger term than policy's depend. The driver software requires the portion of the hardware that can also be described as software. I assume the relevant quote is: We will never make the system require the use of a non-free component. I don't think this sentence can be understood by looking at each work through a magnifying glass. You need some kind of context (beyond the text of the Social Contract) to know what was intended here, not a detailed analysis of what require means. For example, you could understand the sentence to mean: We won't make the whole system dependent on a non-free component, but parts of the system might be designed to communicate with non-free software and therefore be useless without the corrresponding non-free software. Or it could mean: We won't deliberately make the system dependent on a non-free component, but if it so happens that there is no free software that implements the other side of some protocol, then that's a problem with the rest of the world, not with Debian. I don't claim it does mean either of these things, just that the sentence in isolation could be interpreted that way.
Re: non-free firmware: driver in main or contrib?
Brian Thomas Sniffen [EMAIL PROTECTED]: Huh? If a driver requires a firmware blob be copied from a driver CD, Please repeat after me: drivers do not require firmwares, hardware devices require firmwares. And the driver requires a functioning hardware device. Thus, the loadable firmware is in the dependency tree of the software Debian ships. There are two slight problems with your argument here: (1) You wrote a functioning hardware device, i.e. not necessarily the particular device that requires the particular firmware. (2) If a driver requires a functioning hardware device, then presumably Debian can't ship the driver in main because Debian doesn't include any hardware devices in any part of its distribution!
Re: Is javacc DFSG compliant?
Ken Arromdee [EMAIL PROTECTED]: I know that you must acknowledge that doesn't mean you need to mail Sun a written statement bearing an acknowledgement, but I don't think that makes a difference. Would a license you must acknowledge that Jesus is Lord be free? I would guess not, because it would mean that someone who has publicly claimed otherwise and wishes to continue doing so does not have a licence. Or a license you must acknowledge that any damage you might suffer as a result of using this software is no greater than 99 cents? That sounds like a weaker version of the warranty disclaimer in the GPL. If not, why is you must acknowledge something that might put you at a disadvantage in court free? Presumably because acknowledging the truth of something that is true is no burden. For example, you must acknowledge that this software is released under the XPL is probably acceptable in the text of the XPL, a hypothetical licence. The trouble with the no-nuclear acknowledgement is that it might not always be true: someone might want to create a derived work that is licensed for use in nuclear power stations.
Re: non-free firmware: driver in main or contrib?
Nathanael Nerode [EMAIL PROTECTED]: There is an argument that the whole of Debian belongs in 'contrib' rahter than 'main' because there is no entirely free (as in speech) machine on which it can run. I think there are free CPU designs around and you could probably compile a free emulator to run on one of them. Would that solve your problem? In general you would have to stick to using an emulator, as it is impossible to make a hardware implementation of some architectures without infringing certain US patents.
Re: Bug#265352: grub: Debian splash images for Grub
Josh Triplett [EMAIL PROTECTED]: Trademark problems only arise when the image is used in a particular way. I would think that Debian is not obliged to and cannot give permission for all possible uses of Debian software. We most certainly can and should. We can't give permission for people to use Apache to implement one-click shopping. That's a far greater and far more serious restriction, and one more direcly related to software, than the trademark restriction on the use of the Debian logo, and yet we don't argue that Apache is non-free because of it.
Re: Bug#265352: grub: Debian splash images for Grub
Josh Triplett [EMAIL PROTECTED]: Please note that I did not say that a work is non-free if it can be transformed to contain a trademarked item, any more than a work is non-free if it can be transformed to contain a copyrighted work to which we don't have a Free license, such as the source code to Microsoft(TM) Windows(TM). :) This doesn't really make sense. The only way you can transform a work to contain a different copyrighted work is by including parts of the other copyrighted work, which means you're transforming that other work, not just the first work. The comparison between trademarks and patents makes some sense; this comparison with copyright doesn't. I am only concerned with whether a given work, and all derived works of that work, have permission to use the trademark. Which trademark? Trademarkedness isn't a property of the work; trademarks exist independently of the work. I have no problem with Debian holding and licensing rights under both trademarks and copyrights that apply to Debian's works. The whole point of a trademark restriction is that it doesn't just apply to one's own works. Therefore, if we want to ship the logo in main, we need to grant a DFSG-Free license to the logo itself and to derived works of the logo. Why the if clause? Debian owning a trademark is a restriction on all works whether or not they include a representation of the trademark and whether or not Debian ships them, so surely what you are really saying is that Debian should not restrict the world's freedom by owning a trademark, which seems to me like a reasonable, if extreme, point of view.
Re: Bug#265352: grub: Debian splash images for Grub
Nathanael Nerode [EMAIL PROTECTED]: Just put a This copyright license does not grant a trademark license disclaimer after your choice of standard license, and I think we're set, right? That's what I would have thought. Does anyone disagree? (However, I would add something along the lines of 'Debian' and the Debian swirl are trademarks or registered trademarks of ... in front of This copyright licence does not ) (With the image released under a free software licence Debian would presumably have one less stick to bash someone over the head with if they were to abuse the image: it would have to be just trademark infringement rather than trademark and copyright infringement. However, if this is the only disadvantage, I would have thought it is outweighed by the advantage of Debian being able to package its own trademark without becoming a public laughing stock by making a hypocritical exception to its own DFSG.)
Re: Bug#265352: grub: Debian splash images for Grub
Josh Triplett [EMAIL PROTECTED]: A Free logo, like any other Free image or Free work in general, must be usable for any purpose. It is, provided you modify it sufficiently. You could use it to make your own trademark, for example. On the other hand, if you take the source code to GCC and format it into the shape of a Coca Cola trademark, then you can't use it for selling soft drinks. Does this mean that GCC is not free? If this right is restricted, whether by copyright, patent, trademark, or any other law, then the work is non-free. Should this include criminal law, such as laws against murder? :-) Obviously Debian can make up its mind either way on this question, but the point of view according to which trademark licences are not required for a bunch of data to be DFSG-free seems more internally consistent to me and more useful in practice. So personally I'd recommend going with that direction.
Re: Bug#265352: grub: Debian splash images for Grub
Josh Triplett [EMAIL PROTECTED]: I acknowledge that all of those classes of law are quite different in many ways. Nevertheless, the DFSG does not differentiate among methods of restricting Freedom. That's because they're guidelines, though you seem to want to apply them legalistically without regard for the practical consequences. In particular, you seem to claim that because the DFSG doesn't distinguish between copyright and trademarks Debian is compelled to treat them the same way, though it's not clear to me how you can treat two such different things the same way. However, if we use the Debian trademark to restrict the rights of users over the actual Debian logos in the distribution and/or any derivative works of that logo, Are the actual Debian logos in the distribution, or does the distribution merely contain a picture of the actual Debian logos? That may sound like a pointless philosophical question but I think it lies at the root of the some of the disagreements in this thread. Trademark problems only arise when the image is used in a particular way. I would think that Debian is not obliged to and cannot give permission for all possible uses of Debian software.
Re: GFDL and Debian Logo
Walter Landry [EMAIL PROTECTED]: The Debian Open Use Logo is not compatible with the GFDL. If fair use is really that limited in Germany, then the German wikipedia is going to have to purge all logos. I doubt that any have anything approaching a free license. As a comparison, the English entries for IBM and HP have their logos, while the German entries do not. So at least that is consistent. Perhaps I'm being thick here, but what legal difference does the language make? Doesn't the German Wikipedia use the same licence as the English Wikipedia, and aren't they both accessible in Germany?
Re: Bug#265352: grub: Debian splash images for Grub
Josh Triplett [EMAIL PROTECTED]: First of all, even if it is the case that we can't offer a DFSG-free license for the logo without allowing it to become diluted, then that does not exempt it from being DFSG-free. I believe the suggested licenses were very clearly non-DFSG-free. Does it qualify as DFSG-free if you give it a free copyright licence without granting any kind of trademark licence? If it doesn't, what exactly are the situations in which a trademark licence is required in addition to a copyright licence? I note that many packages contain the word Microsoft without there being a DFSG-free licence for that trademark, so a line would have to be drawn somewhere between the two cases; I can't immediately see how or why.
Re: GPL or any greater version (was: NEW ocaml licence proposal)
Raul Miller [EMAIL PROTECTED]: What rights from the GPL are being restricted by using a specific version of it? The right to use other versions of the GPL. Have you considered the consequences of your weird legal theory? Presumably the Linux kernel would be undistributable because it contains both GPL 2 and GPL =2 code. Also, the main reason for the or any later version stuff would disappear. The purpose of this is to allow the FSF to correct bugs in the GPL. If projects licensed under GPL =2 had to be licensed under GPL =2 forever then it would not be possible to upgrade them to GPL 3 by licensing new code under GPL =3. Fortunately your interpretation of the GPL is not the standard one and seems rather difficult to justify.
Re: CeCILL again...
Glenn Maynard [EMAIL PROTECTED]: I think that it's fine to have licenses in other languages; I just think that there should always be an authoritative license in English, too. I don't think that's acceptable as a general rule. The licence is binding on the licensor, who should not have to be bound by a text in a language that they don't understand properly. I don't think it's acceptable to have a /usr/share/doc/foo/copyright that doesn't include a *binding* English version. The general case would lead to having those files in a dozen different languages, and nobody anywhere would actually be able to understand their rights (except for linguists); everyone would have to trust in a non-binding translation and the word of somebody they don't know that it's equivalent to the real terms. In practice almost everyone relies to some extent on other people's opinion of the licence even when it's written in their own language. Also, it seems rather unreliable to have a text in English that is to be interpreted under French law. There might be nasty surprises for everyone if such a thing ends up in court. To put it another way, even an English lawyer might prefer the text to be in French if it is to be interpreted under French law. Of course, if the licensor is happy to parallel-license under several language versions, I would encourage them to do so. It would be very helpful. I just wouldn't want to make it a Debian rule that they have to do that.
Re: CeCILL again...
Glenn Maynard [EMAIL PROTECTED]: The license is binding on the licensee, Not in the same way, assuming it really is a licence, rather than a contract. who should not have to be bound by a text in a language that they don't understand properly. (The only solution available to me, in that situation, is to not touch the software.) Then you have a solution. Use it. But please don't try to force your solution on other people who may be perfectly happy, or even happier, with a licence in French.
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Brian Thomas Sniffen [EMAIL PROTECTED]: Yes, it does -- it prevents me from incorporating any patch to which I don't own the copyright. There is no license I can have from anybody which permits me to grant a license like this to the initial developer -- granting new licenses is something only the copyright holder can do. Not true: it's quite normal to give permission for sublicensing. Some kind of do whatever you like with this patch licence would be sufficient in this case. You could argue that someone who submits a patch to a Debian maintainer of a QPL-licensed work is implicitly allowing the maintainer to sublicense the patch in the manner required by the QPL just as someone who submits a patch to a GPL work is often assumed to be licensing their patch under the GPL.
Re: Netatalk and OpenSSL licencing
Ken Arromdee [EMAIL PROTECTED]: Then any Windows program which uses undocumented Windows system calls (of which there are plenty) is a derivative work of Windows and can't be distributed without Microsoft's permission, at least until someone discovers the system calls and implements them in Wine? Probably not, but Windows plus the program is probably a derivative work of Windows, rather than mere aggregation, which means that if Windows were licensed under the GPL then the program would also have to be licensed under the GPL. However, since Windows is released under a non-viral licence, this problem doesn't arise :-) (I think you've made the usual mistake of confusing A is a derivative work of B with A plus B is a derivative work of B.)
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Walter Landry [EMAIL PROTECTED]: The problems concerning QPL 3 remain, Not so great. but consensus about it has been much more dubious, I haven't seen anyone seriously dispute my analysis in http://lists.debian.org/debian-legal/2004/07/msg01705.html I'm not convinced that QPL 3 makes it non-free. Of course I don't like QPL 3, so don't expect me to spend much time arguing for it, but I have mentioned it a few times. For example: http://lists.debian.org/debian-legal/2004/07/msg01315.html I don't see a clear qualitative distinction between the licensing required by QPL 3 and the licensing required by the GPL, for example, that makes one a fee but not the other.
Re: Web application licenses
Josh Triplett [EMAIL PROTECTED]: But standard advice on network security is *not* to advertise specific banners. I don't think much of that advice, but I sure do see a lot of it. Is it free to make this kind of requirement of users of the software, that they ignore good security practice? If your network would be insecure if someone knew the versions of software you run, then your network is insecure. Security isn't just a binary quality. In particular, you should worry about someone (or a worm) using a search engine or scan of IP addresses to find vulnerable machines. So, if you do advertise your software version on a web page, it's probably helpful to tell Google, etc not to index that page, and if you put the information in a form that makes it harder to automatically query, that might help, too.
Re: SRP
Andres Salomon [EMAIL PROTECTED]: I'm not sure how to interpret this; I'm not familiar enough w/ SRP-Z. Is this a different algorithm, such that the source would need to be significantly modified (such that SRP-Z is essentially a separate thing, convered by its own license; converting SRP-3 to SRP-Z is just as difficult as converting openssh to SRP-Z)? Is this merely a layer on top of SRP-3 (thereby restricting a derived work, and making it DFSG-incompatible)? If you take that argument to its logical conclusion then no software is DFSG-free, because patents restrict all derived works. (Given any free software, it is possible to modify it so that it infringes some patent that is being actively enforced; therefore no free software can be freely modified.)
Re: Quick(?) Questions on Choice of Law Venue
Anthony DeRobertis [EMAIL PROTECTED]: Lastly, if there is a choice of venue clause, can Arthur force Tom to appear in France, where he could be arrested for violating French hate-speech laws? I don't think you have to appear in person for a civil case. However, it has just occurred to me that a case might be prejudiced by one party's inability to use certain witnesses who for various reasons might not be able to travel to the country where the case is being heard, so there's another area for wild speculation ...
Re: RPSL and DFSG-compliance
Matthew Garrett [EMAIL PROTECTED]: In its current form, I think there'd be few people who would accept the RPSL as DFSG-free. If you terminated patent grants rather than the copyright license, I think there'd be a sizable proportion of developers who would accept it as DFSG-free. See also the IBM Public License, Version 1.0, which GNU considers to be free: http://www.gnu.org/licenses/license-list.html The relevant clause of that licence is: If Recipient institutes patent litigation against a Contributor with respect to a patent applicable to software (including a cross-claim or counterclaim in a lawsuit), then any patent licenses granted by that Contributor to such Recipient under this Agreement shall terminate as of the date such litigation is filed. In addition, If Recipient institutes patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Program itself (excluding combinations of the Program with other software or hardware) infringes such Recipient's patent(s), then such Recipient's rights granted under Section 2(b) shall terminate as of the date such litigation is filed.
Re: ocaml, QPL and the DFSG: QPL 6c argumentation.
Sven Luther [EMAIL PROTECTED]: I create a program P that consists of an executable X linked with a library L. X links with L, but P is a modification of L, albeit a modification that was made by adding material to L. Ok, in this case, you can either distribute it together in the L tarball, and it is a modification, or you can distribute it separatedly, and in this case it is a work linked with the software. And the first option may be sufficient for DFSG-freedom. In any case, if you consider it as a modification, you have to provide a patch for it, and if you make binaries, they have to be QPLed. If you provide it separatedly, you can chose a more liberal free licence, but you must honor the upstream request covered by 6c. Then you're agreeing with me. The first way (QPL 3) is on the face of it very restrictive compared with the second way (QPL 6) - as you say, you have to QPL the whole thing - but if the first way is free, then the licence is free, and if the first way isn't free, then the licence isn't free, or at least that's the point of view I'm trying to argue for in this subthread. original modified work. (The original modified work is almost as good as granting additional restrictions. I think we should do a new licence using both those expressions!)
Re: the meaning of 'the same terms in DFSG 3, and why the QPL fails it (was: An old question of EGE's)
Branden Robinson [EMAIL PROTECTED]: DFSG 3 was intended to forbid licensors from placing themselves in a specially advantaged position. If not, why doesn't DSFG 3 simply say: The license must allow modifications and derived works. ...hmm? Perhaps DFSG 3 is looking at it from the point of view of the receiver of the modified work rather than the modifer: A creates a QPL work, B modifies it and gives the modified version to C. Then C gets the modified work under the same licence as the original work was distributed. However, if you really want to know how DFSG 3 was intended then you must talk to the people who wrote it.
Re: ocaml, QPL and the DFSG: QPL 6c argumentation.
Sven Luther [EMAIL PROTECTED]: No, it grants some additional restrictions, which is why we have to consider it. be QPL (with a licence grant to the initial developer). With section 6 only the part that contains the original software has to be QPL; the rest can have any free licence, more or less, except that there's an additional requirement (6c) that might be problematic. Edmund. Why don't you reply to my above question. Because I have already expressed my reasoning as clearly as I can. The concept of granting additional restrictions doesn't make much sense to me. Note that QPL 6 does NOT start with If you develop ...; it starts with You may develop On the face of it, I can't read this as a further restriction on QPL 3. Obviously, if upstreams claims it is, then I will have to accept it as such, and then I can agree that the QPL is not a free software licence, because I don't think the restrictions in QPL 6 are compatible with the way the DFSG are traditionally applied. Anyway, I suggest you wait a bit before talking to upstream about QPL 6, because it might turn out that the consensus is that it doesn't matter for DFSG-freeness.
Re: ocaml, QPL and the DFSG: QPL 6c argumentation.
Sven Luther [EMAIL PROTECTED]: since a given software can either be a modification of the original software (which can replace it) or link with the original or modified software (and thus use it). One last attempt: I create a program P that consists of an executable X linked with a library L. X links with L, but P is a modification of L, albeit a modification that was made by adding material to L. If the word modify excludes modifications made by adding stuff then I suspect that quite a lot of licences will need reexamination.
Re: ocaml, QPL and the DFSG: QPL 6c argumentation.
Sven Luther [EMAIL PROTECTED]: Anyway, there's a third chance of getting 6c past debian-legal, which someone brought up in a different thread and which might be the strongest yet: (3) Claim that the rights granted in section 3 of the QPL are sufficient to make the software free so there is no need to even look at section 6. No, since they apply to two different things. QPL 3 and 4 is for modifications of the original software, while QPL 6 is for applications linking with the software. I'm surprised to see you dismiss so readily what is potentially your strongest argument, but perhaps it's a trick to make me argue your No, because i honestly believe that the QPL makes this modified work/linked work distinction, so you can't use this case. Do you think that the QPL without section 6 is a free software licence? If YES, how do you argue that section 6 detracts from the permissions granted by section 3? If NO, how do you argue that the language of section 3 excludes the kind of derived work that is permitted by section 6?
Re: ocaml, QPL and the DFSG: QPL 6c argumentation.
Sven Luther [EMAIL PROTECTED]: Do you think that the QPL without section 6 is a free software licence? I am tentatively in favor of that, yes. If YES, how do you argue that section 6 detracts from the permissions granted by section 3? They do not, since they apply to two different clases of software. That seems like a contradiction to me. You seem to be saying that the QPL without section 6 is a free licence, section 6 does not detract from the permissions granted by section 3, and yet we have to look at section 6 in detail to tell whether the QPL is free. How does that work? What is your argumentation to ignore the above and makes as if modified work and linked works are one and the same thing ? It looks to me like section 6 grants some additional permission in the case of mere linking. Without section 6 the entire work would have to be QPL (with a licence grant to the initial developer). With section 6 only the part that contains the original software has to be QPL; the rest can have any free licence, more or less, except that there's an additional requirement (6c) that might be problematic. So the argument here is that the DFSG requires the conditions in QPL 3 to be acceptable, and if they are, then the DFSG is satisfied and we don't have to look at QPL 6. I'm concerned that you might be heading in the direction of claiming that Debian requires explicit permission to link in addition to general permission to distribute modified versions, in which case you are presumably about to claim that BSD licences are non-free because they don't have a linking section.
Re: ocaml, QPL and the DFSG : QPL 3b argumentation.
Sven Luther [EMAIL PROTECTED]: First point, this only applies to released software. Also let's see what the trolltech annotation has to say about it, since it covers some doubt in the language above : Firstly, I would think that the Trolltech annotation is irrelevant unless INRIA have publicly stated that it applies to their licence. Secondly, even if they have done that it would probably only help to disambiguate the licence where it is ambiguous, and I don't think it is ambiguous in this case. Thirdly, I don't think the bit you quoted from the annotation out of context means what you think it means. So, to save time, I'd rather just ignore the annotation for now. I think the effect of 3b is to give the initial developer the right to incorporate modifications into their code which they can subsequently licence in any way they like provided they also make it available under the QPL. I think you agree with this really, so I don't know why you dragged the annotation into this. The only way this would be considered as non-free is under the DFSG #1, when you consider the fact of giving those right back to the upstream author a fee or royalty. Ok, this can be argued, and probably will be in a subthread of the corresponding topic, but my own position is that if we consider it a fee, it must include a cost to M to fullfill it, and since M still keeps the whole right to the patch he wrote, and in no way loses any of his rights to it, it cannot really be considered a fee. I disagree with that argument. Firstly, I don't think the reference to royalty of other fee in DFSG #1 is meant to be interpreted narrowly; I think it's meant as an example of a restriction. Secondly, giving someone a right which they didn't already have does potentially include a cost because it prevents you from asking for payment in return for giving that right. However, I think there is another argument for 3b not making the QPL non-free: M can choose to grant everyone a BSD-like licence for the modifications, and then the initial developer doesn't get any right they didn't already have. Another way of stating the same argument: a licence that forces modifiers to licence their modifications to the initial developer is no worse than a licence that forces modifiers to licence their modifications to everyone, and the latter is arguably still free. I'm undecided, but I think I can just about accept 3b as consistent with the DFSG. Note that I'm not a DD, so my opinion is irrelevant. Only my arguments might count, if you choose to accept them.
Re: ocaml, QPL and the DFSG: QPL 6c argumentation.
Sven Luther [EMAIL PROTECTED]: | 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. The upstream author can request a copy of the items, if they are distributed, but not openly distributed (in which case he just needs to get the public version). One could argue again that this would mean a breach of the DFSG #1, since the right of the author to those software would be considered a fee or royalty, but the same argumentation as above makes me reject that. I assume the same argumentation as above refers to your argument about it not costing anything which you used in the 3b thread. I disagree about it not costing anything. Even if you are entitled to charge for the cost of data transfer there is still the cost of administration. The cost of administration is probably not much, but in many cases it's more than the cost of sending a postcard, and Debian has, I think, always regarded as non-free a licence that requires you to send a postcard to the author. Debian has also regarded petting a cat as a restriction or cost, so I think it would be a big break with tradition to accept 6c as an allowable restriction. In some cases the administration might cost quite a lot, if you need legal approval or if you're on a Deser... sorry, I won't mention that possibility! Furthermore, the distribution of these items is governed by the QPL 6a and 6b, It's not clear to me that 6c is governed by 6a. I would guess it probably isn't, but it's not worth arguing, because the cost of administration is probably a bigger burden anyway. So I see two chances of getting 6c past debian-legal: (1) Claim that the cost of administration is negligible. I think this goes against tradition. (2) Claim that the developer can avoid 6c altogether by making sure the items are available to the general public. Unfortunately, there's no precedent that I know of for Debian regarding as free a requirement to make software available to the general public when it is distributed, so you'd have to try and build a consensus for that rather than argue legalistically. In either case you'd still have to cope with the privacy problem, which you don't seem to have mentioned in your summary. It's not (in my opinion) implied by the DFSG, but there seems to be quite a lot of support for the idea that a free software licence should permit private distribution within a group.
Re: ocaml, QPL and the DFSG: Choice of venue argumentation.
Sven Luther [EMAIL PROTECTED]: How would that work? How can you sue someone based on a unilateral permission that they gave you? Because upstream used one of your modification in a private version of the software, without including it in the QPLed version for example ? Isn't that more a case of you suing upstream for copyright infringement and upstream perhaps using the licence in their defence and perhaps not? I don't know enough about judicial procedure (massive understatement) to be able to guess what might happen in a case like this: A: We are suing you in country X for copyright infringement. B: You can't sue us in country X because we granted you a licence which contains a choice-of-venue clause specifying country Y. A: Our case does not rely upon that licence. If you think you can use that licence in your defence by all means try it. See you in court in country X.
Re: ocaml, QPL and the DFSG: QPL 6c argumentation.
Sven Luther [EMAIL PROTECTED]: So I see two chances of getting 6c past debian-legal: (1) Claim that the cost of administration is negligible. I think this goes against tradition. Could you define more precisely what is meant by cost of administration ? I think i am going this way, but it is unclear to me under what assumption you can separate these so called administrative costs from the costs of data transfer. It seems to me to be an artificial distinction. And notice that nothing in QPL 6 is stopping you from charging the upstream author for the binary. Some things that could come under administration and might not be chargeable to the initial developer: 1. Time spent in forwarding the request to the appropriate person and replying to it. 2. Ensuring copies of the software are kept. 3. Getting legal approval for each release to the initial developer. 4. Insurance for the consequences of accidentally releasing confidential material. It wouldn't surprise me if many companies would prefer to send all the software upstream at the same as releasing it to avoid the risk of dealing with requests later. From the company's point of view the situation is then very similar to the situation of being compelled to make the software available to the general public. In either case you'd still have to cope with the privacy problem, Privacy problem ? Could you clearly define that. If the author is able to make a request to you, your privacy is already lost anyway. This is if i understand this argument right. As I explained earlier, it might be public knowledge (because of press releases and job adverts) that you are modifying compiler X to exploit the new CPU architecture that you are developing and that you are distributing a prototype of the compiler to partners. However, you don't want to publicly release the code itself because the code would reveal details of the CPU architecture that you do not want the world to know about yet. Still, if it is really a private distribution, the upstream author will not know of it, and thus cannot make a request. As I said: the existence of the distribution is public knowledge, but details contained in the code are confidential. Anyway, i doubt the privacy issue is worth mentioning, as you said, it is not covered by the DFSG right now, and would need a new guideline to be added, i think. And finally, what do the free software gain by mandating the possibility of private distribution ? Obviously we can't mandate it; we can just encourage it by Debian disapproving of licences that don't allow private distribution. Gain for Debian: greater confidence that people won't be inconvenienced by the licences that apply to stuff in main. Gain for free software: more people using it. Loss for Debian: less stuff in main. Loss for free software: some stuff not being released to the public, or not being released so early. It's anyone's guess whether the gains or the losses are bigger. Anyway, there's a third chance of getting 6c past debian-legal, which someone brought up in a different thread and which might be the strongest yet: (3) Claim that the rights granted in section 3 of the QPL are sufficient to make the software free so there is no need to even look at section 6.
Re: ocaml, QPL and the DFSG: QPL 6c argumentation.
Sven Luther [EMAIL PROTECTED]: dealing with requests later. From the company's point of view the situation is then very similar to the situation of being compelled to make the software available to the general public. Why ? You could ask upstream not to release it. According to 6b you have to give them permission to release it. And again, if you don't make public announcement, upstream has no way to know about said software, and if he does, you have a leak somewhere. Perhaps in some cases you could keep the matter secret, but it's an additional inconvenience, to put it mildly. Again, do we really want to care about such far fetched cases ? I don't think the case I invented is particularly far-fetched, certainly not by debian-legal standards. So, if you distribute it to partners, based on the work done by the upstream author, you can as well distribute it to the upstream authors. And if you don't like it, don't modify its software. Nowhere in the DFSG does it say that you have a right to make modifications not widely available. There is enough licences out there which allow this kind of thing. And in the ocaml case, if you really like to do this, you become an Ocaml consortium member, and get the ocaml compiler suite under another licence which is less restrictive. Yes, you always have the right not to use the software. That hardly makes it free. Are there other licences in Debian main that have this privacy problem (this privacy issue that you consider not to be a problem)? Anyway, there's a third chance of getting 6c past debian-legal, which someone brought up in a different thread and which might be the strongest yet: (3) Claim that the rights granted in section 3 of the QPL are sufficient to make the software free so there is no need to even look at section 6. No, since they apply to two different things. QPL 3 and 4 is for modifications of the original software, while QPL 6 is for applications linking with the software. I'm surprised to see you dismiss so readily what is potentially your strongest argument, but perhaps it's a trick to make me argue your case for you: Where in the DFSG does it say that a licence must give special additional permission for applications linking with the software? Isn't the right to distribute modified versions as source and binary enough, and doesn't QPL 3 and 4 grant those rights?
Re: Summary : ocaml, QPL and the DFSG.
[EMAIL PROTECTED] [EMAIL PROTECTED]: 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. As I see it 6c is a serious privacy problem. Perhaps the requirement for privacy is not directly implied by any of DFSG, but I can't imagine people being very happy with the requirement to let the initial developers know how the software is being used. Do you think upstream really need this clause? I asked upstream, but didn't get a response yet. Since it is french holydays time, i doubt i will get one for the next weeks, if ever. Still i question the unsupported claim of a privacy breach you make. What is the privacy problem here ? And i don't want to hear about chinese dissidents or desert islands ? I was thinking of a case where the software is being used in a secretive industry. For example, suppose I work for a semiconductor company with 500-100 employees. A lot of what we do is temporarily confidential, in that we don't want the rest of the world finding out what we are working on until there is an official announcement. We use free software. We even use ML in some projects, though I personally use Haskell. Sometimes we might want to distribute software that uses a free library to selected partners, with whom carefully drafted non-disclosure agreements have been signed. I can't imagine the legal department accepting anything like 6c. And do you consider that violation of a licence is also admissible in fear of breaching privacy ? Sorry, I don't understand that question.
Re: Summary : ocaml, QPL and the DFSG.
Sven Luther [EMAIL PROTECTED]: I was thinking of a case where the software is being used in a secretive industry. For example, suppose I work for a semiconductor Well, if they can't abide with the term of the licence, nobody is forcing them to use the software in question. Of course, but everyone loses if people who might have been able to contribute, even in a small way, by identifying bugs, for example, find themselves unable to use the software. Compare that if someone has some GPLed software whose otherwise constraints stop you from freely distributing it. It is common knowledge that this means you cannot distribute it at all. It's surprising, though, how uninterested some people are in licensing issues. GNU Prolog used to have a GPL run-time library, and perhaps still does. That's quite a limitation, and I'm not sure it's deliberate on the part of the author. company with 500-100 employees. A lot of what we do is temporarily confidential, in that we don't want the rest of the world finding out what we are working on until there is an official announcement. We use So what. if upstream is aware of it enough to make a request, the secret is out anyway, The fact that the software is being used is presumably not secret, but the (modified) source code might contain confidential information. This is somewhat hypothetical, because, as I understand it, ocaml's run-time library is released under the LGPL with additional permissions, so the QPL would not cause any problems for someone who just wants to use ocaml for making binaries which they then distribute. Nevertheless, it's worth noting that the GPL allows something that the QPL does not allow: namely, a limited release of software that contains confidential information. For example, it's possible, I think, that a microprocessor company might want to modify GCC to make it handle some new instructions that are highly confidential, then release the modified GCC to partners who have signed non-disclosure agreements, and publicly announce that they are doing this, without revealing details of how the new instructions work. I think that's possible with the GPL, but not with the QPL.
Re: Summary : ocaml, QPL and the DFSG.
Matthew Garrett [EMAIL PROTECTED]: Why should free software support companies in not releasing their knowledge to the world? Why do we consider the freedom to hoard information an important one? I'm not sure we do, and this is somewhat off-topic, but: - The information in question will be made public in due course. It's not like a UK state secret. - If a company is prevented from keeping its plans confidential then it will have a hard time competing with other companies that do keep their plans confidential. - I don't think we should be trying to make a list of all the freedoms that we consider to be important and allowing licences to restrict any freedom that isn't in our list. A better approach, I think, is to be suspicious of any restrictions that are not easily justified as a means of furthering software freedom. In general, I don't think it helps free software for licences to restrict privacy and confidentiality of business plans, hardware designs, etc. However, I don't necessarily claim that such restrictions make a licence non-free; I am undecided about that.
Re: DRAFT: debian-legal summary of the QPL
Josh Triplett [EMAIL PROTECTED]: Do you see anything in the QPL that says the original developer can only request your changes once? They can ask twelve times a day if they want, and you have to comply; there is nothing in the license that says otherwise. For that matter, do you see anything in the QPL that says the original developer has to compensate you for the costs of providing your changes (bandwidth charges for network distribution, or media costs for physical distribution)? - Josh Triplett [Do you want both of your email addresses CCed on these mails?] I recommend CCing both of them twelve times a day for good measure. That should get him into a good mood where he will be willing to listen to finely honed legal arguments like the above! I think contracts often don't specify things like how rapidly a letter must be answered, etc, so people apply established standards and common sense. I don't know what the standard would be in this case, but maybe 28 days would be an appropriate time for responding to a request for changes, and common sense says you can ignore further requests while dealing with the first request, so maybe you would have to send your changes every 28 days. Still, if you're a Chinese Dissident stranded on a Desert Island that could be quite a burden ...
Re: More questions about the QPL for compilers and other things (was Re: More questions about the QPL for a compiler)
Brian Thomas Sniffen [EMAIL PROTECTED]: Yes, but that mechanical transformation has two sources: the program I feed it as input, and various copyrightable elements in the compiler. I don't think anyone is going to argue against a claim that the output of a compiler might contain copyrightable elements from the compiler. Indeed it typically does: the runtime support library. However, in the case of OCaml the runtime support library seems to be identified as such and given a different licence: LGPL plus additional permission. Do you have any reason to believe that OCaml might be inserting some other copyrightable stuff into its binaries? If not, why are you raising the issue now, and why are you raising it in connection with OCaml rather than with GCC, say? If you're going to suggest that a compiler licence should give some general BSD-like permission for copyrightable stuff that gets inserted into the output, then the problem is that someone might modify the compiler so that it outputs itself in a Quine-like fashion, so unless you want to BSD the whole compiler you have no choice but to identify the runtime support bits and give broader permission just for those parts, which is what the GCC and the OCaml people seem to have done.
Re: Termination clauses, was: Choice of venue
Sam Hartman [EMAIL PROTECTED]: Note that even if we end up disagreeing on this issue, I'm still interested in helping draft GRs to address conclusions of the QPL discussion. I think some of these issues are fairly important to actually bring to the project; they keep coming up again in multiple contexts and I'd like to know how the project as a whole feels because it would make evaluating licenses easier. In http://lists.debian.org/debian-legal/2002/01/msg00051.html it is claimed that you must send your changes back upstream requirements have been rejected as DFSG-free by debian-legal since 1998. And, if you're interested in this, please take a look at http://lists.debian.org/debian-legal/2003/10/msg00296.html in which I claim not to understand something, which I still don't understand and understand even less after reading the follow-up which Branden described as expressing this so clearly.
Re: Summary : ocaml, QPL and the DFSG.
Sven Luther [EMAIL PROTECTED]: The reproach which is being done is twofold : Perhaps two separate threads would be justified. I'm only replying on the first reproach. 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. Now, the clause which causes problem is the 6c, which states that upstream might also want to get those works linked with the software. I understand that this may be considered non-free, but let's go over the DFSG points one by one, and not start with discutable chinese disident or desert island stuff which only muddy the water. As I see it 6c is a serious privacy problem. Perhaps the requirement for privacy is not directly implied by any of DFSG, but I can't imagine people being very happy with the requirement to let the initial developers know how the software is being used. Do you think upstream really need this clause?
Re: More questions about the QPL for a compiler
Brian Thomas Sniffen [EMAIL PROTECTED]: Yes, I understand that the runtime library and such are LGPL'd. But the compiler, when it compiles a loop, for example, does it in a particular way. The patterns of assembly code output by the compiler -- not the parts in the library linked in, but the part actually written out by the compiler -- are part of the compiler. And they end up linked with my code. It's hard for me to believe that the compiler doesn't write any creative bits into its output -- though maybe there really has been effort to put those all into the runtime. Could you give an example of such a pattern in the binary output of any compiler that you think might require a copyright licence? I've seen some non-trivial patterns used for procedure prologues and epilogues, for example, but it's not the sort of thing people usually claim copyright for (they're not the expression of an idea), and typically the same patterns are used by different compilers and also by assembly-language programmers, so, if there is a problem, it's a very general one. Perhaps someone will claim to own the copyright for any code that stores the return address on a stack or uses a particular set of callee-save registers or a frame pointer or finds the lowest set bit in x by computing x ~(x - 1) ...
Re: RE-PROPOSED: The Dictator Test
Nathanael Nerode [EMAIL PROTECTED]: That's interesting. I propose the following license then. Is it free in your opinion? It doesn't technically violate any DFSG clauses, but I think it's self-evidently non-free, because it takes away fundamental freedoms. Anyone (you) may use, copy, modify, and distribute copies (modified or unmodified) of this software, provided that: (1) You must never say or write anything negative about the authors. (2) You agree never to exercise your fair use, fair dealing, or other similar rights regarding this software. (3) You agree not to use this program at all, in any way, without agreeing to this license. (3) You agree never to sue anyone over anything. (4) You agree to allow the authors to search your home and person without notice at any time. (5) You agree to waive your right to trial by jury in all criminal or civil cases brought against you. If you want this to be a licence, rather than a (common law) contract, which would probably require a signature or some communication between the parties, then you should probably phrase it differently, perhaps along the lines of: (1) This licence terminates if you ever say or write ... You would then have something practically equivalent to a licence subject to arbitrary termination. Incidently, and irrelevantly, if you wanted to make a contract like this, and you wanted it to work in practice, then apart from getting a signature on it you would probably also have to specify a sum of money that should be paid by the licensee if the licensee for some reason can't or doesn't fulfil the specified conditions. Otherwise it might be very hard for a court to assess damages in the case of non-performance of point 3, for example, and the uncertainty would be a burden for both parties. IANAL, of course.
Re: Choice of venue, was: GUADEC report
Nathanael Nerode [EMAIL PROTECTED]: Either the choice of venue clause is invalid and ignored, or it's an imposition on whoever has the most trouble travelling! I think there are many more possible cases than that. For example, since there is no signed and witnessed document, the relevance of the choice of venue clause is likely to depend on disputed facts (such as, did the person agree to the licence?) so you need a court to decide on its validity, and maybe even a whole trial with witnesses and even a jury, if you're in a jurisdiction where they use juries for civil cases. That court, having already investigated the case, might decide to finish the job rather than send the case to another country, and it might then treat the choice of venue as a choice of law. Who knows? I certainly don't, but I would guess it's a lot more complicated than the clause being just valid or invalid.
Re: Termination clauses, was: Choice of venue
Brian Thomas Sniffen [EMAIL PROTECTED]: I'd be particularly interested to hear your comments on the asymmetry issue, which is most closely tied to a DFSG point: Which DFSG point?
Re: Termination clauses, was: Choice of venue
Brian Thomas Sniffen [EMAIL PROTECTED]: I'd be particularly interested to hear your comments on the asymmetry issue, which is most closely tied to a DFSG point: Which DFSG point? 3. Derived Works: The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. I can't take two different QPL'd works and combine them -- this doesn't make them non-free, but it should make us awfully suspicious. The patch clause would make combination difficult, conflicting choice of venue clauses would make it worrisome, but I don't have the right to give rights to my modifications to either initial author. Two different QPL'd works are just like two works under different, incompatible copyleft licences. It's bad, but not non-free, I think. Even if I'm only making changes to one QPL'd work, and own the rights to everything else involved, I can't distribute that under the same license as I received the code. I have to distribute it under a license where the *initial* author gets a proprietary license to my work, and that of other developers who come later. I agree that this is bad, but does DFSG 3 forbid this? Perhaps it does, but only if you assume some kind of implicit substitution where the modifier replaces the author in the same terms. I don't think that's a particularly natural way to read it. So, I agree that asymmetry is bad, but I find it a bit of a stretch to claim that DFSG 3 says that. If you want to try and formulate the asymmetry criterion you might want to consider the case of a licence L that forced everyone who distributes a modified version to make their modifications available under a BSD licence to teachers, or some other class that may or may not include the original author. What would be the same terms then? (You could claim it's discrimination against the group of non-teachers, but DFSG 5 is usually understood just to mean that everyone must have the rights, not that it is forbidden to grant additional rights to certain groups.) Hm ... DFSG 12. The licence must not force modifiers to grant rights over their code that previous contributors have not granted to the modifier?
Re: DRAFT: debian-legal summary of the QPL
Matthew Garrett [EMAIL PROTECTED]: A hostile government can also declare that the subversive code can not be distributed because it says so; that's not the point of that test. Please see http://people.debian.org/~bap/dfsg-faq.html, 9 A(a). Did you mean 9A(b)? Any requirement for sending source modifications to anyone other than the recipient of the modified binary---in fact any forced distribution at all, beyond giving source to those who receive a copy of the binary---would put the dissident in danger. The very fact that he's a dissident puts him in danger, and the hostile government can declare that the source must be provided regardless of what the license says. I still can't imagine a practical situation where this would be an issue. If the dissident is likely to be put in danger then he is already doing something worse than breaching copyright law. The dissident test does sound very silly the way it is described in the FAQ. Perhaps the FAQ should give a realistic example as well as the memorable but silly dissident example. A realistic example might be a group of people doing something that someone else might consider to be an infringement of their patent; to avoid problems they want to avoid letting other people know what they are doing. Or they might want to avoid revealing a perfectly legal business plan. In general, a free software licence should allow privacy of a group.
Re: DRAFT: debian-legal summary of the QPL
Matthew Garrett [EMAIL PROTECTED]: Edmund GRIMLEY EVANS wrote: The dissident test does sound very silly the way it is described in the FAQ. Perhaps the FAQ should give a realistic example as well as the memorable but silly dissident example. A realistic example might be a group of people doing something that someone else might consider to be an infringement of their patent; to avoid problems they want to avoid letting other people know what they are doing. Or they might want to avoid revealing a perfectly legal business plan. In general, a free software licence should allow privacy of a group. I'm also unconvinced by these examples. The first sounds like A free software license should allow for small groups to avoid lawsuits while breaking the law, You might honestly believe that you are not infringing the patent but that you will get sued anyway if Company X finds out what you are doing, and you can't afford to get sued even though you are fairly confident that you would win if you had sufficient legal resources to defend yourself. But that's not the point. The point is is that you have privacy, which you may use for legal or illegal purposes, and if anyone wants to know what you're using your privacy for, then that's none of their business. and the GPL can damage a wide range of perfectly legal business plans. Yes, but only business plans that involve distributing the GPL software while denying certain freedoms to the recipients of the GPL software, or at least that's the idea. It seems to me that the dissident test is just a weird way of saying something like: DFSG 11. Licence Must Not Invade Privacy of Individuals or Groups If it's too hard to come up with a realistic example of a group that everyone agrees is deserving of privacy then perhaps it's best to just leave it as an abstract requirement.
Re: DRAFT: debian-legal summary of the QPL
Josh Triplett [EMAIL PROTECTED]: I believe the situation in the Dissident test is that the laws of the totalitarian government are irrelevant. The Dissident test triggers if, when the dissident finally leaves the jurisdiction of the totalitarian government, some copyright holder can say that the actions they took to maintain their privacy violated the copyright license, by the laws of non-totalitarian governments. And why should those laws apply in a different country? Ah, I suppose that would be because it's an imperialist government ...
Re: Visualboy Advance question.
Nathanael Nerode [EMAIL PROTECTED]: Does Debian main contain any MP3s? If not, would you like to see MP3 players removed from Debian main? Debian main does contain MP3 recorders. I think that is quite sufficient to render MP3 players useful with no non-free software; you can make your own MP3s. Yes, I suppose so. You can also make your own ROMs. In both cases it's not very easy to make a good one, for some senses of good, and most people who use the software aren't going to do it. So it's not obvious to me where to draw the line and whether those two cases really are on different sides of the line. Perhaps it would be best just to stop worrying about it. Unless there's a lot of potential main material that depends on it, does it really matter that much whether a package goes in main or contrib?
Re: GPL-compatible, copyleft documentation license
Florian Weimer [EMAIL PROTECTED]: * Branden Robinson: In the copyright holder's understanding, re-imposition of the requirements of sections 2a and and 2c by those creating a derivative work is not allowed, since those restrictions never attached to this work; see section 6. This work can be combined with another work licensed under the GNU General Public License, version 2, but any section 2a and 2c restrictions on the resulting work would only attach only due to the copyright license on the work(s) with which this work is combined and for which those restrictions are in force. Isn't this at least a bit self-contradicting? Why produce such a mess in the first place? To me it seems potentially useful to release licensees from those requirements. Your license doesn't give me permission to publicly perform the work, or to broadcast it. It doesn't deal with moral rights at all (which are quite important in some jurisdictions when it comes to non-programs). As I understand it moral rights are not portable in the way that copyright is, so it might not even be possible to deal with moral rights without hiring a huge international team of lawyers and producing a multilingual licence the size of a small book. However, if you know of a good portable way of handling moral rights, broadcast and public performance please suggest some appropriate language. I'm currently trying to draft a general-purpose non-public licence for application to non-software so I'd be interested in any precedents you can produce. It doesn't special-case distribution of printed copies, which means that the GPL provisions apply. These provisions pretty much rule out small-scaleprinting and redistribution because of the valid for at least three years rule. I don't think that's a huge problem in practice. If you tell the people to whom you give the hard copy that they must download the source within the next 48 hours, then that probably counts as giving them the source. If you're selling the hard copies then you can probably afford to include a CD. (I'm told that producing the inlay card of a music CD costs more than producing the CD itself. Unless something ghastly happens digital media will probably continue to get cheaper relative to hard copy.) However, the license does clarify what constitutes source code, but this might also be a further restriction in the GPL sense, making the license incompatible with the GPL. It says what the copyright holder regards as source. I think it's fairly clear that this clarification is not intended to modify the terms of the GPL. All in all, I don't think this is a particularly good license for documentation, it's just yet another GPL variant. Perhaps the word proviso should be replaced something like additional permission to make it even clearer that this licence is compatible with version 2 of the GPL. I think there's a typo in this line, by the way: 2c restrictions on the resulting work would only attach only due to the
Re: Choice of venue, was: GUADEC report
MJ Ray [EMAIL PROTECTED]: 1. someone can explain why choice of venue can be DFSG-free; How is it not, exactly? It does not limit, in any way, your rights to use, modify or distribute the software. As I understand it, it limits all those rights by allowing the licensor to require out-of-pocket expenditure by any licensee on legal representation in the given venue, instead of possibly representing yourself in the court local to your offence as seems to happen otherwise. It might do that. Or it might have exactly the opposite effect, depending on the legal systems involved and how they interact. If you can show that a particular choice of venue clause has a particular problem because of a particular combination of laws or legal procedures, then that might be an argument for it not being DFSG-free. Otherwise, isn't it sufficient to just mention is as a possible risk when the licence is being discussed and leave it at that?
Re: RE-PROPOSED: The Dictator Test
Andreas Barth [EMAIL PROTECTED]: A typical warranty disclaimer doesn't prohibit you from suing the author; it just makes it less likely that you would win if you did. That's a bogus reason. A typical you must give the author 1000 $ / month doesn't prohibit you from paying nothing; it just makes it less likely that you would win if he sues you. My point was that typically the disclaimer is not a condition of the licence. In particular, it is intended to apply even if you don't accept the licence. Do you dispute that point, or are you just criticising the way I presented it?
Re: Visualboy Advance question.
Matthew Palmer [EMAIL PROTECTED]: The prerequisites for inclusion in main should merely be a reasonable belief that the program is useful without recourse to anything non-free, I disagree. I think an MP3 player should be allowed into main without us trying to pretend that it's only there for playing DFSG-free MP3s.
Re: RE-PROPOSED: The Dictator Test
Josh Triplett [EMAIL PROTECTED]: Good point about warranty disclaimers, though. Assuming you acquired the software lawfully, then you would have the right to use the software, and the right to sue the author if it didn't work, so this test as written would prohibit warranty disclaimers. A typical warranty disclaimer doesn't prohibit you from suing the author; it just makes it less likely that you would win if you did. As I see it, the warranty disclaimer isn't a condition of the licence. It's a notice. Usually there is a condition of the licence that requires that notice to be preserved, but the disclaimer itself isn't saying that you must do or this or must not do that if you distribute the software. In particular, the GPL warranty disclaimer is presumably supposed to have some kind of effect even if you don't copy the software and therefore don't use the licence. Also, if anyone is going to get sued, isn't it more likely to be the distributor than the author? I would guess that the disclaimer in the GPL is of more value to Red Hat, say, than Joe Hacker, and I rather suspect that the authors of the GPL had distributors rather than authors in mind when they wrote that part. Then again, the effectiveness of warranty disclaimers in a you only need to accept this license if you distribute the software license like the GPL are already a debated topic. IANAL, but as I see it the disclaimer is a warning to the user not to expect too much from the software, and the use of a licence clause that requires the disclaimer to be preserved is proof that contributors and distributors did everything they could to ensure that the warning reached the user. I don't think it's a magic spell that makes you imune from being sued. I don't think such a spell exists.
Re: Visualboy Advance question.
Branden Robinson [EMAIL PROTECTED]: I put xtrs in contrib because without the ROM (or a DFSG-free OS for the TRS-80 Model 4P, which doesn't exist or at the very least isn't packaged), the only thing it will do is display an error message that no ROM was found. My thinking is that we need to not be pulling any bait-and-switches on our users. If I were to apt-get install xtrs from main, I'd expect it to do something more than throw up an error message. In summary, the decision to put emulators that are largely or completely inoperable without supplementary materials (from non-free, or not provided by Debian at all), is not wholly compelled by the 100% Free Software portion of the Social Contract. It's also motivated by the We will be guided by the needs of our users part. Could you explain how you think the emulator and ROM situation is different from the media player and media file situation, if you think it is? Does Debian main contain any MP3s? If not, would you like to see MP3 players removed from Debian main? As for bait-and-switch, why not include a warning in the package description that you will need a ROM image to use the emulator?
Re: Copyright on 'non-creative' data?
Benjamin Cutler [EMAIL PROTECTED]: Anyway... the program itself is GPL, no problems there. However, on the same site, they have several zip files that are basically rom databases produced by running the program on directories full of ROMs, allowing you to match ROM images by their checksums. I'd like to package those alongside ucon64, but they lack true licenses. The databases constitute effort (because the creators had to assemble an entire directory of ROMs), but in my opinion, no creativity (because all that was involved in the creation was running ucon64 over said directories). Are they still covered by copyright law in that case? From what I've heard, in the USA, probably not, but they may be covered by the Database Directive in the EU, so you should get a licence for them in any case.
Re: Contracts and licenses
Lewis Jardine [EMAIL PROTECTED]: Textbook Example: in Scotland, if you advertise a reward for returning your lost cellphone, you are contractually obligated to reward the person returning the phone. If you refuse, they can take you to court for this reward. (In this case, the phone is not consideration, as it your phone, not theirs. They are not actually giving you anything when they return your phone). I think I've come across a very similar textbook example for English law, with a dog instead of a phone. It was explained to me that the performance of returning the dog counts as consideration. Edmund
Re: Draft Summary: MPL is not DFSG free
Nathanael Nerode [EMAIL PROTECTED]: Also, could someone explain how this sort of condition would work in practice? Suppose I'm the licensee. The licensor would go to court in Santa Clara County and say what, exactly? I haven't signed anything, so how would the licensor convince the court that I have agreed to be sued there? You haven't been granted any rights except under the agreement, so if you didn't agree, you don't get any of the rights in the agreement. Much like the way the GPL is enforced. As I understand it, the GPL isn't an agreement; it's a permission. The licensor might sue for copyright infringement, and the licensee might produce the GPL as evidence in their defence. Or they might not; they might use a difference defence. I may or may have been granted rights other than under the agreement. I may or may require any rights. That's for the court to decide. Which court? If the court is willing to take the licensor's word for it, then couldn't the licensor sue me in Santa Clara even if I had never had anything to do with the software? Yes, but you could then tell them and the court that they had to move the suit to where you lived. With this clause, you couldn't (unless the clause was ruled to be unenforcable). This is circular. A court has to decide from the facts of the case whether the clause is enforceable. Which court decides that? That depends on whether the clause is enforceable. So where do we start?
Re: Draft Summary: MPL is not DFSG free
Matthew Palmer [EMAIL PROTECTED]: Yes, but you could then tell them and the court that they had to move the suit to where you lived. With this clause, you couldn't (unless the clause was ruled to be unenforcable). This is circular. A court has to decide from the facts of the case whether the clause is enforceable. Which court decides that? That depends on whether the clause is enforceable. So where do we start? I would imagine that the plaintiff would argue in their local court that the clause was enforceable, and the defendant would argue in their local court that it wasn't. If both won in their respective juristictions, you would appeal the decisions to a higher court, one with juristiction over both lower courts. From reading groklaw.net I get the impression that US courts don't like duplication of effort, so I would guess that in this scenario the case in the plaintiff's court would be stayed awaiting the result of the case in the defendant's court. The defendant might have a defence that doesn't use the licence at all, so it would be total waste of time for the other court to discuss the details of a clause in a document that turns out to be completely irrelevant. With a contract that both parties have signed it's fairly easy to see that both parties have agreed to the choice of venue; with a public licence quite a lot of legal work has to be done in order to show that the licence has anything to do with the case. So I wonder whether such a clause in a public licence has any practical effect and if so, how. But I guess nobody here knows the answer so I'll shut up now. Sorry for rambling.
Re: request-tracker3: license shadiness
Michael Poole [EMAIL PROTECTED]: # Unless otherwise specified, all modifications, corrections or # extensions to this work which alter its source code become the # property of Best Practical Solutions, LLC when submitted for # inclusion in the work. What is the impact of the third paragraph? It's not listed as a condition (the preceding paragraph is about the absence of guarantee, not about giving permission). The licence is quite clearly stated as Version 2 of the GPL. It seems very similar in spirit to the note you read in some newspapers saying something to the effect of It will be assumed that all letters are for publication unless otherwise specified, which is likewise not a licence condition but just an attempt to clarify the meaning of future communication. It might conceivably be quite a good paragraph to have in case someone sends in a patch, waits a few years, and then starts complaining about people distributing the code without permission. However, become the property of sounds like copyright transfer, which, as you point out, is not possible in the USA and unlikely to be valid elsewhere. The paragraph might be more effective if it said something more reasonable, such as are licensed to ... under the same terms, which is exactly how things usually work in free software, in my limited experience. Can Debian properly redistribute rt3 if rt3 alleges both distribution under the GPL and GPL-incompatible restrictions? Does the fact that the restrictions are non-enforceable (at least in the US) enter consideration? If it were an additional restriction, then it would be a problem. Unenforceability in the USA doesn't help: it might be enforceable elsewhere, and it might be enforceable in the USA if there is a change in the law. However, to me as a layman it doesn't look in context like a restriction.
Re: Draft Summary: MPL is not DFSG free
Jim Marhaus [EMAIL PROTECTED]: I don't really want to defend the MPL, but ... | 2.1. The Initial Developer Grant. | [...] | (d) Notwithstanding Section 2.1(b) above, no patent license is | granted: 1) for code that You delete from the Original Code; 2) | separate from the Original Code; or 3) for infringements caused | by: i) the modification of the Original Code or ii) the | combination of the Original Code with other software or devices. This clause rescinds clause 2.1(b) if the source is modified. This violates DFSG #3. Specifically, the author must allow derived works to be distributed under the same terms as the original software. Hasn't this been rebutted by people pointing out that many or most free software licences don't include any patent licence at all, so including a restricted patent licence is hardly any worse? The real question is: are there any valid patents being actively enforced? If there are, then there would be problem even if the licence were GPL instead of MPL, so the problem isn't the MPL; the problem is software patents. Polling boothes closed 84 minutes ago here in the UK; I hope you voted Green. :-) | With respect to disputes in which at least one party is a citizen of, | or an entity chartered or registered to do business in the United | States of America, any litigation relating to this License shall be | subject to the jurisdiction of the Federal Courts of the Northern | District of California, with venue lying in Santa Clara County, | California, with the losing party responsible for costs, including | without limitation, court costs and reasonable attorneys' fees and | expenses. This clause restricts court venue to Santa Clara County, CA. Venue restrictions may force licensees to travel unreasonable distances to defend themselves in court, and could be used to effectively revoke the license (Tentacles of Evil). For example, if the licensor filed a frivolous lawsuit against a licensee, the latter would be forced to travel to the licensor's home court or hire a representative, since most jurisdictions summarily rule against absent defendants. I don't know much about the US legal system. How different is this from the ordinary default situation? If I were a citizen of, or an entity chartered or registered to do business in the United States of America would I normally be able to safely ignore cases brought against me in Santa Clara County? Also, could someone explain how this sort of condition would work in practice? Suppose I'm the licensee. The licensor would go to court in Santa Clara County and say what, exactly? I haven't signed anything, so how would the licensor convince the court that I have agreed to be sued there? If the court is willing to take the licensor's word for it, then couldn't the licensor sue me in Santa Clara even if I had never had anything to do with the software?
Re: gens License Check - Non-free
Josh Triplett [EMAIL PROTECTED]: So before Wine was created, anything which uses a Windows library was a derivative of Windows? Yes. There are so many theories on this subject that I am perpetually confused, but I don't think that is what is usually claimed in the case of GPL libraries. I think the usual claim is that the program that uses the library plus the library is a derivative of the library (which is obviously true) and also a single work even when the parts are distributed separately (which is at least plausible). In the case of a typical Windows library that's not a problem because: 1. Only Microsoft and its agents are distributing the library. 2. The library is not available from public servers. 3. There is explicit or implicit permission to link the library with arbitrary programs. However, in the case of a a GPL library it is possible to argue that the person distributing the program is encouraging people to fetch the library from a public server and link it with the program, and therefore that person is in effect distributing the GPL library in an unlicensed manner. There are all kinds of hypothetical circumstances that might strengthen or weaken that argument. For example: 1. The argument seems stronger in a case where the program and the library are being distributed by the same person or by people who are in some way working together. 2. The argument seems weaker in a case where the program is being distributed in source form only together with an explanation that the program is for research use only until there is a compatibly licensed substitute for the library. Obviously I have no idea in what circumstances the argument might be accepted by a court in what jurisdictions, but I think that's roughly what the usual argument is, and it doesn't directly imply anything about the situation with a typical Windows library.
Re: oaklisp: contains 500kB binary in source
Jeroen van Wolffelaar [EMAIL PROTECTED]: I just noted that oaklisp has a 500kB binary called 'oakworld.bin' in src/world. oaklisp is GPL. It seems one can re-create this binary with oaklisp, but to build/use oaklisp, you'll first need the .bin. So, there is no real bootstrapping provided AFAICS, in any case, it isn't used since the oakworld.bin is provided in the source tarball. Is this acceptable? For example gcc also cannot be rebuild without first having some C compiler. But gcc is a different beast. From http://bugs.debian.org/122117 I get the impression that it's the same sort of situation as with gcc: a programming language X is implemented in the language X, and so it has a build dependency on itself, in the absence of alternative implementations. GHC seems to be in the same situation: there are other implementations of Haskell, but GHC uses some GHC-specific features, so you have to compile it with GHC. I assume that cyclic Build-Depends are acceptable in Debian. It would be difficult if they weren't.
Re: oaklisp: contains 500kB binary in source
Jeroen van Wolffelaar [EMAIL PROTECTED]: GHC seems to be in the same situation: there are other implementations of Haskell, but GHC uses some GHC-specific features, so you have to compile it with GHC. GHC can be bootstrapped without GHC itself, there is a minimal C implementation of the necessary code. No need to build-depend on itself. Are you referring to the use of HC files in porting GHC? http://www.haskell.org/ghc/docs/latest/html/building/sec-porting-ghc.html I notice the GHC maintainer somehow doesn't use this possibility, I don't know why, it makes bootstrapping GHC difficult. Debian packages should probably be built from source as a matter of principle. The HC files are automatically generated (using GHC) and should not be counted as source. However, maybe for convenience the Debian package could have an option to use the HC files. I assume that cyclic Build-Depends are acceptable in Debian. It would be difficult if they weren't. For essential packages, build-essential and kernels (not in the sense one build-depends on a kernel, but one requires a working kernel before running the build), it's understandable. For everything else, I consider that quite wierd. I'm not sure about that. It's fairly normal for people to implement compilers in the same language and I don't see why they should be expected to provide a bootstrap path using C. There's also the case of Build-Depends cycles caused by non-essential parts of a package, such as the documentation. If a documentation preparation system uses some library, and the author of that library decides to use that documentation preparation system for the library documentation, then there will be a cycle, but one that is easily avoided by just not building the documentation the first time.
Re: You can't get a copy unless you accept the GPL [was: Re: libkrb53 - odd license term]
Henning Makholm [EMAIL PROTECTED]: If you want to *download* the sofware, then you'd better do it by the GPL's terms. Downloading implies that you are instructing some computer to make create a copy of the Work on your hard drive. Because computers, legally speaking, do not *do* anything by themselves, *you* are the one who are creating the copy on your hard drive. And creating a copy is smack in the middle of the copyright holder's legal monopoly. It seems to me that the person who puts something on line is usually regarded as the person doing the copying. I don't know of any legal basis for this point of view, but it makes more practical sense if you think of search engines, Usenet, other situations where copying happens to all intents and purposes automatically once something has been put onto a server, and in general that the person who puts something on line has had a chance to examine and decide whether they are allowed to do so, whereas the person who starts to download a file has no way of knowing what they getting.
Re: CA certificates
Giacomo A. Catenazzi [EMAIL PROTECTED]: In some countries (USA and Germany?) lists/databases are copyrightable, even is single data is not! (phone book, games scores and statistics,...) Don't you mean protected by the Database Directive, which is not the same thing as copyright: it has a much shorter duration, for example?
Re: reiser4 non-free?
Humberto Massa [EMAIL PROTECTED]: In the case of a NDIS driver, the driver itself is without doubt NOT a derived work on the linux kernel. Yes, but the combination of the driver with the kernel is a derived work of the kernel, and it's not a case of mere aggregation, which the GPL permits.
Re: CA certificates
Russ Allbery [EMAIL PROTECTED]: There's an interesting question. Is a public key copyrightable? In other words, does VeriSign have any legal grounds to restrict use of their public keys at all? They might do in some jurisdictions, but I would guess that in most they don't. The public key is a fact, like a telephone number or map coordindates. A collection of such facts might be covered by the European Database Directive, but a single such fact or very small number of them ... I doubt it ... though I don't know, of course. IANAL.
Re: CCPL-by
Joe Buck [EMAIL PROTECTED]: The issue is not whether it's right or wrong. It's more fundamental than that. The DFSG were originally designed for software; if they are to be extended to apply to works that are mainly about expression rather than function, you risk bumping up against the law. Someone in, say, France, may not legally be able to grant the permissions that you are demanding. Now, the French contributor can sneak something past debian-legal by writing a license text that appears to grant permissions that the contributor has no power to grant. Is that what you want? Are you sure the location of the contributor is relevant? With copyright the nationality of the author and where the work was produced are normally irrelevant, as I understand it, so if one American sues another American for an alleged infringement that took place in France, then French law applies. Moral rights might be different, of course. Perhaps according to French law only French authors have moral rights. :-)
Re: Bug#239952: kernel-source-2.6.4: qla2xxx contains non-free firmware
Don Armstrong [EMAIL PROTECTED]: It seems rather clear that those source files are just machine code for the device firmware, and as such, are not the prefered form for modification. Agreed. So the files are not DFSG-free. That pretty much precludes the linking of that code with the rest of the kernel and/or forming a derivative work of the kernel and our distribution of such a resultant work, well before we even get into the DFSG §2 discussion.[1] The situation is somewhat ambiguous. One might argue that the device driver code is not part of the kernel even though it's included in the source tree for practical reasons and that there is therefore no problem with the GPL. However, there's no point in discussing that question in debian-legal as the code has to be separated in any case, because it is not DFSG-free. Edmund
Re: DRAFT summary of the OPL; feedback requested
Jeremy Hankins [EMAIL PROTECTED]: + - The person who makes any modifications must be identified. According + to the Dissident Test this is an unacceptable restriction on + modification. (See the DFSG FAQ[1] for a description of the Dissident + Test.) Maybe I understand the word identified differently from other people, but for me identified does not mean identified in such a way that the police can find the person. In context it seems to me that the most reasonable interpretation of identified is with respect to other people in the ChangeLog. So, you don't pretend to be someone else in the ChangeLog, and you don't pretend to be more than one person in the ChangeLog. But you can use a nom de guerre if you want. (And you can use just your real name, if you want, even if your real name is something like John Smith which wouldn't help the police much on its own.)
Re: If DFSG apply to non-software, is GPL*L* incompatible with DFSG?
Don Armstrong [EMAIL PROTECTED]: The legal terms are not copyrightable; In some jurisdictions, perhaps, but not all. Indeed. I might be wrong here, but I think that one of the ways the Law Society in England prevents non-solicitors from taking work away from qualified lawyers is by asserting copyright on the standard terms and conditions used for buying and selling property, say, and then licensing those terms and conditions only to members of the Law Society. They may also raise money by charging for the use of certain legal forms. I think that licence texts should be public-domain. You could X11-license them, but it would be very confusing to have to carry around a licence for the licence, not to mention a licence for the licence for the licence, plus a few changelogs, perhaps, so public domain is best for that particular purpose, I think. Debian seems to allow the use of licences that are themselves unmodifiable. It's a practical necessity, I think, and fairly easy to justify by saying that licences are a kind of meta-content rather than content of the distribution.
Re: Cypherpunks anti-License
Branden Robinson [EMAIL PROTECTED]: Not true. Governments can (and have) passed legislation to yank a work out of the public domain and put it back under copyright. This happened when they extended the duration of copyright in the EU from 50 to 70 years. (To remember when this happened, it helps to remember that in most of the EU Hitler's Mein Kampf was out of copyright for 3 months before it went back under the control of the state of Bavaria, which apparently tries to prevent it from being reprinted at all.)
Re: latex2html license: A Letter to Leeds University, round 2
Roland Stigge [EMAIL PROTECTED]: Besides, isn't Re: the abbrev. for Reply? The letter is not a reply. No, it's Latin, ablative singular of res (thing), which is also the first element of res publica and part of several Latin expressions used in English legal jargon.
Re: [ardour-dev] The Ardour Manual
Henning Makholm [EMAIL PROTECTED]: Hmm. Provide the LaTex code (scrambled) and place it under the GPL. If it's deliberately scrambled so as to make modifications difficult, then placing it under GPL will be pointless As far as I can see it is not scrambled in order to hinder modification; it is scrambled in order to hinder use. They presumably intend to forbid modification in order to prevent someone from unscrambling it and competing with the version that they sell commercially. So it's non-free. It's possible that the authors might agree to make source available so that people can use it to privately make modifications such as typesetting it for a non-standard paper size, or with a large font for a vision-impaired reader, or whatever. However, people will then use this to remove the Unpaid watermark ... Edmund
Re: Bug#224866: kanjidic: Kanjidic is not DFSG-free
Don Armstrong [EMAIL PROTECTED]: The commercial utilization of the frequency numbers is prohibited without written permission from Jack Halpern. Use by individuals and small groups for reference and research purposes is permitted, on condition that acknowledgement of the source and this notice are included. First, since the frequency can be construed as a fact, and therefore is not copyrightable work of authorship, I'm not particularly concerned by this. [If there is a jurisdiction which does construe mere compendiums of facts as a work of authorship, we could perhaps reconsider this.] The European Union has a Database Directive which grants monopoly rights to the creators of databases, so the prohibition above, which doesn't mention copyright, could still be effective. If the frequencies were manually adjusted, perhaps copyright would apply in some places, too. If as you say the package no longer contains Jack Halpern's work, all this is irrelevant, but perhaps you're interested to know about the Database Directive anyway in case you encounter similar cases.
Re: Changes in formal naming for NetBSD porting effort(s)
Nathan Hawkins [EMAIL PROTECTED]: If Homer isn't copyright and trademark free, nothing is safe. Homer is not trademark-free. Try googling for Odyssey is a registered trademark.
Re: Changes in formal naming for NetBSD porting effort(s)
Branden Robinson [EMAIL PROTECTED]: Still the nice thing about using old, old names like the ones I proposed is that you can be almost positive no one has a leg to stand on in any claim to own the name. An old name can still be a current trademark. Hermes is an old name and a trademark ... probably lots of different trademarks.
Re: Changes in formal naming for NetBSD porting effort(s)
Joel Baker [EMAIL PROTECTED]: Nor do I. I mean, consider the fact that my personal email is [EMAIL PROTECTED], and I use it quite extensively (just check the list archives) - this is not exactly something used by someone big on placating fundies. Presumably fundies will know, or will be happy to find out by reading scripture, that Lucifer is among other things an adaptation of the name of a Babylonian king mentioned in Isaiah and a Latin name for the morning star, which is a symbol of Jesus in Revelation. People who thing Lucifer is the Devil have no right to call themselves fundamentalists as they are following a mediaeval (I guess) tradition instead of going back to the fundamental scripture.
Re: Changes in formal naming for NetBSD porting effort(s)
Branden Robinson [EMAIL PROTECTED]: You seem to have already noted this, but I should re-emphasize that since the Tolkien novels are still under copyright, then legally the names from them are just as much risky choices as names from Pratchett are. Does anyone seriously think that copyright applies to names? I've never heard of copyright applying to anything smaller than a haiku. (I don't think the following forms part of a relevant argument, but if there is such a thing as copyright on names you might want to print out all vaguely pronouncable combinations of up to about 10 letters, whack an ISBN on the print-out, deposit it in the national library, send a complimentary copy to Pratchett by registered post, then sue him next time he invents a new name.)
Re: Plugins, libraries, licenses and Debian
Måns Rullgård [EMAIL PROTECTED]: Exactly my point. What would the equivalent of dynamic linking be? A book that says on the first page: take chapters 3 and 6 from book Foo and insert after chapter 4 in this book, then read the result. Wasn't there a case with a book containing questions and answers about a television programme that was considered (in the USA) to infringe the copyright of the television programme? Maybe that was dynamic linking ...
Re: Plugins, libraries, licenses and Debian
Måns Rullgård [EMAIL PROTECTED]: I know that is how law works. I just find it strange, that the GPL is so explicit on this point, and yet doesn't bother to clarify at all what a derived work might be, just to take an example. I suppose the idea is to have the GPL apply as broadly as possible. Anyone who wants a clarification of derived work that is valid for their position in the space-time continuum should visit a law library.
Re: Plugins, libraries, licenses and Debian
Glenn Maynard [EMAIL PROTECTED]: Due to the GFDL debacle, I no longer trust the FSF's conception of free (eg. similar in spirit) to my own software, so I'm not comfortable with the upgrade clause, and not using the upgrade clause will cause big problems down the road, so I'm starting to avoid the GPL for my own work. So what do you use instead? If you think your licence solves both the problems you mention, then presumably you believe that your licence has a good chance of being compatible with GPLv3 if GPLv3 turns out to be a good licence (otherwise you might as well use GPLv2 only), and a good chance of being incompatible with GPLv3 if GPLv3 turns out to be a bad licence (otherwise you might as well use X11). To me this seems rather difficult to achieve. My current opinion is that it's best to stick with GPLv2 or later and change to GPLv2 only if and when GPLv3 turns out to be non-free. If people make it clear that they are ready to change if necessary it encourages the FSF to be careful. Edmund
Re: possible licensing issues with some scsh source files
Andrew Suffield [EMAIL PROTECTED]: ;;; 2. Users of this software agree to make their best efforts (a) to return ;;;to the T Project at Yale any improvements or extensions that they make, ;;;so that these may be included in future releases; and (b) to inform ;;;the T Project of noteworthy uses of this software. Harmless. My best effort consists of waving a gerbil at my workstation and hoping something along those lines happens. (If this were an actual requirement, rather than a vague request, it would be a problem. I strongly discourage people from writing noise like this into licenses though - put it in the README where it belongs.) Why do you think this is a vague request rather than an actual requirement? Users ... agree sounds like a requirement to me. The expression best efforts is a strong one. It means more than just reasonable efforts. I don't think your gerbil waving would even count as a reasonable effort.
Re: Jimi (Java lib) as a Debian package, is it legal?
Jacob Emcken [EMAIL PROTECTED]: But before it can be packaged it has to be legal :) I have tried to read the license but im not sure if it is legal to package. Well it won't fit into main... but perhapes contrib or non-free? I'm not a Debian developer, but it looks to me that to distribute this software at all Debian would have to: - indemnify Sun - not distribute any competing software I would guess that either of those on its own would prevent this software from becoming a Debian package, even in non-free. (ii) do not distribute additional software intended to replace any component(s) of the Software; 3.Indemnity to Sun. As a condition precedent to each license grant in this Agreement, you agree to indemnify, hold harmless, and defend Sun and its licensors from and against any and all claims, lawsuits, liabilities, demands and expenses ...
Re: Swiss Ephemeris Public License
Branden Robinson [EMAIL PROTECTED]: (Big long quote because a few days have passed:) On Sat, Oct 11, 2003 at 11:05:56AM +0100, Edmund GRIMLEY EVANS wrote: Branden Robinson [EMAIL PROTECTED]: I personally consider that non-DFSG-free, under the theory that in general, your modifications have pecuniary value, and you are compelled to license your valuable modifications to the copyright holder under terms other than those under which you are licensing them to the community. What stops you from licensing your valuable modifications under a BSD-like licence so that everyone has them under the same terms? There's a difference between everyone and the copyright holder. Therefore, I see no fundamental difference between this clause and one which insists that all modifiers pay a license fee to the copyright holder. Both cash and copyrightable modifications have pecuniary value. Consequently, in my view, this clause fails the freely modifiable requirement of the FSF's definition of Free Software. Would you feel the same way about a licence that said that all modifications must be public-domain or BSD-licensed? Public domain? No, because that doesn't put anyone in a privleged position. BSD-licensed? Depends on to whom the license is granted. If it's a public license, then I see no particular problem, though it's a much harsher form of copyleft than we're used to. I think a case could be made that OpenSSL is in fact already under such a license.[1] What about a copyleft licence that grants the DFSG-freedoms but gives additional permissions to Jehova's Witnesses (who happen to come to mind as they turned up at my door as I was typing this)? The additional permissions test is only applicable if the license without the additional permissions granted to a certain group or individual is already DFSG-free, which is -- I submit -- not the case here. If the base license is not DFSG-free, then the wrinkle that it's DFSG-free only for a select group of people makes it fail DFSG 5 (No Discrimination Against Persons or Groups). Freedom for an elite few is not freedom. To boil it down a different way: compelling you to give something away to the whole world[2] is DFSG-free; compelling you to give something away just to me is not. I still don't understand this. Suppose we have: licence A that forces you to release modifications under a BSD-licence to the whole world licence B that forces you to release modifications under a BSD-licence to the original authors and a GPL-licence to the whole world licence C that forces you to release modifications under a GPL-licence to the whole world Then licence A gives fewer permissions than licence B, and licence B gives fewer permissions than licence C. If you dual-license something under A and B that's the same as licensing it under B (because licence B doesn't stop you from also BSD-licensing your modifications to the whole world), and if you dual-license something under B and C that's the same as licensing it under C (because licence C doesn't stop you from also BSD-licensing your modifications to the original authors). You seem to be saying that A and C are DFSG-free, but B isn't. So something released with license A is free, but software dual-licensed with A and B is non-free. I seem to be seeing or imagining some kind of paradox here ... Edmund
Re: If not GFDL, then what?
Joe Moore [EMAIL PROTECTED]: The publisher couldn't legally sell the book without the CD (or 2(b) notice); however, anyone else could buy a copy from the publisher, remove the CD, and resell it. See the first sale doctrine. But the reseller would be distributing a modified GPLd work (without source), so would be bound by the terms of the GPL. I think the first sale doctrine is just a USA thing[*], and I don't know much about it, but I think the idea is that selling a hard-copy book second-hand does not count as copying or distributing and can therefore be done without permission from the copyright holder, so the reseller would not be bound by the GPL. There may well be some other conditions attached to the first sale doctine to stop this becoming a loophole in the GPL or elsewhere, such as not handling lots of copies of the same work in this manner. [*] The following frequently seen words come to mind: Except in the United States of America, this book is sold subject to the condition that it shall not, by way of trade or otherwise, be lent, resold, hired out, or otherwise circulated without the publisher's prior consent in any form of binding or cover other than that in which it is published and without a similar condition including this condition being imposed on the subsequent purchaser.
Re: If not GFDL, then what?
Nathanael Nerode [EMAIL PROTECTED]: If you feel that the GPL needs clarification for the term 'object code', add a specific notice stating what forms you consider to be object code (not source code) in your interpretation. But make sure this clarification functions as an additional preamble or an additional permission rather than as a patch to the GPL which might create a new version of the GPL incompatible with other versions. Consider, for example, a case where two people write GPL documentation, but one writes that the source must be in LaTeX and the other writes that the source must be in Lout.
Re: Swiss Ephemeris Public License
Branden Robinson [EMAIL PROTECTED]: b. If modifications to the SE are released under this license, a non-exclusive right is granted to the holder of the copyright of the unmodified SE to distribute your modification in future versions of the SE provided such versions remain available under these terms in addition to any other license. I recall that we recently discussed whether such clauses are sufficiently discriminating to fail the implicit with no consideration to the author test of the DFSG. It eludes me what we concluded, however. I personally consider that non-DFSG-free, under the theory that in general, your modifications have pecuniary value, and you are compelled to license your valuable modifications to the copyright holder under terms other than those under which you are licensing them to the community. What stops you from licensing your valuable modifications under a BSD-like licence so that everyone has them under the same terms? Therefore, I see no fundamental difference between this clause and one which insists that all modifiers pay a license fee to the copyright holder. Both cash and copyrightable modifications have pecuniary value. Consequently, in my view, this clause fails the freely modifiable requirement of the FSF's definition of Free Software. Would you feel the same way about a licence that said that all modifications must be public-domain or BSD-licensed? What about a copyleft licence that grants the DFSG-freedoms but gives additional permissions to Jehova's Witnesses (who happen to come to mind as they turned up at my door as I was typing this)? Edmund
Re: GFDL and Anonymity --- another problem?
Mathieu Roy [EMAIL PROTECTED]: So I wonder how it would be possible for a license to be valid with an anonymous copyright holder. So, use a pseudonym. This is only a problem if you live in a country where it is illegal to use a pseudonym and you are very law-abiding dissident and cannot bring yourself to break that particular law. If they ever try to ban pseudonyms in the UK I will start a campaign for everyone to officially name all their children Robin Smith and use unofficial nicknames to distinguish them. Maybe also introduce a mating season to cause more date-of-birth confusion ...
Re: MPlayer DFSG compatibility status
Josselin Mouette [EMAIL PROTECTED]: We don't want to receive the endless flow of mails asking about why the newest, apt-get'ed MPlayer doesn't play ASF/WMV files (a very significant part of the streaming media on the Internet). If we don't want to include this support, this is not your problem. E.g. xine in Debian has WMV9 support stripped off, and there would be no reason for mplayer to include it if there are legal issues with it. Should this perhaps be mentioned in the package description? In http://packages.debian.org/unstable/graphics/xine-ui.html there is no mention of WMV, but there is a link to http://xine.sf.net/ for a more complete list of supported audio/video formats, and http://xine.sf.net/ says that xine decodes WMV. I'm not saying you should write Don't bother getting this crippled Debian package; get the upstream source instead, but I think it's only fair to tell people if functionality has been stripped off. You could include a link to freepatents.org by way of explanation.
Re: Attribution-ShareAlike License
Seth David Schoen [EMAIL PROTECTED]: Adobe has patents which it claims apply to PDF and has licensed them only for the purpose of creating compatible implementations. http://partners.adobe.com/asn/developer/legalnotices.jsp If you modified an application which implements PDF so that it was incompatible with Adobe's specifications, you might be outside the scope of Adobe's patent license grant. That's interesting to know - though I don't intend to read the patents themselves. Presumably you are not suggesting that programs that manipulate PDF files are non-free just because you can infringe a US patent by modifying them. Are you suggesting we should avoid using PDFs? By the way, is ReportLab (a python toolkit for generating PDFs) free software? Their website seems not to be working at present.
Re: License requirements for DSP binaries?
Florian Weimer [EMAIL PROTECTED]: We should allow it if source code once existed but no longer exists (all the copies of the source code were wiped accidentally at some time in the past). So it's okay to ignore the DFSG in this case? It's not ignoring the DFSG; it's interpreting source code to mean the preferred form for modification, as in the GPL, and it's interpreting that to mean of the forms that are still extant. Back to the DSP binaries: I remember that at one point there were DSP binaries included in the Linux kernel source. Is that still the case? I think my opinion was that the DSP binaries in the kernel source are not DFSG-free, because someone still has the source, but they are not a GPL violation because they are not part of the kernel despite being distributed with it for good technical reasons. Look at the right-justification of this e-mail! An accident, I assure you ...
Re: Why documentation and programs should not be treated alike
Richard Stallman [EMAIL PROTECTED]: This is why the GFDL does not require complete corresponding source code for a published manual. It's easier to change the manual if you have this, but no disaster if you don't: you just have to write your own mark-up, which is pretty straightforward. The requirement for a transparent copy is so that you don't have to keyboard the whole text again in order to publish a modified manual. Even that is not impossible, but it's a bigger pain than writing mark-up afresh. I'm not sure I agree with this. In many cases it is probably cheaper to get someone to OCR or type in the plain text than to typeset it to the original standard, given the plain text. I admit that the following isn't directly relevant to manuals or documentation, but in some cases, such as a bilingual dictionary, the mark-up can be very complex and non-trivial to reinvent. I'm currently working on a bidirectional dictionary where both directions are derived from the same source data using a Perl script that is already hard to understand and I still have to add some features. I might release the whole lot under the GPL. I wouldn't want to release it under the GFDL.
Re: There was never a chance of a GFDL compromise
Richard Stallman [EMAIL PROTECTED]: This reinforces my conclusion that it is essential for these sections to be unremovable as well as unmodifiable. Well in that case you can rest assured that they will be removed from Debian together with the documentation to which they are attached!
Re: A possible GFDL compromise: a proposal
Richard Stallman [EMAIL PROTECTED]: Manuals are not free software, because they are not software. The DFSG very clearly treats software and programs as synonymous. And we very clearly treat everything in Debian as software (see the first clause of the Social Contract). That clause appears to neglect the fact that there are things other than software in the system. It seems to say that all the software must be free software. Aaargh! Debian Will Remain 100% Free Software = Debian Will Remain 100% Software If I buy something in the supermarket that is advertised as 100% cow's milk I expect to get 100% milk. I don't expect to get 85% cow's milk, 15% goat's piss and the piss-poor excuse that 100% of the milk is from cows.
Re: A possible GFDL compromise: a proposal
Mathieu Roy [EMAIL PROTECTED]: Does everybody on that list, that thinks that GNU political/historical/philosophical/ texts must be DSFG compliant to be distributed by Debian, also thinks that the Debian logos must be DFSG compliant? No. I think it's much easier for Debian to make an exception for Debian's logo than for documentation produced by other organisations, be they the FSF or O'Reilly. So the next step seems obvious to me, Debian have make a choice: - follow the strict definition of DFSG promoted by many persons on that list and move the Official Debian Logo to non-free. - think about an another policy for logos or political/philosophical/historical texts. One could do that, but it wouldn't help because the FSF documentation under discussion is neither a logo nor in the category of political/philosophical/historical texts. Are we going round in circles here?
Re: A possible GFDL compromise: a proposal
Mathieu Roy [EMAIL PROTECTED]: One could do that, but it wouldn't help because the FSF documentation under discussion is neither a logo nor in the category of political/philosophical/historical texts. The GNU Documentation under discussion _is_ in the category of political/philosophical/historical texts. Only these texts can be invariant in the GFDL. The GNU Documentation under discussion is _not_ in the category of political/philosophical/historical texts. Only the invariant sections are in this category. So your suggestion would only help if one were to remove all the actual documentation from the GNU Documentation and replace it by other unrelated political/philosophical/historical stuff so that the FSF invariant sections would still be secondary. Then Debian could include the FSF's invariant sections, if Debian changed its rules in the way you suggested, but Debian still couldn't include the actual documentation, so why exactly do you think this is useful?
Re: A possible GFDL compromise: a proposal
Mathieu Roy [EMAIL PROTECTED]: No, it makes thing less clear, in fact. - If everything that is on a Debian CD is software, it may means that any text that can be included (for instance the Bible) is software for Debian. - But it may also means that the only content that can be on a Debian CD must be software under the definition that I copied from two dictionnaries in the mail I just sent. In this case, Bruce statement would just mean that the Bible cannot be included in Debian. The Bible is included (bible-kjv-text) so clearly in the context of the DFSG software does indeed mean the stuff that isn't hardware. Can we stop this discussion now?
Re: Changing a license of a unmaintained software
Mathieu Roy [EMAIL PROTECTED]: But to avoid any delicate issue in the future, if I were you, if would ask him to confirm with a gpg signed email the license change (just an email is something easy to fake). Getting him to sign the e-mail with his own key won't help much in the case of him later claiming that the e-mail isn't genuine: he could at any time accidently publish his secret key and revoke it; now anyone can fake the e-mail. A better solution is to do everything in public so that there are lots of witnesses. In some countries, it's accepted as a valid proof of the origin of the email. A signature made with a secret key that was published on Usenet can hardly be a valid proof of anything. Edmund
