How does the license of an M4 autoconf macro affect a software license?
Hi, the game Battle of Wesnoth contained in Debian is licensed under GPL v2+. Now a dependence on the Boost libraries (www.boost.org) was added and the configure script missed a test for it. So I integrated (see https://gna.org/bugs/?10419) the file boost.m4 from http://repo.or.cz/w/boost.m4.git which is licensed under GPL v3+ into the build system (I these macros from configure.ac). Now the question: Could the different license versions cause problems? Can Wesnoth still be shipped as GPL v2+ or not? I would also like to know the following (as the author is willing to relicense boost.m4 if necessary to the Boost license): If a possible non-free software which uses Boost would start using boost.m4 in their build environment, is it necessary to relicense the whole software under GPL v3+? I searched the web for quite some time and couldn't find an explicit answer except: According to GPL v2 the build system belongs to the source code of software but is the integration and usage of M4 macros a modified work? Since I mentioned that some autoconf macros contain a GPL exception I have doubts about compatibility and Eric S. Raymond asked me to resolve it so please help ... Thanks, Jens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#451799: new evince cannot display Japanese characters correctly
Hi, On Wed, 28 Nov 2007 13:33:07 -0800, Steve Langasek wrote: On Wed, Nov 28, 2007 at 02:43:34PM +, John Halton wrote: On 28/11/2007, Michael Poole [EMAIL PROTECTED] wrote: Based on a quick look, these files establish a correspondence between different character set encodings. Copyright protects creative expression. What is the creative part of this mapping? I can see two possible bases: character selection and ambiguity resolution. Can't speak for the US, but in the UK the standard for copyright protection is somewhat lower than creative expression. Generally, a work merely has to be original (i.e. not copied from elsewhere). However, a file consisting of mappings of this nature probably constitutes a database under UK law (and in other EU jurisdictions). In that case it only attracts protection if, and only if, by reason of the selection or arrangement of the contents of the database the database constitutes the author's own intellectual creation. I really doubt that this file would meet that test, or that it would reach the substantial investment test for the separate database right. That being said, I am not sure enough to risk it in court on my dime. I would hope that Adobe would be willing to provide the data with a DFSG-compatible license and/or a notice that makes it clear whether they think the mappings are protected by copyright. Well, quite. What I said above only goes to show how complex copyright questions can become, and that's only looking at one jurisdiction. I find it hard to believe Adobe could or would assert copyright here, but I'm no more willing than you to be the one who tests that hypothesis! FWIW, I believe a search of debian-legal archives will show that we've come to the same conclusion before about copyrightability of non-creative databases, and are already shipping a number of these in Debian. I have a question: can we regard CMaps as database? Well, several years ago, some Japanese developers paid attention to the fact that CMaps are PostScript programs, not data tables like unicode tables[1]. Also, Adobe prohibits modification of that format as well as the mapping. BTW I have a news: Kenshi Muto (kmuto) asked GNU pdf developers about how they intend to get a handle on the CMap issue. The answer was they could try to ask Adobe to relicense the maps (a formal petition from the FSF)[2] and they proposed that they could do that along with Debian in order to achieve a better effect[3]. IMHO (actually, Taketoshi Sano's opinion[4]), Adobe would like to promote PDF (and PostScript), but would not like to increase incompatible unique CMaps that will impair the credibility of the format. So, it would be better for Adobe to loosen up the license of its CMap than to force FLOSS communities to create unique CMaps. So, formal petition would be a good measure. (IANAL, IANADD, and TINLA, but I am one of Japanese guys who suffers inconvenience from the CMap issue of PS/PDF. ;-) ) [1] http://lists.debian.or.jp/debian-devel/200104/msg00092.html (in Japanese) [2] http://lists.gnu.org/archive/html/pdf-devel/2007-12/msg1.html [3] http://lists.gnu.org/archive/html/pdf-devel/2007-12/msg3.html [4] http://lists.debian.or.jp/debian-devel/200104/msg00160.html (in Japanese) Many thanks, -nori -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Review-request for Mugshot Trademark Guidelines
In message [EMAIL PROTECTED], John Halton [EMAIL PROTECTED] writes 3. If they charge a fee for the CD-ROM or other media on which they deliver the Mugshot™ code, they warranty the media on which the Mugshot™ code is delivered, thus ensuring that the recipient receives a usable copy. Paragraph 3 may be the first problem. It basically prevents cheap CD vendors from selling copies of Debian on an as is basis. Note that, in many jurisdictions, this is actually a legal requirement. For example, this clause would be meaningless in the UK because the vendor would be liable under SOGA (Sale Of Goods Act) anyway. Cheers, Wol -- Anthony W. Youngman - [EMAIL PROTECTED]
Re: Bug#451799: new evince cannot display Japanese characters correctly
Hi, On Thu, Dec 06, 2007 at 04:11:59AM +0900, Kobayashi Noritada wrote: FWIW, I believe a search of debian-legal archives will show that we've come to the same conclusion before about copyrightability of non-creative databases, and are already shipping a number of these in Debian. I have a question: can we regard CMaps as database? Well, several years ago, some Japanese developers paid attention to the fact that CMaps are PostScript programs, not data tables like unicode tables[1]. Also, Adobe prohibits modification of that format as well as the mapping. Being in program form doesn't automatically make it creative and copyrightable. Adobe's prohibition on modification of the format is begging the question: if it's not a copyrightable work, their prohibition carries no legal force (in the US). I have not looked at the CMaps myself, so I can't give you an informed opinion on whether I believe they contain a creative element; if you need me to give my (non-lawyerly) opinion on this, please provide a pointer to the CMaps. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Review-request for Mugshot Trademark Guidelines
John Halton [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 3. If they charge a fee for the CD-ROM or other media on which they deliver the Mugshot™ code, they warranty the media on which the Mugshot™ code is delivered, thus ensuring that the recipient receives a usable copy. Paragraph 3 may be the first problem. It basically prevents cheap CD vendors from selling copies of Debian on an as is basis. I'm not sure this is a real concern. are they really selling the media as-is? So If the cd comes scratched so bad it does not work, or is warped, the buyer has no recourse? I can see no warrenty on data being useable for anything, but I'm not aware of anybody who sells Disc's who does not have at least a limited warrenty covering manufactiong defects on the media. (As opposed to data defects) [Snip, following quote is in regard to the FTP part of the license] If Red Hat consider a README in the same download directory to be good enough then that should be fine, however. Presumably it would be fine in general. However, it may be a problem for Debian, as I'm not sure our arcitecture is properly set up for this. Including that notice in the package long description would certainly cover the packages.debian.org and downloading via aptitude/synaptic. But I don't think out ftp architecture is set up such as to allow us to include a README file in the same directory. My guess is that including the statement in the package's long description is would be considered by RedHat as sufficient, but we should really get clarification. Modified Mugshot Client Code – Limited Trademark Permission Red Hat and the Mugshot Project support the extension of Mugshot™ to new platforms and languages. Red Hat grants a limited permission to use the Mugshot™ mark on these modified versions of the Mugshot™ client code Note that is only covers extending Mugshot to other platforms and languages, not distributing modified versions for the same platform or language. But packaging it for Debian probably counts as extension ... to a new platform, especially given the stated purpose of this limited permission being to make Mugshot as widely available as possible (while preserving Red Hat's trade mark rights). Indeed. I would consider Debian a seperate platform, in so far as it has a seperate package managment system. Clarification by RedHat on this point would be nice, but I'm fairly convinced this is not a problem. provided the following conditions are met: 1. You identify your version of the client code as an adapted version of Mugshot™ in the “About” dialog associated with the Mugshot icon. The attribution statement should be similar to: “Mugshot™ client code adapted for .” I'm guessing that's OK. I agree. There is no special freeness problem here because we (or the end user) could always change the program name if they wanted to remove that message. 2. You do not prefix the named product with Red Hat (e.g. Red Hat Mugshot is not allowed.). That's fine too. Agreed. No problem there. After all Debian's Red Hat Mugshot package would sound really weird. :-D. 3. The changes you make do not alter the fundamental user experience from that provided by Mugshot™ as made available by Red Hat. That is, you can: 1. localize the client code; 2. provide patches or bug fixes to the client code; 3. provide extensions or plug-ins to the client code; or 4. adapt the client code to run on another platform; but 5. you cannot substantively modify or remove basic components of the client code such that the user experience is altered. 4. You do not redirect the client code to operate with a server other than the server found at mugshot.org Again, that's probably OK too. From a free software POV, it's always open to people to do any of the unpermitted acts under a different name. Yeah. That sounds fine, and sounds like it includes all we really would need to make a Debian package using the Mugshot name. It is very important that any modified version of Mugshot™ meet (or exceed) the quality level people have come to associate with Mugshot™. Red Hat reserves the right to require persons to cease use of the Mugshot™ mark if they are redistributing software with low quality and efforts to remedy the situation have not succeeded. This is probably a key point in practice. It would be worth getting Red Hat to confirm that they are happy with the Debian package. IIRC the issue over Firefox/Iceweasel arose (at least in part) because Mozilla were unhappy with some of the changes being made in order to Debianize the software (e.g. disabling the built-in update system). That was a small part. They had a policy of not letting patched versions be called Firefox, unless the patches were approved. That is fair enough, and I suspect that most changes
Re: JOGL in Debian
On Wed, 05 Dec 2007 16:58:50 +0100 Sylvestre Ledru wrote: I am one of the developer of Scilab. We are rewriting the GUI from scratch using Java (Swing) and JOGL. Since we prefer to have Scilab packages available (especially because Scilab is going to change his license to a free one), That's really good news! Which license are you considering to switch to? It is probably going to be CECILL. Do you mean this one? http://www.cecill.info/licences/Licence_CeCILL_V2-en.txt It has an explicit conversion-to-GPLv2orlater clause, IIUC. For this reason, it meets the DFSG. Last discussion on this topic on debian-legal that I could find is http://lists.debian.org/debian-legal/2005/08/msg00144.html However, why not just adopt the plain GNU GPL v2 ? Disclaimers: IANAL, TINLA, IANADD, TINASOTODP. Firstoff, from a technical point of view, shipping the *exact same code* in two different packages does not seem to be a good idea. Could this duplication of code be avoided? Is it possible to link or otherwise use the code included in the mesa package, rather than packaging another copy of it? Well, it is the exact same code (ie not rewrote) but in Java... and I think JOGL devs prefer to avoid JNI code. Then it's not the *exact same code*: it's a translation in Java. That kinda explains why the original code included in mesa packages cannot be directly used. Anyway, from a DFSG-freeness point of view, that license is indeed problematic: see http://bugs.debian.org/368560 for the details. Unfortunately, there seems to have been too little progress on this bug so far. Do you know if anyone contacted the owner of the code ? Or if anything is planned to fix this issue ? I have not been directly involved in the issue: I think that the people who participated in the bug discussion should be contacted for further information. -- http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html Need to read a Debian testing installation walk-through? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp1SRwc4NXbY.pgp Description: PGP signature
Re: JOGL in Debian
I am one of the developer of Scilab. We are rewriting the GUI from scratch using Java (Swing) and JOGL. Since we prefer to have Scilab packages available (especially because Scilab is going to change his license to a free one), That's really good news! Which license are you considering to switch to? It is probably going to be CECILL. Firstoff, from a technical point of view, shipping the *exact same code* in two different packages does not seem to be a good idea. Could this duplication of code be avoided? Is it possible to link or otherwise use the code included in the mesa package, rather than packaging another copy of it? Well, it is the exact same code (ie not rewrote) but in Java... and I think JOGL devs prefer to avoid JNI code. Anyway, from a DFSG-freeness point of view, that license is indeed problematic: see http://bugs.debian.org/368560 for the details. Unfortunately, there seems to have been too little progress on this bug so far. Do you know if anyone contacted the owner of the code ? Or if anything is planned to fix this issue ? Sylvestre signature.asc Description: Ceci est une partie de message numériquement signée
Re: Review-request for Mugshot Trademark Guidelines
On Wed, Dec 05, 2007 at 09:18:54PM +, Anthony W. Youngman wrote: Note that, in many jurisdictions, this is actually a legal requirement. For example, this clause would be meaningless in the UK because the vendor would be liable under SOGA (Sale Of Goods Act) anyway. ...unless it was a business to business sale (as opposed to selling to a consumer). But I agree that the number of cases in which people are refusing to warrant the *installation media* (as opposed to the software) are likely to be pretty low in practice, even if the extent of the warranty is just We'll replace any dodgy discs. (Though that in turn makes me wonder why Red Hat bother to insist on the point.) The issue is that it is placing a direct requirement on those vendors, regardless of what the local law might say, for the sake of one package out of c.20,000. John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
