Re: BOINC: lib/cal.h license issue agree with the DFSG?
On Jan 2, 2010, at 2:11 AM, Steve Langasek wrote: No, it's not different at all - and a license that says you aren't allowed to do anything illegal with this software is *not* DFSG-compliant. Civil disobedience should not result in violations of the copyright licenses of software in Debian. Civil disobedience works by appealing to the general public. You don't simply break the law and claim it was rightful civil disobedience. Those who choose not the follow the law must know the consequences of what they do. By that reasoning, if your cause is indeed just, and worthy, then I don't see why the same view doesn't apply to possible copyright suits. Who's to say that the copyright owner doesn't agree with you? Why would the potential threat of an infringement suit dissuade you more than, say, 10 years in jail? Because you can be sued and forced to declare bankruptcy? Or put it this way, if the software said you may use this for illegal purposes then that could be seen as promoting breaking the law. And doesn't the GPL depend on people, you know, following the law? Otherwise I'm going to say that my not following the GPL is justifiable civil disobedience against (rolls dice) the hegemony of (rolls again) oppressive communistic (rolls again) techno-weenies. If the copyright owners of embedded software for vehicles, and of GPS systems, had the same clause, do you think they would be suing people for copyright infringement every time you went over the speed limit? Andrew da...@dalkescientific.com -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Artistic and LGPL compatibility in jar files
On Dec 15, 2009, at 10:20 AM, Matthew Johnson wrote: Clause c and the fact that the author may have claims to the JUMBO name under trademark law means he can certainly require a name change. I don't think he can stop you from claiming that you can read and write his format, however. A secondary thing here, however, is that you generally want to get on with your upstream. If you start doing things he doesn't like, then he will make life difficult for you (see: ion3). Yeah. Since the biggest users of the Jumbo software, and also promotors of that CML format, distribute a patched version of the software, it's something they'll have to work out amongst themselves. I think it won't stay for all that long. Either that or I'll be an annoying bastard and harp on it in emails. ;) The feedback here has helped. The CML maintainers are going to split off the CC-BY-ND into another file which can go into non-free, the rest of the JUMBO code will clarified to be Apache 2.0, the CML developers are going through all their code to check that there are no other outstanding licensing details like that. There's the minor point outstanding of it Apache 2.0's relicense clause allows LGPL, but the only time that will come into play is if as of yet non-existent downstream providers package the software and distribute the derived system with a license fee. My judgement is that that is unlikely, what CML has done is enough, that the result is free (since it can all go to GPL), and therefore these changes fit into Debian's policy. Cheers! Andrew da...@dalkescientific.com -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Artistic and LGPL compatibility in jar files
On Dec 17, 2009, at 12:19 AM, Matthew Johnson wrote: I assume, then, that it can function without that non-free file? Yes. Either it provides validation capabilities they don't need, or they have some hand-written code to deal with the parts that were automated because of having the schema around. Andrew da...@dalkescientific.com -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Final updates for this Python Policy revision
On Dec 17, 2009, at 2:00 AM, Anthony W. Youngman wrote: CLOSED derivative works. If it's copyright, it's proprietary. proprietary == property. If it's copyright, it has an owner, therefore it's property, therefore it's proprietary. Although the GNU project disagrees again with your viewpoint: http://www.gnu.org/philosophy/words-to-avoid.html “Closed” Describing nonfree software as “closed” clearly refers to the term “open source”. In the free software movement, we do not want to be confused with the open source camp, so we are careful to avoid saying things that would encourage people to lump us in with them. For instance, we avoid describing nonfree software as “closed”. We call it “nonfree” or “proprietary”. http://www.gnu.org/philosophy/categories.html#ProprietarySoftware Proprietary software is software that is not free or semi-free. Its use, redistribution or modification is prohibited, or requires you to ask for permission, or is restricted so much that you effectively can't do it freely. Of course, in this regard Stallman's well known viewpoint that intellectual property is a legal unjustifiable term as copyright, patent, and trademark law are not based in property rights at all, is counter to what I expect most lawyers would say. (I say that if a dwarf planet like Pluto isn't a planet then it holds that intellectual property might also not be property. But I'm just a guy on a couch.) In the context of debian-legal, especially where the term copyleft is used, I would have assumed that the default vocabulary is well aligned with that of GNU, and to be expected. Andrew da...@dalkescientific.com -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Artistic and LGPL compatibility in jar files
On Dec 17, 2009, at 3:41 AM, MJ Ray wrote: This part followed if it's the book I think it is, then I already have read it. Maybe the contradictions aren't in the part of the book linked, but elsewhere in the book read. Indeed. BTW, I should have interpreted the original phrase as read the linked document rather than read the book. I have not found those contradictions, and as I asked in my earlier response I would like an example. Maybe a proper citation instead of a bare URL would have helped avoid this confusion. (Line wraps would help too.) Since my first post, of which I think you are talking about, also included the book title and author name, I figured that was sufficient. Should I have also included publication year and publishing company? Or do I have to give the proper citation every time I repeat the same book link in a thread? I think you're the first person in about 12 years to mention that linewraps are a problem. I stopped carefully linewrapping when I started seeing all my nicely wrapped text look ugly once quoted a few times and displayed on systems which had automatic wrapping. I thought that nearly all of the email programs did that these days, including the text-based ones. Linewrapping at fixed column sizes also looks very ragged when viewed with proportional fonts. Further, Anthony W. Youngman isn't the only debian-legal contributor to think Larry Rosen's interpretations should not be taken wholesale, nor the only one who can't give full citations because those impressions were formed by interactions as much as literature. I'm another and I'm pretty sure there are others. Eternal September. I've never posted here before, and I'll be unsubscribing soon, once this thread is over. They did not come up in my searches for more information about this topic. So people who were persuaded to buy the book were persuaded by the book - is that surprising for this type of book? Pardon? One isn't required to purchase an item via Amazon before one can comment on said item, at least to my understanding. I believe one could get the book from the library and also comment on Amazon. Or read parts of it online and gratis, as I did. Also, remember that Amazon ... It seemed an appropriate source to try to understand if the views of Youngman were singular, rare, or widely espoused. It wasn't my only information source used to construct my reply, and I gave references to those other sources, including two letters by Stallman defending Rosen from more egregious statements made by reviewers of Rosen's book. In one of them Stallman does point out that Rosen's criticism did not hold up in court, but that is the only criticism I could find regarding the book that I could find from a freedom perspective. Again, I was not thorough. Given that the response came so quickly I would assume it's a matter of a few moments to point to something definite, and that my details responses would indicate that it's not a trivially found and widely expressed idea. It scores 3.8 our of 5 on http://www.librarything.com/work/72601 (compared to 4.17 for Free Software, Free Society: Selected Essays of Richard M. Stallman http://www.librarything.com/work/179957 which I think is the highest-rated book in the cluster: read them yet?) I had never heard of librarything before this. I will have to look at it some more. I have not read that collection of essays by Stallman. The point I was researching was in regards to Youngman's comment I'm always wary of explicitly relicencing. The GPL doesn't permit it, and by doing so you are taking away user rights. Searching Stallman's book now I see that relicense is not mentioned and sublicense is only mentioned as parts of the quoted GNU licenses. It provides no extra information to this topic. I still hold that Youngman is wrong in saying that relicensing takes away user rights, as a universal statement. The best counter example is the GFDL-Creative Commons relicensing, when the original GFDL's license grant is essentially identical to the GPLs. He urged me to Read what the GPL says, CAREFULLY, but I see nothing in GPLv2 which prevents the addition of a relicensing clause of the kind which occurred with GFDL. Rosen's book, on the other hand, did specifically discuss the need for sublicensing and relicensing, and helped me understand some of the changes that went into GPLv3. As well, it helped me understand some of the nuances between the BSD and MIT licenses. As far as I recall (I read it too long ago), the book was partly a sales pitch for Rosen's licences I did not notice anything in the chapters I read which mentioned any of his licenses. I did not read the entire book. Nor do I know of the 5-point definition of which you also spoke. It may have occurred after he published the book. it should be immediately obvious that that book is probably going to have an inflammatory perspective. Its title is Open Source Licensing: Software Freedom
Re: Artistic and LGPL compatibility in jar files
On Dec 14, 2009, at 8:36 PM, Anthony W. Youngman wrote: (And you might guess I read groklaw avidly, where there's a lot of emphasis on getting things right.) Sorry, but I don't know what groklaw is, at least, not enough to guess about your interests in it. I'm contacting debian-legal because I don't know enough about what the details are concerning a package where the developers want it to be distributed as part of Debian. After all, rms isn't keen on the LGPL - it's just a useful stepping stone on the way to full GPL as far as he's concerned. And having seen that, I'd be rather wary of the LGPL 2.1! For what it's worth, the authors of these packages I'm talking about want LGPL and are removing all traces of GPL-licensed code from their package. While I'm more of an BSD/MIT kinda person. The subject line of this post is also about the LGPL, so I'm really diverting things by going into a GPL discussion. Let's go back to what I originally wrote - I'm wary of relicencing. While I don't think rms has done anything wrong (as far as I can see he has just enabled switching from one strong-copyleft licence to another), it still throws up the spectre of relicencing! Or the more complete quote I'm always wary of explicitly relicencing. The GPL doesn't permit it, and by doing so you are taking away user rights. I still would like to know what user rights I'm taking away by relicensing. Stallman seems to think that relicensing is acceptable under some circumstances so long as the essential rights are preserved, which include the rights supported by GNU and the FSF. (I say essential rights because that is what Stallman used. There are obviously differences between the licenses.) Okay, I'd use the FSF-recommended wording, fine. (Actually, personal choice, I'd probably take a leaf out of Linus' book and use the wording either version 2 or version 3.) One of the projects I work with uses source code which was explicitly GPL version 2 only. Now they are starting to have problems integrating with GPLv3 software and they are considering if a massive rewrite is in order. But note, the GPL *itself* says that the recipient gets their licence from *me*. And the licence I would grant is 2+ or 2 or 3. I pointed out the quote from a copyright lawyer with a special interest in free software who said that the GPL was ambiguous about sublicensing and if a chain of licenses was required or not. Oh - and the GFDL 1.2 does *not* allow relicensing to CC-BY-SA. Your legal logic has slipped up. You've made the elementary error of confusing the *grant* of licence with the licence *itself*. If I use the recommended wording from GNU, which is what I quoted and was using as a reference, then the phrase is Version 1.2 or any later version published by the Free Software Foundation; Obviously if the license says 1.2 and leaves out that provision for sublicensing/ relicening/ whatever you want to call it, then it's not possible to change it. The GPL even has a section where it describes the impact or later has on being able to re/sub/license. Just like if something says GPL 2 and leaves out the provision for or later then it cannot be changed to GPLv3. It's just, well, I didn't say that. I don't understand why you think I'm confused about this matter. If I licence my work as GFDL 1.2 and you relicence it as CC-BY-SA, I'll be after you for infringement like a shot! You *need* the or later wording in the grant, and that is nothing to do with the licence itself. I see. It's because when I said Well, the GPL does allow relicensing to newer versions of the GPL it's because I should have written Well, the GPL does allow relicensing to newer versions of the GPL so long as you use the recommended phrase from GNU which allows 'or later' licenses to be applied. If you get a work as GFDL 1.2 or later, *then* and *then*only* can you say to yourself stuff 1.2, I'll use 1.3 which allows you to pass the stuff on as CC-BY-SA instead of GFDL. I really do think you're reacting to what was a minor omission on my part, by my using the phrase the GPL when it was the grant that most people make to use the GPL. Pointing out that omission would have been more clarifying than saying IT DOESN'T, ACTUALLY !!! My omission came up because you outright declared that relicensing takes away rights, when it's clear from the history of free licenses that relicensing does occur and that it's possible to relicense without taking away (essential) rights. In this case, I think *YOU* are now the licensor. My legal-fu isn't up to this, but if I originally granted GFDL, I don't think a CC-BY-SA recipient can get their CC-BY-SA licence from me (they are *restrospectively* changing my grant of licence, which I don't think is possible). Likewise with LGPL 2.1, I think the person who changes the licence to GPL becomes the new licensor. Except that that wasn't at all
Re: Artistic and LGPL compatibility in jar files
On Dec 14, 2009, at 9:16 PM, Anthony W. Youngman wrote: I can't be bothered to read the book, but if it's the book I think it is, then I already have read it and came to the conclusion that the author was blind. Still, I have given references to Stallman, to the GNU pages, to the XEmacs project, and to Rosen, in order to back up my views and understanding. I would like to see some external references to back up your statements. Read it for yourself, make sure you've got a copy of the GPL next to you so you can *check* every reference he makes, and see if you come to the same conclusion I did, namely that the black letter of the GPL flatly contradicted the core assumption on which a large part of this book is based. You haven't read it and you made that conclusion? It sounds like you are promulgating hearsay and rumor. There's a free online copy which I linked to, and if what you are saying is right then it should be easy to point out some of the contradictions. Are you sure you haven't confused Don Rosenberg with Larry Rosen? Stallman wrote http://richardstallman.sys-con.com/node/128143/mobile Don Rosenberg's review in LWM (Vol. 3, issue 4) of Larry Rosen's book, Open Source Licensing, did double-duty as a platform for FUD about the GNU GPL. and while Stallman expresses disagreements with Rosen on requirements on combined works, he is much more directed towards Rosenberg. Stallman also writes in: http://richardstallman.sys-con.com/node/48833/mobile Richard Stallman writes: Maureen O'Gara's review in Linux Business Week of Larry Rosen's book misrepresents the Free Software Foundation's views, when it says we criticized Rosen for recognizing...licenses other than the GPL. I find nothing by Stallman which expresses similar levels of dismissiveness towards Rosen as you have, which should have arisen if the book was as against the GPL as you say. BTW, none of the reviewers on Amazon agree with you http://www.amazon.com/Open-Source-Licensing-Software-Intellectual/product-reviews/0131487876/ref=dp_top_cm_cr_acr_txt?ie=UTF8showViewpoints=1 and I thought that if the the book would be that poorly written then there would be some evidence. I have now read a few chapters of Rosen and found them to be instructive, interesting, and clear. Oh - and I've more than enough experience of lawyers who's grasp of the law appears tenuous, I don't kow-tow to them until they've earnt my respect. (I respect them as a *person* until they *earn* my respect as a lawyer. If this is who I think he is, he lost that ... :-( Congratulations. As for me, citations needed. Andrew da...@dalkescientific.com -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Artistic and LGPL compatibility in jar files
On Dec 14, 2009, at 11:24 PM, Anthony W. Youngman wrote: It's a law site, where SCO Group's lawsuit against IBM, Novell and Linux in general is getting thoroughly dissected. If you're not interested then fair enough, but copyright and the GPL in particular are very important there. I have and enjoy using my Mac. I remember that case but did not follow the details. Sounds weird to me you're deferring to rms then :-) While he'd defend your *right* to choose BSD/MIT or LGPL, he'd be very sorry about your choice - you should be choosing GPL :-) This is an issue of Artistic License and LGPL compatibility which I'm bringing up because people I associate want to include their software with Debian. Debian's policies and those of Stallman's are well aligned, excepting that Stallman and the FSF does not consider the Artistic License to be a free license while Debian does. My deference, as you incorrectly put it, is because that's the closest proxy I have to something which is definite for this argument. My own views on BSD are largely irrelevant. I also wrote that I thought the artistic licence was close to BSD (ie not strong copyleft). And that would not be correct. The Artistic License has many clauses which are not BSD-like, such has prohibitions against license fees which the BSD does allow. You can relicence BSD as closed source - where are your essential rights now? I quoted and used the phrase essential rights because it derives from Stallman's use in the GFDL-Creative Commons relicensing, which he specifically called a relicensing which does not lose essential rights. I obviously thought something similar could happen with artistic. (looking at it - especially artistic 2 - in more detail, I see that it's far more strong copyleft than I thought.) Why did you not look at it the first time, instead of making quite incorrect assumptions about it? Well, linux itself is explicitly v2 only :-) I was unaware of that. I rarely am on a Linux box. My main server machine is a FreeBSD box. I pointed out the quote from a copyright lawyer with a special interest in free software who said that the GPL was ambiguous about sublicensing and if a chain of licenses was required or not. I see the GPL explicitly agrees with me, not Larry Rosen :-) !!! This is the GPL v3 - read the last section of 2. Basic Permissions : Which means you didn't look at the top of the first page of the link I sent you, where you would see the book was written in 2004 and therefore pre-GPLv3. It also means you didn't recall my original text where I wrote: As you can tell, a professional lawyer in this field is not clear about if the GPLv2 allows sublicensing, so I hope it's understandable how someone could view a change from GPLv2 to GPLv3 without keeping the chain of titles (which is the common practice) could be considered a relicense. I believe I have careful to only used references from that book with respect to GPLv2, and not use it as a way to interpret reading the book has helped me understand some of the improvements made in GPLv3. The above was one of the few cases where I was not. The proper behavior should be to point out that I likely was imprecise and should have written GPLv2 instead of simply GPL. 10. Automatic Licensing of Downstream Recipients. Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License. This is exactly the section (maybe worded, certainly numbered, differently) that I have repeatedly been referring to from the GPL v2. This is the specific improvement to text which Rosen says is ambiguous in GPLv2. As you have not bothered to read the text and yet still comment on what you believe he has written, I shall copy it here: http://rosenlaw.com/Rosen%5FCh06.pdf This GPL section 4, with its negative wording, is also the only place that references the right to sublicense. One might assume from the way GPL section 4 is worded that the right to sublicense was intended in sections 1 (right to copy), 2 (right to modify) and 3 (right to distribute) as well. However, section 6 implies that there are no sublicenses but instead a direct license from each up-stream contributor: ... As to sublicensing, then, the GPL is ambiguous. I refer you to the discussion in Chapter 5 of sublicensing in the MIT license. Sublicensing rights can be very important to open source distributors for dealing properly with the chain of title to contributions. In practice, most software projects ignore the issue completely and assume that, for GPL software, only the most recent license in the chain of title matters. They assume that GPL licensed software is sublicenseable, but the GPL isn’t clear about that. Sorry, I know I'm
Re: Artistic and LGPL compatibility in jar files
On Dec 15, 2009, at 12:20 AM, Ben Finney wrote: More precisely, the grant would need to say (words to the effect of) either: You may do X, Y, Z to this work under the following terms: foo, bar, baz. or: You may do X, Y, Z to this work under the terms of foobar license; see $EXPLICIT_REFERENCE_TO_SPECIFIC_VERSION_OF_FOOBAR_TERMS. which brings my back to my original question. The LICENSE.txt file from JUMBO/CML says All JUMBO code is distributed under the Open Source Artistic License (http://www.opensource.org). You are free to modify the code but if you do it may no longer be distributed under the name JUMBO (or a derivative) without permission of Peter Murray-Rust. Any distribution must acknowledge the origins and also include copies of the JUMBO source (see Artistic License for details). You may not claim that a modified version is a compliant CML system and may not assert that it reads or writes CML. In private mail the copyright owners have clarified that this is 2.0. How do I interpret this LICENSE.txt? The Artistic License 2.0 allows relicensing to the GPL. I'm well and clear about that (though there's still a subtle question of if it allows relicensing to the LGPL). However, if I use clause 4(c)(ii) to switch the GPL, am I and my downstream users still prohibited from: - distributing the software under the name JUMBO (or a derivative) (Jumbo, Jr, Dumbo, Elephant and Timothy all seem derivative) - calling a modified version a compliant CML system - asserting that a modified version can read and write CML? That is, are these clauses additions to the Artistic License 2.0 which must be preserved even after 4(c)(ii) relicensing to the GPL? My suspicion is that derivatives must still be prohibited from those activities. Is the resulting software (with these extra limitations) free software enough for Debian? Best regards, Andrew da...@dalkescientific.com -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Artistic and LGPL compatibility in jar files
On Dec 13, 2009, at 2:24 AM, Anthony W. Youngman wrote: In message f4ccec28-fe42-4af3-b0c0-c832a6b0d...@dalkescientific.com, Andrew Dalke da...@dalkescientific.com writes Well, the GPL does allow relicensing to newer versions of the GPL... IT DOESN'T, ACTUALLY !!! Read what the GPL says, CAREFULLY. Here is relevant commentary in Rosen's book Open Source Licensing book at http://rosenlaw.com/Rosen%5FCh06.pdf This GPL section 4, with its negative wording, is also the only place that references the right to sublicense. One might assume from the way GPL section 4 is worded that the right to sublicense was intended in sections 1 (right to copy), 2 (right to modify) and 3 (right to distribute) as well. However, section 6 implies that there are no sublicenses but instead a direct license from each up-stream contributor: ... As to sublicensing, then, the GPL is ambiguous. I refer you to the discussion in Chapter 5 of sublicensing in the MIT license. Sublicensing rights can be very important to open source distributors for dealing properly with the chain of title to contributions. In practice, most software projects ignore the issue completely and assume that, for GPL software, only the most recent license in the chain of title matters. They assume that GPL licensed software is sublicenseable, but the GPL isn’t clear about that. I will try to use the word sublicense in the future as that seems more precise. As you can tell, a professional lawyer in this field is not clear about if the GPLv2 allows sublicensing, so I hope it's understandable how someone could view a change from GPLv2 to GPLv3 without keeping the chain of titles (which is the common practice) could be considered a relicense. Best regards, Andrew da...@dalkescientific.com -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Artistic and LGPL compatibility in jar files
[ on combining LGPL and Artistic Licenses in a single JAR file as part of a Java library distribution.] On Dec 12, 2009, at 3:26 PM, Matthew Johnson wrote: I believe that neither of these licences specify the licence of the code they are linked with, so this will be alright. The resulting licence of the package will be _both_, applying to different parts, AIUI. Both licenses mention linking, although in the Artistic License it's an irrelevant reference. In 2.0 there's a direct statement about linking - section (8). I wasn't sure if the jar file counts as a derived work in its totality, or if it counts as an aggregate. If I read the Artistic License correctly then it does seem to limit itself to textual changes, which I didn't catch the first few times I read the license. There is a clause about object code. If a distribution includes object code then it must do at least one of four possibilities. Option (c) is c) accompany any non-standard executables with their corresponding Standard Version executables, giving the non-standard executables non-standard names, and clearly documenting the differences in manual pages (or equivalent), together with instructions on where to get the Standard Version. and is the easiest to do, since the JAR distributes no executable. So with the Artistic License it's clear (now) that there's no imposition on the license terms for the other packages in the jar. Interestingly, the license does mention linking in a strange way, given that this is a Java package (but obvious given the Perl source): 7. C or perl subroutines supplied by you and linked into this Package shall not be considered part of this Package. It's a moot point since CDK links to the Package and not vice versa. The above was for the Artistic License. For Artistic License 2.0 there is a section on linking. Aggregating or Linking the Package (7) You may aggregate the Package (either the Standard Version or Modified Version) with other packages and Distribute the resulting aggregation provided that you do not charge a licensing fee for the Package. Distributor Fees are permitted, and licensing fees for other components in the aggregation are permitted. The terms of this license apply to the use and Distribution of the Standard or Modified Versions as included in the aggregation. (8) You are permitted to link Modified and Standard Versions with other works, to embed the Package in a larger work of your own, or to build stand-alone binary or bytecode versions of applications that include the Package, and Distribute the result without restriction, provided the result does not expose a direct interface to the Package. If the JAR is an aggregate then (7) applies, but as CDK uses and exposes the API, I strongly suspect (8) is the one which applies. That is why the CDK will have to take the relicense clause, which is why I want to know if the Artistic License 2.0 relicense requirements are compatible with LGPL 2.1. Can the LGPL 2.1 library include functionality which requires this unalterable schema definition? Well, the biggest problem is that the CC-ND licence is not DFSG free, so inclusion of this at all would require putting the package in non-free. I've forwarded this to the CDK maintainer. He's going to look into pulling out that one file so it's not needed in the core. Thanks for the clarification! This software library and program are available under the Artistic License, which you can read in the Sourceforge details and in the distributed pom.xml file. The distribution also includes the file LICENSE.txt, saying: This doesn't sound like the two things being included in the same package? I'd expect it to depend on them at build and runtime. Matt I'm sorry, I didn't understand your comment. The source and jar distributions are named JUMBO and CML is a library distributed as part of JUMBO. I tried to read and understand the Artistic License but I got confused. The simplest conflict seems to be that the Artistic License says You may not charge a fee for this Package itself. where Package refers to the collection of files distributed by the Copyright Holder, and derivatives of that collection of files created through textual modification. This is in conflict with the LGPL 2.1 clause You may charge a fee for the physical act of transferring a copy. This may well be a problem for combining things into a single package, but I would not have thought it was an issue for things in different packages. Currently the CDK distributes everything in a single jar. One solution might be to distribute two jars. This does have some downstream difficulties. The JChemPaint Java applet uses CDK and it distributes a single applet jar. It would have to rearchitect a bit so there are two jar files, one with the JUMBO/CML code. This is possible, and I think would be an acceptable interpretation. I read that the FSF
Re: Artistic and LGPL compatibility in jar files
On Dec 12, 2009, at 11:12 PM, Anthony W. Youngman wrote: I may (well) be wrong, but I've always understood the INTENT of the artistic licence to be BSD plus a trademark licence. It has some clauses which are decidedly non-BSD-ish. See for example section (8) of the Artistic License 2.0. It is more meant to keep control over what it means to, say, be perl, which is not simply a trademark issue. But, if the JUMBO/CML people are happy, why not ask them to add an extra permission, or dual-licence. If they are the copyright holders (and therefore able to change the licence from Artistic to Artistic 2), they could always change the licence to Artistic 1 or LGPL2.1 if they wanted. *nods head* That's a couple of the possibilities I mentioned to them, and I assume they are considering the options. They do want to use the license to include trademark restrictions. I've explained how that doesn't work in practice. I don't think that made me new friends. I'm always wary of explicitly relicencing. The GPL doesn't permit it, and by doing so you are taking away user rights. Well, the GPL does allow relicensing to newer versions of the GPL... If you're distributing JUMBO/CML code *unchanged*, what I'd do is to keep it separate inside the package (in its own directory or something), and in the CDK documentation state that you are distributing JUMBO/CML under the LGPL as permitted by 4(c)(ii) of the Artistic licence. It a patched version. It also turns out that CDK wasn't distributing the patched source code as per the Artistic License requirements, but that's being addressed as part of this license cleanup. (There were other problems we've found, like some of the LGPL packages not listing in the documentation all of the third-party LGPL'ed components they were using and including. This has triggered a long-needed review of what's going into the distributions.) Thank you for your time, and best regards! Andrew da...@dalkescientific.com -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Artistic and LGPL compatibility in jar files
On Dec 13, 2009, at 2:24 AM, Anthony W. Youngman wrote: In message f4ccec28-fe42-4af3-b0c0-c832a6b0d...@dalkescientific.com, Andrew Dalke da...@dalkescientific.com writes I'm always wary of explicitly relicencing. The GPL doesn't permit it, and by doing so you are taking away user rights. Well, the GPL does allow relicensing to newer versions of the GPL... IT DOESN'T, ACTUALLY !!! Read what the GPL says, CAREFULLY. I didn't realize this was such a hot point to need the use of capital letters. Pretend I said LGPL instead of GPL. In that case I can talk about relicensing, yes, since the LGPL explicitly allows relicensing to the GPL: http://www.gnu.org/licenses/gpl-faq.html#compat-matrix-footnote-7 7: LGPLv2.1 gives you permission to relicense the code under any version of the GPL since GPLv2. If you can switch the LGPLed code in this case to using an appropriate version of the GPL instead (as noted in the table), you can make this combination. LGPL is, after all, the Lesser GPL. In v3 the LGPL is specifically designed to give additional permissions than those of the GPL. You talked about how relicensing takes away user rights but in that case relicensing from LGPL to GPL is more taking away user permissions, yes? Still, the LGPL is designed to be relicensed to the GPL. What about something which doesn't have a built-in relicensing? Pretend I had said GFDL instead of GPL, in which case this quote from Stallman is highly relevant: http://www.fsf.org/blogs/licensing/2008-12-fdl-open-letter The relicensing option in GFDL 1.3 is fully consistent with the spirit and purpose of the GFDL. Stallman used the term 'relicense' several times in that open letter, and as a highly-visible response to the accusations of misdeeds during the GFDL/CC-BY-SA change, where 1.3 has an explicit section titled RELICENSING while 1.2 did not. He cannot have used it by mistake or as a poor word choice. Does that relicensing take away any user rights which are part of the spirit and purpose of the GFDL? (It does obviously take away the right to revert the license to 1.2, but is that an important right?) Let's say I write a load of code, and release it with a notice saying this code is licenced as 'GPL version 2 or later' . The FSF suggests that you should write it thusly: This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. Compare to the suggested text for the GFDL Copyright (c) YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. If changing from GFDL 1.2 to GFDL 1.3 to CC-BY-SA is called a relicense by the FSF and by Stallman, and allowed under the GFDL 1.2, then I hope you can see why I did not spot the subtle difference in these texts which means I should not call switching from GPLv2 to GPLv3 a relicense. I looked again. I still don't see the difference. Could you point it out? What this give YOU is the right to redistribute the code according to the terms of the GPL v3. BUT - READ THE GPL - the people to whom you give the code get their licence from ME, NOT YOU. And I granted the licence as v2 or later. So, AT NO POINT WHATSOEVER, does my code become v3, whatever you say or do. If you modify my code and licence your stuff as v3, the resulting work then becomes v3-only because the licence of the work as a whole is the subset of the individual licences - here v3 - but my code still remains v2+. That interpretation is not consistent with the license upgrade path from GFDL 1.2-GFDL 1.3-CC-BY-SA. The 1.3 license clearly says a Massive Multiauthor Collaboration Site can relicense simply by republishing the site during the given time period. It does not require any changes to the content of the site in order to allow the relicense. I understand that some people feel Stallman and the FSF were wrong in doing this, but I again think I can excused for considering the change from v2 to v3 as a relicense. Even if you say that the GPL is different in this matter than the GFDL, can I not simply change the COPYING file because that alone is a modification to your code? Perhaps also changing the README to say Now under GPLv3 - w00t!, in order to add creative input? That would be consistent with statements like: http://calypso.tux.org/pipermail/xemacs-beta/2009-February/016039.html To relicense to GPLv3 in principle is just a global substitution, and exchanging the license text in COPYING. We should also make sure we have
Artistic and LGPL compatibility in jar files
There seems to be a licensing problem with some of the chemistry software packages, at least one of which is included in Debian. I'm working with a few of the package developers to see if there really is a problem. We need some better advice than I can find. Short version: - Can an LGPL 2.1 JAR library include an Artistic License library and still be distributed under the LGPL 2.1? - What about an LGPL 2.1 JAR library including a package under the Artistic License 2.0 license? Or would the entire package need to be moved to the GPL as a relicensing which is compatible with both underlying licenses? - One of the XML schema files is released (most likely) under the Creative Commons - No Derivation license. This is used by the Artistic License package in order to do schema validation. Can the LGPL 2.1 library include functionality which requires this unalterable schema definition? I'm going to simplify the story a bit and give a minimal example. CDK is the Chemistry Development Kit, available in Debian as http://packages.qa.debian.org/c/cdk.html It is distributed under the LGPL 2.1. It is one of a number of LGPL'ed chemistry tools which use the JUMBO and CML toolkits available from https://sourceforge.net/projects/cml/ This software library and program are available under the Artistic License, which you can read in the Sourceforge details and in the distributed pom.xml file. The distribution also includes the file LICENSE.txt, saying: == All JUMBO code is distributed under the Open Source Artistic License (http://www.opensource.org). You are free to modify the code but if you do it may no longer be distributed under the name JUMBO (or a derivative) without permission of Peter Murray-Rust. Any distribution must acknowledge the origins and also include copies of the JUMBO source (see Artistic License for details). You may not claim that a modified version is a compliant CML system and may not assert that it reads or writes CML. CML Schema is distributed under a Creative Commons license, allowing redistribution but NOT derivative works. This is to ensure that the schema does not mutate. == I have contacted one of the authors and gotten different responses. Originally he said the package was Artistic License 2.0 and then said the pom.xml file says it is 'Artistic License', and in discussions where I pointed out the existence of the LICENSE.txt file he said that he wants those additional restrictions in place, so I am going on the principle that the LICENSE.txt file is correct, and that the license is Artistic License and not Artistic License 2.0. Notably, the license text is not included in the distribution. CDK is one of the downstream chemistry toolkits which make Java jar distributions which use and repackage the jar file released by the JUMBO/CML project. One of them also includes a patched JAR file. These are not simple aggregates in a single jar file; the downstream packages make use of functionality from the JUMBO/CML package. My understanding is that mixing the Artistic License and LGPL 2.1 is not possible. I base this primarily on the FSF statement that they consider the Artistic License to be incompatible with the GPL. I have not found a statement about compatibility between the Artistic License the LGPL. I tried to read and understand the Artistic License but I got confused. The simplest conflict seems to be that the Artistic License says You may not charge a fee for this Package itself. where Package refers to the collection of files distributed by the Copyright Holder, and derivatives of that collection of files created through textual modification. This is in conflict with the LGPL 2.1 clause You may charge a fee for the physical act of transferring a copy. Beyond that, I don't know if the additional restrictions in the CML license are compatible with the LGPL 2.1. One clear conflict should be enough. I have talked with one of the authors of JUMBO/CML and they may be willing to relicense under the Artistic License 2.0. In doing the research for that I read that the FSF considers the 2.0 license compatible with the GPL because of the relicensing clause 4(c)(ii), which allows the GPL. My reading of the clause suggests that the 2.0 license does NOT allow relicensing under the LGPL. Specifically, 4(c)(ii) requires that the Source form of the Modified Version, and of any works derived from it, be made freely available. If I write a package which includes JUMBO/CML as a component or library and I release that in an object or executable form, then my release is a derived work, which means my entire work must be available under a free license. That is, 4(c)(ii) seems to require that the relicensed version must use a free license with the GPL viral nature. LGPL does not suffice. This is relevant because it would prevent CDK and other downstream packages from including libraries which are
