Re: The Software shall be used for Good, not Evil.
Josselin Mouette j...@debian.org writes: Le vendredi 26 mars 2010 à 18:43 +0100, Thomas Koch a écrit : Yes, it's this topic again. I've just had a short mail exchange with crockford himself. His final answer: If you cannot tolerate the license, then do not use the software. Could you please give me a definitive Yes or No for the below license? The Software shall be used for Good, not Evil. Definitely non-free, and the author's clarification removes any doubt. It is certainly a bizarre licence, and it is clearly best to regard it as non-free. However, I suspect he'd have a very hard time enforcing it in court. IANAL -- Måns Rullgård m...@mansr.com -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/yw1xiq8isx7h@unicorn.mansr.com
Re: GPL photographies, eg for backround
Ken Arromdee arrom...@rahul.net writes: On Mon, 29 Dec 2008, Josselin Mouette wrote: More precisely: if you are the copyright owner, you can publish it in whatever format you like, and if under a free license (e.g. the GPL), it will be acceptable for Debian. Say what? If you GPL a program and don't provide source code, Debian doesn't even have the right to distribute it, since they have to distribute it with the source code and they don't have that. The fact that you are the copyright owner means that your sending it *to* Debian is legal, but that doesn't grant Debian permission to distribute it any further. More precisely, Debian has the right to distribute such a work, but chooses not to do so. -- Måns Rullgård m...@mansr.com -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL photographies, eg for backround
Don Armstrong d...@debian.org writes: On Mon, 29 Dec 2008, Måns Rullgård wrote: More precisely, Debian has the right to distribute such a work, but chooses not to do so. If a work is GPLed and we do not have the complete source for the work, we cannot distribute it under the GPL. If the work as distributed *by the author* lacks something one might call source, a recipient may still redistribute whatever he received. When *redistributing* a work, possibly modified, received under the terms of the GPL, you may of course not omit any parts that would be considered source for any part of what you do distribute. [For non-copyleft works, however, your statement is correct.] Yes, obviously. -- Måns Rullgård m...@mansr.com -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL photographies, eg for backround
Don Armstrong d...@debian.org writes: On Tue, 30 Dec 2008, Måns Rullgård wrote: Don Armstrong d...@debian.org writes: On Mon, 29 Dec 2008, Måns Rullgård wrote: More precisely, Debian has the right to distribute such a work, but chooses not to do so. If a work is GPLed and we do not have the complete source for the work, we cannot distribute it under the GPL. If the work as distributed *by the author* lacks something one might call source, a recipient may still redistribute whatever he received. That's not correct, unless you're in a locality that has some form of the First Sale doctrine. Debian doesn't ever distribute under the first sale doctrine, and furthermore, Debian modifies everything that is distributed (even if just to package it), so it doesn't apply either. [And we certainly don't distribute in 1:1 ratio from the copies we obtain from original author.] Under GPL v3, when we convey a work in a non-source form, we must satisfy all of 6d. That requires making the Corresponding Source available, which we cannot. Under GPL v2, we distribute under 3(a), and that also requires distributing the corresponding machine-readable source code. If we don't have the corresponding source, we can't satisfy the GPL, so we cannot distribute (GPLv2 §4, GPLv3 §8). Your argument, if it can be called that, assumes that the requirements of the GPL, or any license, extend backwards, prior to the point it was applied. The extent to which this is true has to be determined by real lawyers. For photographs, the argument about what constitutes source can easily become absurd. I can easily imagine a photograph where the preferred form for modification is the depicted scene itself, rather than its depiction. To created a modified photo, the photographer would rearrange the scene and make a new photo, not alter an existing one. Does this mean a photo of this scene cannot be distributed under the GPL (unless the physical scene is also included)? Similarly, when I write a computer programme, a lot of ideas, structures, etc. that could be seen as source remain as thoughts in my brain, never to be written down. Does this make my programmes non-distributable? -- Måns Rullgård m...@mansr.com -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Licence query
Francesco Poli [EMAIL PROTECTED] writes: On Sun, 14 Sep 2008 17:10:17 +0100 Julian Gilbey wrote: Hi all! Hi! :) I'm looking at a package (GLFW, bindings to OpenGL from Haskell) which has the following licence. I think that it is DFSG-free, but I'd like someone else to check over it, as I've not seen a licence exactly like this one before. The license you quoted (thanks for quoting its text in full) is word-by-word identical to the zlib license: http://www.gzip.org/zlib/zlib_license.html I thought it looked familiar, but couldn't quite place it. There is one thing about that license that strikes me as slightly odd. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: In the above grant of permissions, I see no explicit grant to distribute modified versions. It is fairly obvious from the remainder of the license that such permission was intended, but it should still be explicitly mentioned. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Licence query
Stephen Gran [EMAIL PROTECTED] writes: This one time, at band camp, Måns Rullgård said: There is one thing about that license that strikes me as slightly odd. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: In the above grant of permissions, I see no explicit grant to distribute modified versions. It is fairly obvious from the remainder of the license that such permission was intended, but it should still be explicitly mentioned. Permission is granted to ... alter it and redistribute it freely seems like it does just that? The first it is clearly referring to the unmodified source. The second it has no other noun to refer to, so must also be referring to the unmodified source. Had the text said something like and redistribute it freely, with or without modification, all would be much clearer. The BSD license uses this precise phrase. One can never be too careful with legal language. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Licence query
Stephen Gran [EMAIL PROTECTED] writes: This one time, at band camp, Måns Rullgård said: Stephen Gran [EMAIL PROTECTED] writes: This one time, at band camp, Måns Rullgård said: There is one thing about that license that strikes me as slightly odd. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: In the above grant of permissions, I see no explicit grant to distribute modified versions. It is fairly obvious from the remainder of the license that such permission was intended, but it should still be explicitly mentioned. Permission is granted to ... alter it and redistribute it freely seems like it does just that? The first it is clearly referring to the unmodified source. The second it has no other noun to refer to, so must also be referring to the unmodified source. Had the text said something like and redistribute it freely, with or without modification, all would be much clearer. The BSD license uses this precise phrase. One can never be too careful with legal language. One can also try to be slightly sensible. Try telling that to the lawyers. English is an inexact language at the best of times. In this context, the meaning is clear enough - it's a logical and operation. Of course it's possible that some legalistic moron could find a way to argue that the intent of the license is the opposite of what it apparently says, but I doubt it will stand up in any court that counts. Even the Eastern District Court of Texas? -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Copy vs. (re)distribute
Cyril Brulebois [EMAIL PROTECTED] writes: Hi, since I've got upstreams (having copied some code from others, that's why they aren't spelling it out directly) that aren't convinced that having the rights to copy, use, modify is insufficient to meet the DFSG. From what I recall having read during NM, I've never seen any discussion comparing the rights to copy and to (re)distribute. Could someone please shed some light, and/or share pointers to some nice reading on that topic? I also believe that You may use this program as desired without restriction can't be understood as one is free to modify and redistribute it; but I'd appreciate your views (anyway, I believe it was meant to be free for real, just not worded adequately -- this one dates back to 1986 -- but I'd like to make sure it's not DFSG-free as-is). There is another important aspect you didn't mention. In addition to granting rights to use, copy, and redistribute, the license must allow you to pass on these rights to those receiving copies or modified versions from you. I agree that the rights to use, copy, and redistribute are distinct, and that none of them implicitly include any of the others. IANAL -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#476644: bring back H.261 encoding
Fabian Greffrath [EMAIL PROTECTED] writes: Package: ffmpeg Severity: wishlist Version: 0.svn20080206-1 Hi, according to http://blogs.sun.com/openmediacommons/entry/oms_video_a_project_of and other resources, SUN develops a new codec called OMS, which is a royalty-free codec loosely based on the h.26x codec family. In the FAQ the question asking Why have you started from h.261? is answered with the following reply: H.261 was finalized in 1989, outside the (17-year) patent window. Key tool strategies and prior art were already established in that era. Wouldn't this mean that we are also free to ship the built-in H.261 encoder in ffmpeg packages? Even though the spec dates from 1989, it is possible to use newer algorithms in an encoder, e.g. for motion estimation, quantisation, or any other aspect where the spec doesn't detail how values are to be computed from input data. I have no idea whether any patents are applicable to the FFmpeg H.261 encoder, but I wouldn't discount the possibility without a thorough examination. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Do web applications disable GPL obligations?
M. Tyler [EMAIL PROTECTED] writes: Måns Rullgård-3 writes: Mark Tyler [EMAIL PROTECTED] writes: Dear all, I hope this is the right list to discuss GPL related issues. (Or where would be a better place to get help with the following question?) Your question doesn't relate to Debian, so strictly speaking it is off-topic here. We are talking about Debian servers, of course ;-) Fact is that I haven't found a list or a newsgroup where GPL questions are answered nearly as competent as here. So I thank all writers for sharing their experience. It is my understanding that source is only required to be supplied to those who receive binaries. In your case, it seems pretty clear that the Java classes should be accompanied with source (or instructions how to obtain it). This is exactly how I see the situation. But two questions remain to be clarified: 1) I have not mentioned explicitly that the Java classes are published as applets on a website. They are not offered as standalone download. I don't see any difference in that the source code of GPLd applets must still be made available, do you? Anyone who can get their hands on the Java class files has a right to get the source code as well. It doesn't matter how they obtain those files, or whether whomever they were obtained from was aware of the files being distributed. It is the responsibility of the server operator to keep track of what is distributed from his server, and ensure that any conditions attached to such distribution are adhered to. 2) What about icons which are delivered with any GPLd software (not necessarily our situation, but if it is different, please mention the crucial points as well)? I haven't found a conclusive answer in previous discussions on this list. I don't see how icons are affected by the GPL, because the GPL deals with source code and binary program code, not with media files. This is a (common) misconception. The conditions of the GPL can be applied to anything, not just program code. For this reason I assume that icons remain copyright of their creator, such as any data which is published without any license at all. Is this assumption true, or what are the obligations if somebody copies icons onto his website, icons that we created for and distribute with our GPLd software? It is usually assumed, unless otherwise noted, that artwork included in a package is under the same license as the source code. It is, however, not all too uncommon with special conditions for logos, icons and the like. C.f. the Mozilla projects. However, source for software that only runs on the server need not be supplied to users of the service. This is evident. Disclaimers: IANAL, TINLA. BTW, is there a reason why many of the list contributions end with these acronyms? Do they have any legal significance or do they only show that you don't want to be misunderstood to tell the final truth? You can never be too careful in legal matters. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Do web applications disable GPL obligations?
Mark Tyler [EMAIL PROTECTED] writes: Dear all, I hope this is the right list to discuss GPL related issues. (Or where would be a better place to get help with the following question?) Your question doesn't relate to Debian, so strictly speaking it is off-topic here. A friend and I have developed a web application for an online shop with some pretty advanced features that were requested by our customers. We included GPL sources into the application and for that reason distributed the application according to the same license (GPLv3). Now one of the customers has modified large parts of our shop without mentioning the origin, the GPL license or the authors, and without publishing the modified sources. Program icons and dialog boxes where copied identically. When we asked him to comply with the GPL he only replied that web applications are not affected, because the application is only used, but not distributed. It is true, that the application is installed on the server side, but parts of it, namely java classes, are distributed to the clients (=the shop visitors) in binary form. We are really annoyed because we spent months fulfilling our customers' wishes at an almost negligible price (assuming that we were contributing to open source software), and now our work as well as the original authors' work is exploited to generate large turnovers. Can you judge from this information, whether we are right or the customer who claims to have the right to publish our java classes and icons within the web application as if he owned the copyright? It is my understanding that source is only required to be supplied to those who receive binaries. In your case, it seems pretty clear that the Java classes should be accompanied with source (or instructions how to obtain it). However, source for software that only runs on the server need not be supplied to users of the service. There were early plans to have the GPLv3 require source distribution with web services and similar, but these requirements were dropped from the final version. Disclaimers: IANAL, TINLA. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: k3b monkey audio plugin
Robin Heron [EMAIL PROTECTED] writes: Hi, I am unclear of the license and exactly which section a deb package should belong. I am currently building k3b plugin for monkeys audio codec. The author has licenced under GPL 2 so no problem there. The actual codec however uses the following: Monkey's Audio Source Code License Agreement It may be of interest to you that FFmpeg has an independent implementation of this decoder licensed under the LGPL 2.1. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TrueCrypt License 2.3
Patrick Matthäi [EMAIL PROTECTED] writes: Måns Rullgård schrieb: Patrick Matthäi [EMAIL PROTECTED] writes: Hello, I wanted to package maybe truecrypt for Debian. There was an older discussion on l.d.legal for an older version of the TrueCrypt license, where the most developers said, that it is not distributeable. But as I know TrueCrypt has modified the license, so that more distributions could ship it. Here it is: http://www.truecrypt.org/license.php I'm not a lawler, so what do you mean, is this license free or when not could I distribute it in non-free? At a glance, the bits that might be controversial appear to be a few naming restriction clauses and some advertising clauses. I don't see anything restricting use or distribution. IANAL Thanks, sounds good :) Hold on. I didn't say it was free or anything, only that I didn't see anything that struck me as obviously non-free. Some consider renaming clauses non-free (although I don't), and the plethora of licenses used for Truecrypt could be conflicting, even if each on its own is free. Wait for another opinion before drawing any conclusions. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TrueCrypt License 2.3
Iain Nicol [EMAIL PROTECTED] writes: VI. General Terms 1. You may not use, modify, reproduce, derive from, (re)distribute, or sublicense This Product, or portion(s) thereof, except as expressly provided under this License. Any attempt (even if permitted by applicable law) otherwise to use, modify, reproduce, derive from, (re)distribute, or sublicense This Product, or portion(s) thereof, automatically and immediately terminates Your rights under this License. This paragraph explicitly denies rights available under fair use or fair dealing. Hopefully a non-op (?), but not good. If it were a contract, such a clause could be valid. Whether licenses like this are to be considered contracts is matter for debate. Either way, the license has a clause about unenforcable terms: 4. If any term of this License is found to be invalid or unenforceable under applicable law, You agree that it shall not affect the validity or enforceability of any other terms of this License that are found to be valid and enforceable under applicable law. All the above was about the TrueCrypt License version 2.3. The other license I have trouble with is a short one. This is an independent implementation of the encryption algorithm: Twofish by Bruce Schneier and colleagues which is a candidate algorithm in the Advanced Encryption Standard programme of the US National Institute of Standards and Technology. Copyright in this implementation is held by Dr B R Gladman but I hereby give permission for its free direct or derivative use subject to If the copyright is held be Dr Gladman, how can I (Schneier?) grant any permission pertaining to it? acknowledgment of its origin and compliance with any conditions that the originators of the algorithm place on its exploitation. I know the reference implementation for Twofish is in the public domain, and it's not been patented. But what happens, hypothetically, if Bruce Schneier were to publicly assert that people should not use the algorithm, say for moral reasons. Or what if he said people should not use this algorithm [as it is no longer considered secure enough. Could those situations not revoke my license to use this software? Note that the text says algorithm, not implementation. If it is not patented, there is nothing the originators of the algorithm can do to stop it being used. IANAL -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TrueCrypt License 2.3
Patrick Matthäi [EMAIL PROTECTED] writes: Hello, I wanted to package maybe truecrypt for Debian. There was an older discussion on l.d.legal for an older version of the TrueCrypt license, where the most developers said, that it is not distributeable. But as I know TrueCrypt has modified the license, so that more distributions could ship it. Here it is: http://www.truecrypt.org/license.php I'm not a lawler, so what do you mean, is this license free or when not could I distribute it in non-free? At a glance, the bits that might be controversial appear to be a few naming restriction clauses and some advertising clauses. I don't see anything restricting use or distribution. IANAL -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rescuing code from the GPL
Shriramana Sharma [EMAIL PROTECTED] writes: Wesley J. Landaker wrote: 2. Y modifies this program to use Qt (under the GPL), creating 02-qt-nothirdvar.cpp, and distributes it under both the BSDL and GPL. Well, they could distribute the source code under the BSD, as the source code isn't a derivative work of Qt just by using it. But they could not legally distribute a compiled binary that included copyrightable parts of GPL-only Qt. You could distribute binaries under the GPL. I don't agree with some points in this. The question is not whether a work *includes* parts of Qt or not. The very fact that it is dependent on Qt for its functioning makes it a derivative work, and it *must* be licensed under the GPL when distributed, whether in source form or compiled form. Please point out the flaw in this reasoning. Thank you. Suppose I write from scratch a new library, Tq, that is source and binary compatible with Qt (huge task, but that's beside the point). Every app written to use Qt can now instead use Tq without even a recompile. Are these apps now suddenly derivatives of Tq as well as Qt? I think not. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: algorithm copyright? what's that?
Antti-Juhani Kaijanaho [EMAIL PROTECTED] writes: Is it a kind of algorithm copyright? No. In some countries there is. They call it a patent. IANAL etc Neither am I. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LGPL v3 compatibilty
Walter Landry [EMAIL PROTECTED] writes: Francesco Poli [EMAIL PROTECTED] wrote: On Sat, 14 Jul 2007 21:56:27 -0700 (PDT) Walter Landry wrote: Francesco Poli [EMAIL PROTECTED] wrote: On Mon, 2 Jul 2007 12:31:13 -0400 Anthony Towns wrote: [...] Note that _if_ we do stick to the view we've taken up until now, when we have a LGPLv3 only glibc in the archive, we'll no longer be able to distribute GPLv2-only compiled executables. Unless the GPLv2-only work copyright holder(s) add(s) a special exception, similar to the one needed to link with the OpenSSL library, right? This scenario is worrying me... :-( Is this going to be a problem for the kernel? It is definitely not going to go to GPLv3. Is the Linux kernel linked with any LGPL'd work? AFAIUI, it is not, so no problem for the kernel. Doesn't the kernel get its implementations for pow(), sqrt(), printf(), and the rest of the C standard library from glibc, which is LGPL'd? No. The kernel is completely self-contained. Some code may of course have been borrowed from glibc at some point, but that's irrelevant. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LGPL v3 compatibilty
Walter Landry [EMAIL PROTECTED] writes: Måns_Rullgård [EMAIL PROTECTED] wrote: Walter Landry [EMAIL PROTECTED] writes: Francesco Poli [EMAIL PROTECTED] wrote: On Sat, 14 Jul 2007 21:56:27 -0700 (PDT) Walter Landry wrote: Francesco Poli [EMAIL PROTECTED] wrote: On Mon, 2 Jul 2007 12:31:13 -0400 Anthony Towns wrote: [...] Note that _if_ we do stick to the view we've taken up until now, when we have a LGPLv3 only glibc in the archive, we'll no longer be able to distribute GPLv2-only compiled executables. Unless the GPLv2-only work copyright holder(s) add(s) a special exception, similar to the one needed to link with the OpenSSL library, right? This scenario is worrying me... :-( Is this going to be a problem for the kernel? It is definitely not going to go to GPLv3. Is the Linux kernel linked with any LGPL'd work? AFAIUI, it is not, so no problem for the kernel. Doesn't the kernel get its implementations for pow(), sqrt(), printf(), and the rest of the C standard library from glibc, which is LGPL'd? No. The kernel is completely self-contained. Some code may of course have been borrowed from glibc at some point, but that's irrelevant. Are you sure that it is self-contained? Grepping through the sources of 2.6.22.1, I do not see an implementation of stdarg.h or stdio.h. I do see string.h, and math.h is never included. Inside the kernel stdio is meaningless, so I'd hardly expect to find that header there. The only places in the kernel source where stdio.h is included are in tools, such as kconfig, only to be used for building the kernel or for testing purposes. This use of standard C header files is of course completely outside the scope of any license. As for stdarg.h, it is provided by the compiler, and generally (including GCC) licensed without restrictions on use. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final text of GPL v3
Ben Finney [EMAIL PROTECTED] writes: Stephen Gran [EMAIL PROTECTED] writes: You continually miss the point that the GPL is explicitly noted as a free license, which means that anything in the GPL is DFSG free. No. It means that works licensed under the GPL are considered free software under the DFSG. That does *not* mean that anything in the GPL is DFSG free outside the context of a work licensed under the GPL. It may also be worth noting that GPLv2 *has* to be considered DFSG free, or there would be little left to call Debian... -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
Ken Arromdee [EMAIL PROTECTED] writes: On Sun, 11 Mar 2007, Ben Finney wrote: Those licenses can apply to any software, not just programs. So, if the software is an audio work or picture, a software license like GPL or Expat can apply to it. Actually, there's one big problem. The GPL's preferred form for modification clause. Unless the creators of the podcast directly edit the MP3--which is rather unlikely--the MP3 is not the preferred form for modification and putting the MP3 under GPL without releasing the raw audio files grants no rights at all. GPLing video has a similar problem. The preferred form for modification for a film director is often a reshoot of the scene. I guess this means that a GPL video would have to ship with (a copy of) Tom Cruise if he happens to be one of the actors in the film. Sounds difficult to fulfill. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DFSG as Licence?
Michelle Konzack [EMAIL PROTECTED] writes: Hello *, Since I have read tonns of different licences I do not realy know what to do. Since I am using Debian/main only (with the exception of libdvdcss2) since more then 7 years now I want to say, that my Software any Licence which comply with the DFSG. Question: Is there allready a licence which use the term DFSG as licence? I do not fully agree with the FSF and the GPL. v2.0 maybe ok, but I have complains against the new one. If you do not like gpl3, use gpl2 without the or later option, if that does what you want. The FSF won't like you if you do, but nobody is under any obligation to please them. Personally, I'm allergic to more than two paragraphs of legalese, and I don't want to release my work under terms I do not fully understand, so I release my stuff under the MIT license. It gives a little more permission than the GPL, but I don't really care if someone uses my code in a commercial application. It doesn't interfere with my reasons for releasing it in the first place, and it lets any free software project use it, without any concerns about being GPL compatible. All the fuss about open source licenses being incompatible is, IMHO, contradictory to the spirit of free software, and spending time on such issues is counter-productive. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DFSG as Licence?
George Danchev [EMAIL PROTECTED] writes: On Sunday 11 June 2006 19:25, Måns Rullgård wrote: Michelle Konzack [EMAIL PROTECTED] writes: Hello *, Since I have read tonns of different licences I do not realy know what to do. Since I am using Debian/main only (with the exception of libdvdcss2) since more then 7 years now I want to say, that my Software any Licence which comply with the DFSG. Question: Is there allready a licence which use the term DFSG as licence? I do not fully agree with the FSF and the GPL. v2.0 maybe ok, but I have complains against the new one. If you do not like gpl3, use gpl2 without the or later option, if that does what you want. The FSF won't like you if you do, but nobody is under any obligation to please them. Personally, I'm allergic to more than two paragraphs of legalese, and I don't want to release my work under terms I do not fully understand, so I release my stuff under the MIT license. It gives a little more permission than the GPL, but I don't really care if someone uses my code in a commercial application. GPL allows commercial applications, but what GPL does not allow is becoming a 'proprietary application' (non-free). E.g. you are not OK, bad choice of words. I don't much care if someone uses my code in a proprietary application either. allowed to grab a GPL'ed source code, modify it and distribute the modified binaries only. In that case GPL force you to publish the your source modifications, which is perfectly in the spirit of free software ... e.g. what is give is what you get. What I'm talking about is different, each on their own free, licenses being deemed incompatible with each other. Examples are the GPL, the OpenSSL license, and the Open Software License. I find it hard to believe that most authors who choose to release under the GPL do so in order to prevent their code being used in a program released under the OSL. Neither of these two licenses (GPL and OSL) allows for proprieterization of code. However, I see it as a loss to the free software world as a whole, that the open source code is divided into several islands, between which no code sharing is allowed. This leads to time and efforts being wasted in reimplementing perfectly good code, only because the existing version has slightly different terms of use and distribution. How many cases of Foo is under GPL, Foo uses libcurl, libcurl can be linked with OpenSSL, hence Foo is non-distributable have been discussed on this list? I have no figures, but it is a recurring topic. Does anyone seriously believe that the authors of Foo intentionally created those situation? -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: MPEG-4 patent license issues - libfaad* and libx264* and other codecs.
Steve Langasek [EMAIL PROTECTED] writes: On Sat, Apr 29, 2006 at 11:37:39PM +0100, Matthew William Solloway Bell wrote: The packages libxine1, ffmpeg, include libfaad*, libx264* or another codec which implement the MPEG-4 Advanced Audio Coding and Advanced Video Coding standards. Unfortunately, these are patent encumbered in at least the USA, and many other countries. To distribute code implementing any of these patents, a license is required[1], assuming that the claimed patents are valid. This license requires signing an agreement and the payment of royalties, which hasn't been done AFAIK, and is contrary to policy. There is evidence of prior attempts of enforcement, specifically against FAAD at AudioCoding.com[2]. This appears to refer to enforcement of patents covering encoding using the codecs in question. Do libxine1 and ffmpeg implement encoding of these, or just decoding? Is there a history of enforcement of patents on decoding of the codecs in question? FFmpeg has an AVC decoder. It does not include an AVC encoder, and it neither encodes nor decodes AAC. FFmpeg can optionally use external libraries for these tasks. I'm not familiar with libxine enough to comment on it. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: MPEG-4 patent license issues - libfaad* and libx264* and other codecs.
Matthew William Solloway Bell [EMAIL PROTECTED] writes: On Sat, Apr 29, 2006 at 11:37:39PM +0100, Matthew William Solloway Bell wrote: The packages libxine1, ffmpeg, include libfaad*, libx264* or another codec which implement the MPEG-4 Advanced Audio Coding and Advanced Video Coding standards. Unfortunately, these are patent encumbered in at least the USA, and many other countries. To distribute code implementing any of these patents, a license is required[1], assuming that the claimed patents are valid. This license requires signing an agreement and the payment of royalties, which hasn't been done AFAIK, and is contrary to policy. There is evidence of prior attempts of enforcement, specifically against FAAD at AudioCoding.com[2]. This appears to refer to enforcement of patents covering encoding using the codecs in question. Do libxine1 and ffmpeg implement encoding of these, or just decoding? Is there a history of enforcement of patents on decoding of the codecs in question? Hmmm, I think I have missed something; what makes you draw this conclusion? AudioCoding.com has removed all binaries including those related to decoding. I see no reference to encoding only in [2]. The licensing authorities in [1] have licenses that cover decoders. I did look at their patent portfolio, but is was brief and shallow. I'm having a closer look now. libxine: libfaad (AAC decoder) vlc: libfaad (AAC decoder); libx264 (AVC decoder) libavcodec0: libfaad (AAC decoder); libx264 (AVC decoder) AFAIK, libx264 is a decoder only but the decoding functions are called x264_encoder_? x264 is an AVC *encoder* only. libavcodec can optionally call it for AVC encoding. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: MPEG-4 patent license issues - libfaad* and libx264* and other codecs.
Don Armstrong [EMAIL PROTECTED] writes: On Sun, 30 Apr 2006, Josselin Mouette wrote: Le samedi 29 avril 2006 à 23:37 +0100, Matthew William Solloway Bell a écrit : The packages libxine1, ffmpeg, include libfaad*, libx264* or another codec which implement the MPEG-4 Advanced Audio Coding and Advanced Video Coding standards. I have already stated this: Debian shouldn't have anything to do with regard to patents. We should entirely ignore them unless directly threatened, and such issues that depend so much on the country should be up to the end-user to deal with. Like it or not, we can't completely ignore them in Debian. Each mirror operator needs to make their own decisions about their liability in their own country, but Debian itself needs to be careful about distributing works which have patents in the United States[1] where the patent holders are well known and have been inolved in patent litigation against individuals using their patents. Correct me if I'm wrong, but isn't it use, not distribution, that requires a patent license? -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: license of schema files
Noèl Köthe [EMAIL PROTECTED] writes: Hello debian-legal and openldap maintainers, the upstream kolabd package includes rfc2739.schema: http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolabd/kolabd/rfc2739.schema?rev=1.1.1.1content-type=text/vnd.viewcvs-markup kolabd was rejected by ftpmaster because of this schema license text (this schema is now removed but it would be better to get it included again): ... However, this # document itself may not be modified in any way, such as by removing # the copyright notice or references to the Internet Society or other # Internet organizations, except as needed for the purpose of # developing Internet standards in which case the procedures for # copyrights defined in the Internet Standards process must be # followed, or as required to translate it into languages other than # English. ... document itself may not be modified in any way is the main point. The following are examples and more information. It looks like its just a copy of a RFC license e.g. ftp://ftp.rfc-editor.org/in-notes/rfc2821.txt IMHO permission to modify standards is uninteresting. The document is only useful in it's original form anyway. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Francesco Poli [EMAIL PROTECTED] writes: On Tue, 21 Mar 2006 18:19:52 +0100 Eduard Bloch wrote: Don't count much on dvdrtools, it has no active upstream at all (no, I don't mean the guys whoes only heroic act was the replacement of the Schilly build system with autodev-stuff). That's a good reason to find someone willing to take over dvdrtools maintenance and development... We should really seek someone interested. Umm... they released a new version just a couple of weeks ago. What do you require of a project to count it as active? -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Francesco Poli [EMAIL PROTECTED] writes: On Mon, 20 Mar 2006 01:21:08 + Måns Rullgård wrote: Francesco Poli [EMAIL PROTECTED] writes: On Sat, 18 Mar 2006 22:05:53 + Måns Rullgård wrote: Just use dvdrtools instead. ITYM dvd+rw-tools, That's what I use for burning DVDs. It doesn't handle CDs though. Ouch! It seems that we are left with *no* DFSG-free tools to burn CDs in Debian, until someone forks cdrtools (from a version prior to the license clarifications) or implements an equivalent program suite... JS insists that his clarifications also apply to previous versions of cdrecord... since dvdrtools is in non-free too... Someone's launched an investigation into the reason for this. Let's wait and see what comes back. Assuming that its debian/copyright file is accurate (in Debian sid), it seems that the same license (and added restrictions, passed off as license interpretation) applies. If this is the case, my bet is that dvdrtools is in non-free for pretty the same reason why cdrtools should not be in main (at least, not as it is now)... The dvdrtools web page has this paragraph: dvdrtools is a fork of cdrtools, with the primary goals of remaining 100% Free Software (dvdrtools is a fork of the last version of cdrtools without any you are not allowed to modify this section comments), and adding support for DVD-R/DVD-RW drives and media. Checking the source, none of the troublesome bits from cdrtools are there, and the build system is replaced with automake. I can't see any problem with it. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: MIT licenses
Francesco Poli [EMAIL PROTECTED] writes: On Mon, 20 Mar 2006 02:39:56 + MJ Ray wrote: I think that's the one. There are several often called MIT. Someone has moved the copy on X.org to which http://www.fr.debian.org/legal/licenses/ links - has anyone a new URL besides the failed open source initiative, please? AFAIK, the two most famous licenses ambiguously called MIT license, are: a) the Expat license (http://www.jclark.com/xml/copying.txt) b) the X11 license (formerly http://www.x.org/Downloads_terms.html) The latter URL (http://www.x.org/Downloads_terms.html) has been useful for long time, but now seems to have vanished. Another URL (http://www.xfree86.org/3.3.6/COPYRIGHT2.html#3) includes something that resembles to the X11 license, but it rather seems to be an Expat license with an added final no-advertising/no-promotion clause similar to the one found in the X11 license. I'm pretty sure the real X11 license (the one once found at http://www.x.org/Downloads_terms.html, now vanished) has other differences that distinguish it from the Expat license. Namely: a) the condition explicitly mentions that the copyright notice and license text must be included in supporting documentation (as well as in the Software or any substantial portion) b) permission to sublicense is not explicitly mentioned These two differences seem to be negligible, since the term Software includes associated documentation files and the list of granted rights is exemplary, not exhaustive (Permission is hereby granted [...] to deal in the Software without restriction, including without limitation the rights to [...]). Nonetheless, the X11 and Expat license texts differ in those details too (not only for the presence of the final no-advertising/no-promotion clause). Has anyone found another URL for the real X11 license (the one that used to live at http://www.x.org/Downloads_terms.html)? Gentoo has a fairly comprehensive collection of license texts at http://www.gentoo.org/cgi-bin/viewcvs.cgi/licenses/, including an MIT and an X11 license that are quite distinct. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Eduard Bloch [EMAIL PROTECTED] writes: #include hallo.h * Måns Rullgård [Sun, Mar 19 2006, 01:50:24AM]: Sam Morris [EMAIL PROTECTED] writes: These are the bits I'm referring to, from cdrecorc.c (sorry for the long lines, but that's how it's written): ---BEGIN QUOTE--- /* * Begin restricted code for quality assurance. * * Warning: you are not allowed to modify or to remove the * Copyright and version printing code below! * See also GPL § 2 subclause c) ... For completeness, here's GPL 2c: ---BEGIN QUOTE--- c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) ---END QUOTE--- Take note that cdrecord is never interactive, so GPL 2c doesn't apply. Wrong. It displays messages by default and tells you how to stop the command etc. IMO this can clearly be interpreted as interaction. It does not read commands interactively, which is the provision for GPL 2c applying. If every program that exits when it receives certain signals is interactive, then all programs are interactive (think SIGKILL). And since it does print such an announcement by default then it should be kept. However, I disagree on the level appropriateness - stuff like This is a broken Linux system does not belong to the disclaimer/copyright category. It is clearly not a copyright notice or disclaimer, and not being this restricting its removal is non-free. -- Måns Rullgård [EMAIL PROTECTED]
Re: Problematic distribution of P2P clients in France
Mike Hommey [EMAIL PROTECTED] writes: On Sun, Mar 19, 2006 at 12:35:16PM +0100, Marco d'Itri [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: If courts were to go for the first interpretation, my opinion is that french Debian (and other distributions) mirrors could be endangered. This is a problem for French mirror operators, not for Debian. It is also a problem for any Debian Developer that would come to France. What? Do the French lock you up for things you did outside of France, even if they were legal there? -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Bernhard R. Link [EMAIL PROTECTED] writes: * Mns Rullgrd [EMAIL PROTECTED] [060319 01:14]: Don Armstrong [EMAIL PROTECTED] writes: Not just linking; it's the creation of a derivative work of a GPLed work. Frankly, I don't see how you can argue that cdrecord is not a derivative work of the GPLed part of cdrecord and the build system. I disagree. The final executable is no more a derivative of the build system than it is of the compiler. After all, no parts of the makefiles end up inside the executable. I think derivative or not is not the question here, but the GPL explicitly demands that the build system is available under GPL-compatible changes. from Section 2 of the GPL: # b) You must cause any work that you distribute or publish, that in # whole or in part contains or is derived from the Program or any # part thereof, to be licensed as a whole at no charge to all third # parties under the terms of this License. from Section 3 of the GPLL: # Accompany it with the complete corresponding machine-readable # source code, which must be distributed under the terms of Sections # 1 and 2 above on a medium [...] # For an executable work, complete source # code means all the source code for all modules it contains, plus any # associated interface definition files, plus the scripts used to # control compilation and installation of the executable. scripts used to control compilation is clearly what we currently refer to as build system. Point taken. The obvious solution is to replace the build system with an acceptably licensed one. While at it, one could also make it work properly. Incidentally, this is what the dvdrtools folks have already done. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problematic distribution of P2P clients in France
Mike Hommey [EMAIL PROTECTED] writes: On Sun, Mar 19, 2006 at 01:39:12PM +, Måns Rullgård [EMAIL PROTECTED] wrote: Mike Hommey [EMAIL PROTECTED] writes: On Sun, Mar 19, 2006 at 12:35:16PM +0100, Marco d'Itri [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: If courts were to go for the first interpretation, my opinion is that french Debian (and other distributions) mirrors could be endangered. This is a problem for French mirror operators, not for Debian. It is also a problem for any Debian Developer that would come to France. What? Do the French lock you up for things you did outside of France, even if they were legal there? I think you can get charged for exporting illegal stuff to France whenever you touch the french soil, this being legal in your own country or not. That applies to a lot of countries, I believe. There ought to be some requirement for said export to be somewhat active or deliberate for the law to kick in. Simply offering stuff for download being sufficient is insane. Unfortunately, the system is insane, as evidenced by some cases involving Nazi uniforms. -- Måns Rullgård [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Francesco Poli [EMAIL PROTECTED] writes: On Sat, 18 Mar 2006 22:05:53 + Måns Rullgård wrote: Eduard Bloch [EMAIL PROTECTED] writes: Hello debian-legal experts ;-), I need a bit support to clarify the issue with cdrtools' build system. Summary: a while ago, Joerg Schilling (upstream) replaced the copyright headers in the files of his build system inside of the cdrtools package with references to a CDDL license context. D-L v. JS, now that's a flame war I'd like to see ;-) Flaming aside, this is a non-issue. The source for cdrecord contains invariant sections (those obnoxious warnings about using device names), so it's certainly not DFSG-free. Aaargh! :-( I was hoping this problem had been fixed... [...] How can such a package still be in main with this non-freeness? I'm surprised that nobody filed a serious bug for this... I guess everyone has just gotten used to Schilling's inane ramblings, and ignores him without further thought. Just use dvdrtools instead. ITYM dvd+rw-tools, That's what I use for burning DVDs. It doesn't handle CDs though. since dvdrtools is in non-free too... Someone's launched an investigation into the reason for this. Let's wait and see what comes back. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
Adam McKenna [EMAIL PROTECTED] writes: On Sun, Mar 19, 2006 at 01:36:14AM -0500, Anthony DeRobertis wrote: Adam McKenna wrote: But you can only use one copy at a time. You could make a good argument that the copies not in use are backup copies. (Remember, we're talking about documents here.) Well, US copyright law at least gives the right to make a backup copy so long as such new copy or adaptation is for archival purposes only. Clearly, if you're regularly using it, its no longer for archival purposes only. That would need to be decided by a court. Obviously if you can only use one copy at a time, and your backup strategy involves keeping multiple copies on multiple machines, someone would have to *prove* that you were using more than one copy at a time, and convice the cort that your backup strategy does not comply with the license. Next we know, they'll be counting mirrored disks as multiple copies, and probably as using all the copies at once too. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Eduard Bloch [EMAIL PROTECTED] writes: Hello debian-legal experts ;-), I need a bit support to clarify the issue with cdrtools' build system. Summary: a while ago, Joerg Schilling (upstream) replaced the copyright headers in the files of his build system inside of the cdrtools package with references to a CDDL license context. D-L v. JS, now that's a flame war I'd like to see ;-) Flaming aside, this is a non-issue. The source for cdrecord contains invariant sections (those obnoxious warnings about using device names), so it's certainly not DFSG-free. Just use dvdrtools instead. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL v3 possible issues.
Steve Langasek [EMAIL PROTECTED] writes: On Sat, Mar 18, 2006 at 09:15:40PM +, John Watson wrote: On controlling music, I personally see no issues with this. With out DRM, music or other media type content could not be legally made available over the Internet. This is false. Without DRM, certain greedy and immoral content providers will be *unwilling* to provide music over the Internet; but I am aware of no copyright laws in any jurisdiction that *mandate* the use of DRM. Well, since the content providers appear bent on using DRM, I'd rather have them use an open source DRM than some Sony-style rootkit. The majority of the content will always be non-free anyhow (and I don't have a problem with that), so an unobtrusive, portable DRM scheme isn't inherently bad in my view. DRM becomes nasty when it is closed and difficult (or even illegal) to use on your operating system of choice. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Don Armstrong [EMAIL PROTECTED] writes: On Sat, 18 Mar 2006, Eduard Bloch wrote: Summary: a while ago, Joerg Schilling (upstream) replaced the copyright headers in the files of his build system inside of the cdrtools package with references to a CDDL license context. In #350739, the reporter claims that we and JS are violating the GPL because not all files required to create the executable work are available under the GPL license. It's not that they have to be available, it's just that they have to be compatible. [Moreover, JS violation of the GPL isn't interesting because he's presumably the copyright holder, and can therefore do whatever he wants with his work.] Even if JS can do whatever he wants, Debian can't lawfully distribute a work with inconsistent license terms. CDDL is considered GPL-incompatible for linking with GPLed code. Not just linking; it's the creation of a derivative work of a GPLed work. Frankly, I don't see how you can argue that cdrecord is not a derivative work of the GPLed part of cdrecord and the build system. I disagree. The final executable is no more a derivative of the build system than it is of the compiler. After all, no parts of the makefiles end up inside the executable. We have the option of splitting the source package into code (GPLed) and meta-code (CDDL). Would that be suitable for main? I don't see how this would get around the GPL incompatibility issues, as the build system is only useful for cdrecord. Not that I'd go so far as to call it useful, but JS does use the same makefile templates for other software. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Don Armstrong [EMAIL PROTECTED] writes: On Sun, 19 Mar 2006, Måns Rullgård wrote: Don Armstrong [EMAIL PROTECTED] writes: Not just linking; it's the creation of a derivative work of a GPLed work. Frankly, I don't see how you can argue that cdrecord is not a derivative work of the GPLed part of cdrecord and the build system. I disagree. The final executable is no more a derivative of the build system than it is of the compiler. After all, no parts of the makefiles end up inside the executable. The makefiles direct the assembly of the executable, just like the source code directs the operation of the compiler. [And indeed, some question as to whether some part of the executable is a dirived work of the compiler exists as well; luckily there are exceptions in the licences of gcc to deal with this case.] There are multiple different ways that the compiler and assembler can be directed by the makefile; quite a large number of them will produce an operational executable. Given only the source files, writing a makefile that will produce a working executable is fairly simple. I see makefiles as more of a convenience than a necessity to build a program. You might as well argue that every program in Debian is a derivative of apt and the package descriptions, since the former uses rules in the latter to decide what to install. Again, I say this is just a convenience that saves users the time to find out and install the dependencies manually. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Sam Morris [EMAIL PROTECTED] writes:
Måns Rullgård wrote:
Flaming aside, this is a non-issue. The source for cdrecord contains
invariant sections (those obnoxious warnings about using device
names), so it's certainly not DFSG-free. Just use dvdrtools instead.
Oh? How is it in main then?
A package being in main doesn't automatically mean that it should be
there. Packages have been removed from main in the past.
These are the bits I'm referring to, from cdrecorc.c (sorry for the
long lines, but that's how it's written):
---BEGIN QUOTE---
/*
* Begin restricted code for quality assurance.
*
* Warning: you are not allowed to modify or to remove the
* Copyright and version printing code below!
* See also GPL § 2 subclause c)
*
* If you modify cdrecord you need to include additional version
* printing code that:
*
* - Clearly states that the current version is an
* inofficial (modified) version and thus may have bugs
* that are not present in the original.
*
* - Print your support e-mail address and tell people that
* you will do complete support for this version of
* cdrecord.
*
* Or clearly state that there is absolutely no support
* for the modified version you did create.
*
* - Tell the users not to ask the original author for
* help.
*
* This limitation definitely also applies when you use any other
* cdrecord release together with libscg-0.6 or later, or when you
* use any amount of code from cdrecord-1.11a17 or later.
* In fact, it applies to any version of cdrecord, see also
* GPL Preamble, subsection 6.
*
* I am sorry for the inconvenience but I am forced to do this because
* some people create inofficial branches. These branches create
* problems but the initiators do not give support and thus cause the
* development of the official cdrecord versions to slow down because
* I am loaded with unneeded work.
*
* Please note that this is a memorandum on how I interpret the GPL.
* If you use/modify/redistribute cdrecord, you need to accept it
* this way.
*
*
* The above statement is void if there has been neither a new version
* of cdrecord nor a new version of star from the original author
* within more then a year.
*/
/*
* Ugly, but Linux incude files violate POSIX and #define printf
* so we cannot include the #ifdef inside the printf() arg list.
*/
# define PRODVD_TITLE
#ifdef CLONE_WRITE
# define CLONE_TITLE -Clone
#else
# define CLONE_TITLE
#endif
if ((flags F_MSINFO) == 0 || lverbose || flags F_VERSION) {
printf(Cdrecord%s%s %s (%s-%s-%s) Copyright (C) 1995-2004 Jörg
Schilling\n,
PRODVD_TITLE,
CLONE_TITLE,
cdr_version,
HOST_CPU,
HOST_VENDOR, HOST_OS);
#if defined(SOURCE_MODIFIED) || !defined(IS_SCHILY_XCONFIG)
#define INSERT_YOUR_EMAIL_ADDRESS_HERE
#define NO_SUPPORT 0
printf(NOTE: this version of cdrecord is an inofficial
(modified) release of cdrecord\n);
printf( and thus may have bugs that are not present in
the original version.\n);
#if NO_SUPPORT
printf( The author of the modifications decided not to
provide a support e-mail\n);
printf( address so there is absolutely no support for
this version.\n);
#else
printf( Please send bug reports and support requests to
%s.\n, INSERT_YOUR_EMAIL_ADDRESS_HERE);
#endif
printf( The original author should not be bothered with
problems of this version.\n);
printf(\n);
#endif
#if !defined(IS_SCHILY_XCONFIG)
printf(\nWarning: This version of cdrecord has not been
configured via the standard\n);
printf(autoconfiguration method of the Schily makefile system.
There is a high risk\n);
printf(that the code is not configured correctly and for this
reason will not behave\n);
printf(as expected.\n);
#endif
}
/*
* I am sorry that even for version 1.297 of cdrecord.c, I am forced to
do
* things like this, but defective versions of cdrecord cause a lot of
* work load to me and it seems to be impossible to otherwise convince
Re: cdrtools - GPL code with CDDL build system
Andrew Donnellan [EMAIL PROTECTED] writes: Why is he quoting the GPL *preamble*? Preambles aren't supposed to have legal effect, are they? I guess JS is as thoroughly confused about legal matters as he is about device naming. (Interesting looking at the case of the preamble question in Australia's 1999 constitutional referendum - the 'no' case says that the preamble could have had legal effect.) Could you elaborate on this, or provide some pointers? -- Måns Rullgård [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Don Armstrong [EMAIL PROTECTED] writes: On Sun, 19 Mar 2006, Måns Rullgård wrote: Given only the source files, writing a makefile that will produce a working executable is fairly simple. I see makefiles as more of a convenience than a necessity to build a program. You could extend this argument to any segment of sourcecode in the program. Not at all. Every piece of source code gets compiled into some machine code (except parts that get optimized out), and so is part of the work, both before and after compilation. Exactly how the source code is transformed into machine code is irrelevant. You might use compiler A, I might use compiler B, and someone else might prefer to do it all by hand. In each case, the executable is a transformed version of the source code. In neither case does any part of a makefile (or equivalent) get included in the output. A work can't be derived from another work without including some piece of it (ignoring for the moment reuse of literary characters without any verbatim copying of text taking place). In many cases a program could be compiled with a command like find . -name '*.c' | xargs gcc If the program is large, gcc will probably run out of memory, but that makes no difference in principle. The makefile describes how the work can be done in smaller steps, nothing else. Is a printed book a derivative work of the manual for the printing press? Since the output that you get from the compiler is dependent on the way in which the compiler was called, just like the way in which the source code was written determines the object code you get out, this argument isn't terribly persuasive. The output depends on which compiler is used, and on which options were given to that compiler. This still does not change the fact that the output is a mechanical transformation of the input, and is not a derivative of anything of which the source was not already. You can certainly not be arguing that the source code is derived from the makefiles. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: x264 for Debian
Mike Hommey [EMAIL PROTECTED] writes: On Thu, Mar 02, 2006 at 08:39:32PM -0500, Arc Riley [EMAIL PROTECTED] wrote: I'm not saying the patent issue should be ignored. It just strikes me as silly to even start comparing Theora with H.264. Certain graphic artists would say the same of GIMP vs Photoshop, or compare their favorite music application with the numerous GNU/Linux offerings, or even 3d Studio Max/Bryce/Poser/etc vs Blender. There are free alternatives. They may or may not be considered acceptable for specific applications, but this doesn't change that proprietary software is proprietary and is, thus, not DFSG-free. For the sake of correctness, please stop linking H264 with prioprietary. The fact is the software is *free* as in speech. It being patent encumbered doesn't make it proprietary. It still is free as in speech in those countries that don't have such patents. The spec is also available free of charge. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: x264 for Debian
Arc Riley [EMAIL PROTECTED] writes: On Thu, Mar 02, 2006 at 01:26:56PM -0800, David Liontooth wrote: Are there objections to including the new H.264 encoder in Debian? For details, see bug 354667 (request for packaging). Debian maintainer Christian Marillat currently maintains an unofficial package, and we would like your advice on whether this GPL'd codec meets the DFSG. Theres a difference between the code and the codec. The codec has dozens of different corporations holding patents over it, who will try to extract royalties for it in countries where those patents are upheld (ie, USA), and giving it this is free because it's GPL hurts truely patent-clear codecs such as VP3.2/Theora from being recognised as such. VP3/Theora is all but free of patents. On2 has granted unlimited free use of the patents they hold relevant to VP3. There are almost certainly other patents that could be construed to cover VP3 as well. It is a good gesture nonetheless. That said, VP3/Theora can hardly compare with H.264 in terms of coding efficiency. There really is no viable alternative in some situations. Microsoft's WMV9/VC1 comes close but I'm sure it has every bit as non-free licensing terms. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: x264 for Debian
Arc Riley [EMAIL PROTECTED] writes: On Thu, Mar 02, 2006 at 10:45:12PM +, M?ns Rullg?rd wrote: The codec has dozens of different corporations holding patents over it, who will try to extract royalties for it in countries where those patents are upheld (ie, USA), and giving it this is free because it's GPL hurts truely patent-clear codecs such as VP3.2/Theora from being recognised as such. VP3/Theora is all but free of patents. On2 has granted unlimited free use of the patents they hold relevant to VP3. There are almost certainly other patents that could be construed to cover VP3 as well. It is a good gesture nonetheless. I didn't say patent-free, I said patent-clear. On2 has put a license on it which allows it to be used for any purpose and disclaims any right to restrict it's use or charge royalties. This is the patent version of the BSD license. Sure, On2 has allowed free use of *its* patents relating to VP3. That doesn't mean that some obscure company will pop up out of nowhere with a bunch of patents they claim *also* apply to VP3, and that On2 has been infringing all along. Something like that happened with JPEG not too long ago. The dozens of corporations holding patents over H.264/MPEG-4 have not made such a release, and are activly seeking royalties. We don't even know yet what those royalties will be since those corporations are still fighting amoung each other over how to divy up the bounty from the combined patent portfolio. Regardless of the result, it is not patent-clear, will not be patent-clear, and will suffer worse bashlash as the free MP3 encoders did. The patent situation is unfortunate. Nevertheless, the H.264 codec is being adopted by broadcasters throughout the world. For good or bad, the codec is here to stay for a while. The GPL specifically forbids redistribution when the liberties granted by the GPL are limited or restricted by patents/etc. To distribute this software on any US-based server is, thus, in violation of the GPL. I won't argue about that. That said, VP3/Theora can hardly compare with H.264 in terms of coding efficiency. There really is no viable alternative in some situations. Microsoft's WMV9/VC1 comes close but I'm sure it has every bit as non-free licensing terms. This argument has nothing to do with the freeness of it, or it's compliance to the DFSG, but instead seems to be arguing that it's patent status should be ignored because it's superiority over free codecs makes it OK to ignore the ethical concerns over it. I'm not saying the patent issue should be ignored. It just strikes me as silly to even start comparing Theora with H.264. If you need HD content encoded at 4Mbps, H.264 is the only codec that is capable. Likewise, SD content at 500kbps is impossible with other codecs. It doesn't matter how free something is when it is useless for the required application. I'm not saying that Theora is useless per se. It is adequate for some applications. They are just not the ones where H.264 would normally be considered. This is all off-topic for debian-legal, so I won't pursue the argument further (unless someone says something really silly). -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A new practical problem with invariant sections?
Nathanael Nerode [EMAIL PROTECTED] writes: Anthony DeRobertis wrote: Nathanael Nerode wrote: Oh, it's possible, the section just ends up as unreadable garbage. Nothing in the GFDL requires that the invariant sections be readable. Well, actually, its not because devices easily barf on things that aren't ASCII. And, further, the GFDL says I must preserve invariant sections unaltered in their text, not unaltered in their octects; I seriously doubt that'd count... Mmm, I guess you're right. But then transliterating to ASCII must be acceptable. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bitstream font license
olive [EMAIL PROTECTED] writes: The lisence for the bitsream (package ttf-bitstream-* in main) font state among other: [...] The Font Software may be sold as part of a larger software package but no copy of one or more of the Font Software typefaces may be sold by itself. [...] (see the full license at http://packages.debian.org/changelogs/pool/main/t/ttf-bitstream-vera/ttf-bitstream-vera_1.10-3/ttf-bitstream-vera.copyright ) Does the fact that the fonts cannot be sold separatly is compatible with the DFSG? In spirit, no. However, it is easy to work around that restriction. Simply sell the fonts as part of the Hello World package. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moglen on kernel firmware blobs
Marco d'Itri [EMAIL PROTECTED] writes: http://news.zdnet.com/2100-9595_22-6028746-2.html?tag=st.next Moglen: I would distinguish the blobs from the proprietary drivers in the kernel. If the kernel's terms were unambiguously GPL, which they are apparently not, (proprietary drivers) would be forbidden. The blobs--though they are ethically objectionable to the Free Software Foundation, which believes that users ought to know what's running--are different because they are separate works when executed running in separate computers. From the point of view of the GPL work called the Linux kernel, they're just data. Exactly what I've always been saying. Call them non-free if you will, but don't get it mixed up with the GPL. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moglen's all good faith
Alexander Terekhov [EMAIL PROTECTED] writes: Hey legals, enjoy Moglen speaking on one-way street, linking, etc. http://news.com.com/Defender+of+the+GPL/2008-1082_3-6028495.html Now, One specific area where the linking question arises is in the Linux kernel, where proprietary video drivers loaded are loaded as modules. Another one might be the use of a network driver that relies on proprietary firmware that is loaded from an operating system. (Such firmware, sometimes called blobs, are strings of hexadecimal digits loaded from the operating system kernel into the hardware device to enable it to run.) Moglen: In all good faith, I can't tell you. If the kernel were pure GPL in its license terms, the answer...would be: You couldn't link proprietary video drivers into it whether dynamically or statically, and you couldn't link drivers which were proprietary in their license terms. I just wonder under what impure GPL license terms do you think Moglen thinks the Linux kernel is developed currently (note that the context is kernel drivers which has nothing to do with Linus' not-really-an-exception for user space). Any thoughts? Perhaps this: Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated. Besides, I'm free to insert whatever modules I want in my kernel, so long as I don't distribute /proc/kcore. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moglen's all good faith
Alexander Terekhov [EMAIL PROTECTED] writes: On 1/20/06, Måns Rullgård [EMAIL PROTECTED] wrote: [...] Moglen: In all good faith, I can't tell you. If the kernel were pure GPL in its license terms, the answer...would be: You couldn't link proprietary video drivers into it whether dynamically or statically, and you couldn't link drivers which were proprietary in their license terms. I just wonder under what impure GPL license terms do you think Moglen thinks the Linux kernel is developed currently (note that the context is kernel drivers which has nothing to do with Linus' not-really-an-exception for user space). Any thoughts? Perhaps this: Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated. And how does that make it impure GPL? Permission to relicense under revised later versions is not part of the GPL license terms. Are we talking about what makes sense, or about what Mr Moglen says? -- Måns Rullgård [EMAIL PROTECTED]
Re: Potential debian logo license violation
Andrew Donnellan [EMAIL PROTECTED] writes: On 11/28/05, Måns Rullgård [EMAIL PROTECTED] wrote: Giannis Beredimas [EMAIL PROTECTED] writes: There are similarities in the shape that has been rolled up to form the spiral. The spiral itself differs, though. The Greek spiral has about 2.5 revolutions, while the Debial logo has barely 2. Maybe they used the same Adobe Illustrator brush that was used to create the Debian logo, and applied it to a spiral with different parameters. Seems to be. So the Debian logo was made with Adobe(r) Illustrator(tm)? alertProprietary software!/alert There was a thread on that topic some time ago. Someone posted a screenshot that was quite convincing. Of course, there are those who refuse to believe it. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Clarification regarding PHP License and DFSG status
Arnoud Engelfriet [EMAIL PROTECTED] writes: The FSF makes very similar claims without additional context in their GPL FAQ: Q: If a library is released under the GPL (not the LGPL), does that mean that any program which uses it has to be under the GPL? A: Yes, because the program as it is actually run includes the library. http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL That doesn't fit any meaning of include that I'm aware of. The program and the library are sitting next to each other in the same address space. That doesn't make one of the include the other. Suppose a library allocates some shared memory that is accessed by all processes using that library (many examples exist). Does that make all programs using this library include each other, since they partially share address space? Q: You have a GPL'ed program that I'd like to link with my code to build a proprietary program. Does the fact that I link with your program mean I have to GPL my program? A: Yes. http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL I guess you all know what I think the GPL FAQ is a load of. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Potential debian logo license violation
Andrew Donnellan [EMAIL PROTECTED] writes: The outer ring of the spiral seems a fair bit wider than the Debian logo. It seems to be just a textured spiral to me. I played around with the Greek site's logo, trying to match it against the Debian logo. This is the result: http://inprovide.com/~mru/junk/debian.png This took a fair amount of rotating and stretching, and it's still not very close. My guess is that someone happened to draw a vaguely similar spiral. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Potential debian logo license violation
Giannis Beredimas [EMAIL PROTECTED] writes: Hi Måns, Måns Rullgård wrote: I played around with the Greek site's logo, trying to match it against the Debian logo. This is the result: http://inprovide.com/~mru/junk/debian.png This took a fair amount of rotating and stretching, and it's still not very close. My guess is that someone happened to draw a vaguely similar spiral. I decided to toy around with the logo myself. However, since the http://infosoc.gr site has a pseudo 3D-rotated version of the logo I decided to use a flat version I didn't know such a version existed, much less where to look for it. (http://ru6.cti.gr/broadband/images/logo-ktp.gif). From the mentioned gif: - I extracted the logo - Rotated 90 degrees anti-clockwise - Replaced the background with a white-one and made the spiral red The result is available at http://mperedim.serverhive.com/box/logo-comparison.jpg. Bottom left is the original debian logo, bottom right is the extracted infosoc logo. Afterwards I resized the bottom-right logo (keeping its original aspect ration) and superimposed it over and under the debian logo. Personally I am seeing more than a vague similarity, but (as I said in original mail) maybe it 's just me. There are similarities in the shape that has been rolled up to form the spiral. The spiral itself differs, though. The Greek spiral has about 2.5 revolutions, while the Debial logo has barely 2. Maybe they used the same Adobe Illustrator brush that was used to create the Debian logo, and applied it to a spiral with different parameters. If you create a logo by using stock items from a widely used graphics design program, you can only expect to find others using similar graphics. -- Måns Rullgård [EMAIL PROTECTED]
Re: Clarification regarding PHP License and DFSG status
Florian Weimer [EMAIL PROTECTED] writes: * Matthew Palmer: On Wed, Nov 23, 2005 at 03:08:24PM +0100, Florian Weimer wrote: * MJ Ray: Do you think that this licence does not require a developer of a modified package (other than PHP) to lie by saying This product includes PHP software? Perhaps the PHP folks subscribe to the view that PHP scripts are derivative works of PHP. Ye ghods, I'd hope not. That would be similar to believing that this message is a derivative of the English Grammar manual I read in school. Or that all non-trivial Emacs Lisp code must be licensed under the GPL. This position is not *that* unusual... Not being unusual doesn't make it sensible or correct. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Clarification regarding PHP License and DFSG status
Glenn Maynard [EMAIL PROTECTED] writes: On Fri, Nov 25, 2005 at 07:23:24PM +, Måns Rullgård wrote: Do you think that this licence does not require a developer of a modified package (other than PHP) to lie by saying This product includes PHP software? Perhaps the PHP folks subscribe to the view that PHP scripts are derivative works of PHP. Ye ghods, I'd hope not. That would be similar to believing that this message is a derivative of the English Grammar manual I read in school. Or that all non-trivial Emacs Lisp code must be licensed under the GPL. This position is not *that* unusual... Not being unusual doesn't make it sensible or correct. Just to take a guess at where this strange claim might have originated: Statements like this one would seem to have something to do with it: http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL The FSF (from what I understand) claims that binaries linked against GPL libraries are derivative works of the library, because the resulting binary has pieces of the GPL software in it. This isn't obviously true with C libraries, which has led to a lot of debate around the topic, but the claim isn't entirely unreasonable. They do not claim (again, AFAIK) that the *source* of the program using it is a derivative work of the library it uses. PHP scripts are derivative works of PHP sounds like someone misinterpreted the FSF's claims, and ended up believing that the source of a program is a derivative work of its libraries. (That, unlike the FSF's claims, seems to make very little reasonable sense.) For compiled languages they do not make this claim. For interpreted languages they appear to be claiming exactly this. The grounds for making such a distinction, or how to make it, are beyond me. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Clarification regarding PHP License and DFSG status
Glenn Maynard [EMAIL PROTECTED] writes: On Fri, Nov 25, 2005 at 09:22:24PM +, Måns Rullgård wrote: Statements like this one would seem to have something to do with it: http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL Odd statements, indeed. It's curious that the FSF would take positions that seem to seek to expand the power of copyright, and it's not the first time I've had this impression. They will gladly make any claim, however preposterous, as long as it suits their agenda. Their agenda, if anyone missed it, is to make everyone use the GPL for various political/philosophical reasons. When people cannot be persuaded to use it, the FSF will tell them lies, in order to make them believe that they have no other choice. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Clarification regarding PHP License and DFSG status
Florian Weimer [EMAIL PROTECTED] writes: * MJ Ray: Do you think that this licence does not require a developer of a modified package (other than PHP) to lie by saying This product includes PHP software? Perhaps the PHP folks subscribe to the view that PHP scripts are derivative works of PHP. Then it wouldn't be lying, would it? They still don't *include* PHP. There's a huge difference between require and include. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Logo rip-off
Henning Makholm [EMAIL PROTECTED] writes: Scripsit Måns Rullgård [EMAIL PROTECTED] Henning Makholm [EMAIL PROTECTED] writes: I'd certainly expect a program as expensive and with such ambitions as Adobe Illustrator to have it. On the contrary - a specific spiral template sounds like an extremely arcane and particular feature for someone to embed in a program. Most programs of that type have tools to draw rectangles, (regular) polygons, circles, ellipses, and spirals. Those are all basic geometrical shapes. I'm beginning to think that you are being deliberately obtuse. There are millions of *possible* spiral shapes that one could draw. Elektrostore chose the *exact same* spiral shape as the Debian swirl, and positioned the stock brush at the *exact same* point on the spiral. *That* is not just a default template. How did you measure the shape? How do you know that both logos were not created using default settings? -- Måns Rullgård [EMAIL PROTECTED]
Re: Logo rip-off
Henning Makholm [EMAIL PROTECTED] writes: I'd certainly expect a program as expensive and with such ambitions as Adobe Illustrator to have it. On the contrary - a specific spiral template sounds like an extremely arcane and particular feature for someone to embed in a program. Most programs of that type have tools to draw rectangles, (regular) polygons, circles, ellipses, and spirals. Those are all basic geometrical shapes. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: MySQL only useable for GPL clients?
Alexander Terekhov [EMAIL PROTECTED] writes: On 10/11/05, Martin Koegler [EMAIL PROTECTED] wrote: [...] At http://dev.mysql.com/doc/internals/en/licensing-notice.html Under the laws of the GNU Republic (MySQL district), all works are derived (in metaphysical sense) from some other preexisting GPL'd work(s) and hence Not just from preexisting works, they can be derived from works to be written later too. Some of the regulars here have repeatedly asserted the equivalent of this. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Logo rip-off
Henning Makholm [EMAIL PROTECTED] writes: Scripsit Amaya [EMAIL PROTECTED] /me wonders... Isn't the Debian swirl logo just a very basic Adobe Illustrator template? The stroke is, but the particular way it swirls is not. Looks like a pretty standard spiral to me. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Logo rip-off
Henning Makholm [EMAIL PROTECTED] writes: Scripsit Måns Rullgård [EMAIL PROTECTED] Henning Makholm [EMAIL PROTECTED] writes: Scripsit Amaya [EMAIL PROTECTED] Isn't the Debian swirl logo just a very basic Adobe Illustrator template? The stroke is, but the particular way it swirls is not. Looks like a pretty standard spiral to me. I didn't know there were standards for spirals. Which standard in particular are you referring to? In this case, most likely one supplied with Adobe Illustrator. The logo is just that texture wrapped along a simple spiral. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Logo rip-off
Steve Langasek [EMAIL PROTECTED] writes: On Thu, Oct 13, 2005 at 09:37:08PM +0100, Måns Rullgård wrote: Henning Makholm [EMAIL PROTECTED] writes: Scripsit Måns Rullgård [EMAIL PROTECTED] Henning Makholm [EMAIL PROTECTED] writes: Scripsit Amaya [EMAIL PROTECTED] Isn't the Debian swirl logo just a very basic Adobe Illustrator template? The stroke is, but the particular way it swirls is not. Looks like a pretty standard spiral to me. I didn't know there were standards for spirals. Which standard in particular are you referring to? In this case, most likely one supplied with Adobe Illustrator. The logo is just that texture wrapped along a simple spiral. Could you please tell us where in the Adobe Illustrator interface to find the simple spiral template in question? I don't have Adobe Illustrator. However, other graphics programs I've used have had such spiral functions. I'd certainly expect a program as expensive and with such ambitions as Adobe Illustrator to have it. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: MySQL only useable for GPL clients?
Martin Koegler [EMAIL PROTECTED] writes: The newer MySQL client libraries are GPL (with the FLOSS exception), older versions were LGPL. At http://dev.mysql.com/doc/internals/en/licensing-notice.html MySQL has put a descrption of their network protocol, where they force programs using this protocol to be GPL: The MySQL Protocol is proprietary. The MySQL Protocol is part of the MySQL Database Management System. As such, it falls under the provisions of the GNU Public License (GPL). A copy of the GNU Public License is available on MySQL's web site, and in the product download. Because this is a GPL protocol, any product which uses it to connect to a MySQL server, or to emulate a MySQL server, or to interpose between any client and server which uses the protocol, or for any similar purpose, is also bound by the GPL. Therefore if you use this description to write a program, you must release your program as GPL. Contact MySQL AB if you need clarification of these terms or if you need to ask about alternative arrangements. What are those people smoking? Writing a program that implements a protocol does not in any way I've ever heard of create anything derived from the protocol specification. An MPEG decoder is not a derivative of the MPEG specification (patents issues are unrelated), and this is no different in principle. Remember that it is perfectly legal to reverse engineer a protocol, and then proceed to write your own programs using it. Surely, there can't be more restrictions when the specification is publicly available. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
[EMAIL PROTECTED] (Claus Färber) writes: Andrew Suffield [EMAIL PROTECTED] schrieb/wrote: You are the one who is supposedly attempting to offer an argument here. Not me. I'm just telling you why yours is broken. You are actually creating straw mans which are broken. The original argument isn't. The argument, simplified, basically goes like this: 1. Program A is licensed under the GPL. = Debian can distribute A. Library M is licensed under the GPL. = Debian can distribute M. Program B is a derivative of A, which dynamically links against M. = Debian can distribute B. 2. Library O is licensed under the a BSD-like license, which contains an advertisting clause. = Debian can still distribute O. Program C is a derivative of A, which dynamically links against O. = Debian can't distribute C. 3. Library M is fully compatible to O. So programs B and C are actually identical. = Debian can and can't distribute B/C at the same time. = This can't be right. So one of the assumptions made above is wrong. The only assumption that is not obviously right is: Debian can't distribute C. Well, you can replace Debian can't distribute C by Debian can't distribute C unless M is available. But this is very strange as it would mean that the advent of M changes the copyright status of C, which is actually derieved from A and O. This is the argument that has been rehashed here countless times. Each time, the reply has been something like you're wrong, with no explanations whatsoever. I can only take this to mean that they are out of real arguments, but refuse to admit it, just like the FSF themselves. I'm giving up this discussion for now, until people perhaps decide to start using logic and reason, rather than philosophy and religion to reach their conclusions. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
Andrew Suffield [EMAIL PROTECTED] writes: On Fri, Sep 09, 2005 at 09:54:04AM -0300, Humberto Massa Guimar?es wrote: On Thu, Sep 08, 2005 at 04:22:18PM -0300, Humberto Massa Guimar?es wrote: If you're going to make an argument at odds with established understanding and industry practice then you'll have to come up with more than that. There's an awful lot of lawyers and law professors who think that the GPL works. Go start by arguing with them. I can't argue with someone who offers ABSOLUTELY NO ARGUMENT. You are the one who is supposedly attempting to offer an argument here. Not me. I'm just telling you why yours is broken. That doesn't No, you are not telling me why my argument is broken. If you are trying, you're not being very clear. Why is my argument broken exactly? By trivially continuing it to the next obvious point, it concludes that the GPL doesn't work. Therefore it's broken somewhere. Figuring out where is left as an exercise for the students. I really don't care about the details. Ah, but this is based on the assumption that the GPL actually does work. The argument was intended to show that it doesn't, and apparently succeeds at this. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
Sean Kellogg [EMAIL PROTECTED] writes: The thing is that the kernel is indeed much like a library, but not like a static one. The kernel is a lot like a shared library in that it exists in memory, and has functions that can be called. It is different mainly in that it stays in memory, and on some architectures has special capabilities not available to regular shared libraries. Note that it is not different by being a critical part of the operating system, as other libraries, especially things like the c library, or even the runtime linking library (ld.so) I've written about this very issue in law school. It seems to me there are two ways to view the issue. One is that the GPL is a Contract (*shudder*) and thus the parties are free to restrict what is done with code they distribute. Consider it a contract that says you can have this code, but only if you free the code you combine it with... otherwise you can't have the code That is a perfectly fine contract, mutual promises and all. However, many say that the GPL is not a contract and must be considered a pure license and the sole product of copyright law. If so, then the GPL can only exercise power over (s)106 rights (US copyright law). Any item outside of those rights cannot be controlled by the license. The GPL tries to do this by claiming a derived work or out-and-out copying. I think you very much hit it on the head by asking whether it is either... and based on my understanding of what is and is not a derivative work, what constitutes copying, and applicable caselaw, I don't think it is. But then again, I think the GPL is a contract... so I don't see it as much of a problem. Even if the GPL is a contract, it doesn't matter. Read section 0: 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The Program, below, refers to any such program or work, and a work based on the Program means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term modification.) Each licensee is addressed as you. Note particularly the phrase derivative work under copyright law. Whatever terms the parties of the contract agree to, they apply only to the program itself and the aforementioned derivatives, specifically not other programs that merely use the code covered by the contract. The contradictory rephrasing following the colon doesn't pose any problems either, as a program dynamically linked to a library doesn't contain the library, or any parts of it. All it does is makes reference to it, and does so in a very non-specific way. The section continues: Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. The phrase running the Program is not directly applicable to a library, so we have to assume that for libraries, this translates into using the library, i.e. causing its code to be run, typically by running a program that uses the library. This act being unrestricted per the quoted paragraph, it follows that any program can link with a GPL library, no matter what license that program has. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
Sean Kellogg [EMAIL PROTECTED] writes: On Thursday 08 September 2005 11:38 am, Andrew Suffield wrote: There's an awful lot of lawyers and law professors who think that the GPL works. Go start by arguing with them. Based on my readings of law review articles and the common legal arguments surrounding the GPL, the reason it works is because the GPL is a contract. The linking clause is a contractual term that you must agree to in order to receive a copyright license. Pretty standard forbearance. Which linking clause? The one in the FAQ? That's not in any way part of the license/contract. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL+OpenSSL issue -- good suggestion?
Pascal Giard [EMAIL PROTECTED] writes: I maintain the mail-notification package and face a GPL+OpenSSL issue. I've tried to reach an arrangement with the upstream author but failed. Find the bug entry here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286672 Recently, a user posted a suggestion, i'd like to know if it's a valid solution. If not, is there anything else i can do? This is getting absurd. The usual argument here is that Debian should follow the wishes of the upstream author, even if the legal foundations are shaky. Why not in this case? -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PEAR-DEV] PHP License
Ian Eure [EMAIL PROTECTED] writes: 6. Redistributions of any form whatsoever must retain the following acknowledgment: This product includes PHP, freely available from http://www.php.net/. Ouch. This means that I can't distribute a PEAR module released under the PHP License without bundling in PHP itself. This makes it impossible to distribute PEAR modules by themselves (i.e. not bundled with the PHP language) in a deb or an rpm. :-( I feel that your interpretation of those clauses is overbroad and incorrect. The clause does not state that the product must bundle PHP, but that it must affix a notice to the effect that it includes it. But without including PHP, it won't be, well, included, making the statement false. Using false statements as part of a license doesn't seem like a very good idea to me. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PEAR-QA] PHP License
Sean Kellogg [EMAIL PROTECTED] writes: On Wednesday 24 August 2005 01:46 pm, Catatonic Porpoise wrote: Sean Kellogg wrote: I'm pretty sure it is a PHP-derivative. It relies on all sorts of built in PHP functions to create the finished work. Perhaps... PERHAPS... the code you download for phpbb, on its own, MIGHT be a separate and distinct work, but it's not phpbb until it's merged with PHP functions to create the finished, derived work. I see a little problem with this line of reasoning. It would seem to imply that if I post a C program I wrote on my website, in source code form, that program is subject to the license of every libc anyone might ever compile it with. I would think the code you post is just code. You're free to post your own code as much as you like. However, if I download that code and use it in conjunction with glibc, then yes, I must abide by the license chosen by the authors of glibc. But it does raise an interesting question... [...] But if we assume the developers of phpBB actually downloaded PHP, they agreed to not make derivative software with certain titles. Going back to the C example you raised... the developer of the C program must abide by the terms of the libc he or she chose to develop with. I build my code on a variety of systems, including Linux/glibc, *BSD, Solaris, AIX, MacOSX, etc. Does this mean that my programs are derivatives of all these C libraries/compilers? -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PEAR-QA] PHP License
Sean Kellogg [EMAIL PROTECTED] writes: On Wednesday 24 August 2005 02:17 pm, Måns Rullgård wrote: Sean Kellogg [EMAIL PROTECTED] writes: On Wednesday 24 August 2005 01:46 pm, Catatonic Porpoise wrote: Sean Kellogg wrote: I'm pretty sure it is a PHP-derivative. It relies on all sorts of built in PHP functions to create the finished work. Perhaps... PERHAPS... the code you download for phpbb, on its own, MIGHT be a separate and distinct work, but it's not phpbb until it's merged with PHP functions to create the finished, derived work. I see a little problem with this line of reasoning. It would seem to imply that if I post a C program I wrote on my website, in source code form, that program is subject to the license of every libc anyone might ever compile it with. I would think the code you post is just code. You're free to post your own code as much as you like. However, if I download that code and use it in conjunction with glibc, then yes, I must abide by the license chosen by the authors of glibc. But it does raise an interesting question... [...] But if we assume the developers of phpBB actually downloaded PHP, they agreed to not make derivative software with certain titles. Going back to the C example you raised... the developer of the C program must abide by the terms of the libc he or she chose to develop with. I build my code on a variety of systems, including Linux/glibc, *BSD, Solaris, AIX, MacOSX, etc. Does this mean that my programs are derivatives of all these C libraries/compilers? Yeah, I believe so. That's absurd. In theory, I could write the code without access to any of the libraries, only using the POSIX spec for reference. The result could be compiled and run on any POSIX compliant system (and there are some). Now in practice, I'll occasionally make a mistake, so I need to test the code to make sure it works. If this makes my program a derivative of all these C libraries, I'm in real trouble, since I have no license to create such derivatives of most of them. This is why glibc is under the LGPL. No, the reason for that is that the FSF insists that using the GPL would disallow non-GPL programs linking with it at all, and for whatever reason they don't want that situation. It's really easy to create derived works under U.S. Law. As a side note, there is some really interesting unexplored areas of law relating to derivative works and things like dynamic vs. static linked libraries. There is some case law, but I think it leaves a lot unanswered. Indeed. For the purposes of this discussion, I'm supporting the popular contention that using a dynamically linked library creates a derivative work (although, I have my doubts). The same logic applies here. If the program can work with either of several different libraries, it is not a derivative of any. If it were, we'd have the absurd situation of programs being derivatives of libraries written after the program. Clearly, this is not possible. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: May be non-copyrighted documment included in main?
MJ Ray [EMAIL PROTECTED] writes: Petr Gajdusek [EMAIL PROTECTED] wrote: The only notice in the documment says: This publication is not copyrighted. One can copy it and use any part of it with mentioning the source. Publishers ask only for information about it. Is this sufficient to include publication in main section? It may depend where it's from: copyright is automatic in many countries. As such, the permission granted to copy it and use any part with attribution is needed and might be sufficient, but it looks like it deliberately discriminates against publishers. I don't think it follows DFSG 1 or 6. It says something about publishers, but exactly what it's supposed to mean is beyond me. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL Possible Derivative Work
Mike [EMAIL PROTECTED] writes: Hello all, If I were to study GPL'ed source in order to understand a protocol that it implements, would I need to and if so how would I cite this in any program I create which uses any knowledge gained? Stating where you obtained the information is always a good idea. IIUC, you are intending to write your own implementation of the protocol, or perhaps write a client for a server. As long as you do not copy any code, you will not be creating a derived work, and hence will not be bound by the GPL in any way. There is, AFAIK, no dispute about this. IANAL, TINLA, etc. -- Mns Rullgrd [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is this license DFSG free?
Anthony DeRobertis [EMAIL PROTECTED] writes: Sean Kellogg wrote: You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. Doesn't this violate the Dissident test and cause troubles for our poor totalitarian state citizen? No, because the following statement is allowed by the GPL, and does not reveal the identity of the dissident: This file was changed on December 10, 2004. Whether that's allowed by the GPL depends on the interpretation of the phrase stating that you changed the files. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RES: Where to put Open Transport Tycoon (openttd)
Humberto Massa Guimarães [EMAIL PROTECTED] writes: See the paragraph from Micro Star v. FormGen cited in my response to Raul. It's not the degree of indirection in reference to artworks, it's the fact that the game experience plagiarizes protectable expression from Transport Tycoon. Ok. I'm conviced you're probably right. I'm not so convinced. It depends on how much of the game is defined in the data files, and how much is part of the engine, in other words, how generic the game engine is. Unless a proper distinction is made, you could argue that the game was made to run on an Intel CPU, and thus AMD is infringing on the game by making a machine capable of running it. I don't expect anyone to seriously attempt such an argument, but with a dedicated game console, the borders are more blurred, especially when the manufacturer of the original hardware also produces games. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL and linking
Jakob Bohm [EMAIL PROTECTED] writes: Well, I have certainly seen no signs that the view expressed in the GPL FAQ does not have consensus on the debian-legal list. Apparently, you have failed to see the numerous disagreeing posts that appear from time to time. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Glenn Maynard [EMAIL PROTECTED] writes: If you make a kernel module that only uses something EXPORT_SYMBOL()'d from the kernel, you are NOT in principle writing a derivative work. If you use EXPORT_SYMBOL_GPL()'d symbols, then you are incurring in (b) above and your kernel module is most certainly a derivative work. The notion that what is a derivative work changes based on whether a symbol was declared with EXPORT_SYMBOL or EXPORT_SYMBOL_GPL seems fundamentally absurd to me. (If somebody is reimplementing the Linux kernel API, he might just as easily reimplement the EXPORT_SYMBOL_GPL symbols, for compatibility with drivers that need them, for example.) Someone could even take the Linux kernel, and replace all EXPORT_SYMBOL_GPL with EXPORT_SYMBOL. I see nothing in the GPL prohibiting this. Sure, it wouldn't be nice, but it's legal not to be nice. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Humberto Massa [EMAIL PROTECTED] writes: Måns Rullgård wrote: Glenn Maynard [EMAIL PROTECTED] writes: If you make a kernel module that only uses something EXPORT_SYMBOL()'d from the kernel, you are NOT in principle writing a derivative work. If you use EXPORT_SYMBOL_GPL()'d symbols, then you are incurring in (b) above and your kernel module is most certainly a derivative work. The notion that what is a derivative work changes based on whether a symbol was declared with EXPORT_SYMBOL or EXPORT_SYMBOL_GPL seems undamentally absurd to me. (If somebody is reimplementing the Linux kernel API, he might just as easily reimplement the EXPORT_SYMBOL_GPL symbols, for compatibility with drivers that need them, for example.) Someone could even take the Linux kernel, and replace all EXPORT_SYMBOL_GPL with EXPORT_SYMBOL. I see nothing in the GPL prohibiting this. Sure, it wouldn't be nice, but it's legal not to be nice. Hmmm. One can argue that the EXPORT_SYMBOL* are copyright grants, and as such can't be freely edited, just like the comments as /* this module (C) 1999 Fulana Perez */ that are in the code. Removing such comments *is* illegal, and editing EXPORTs can be, too... It would be, if the license said it was. As it happens, the license makes no mention of this, but does give explicit permission to make any modifications desired. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Humberto Massa [EMAIL PROTECTED] writes: Måns Rullgård wrote: It would be, if the license said it was. As it happens, the license makes no mention of this, but does give explicit permission to make any modifications desired. If EXPORT_XX are copyright notices, But are they? copyright *law* prohibit their modification. Indeed. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#294559: A very permitive license.
Martin Samuelsson [EMAIL PROTECTED] writes: (Resending this since my Cc to debial-legal got lost the first time) A fair while ago I consulted debian-legal on the public domain license and got the polite reply from Glenn Maynard stating that problems might exist with it not disclaiming warranty. Further discussion with upstream created this short license: Netbiff may be redistributed in any form without restriction. Netbiff comes with NO WARRANTY. Since this is a new license I'm asking debian-legal for completeness if there could be any problems with this licensing? It should be DFSG free as far as I can understand, right? It doesn't explicitly allow distributing modified versions. Maybe any form was intended to include modifications, but it's not obvious. Why not just use the BSD or MIT license? -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
Raul Miller [EMAIL PROTECTED] writes: If you can find us a country whose laws make this illegal, this issue would be worth discussing. On Fri, Apr 01, 2005 at 06:15:34PM +0200, Måns Rullgård wrote: You are obviously convinced that using a command line interface can't be protected by copyright. Right, in the sense that copyright is about tangible forms of creative expression, and it's not about functional mechanisms such as interfaces. Mechanisms like header files, for instance. So, for example, this lack of copyright protection for command line interfaces doesn't mean that I can put some copyrighted story on the command line and make its copyright protection go away. If writing that story on the command line is required for using the program, I can think of three possibilities: 1) the author of the program owns the copyright to the story, and lets you use the story in this way, 2) the author of the program owns the copyright to the story, doesn't let you use it, and effectively prevents you from using the program at all, which would seem quite silly, and 3) the author of the program doesn't own the copyright to the story, and has no possibility of allowing you to use it, which is even sillier. Why, then, are you so persistent in insisting that other interfaces somehow are awarded such protection? That wasn't what I was trying to say. I was trying to say that just because something is a relevant interface in case A doesn't mean that that kind of interface is relevant in case B. Who gets to decide what is relevant, and when? -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
Raul Miller [EMAIL PROTECTED] writes: On Thu, Mar 31, 2005 at 09:17:51PM +0200, Måns Rullgård wrote: Thanks for mentioning command lines. Running a program from the command line, usually involves passing it options. These options are (obviously) copies of strings from the actual program. Can this copying be a copyright violation? IMHO, it is no different, in principle, from using function names declared in a header file. If you can find us a country whose laws make this illegal, this issue would be worth discussing. If the laws of that country were available in english, we could probably do justice to that (hypothetical) discussion. If there are any such countries, and they make a practice of enforcing such laws (rather than just having them on the books to confuse novices), we should probably put together a page warning people to about using computers in that country (or those countries). You are obviously convinced that using a command line interface can't be protected by copyright. Why, then, are you so persistent in insisting that other interfaces somehow are awarded such protection? -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
Raul Miller [EMAIL PROTECTED] writes: Those .h files were held to be not protected by copyright because no viable alternatives were available to interface with the system. It's hard to see how this reasoning would apply in a context where there is some viable alternative available to interface with the system. On Wed, Mar 30, 2005 at 04:15:57AM +0200, Måns Rullgård wrote: Alternative to what? There can be no alternative to the full set of interfaces to the system. Are you trying to argue, that several interfaces exist, use of each one is protected due to the existence of the others? For example: gcc provides a command line interface as an alternative to rebuilding gcc every time you need to compile a program. Thanks for mentioning command lines. Running a program from the command line, usually involves passing it options. These options are (obviously) copies of strings from the actual program. Can this copying be a copyright violation? IMHO, it is no different, in principle, from using function names declared in a header file. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
Raul Miller [EMAIL PROTECTED] writes: On Mon, Mar 28, 2005 at 11:25:39AM -0300, Humberto Massa wrote: My claim was: *Basically*, bits in .h files are not copyrightable. Which I now solemnly amend to The kind of bits you normally (99% of the times) find in .h files in c-language based projects, and often (50% of the times) find in .h files in c++ based projects, are those defining interfaces, deeming them uncopyrightable by current USofAn and Brazilian law. Better? Raul Miller wrote: However, for U.S. law, this isn't necessarily the case. On Mon, Mar 28, 2005 at 04:14:47PM -0300, Humberto Massa wrote: I was referring to the fact that there is some case law in the USofA that deemed interface definitions, as present normally in .h files, uncopyrightable. HTH Those .h files were held to be not protected by copyright because no viable alternatives were available to interface with the system. It's hard to see how this reasoning would apply in a context where there is some viable alternative available to interface with the system. Alternative to what? There can be no alternative to the full set of interfaces to the system. Are you trying to argue, that several interfaces exist, use of each one is protected due to the existence of the others? Suppose there is only one interface, such that it, per your reasoning, is not protected. Now add another. Does this addition suddenly make the first interface protected? What if they were created in the opposite order? -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
Glenn Maynard [EMAIL PROTECTED] writes: On Tue, Mar 29, 2005 at 08:53:52PM -0500, Raul Miller wrote: On Mon, Mar 28, 2005 at 11:25:39AM -0300, Humberto Massa wrote: My claim was: *Basically*, bits in .h files are not copyrightable. Which I now solemnly amend to The kind of bits you normally (99% of the times) find in .h files in c-language based projects, and often (50% of the times) find in .h files in c++ based projects, are those defining interfaces, deeming them uncopyrightable by current USofAn and Brazilian law. Better? Raul Miller wrote: However, for U.S. law, this isn't necessarily the case. On Mon, Mar 28, 2005 at 04:14:47PM -0300, Humberto Massa wrote: I was referring to the fact that there is some case law in the USofA that deemed interface definitions, as present normally in .h files, uncopyrightable. HTH Those .h files were held to be not protected by copyright because no viable alternatives were available to interface with the system. I'd question whether that'd apply to a *free* system, anyway. I havn't looked at these cases (since I don't know which they are), but I recall a case that sounds just like it: an author of a work created (under contract) for a movie claimed that no license to actually use that material was granted, but as the paid-for work was useless without a license to use it, a license was implied. That doesn't seem relevant where the work is being given out entirely for free; the creator has no obligation to anyone else to grant a license to make the library's release useful. (For a commercial SDK, this would seem to apply to header files.) So now the degree of protection by copyright depends on how much you charge for it? What if someone gets paid to develop open source? -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New licence for auto-tools m4 files
Andrew Suffield [EMAIL PROTECTED] writes: On Thu, Mar 24, 2005 at 05:10:36PM +, Scott James Remnant wrote: 8888888-- This file is free software; the Free Software Foundation gives unlimited permission to copy and/or distribute it, with or without modifications, as long as this notice is preserved. 8888888-- It's free, but it's sloppy. I find it hard to believe that FSF legal passed this. Where's the warranty disclaimer? This can't be the full thing. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: x.org non free?
Michael Below [EMAIL PROTECTED] writes: Mickaël Leduque [EMAIL PROTECTED] writes: (I'm not related with debian, except being a debian user) I'm a bit worried by this file I found in x.org source : xc/README.crypto I'm sure this question has been answered hundreds of times and there's nothing worrying here, but the contents of this file seems to make all the files that are related to it non free. What did I miss? I'm not a developer either, but from the legal point of view you're right, I'd say. Their README.crypto says: Without limiting the generality of the foregoing, hardware, software, technology or services provided under this license agreement may not be exported, reexported, transferred or downloaded to or within (or to a national resident of) countries under U.S. economic embargo including the following countries: Cuba, Iran, Libya, North Korea, Sudan and Syria. This list is subject to change. I.E. they are making US export restrictions part of their license -- I think they are simply stating facts, to make the user aware of the situation. at least in german law, it doesn't matter whether they called the file LICENSE or README, they made it clear that they want to make this binding. This seems to be a violation of Nr. 5 of the DFSG, saying: The license must not discriminate against any person or group of persons. Also, the x.org README.crypto limits redistribution: You may not export or re-export this software or any copy or adaptation in violation of any applicable laws or regulations. Again, this is only stating facts that are always true, whether explicitly stated or not. I'd say this conflicts Nr. 1 of the DFSG, saying: The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale. If the law places restrictions on distribution, there is nothing a license can do about it. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
Andrew Suffield [EMAIL PROTECTED] writes: On Wed, Mar 23, 2005 at 08:10:57PM +0100, M?ns Rullg?rd wrote: Henning Makholm [EMAIL PROTECTED] writes: Concluding: when you write a .c file, it is or not a derivative work on another original work independently of what the compiler and linker will do in the future. I repeat: No, but the resulting .o file may be derived from another work that the compiler also read while producing it. The object file may contain bits from header files, or whatever, but this has no bearing on the distributability of it. Nonsense. Literal copying is always copyright infringement. Unless you had permission to make copies, which the GPL explicit grants you. We were talking about GPL'd stuff here, right? They only found their way there as the result of implementation details. Under your rather strange theory, copying a file can never be copyright infringement, because the way cp moves the bits around is just an 'implementation detail'. So presumably you don't think copyright infringement using a computer is possible. You are obviously deliberately misinterpreting what I said. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
Henning Makholm [EMAIL PROTECTED] writes: Concluding: when you write a .c file, it is or not a derivative work on another original work independently of what the compiler and linker will do in the future. I repeat: No, but the resulting .o file may be derived from another work that the compiler also read while producing it. The object file may contain bits from header files, or whatever, but this has no bearing on the distributability of it. They only found their way there as the result of implementation details. Allowing the a particular method of implementation to stretch the reach of copyright in such a way would be absurd, and this is what fair use is about. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
Glenn Maynard [EMAIL PROTECTED] writes: extern char **__err_msgs; #define perror(s) (fprintf(stderr,%d:%s:%s\n,errno,__err_msgs[errno])) Is myfile.c a derivative work on errno.h? The answer is NO. Of course. But myfile.o might have been if perror() were complex enough to leave any room for expressive choice. Again, irrelevant. If your implementation puts things in macros, that's your problem. Uh, what? If my implementation puts things in macros, and you distribute my implementation as part of your binaries as a result, that's *your* problem. I don't even know what you're trying to say here--you put your copyrighted code in a header and I copied it into my object file--that's your problem, not mine! doesn't make any sense at all. The only reasonable way to use your library (which for this discussion shall be assumed to have been legally obtained), is to compile programs using its header files, and link these programs against it. What did you expect me to do with those headers? Frame them and hang them on the wall? -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
Anthony W. Youngman [EMAIL PROTECTED] writes: And doesn't the GPL contain a promise that any future GPL will be identical in spirit to the original? It uses the phrase similar in spirit, which has yet to be given an exact definition. Of course, this assumes you actually want to take the matter to court... an act often prohibitively expensive for most FOSS developers... but then again, most of this conversation is academic anyway because it assumes people will actually dislike v3 AND that there is infringement ABD that the infringement is authorized under v3 but not v2. If the new GPL breaks that promise, then the original licensor has a very good case in law that the new GPL is *not* a later version, but a different version to which the or later wording doesn't apply... That would be a, maybe not desirable, but at least very interesting case. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
Glenn Maynard [EMAIL PROTECTED] writes: Such language is fine as long as the copyright holder and the license author are the same entity. New versions of the license are likely to reflect changes in the opinions of the authors, and they have every right to make provisions for a modified license to automatically apply to already released works. The danger arises when people start out-sourcing the writing of licenses to third parties. The FSF has its own agenda, and has little reason to consider the opinions of others, who just happen to use their license texts, when writing the next version. A couple years ago, this would all have been patently false. The FSF has a very strong interest in their notion of freedom being considered reliable, and having the community trust them to remain consistent There is no single the community, sharing a single opinion on freedom. There are many different views out there, and some recent moves from FSF have been in a direction away from a large enough number of people, with loud enough voices, to make it noticeable. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
Humberto Massa [EMAIL PROTECTED] writes: Arnoud Engelfriet wrote: Interesting point. But the statement would apply certainly to Linus' own contributions. And that would preclude distribution of anything containing those contributions under anything but GPLv2 I think. But if you can take out his code (and any other that's GPLv2 only), you'd be free to apply GPLv3 if and when it comes out. Arnoud Sorry, but no, no, no. Everything that is not completely independent and extractable and beyond any doubt non-historically-derived of Linus code is a derivative work and, as such, can only be distributed under the terms of the GPLv2. To prove something not derivative, you would have to show that historically, it was made for other kernel, and that there is no tranformation of the linux kernel that resulted in that something. There *is* at least one example in the tree: the ppp code is derivative from one of the BSDs. Some of the filesystems (XFS and JFS, at least) have external origins, although they must have been somewhat adapted to the Linux VFS layer. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
Kuno Woudt [EMAIL PROTECTED] writes: On Sun, Mar 13, 2005 at 03:30:28PM +0100, Måns Rullgård wrote: Arnoud Engelfriet [EMAIL PROTECTED] writes: And probably it will also deal with running the code on a publicly accessible server. The question is if a license based on copyright can legally place such restrictions on use of the program. Some idea of how the FSF may attempt this can be seen from the Affero General Public License. Apparantly the Affero GPL is a modified version of the GNU GPL, it adds Section 2(d): * d) If the Program as you received it is intended to interact with users through a computer network and if, in the version you received, any user interacting with the Program was given the opportunity to request transmission to that user of the Program's complete source code, you must not remove that facility from your modified version of the Program or work based on the Program, and must offer an equivalent opportunity for all users interacting with your Program through a computer network to request immediate transmission by HTTP of the complete source code of your modified version or other derivative work. This appears to only apply to self-distributing programs. If the program does not have a send-the-source function, I don't see any requirement that source be provided to users of a service based on the program. It also adds an interesting twist on the or later thing often used with the GPLv2: Affero Inc. may publish revised and/or new versions of the Affero General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. I've always wondered what similar in spirit is supposed to mean. AFAIK, that phrase has no established legal interpretation. Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and any later version, you have the option of following the terms and conditions either of that version or of any later version published by Affero, Inc. If the Program does not specify a version number of this License, you may choose any version ever published by Affero, Inc. This looks similar to the language used in the GNU GPL. You may also choose to redistribute modified versions of this program under any version of the Free Software Foundation's GNU General Public License version 3 or higher, so long as that version of the GNU GPL includes terms and conditions substantially equivalent to those of this license. It would be interesting to see the reaction of these people, if the GNU GPLv3 does not include a source-for-service clause, after all. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Binaries and MIT/expat license interpretative tradition
Andrew Suffield [EMAIL PROTECTED] writes: On Mon, Mar 14, 2005 at 11:24:24AM +0200, Henri Sivonen wrote: (My question is not Debian-related, but I figured the people who know the answer read this list.) The usual interpretation (seen in the list archives) of the MIT/expat license seems to be the that the copyright notice needs to be retained in the source but does not have to be displayed by binaries. The license does not say that the binaries do not constitute a copy of the Software. What's the basis of the interpretation and that the copyright notices do not need to be grepped from the source and stuffed in an about box or similarly placed on binaries? The copyright notice does need to be included with the binaries. On Debian systems it is placed in /usr/share/doc/$package/copyright. This isn't a particularly strange or restrictive thing to require... This is different from the requirement of some licenses that a notice be displayed on the console, or in a dialog box, when the program is run. I think this is what the OP was afraid of. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
Francesco Poli [EMAIL PROTECTED] writes: On Sun, 13 Mar 2005 19:14:09 -0500 Glenn Maynard wrote: [...] There havn't been any such bugs, though, fortunately. Some people don't like the PHP loophole or whatever you want to call it, but I don't believe that's fixable in a free license, Could you please elaborate on the PHP loophole? I've never heard of it: what do you mean by that? (feel free to change the subject or even to reply to me in private, if you think it's better) I'm also curious about this one. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
Daniel Carrera [EMAIL PROTECTED] writes: Hello, My understanding is that Linux is distributed under the GPLv2 exclusively. That is, instead of the usual GPL version 2 or later it just says GPL version 2. That's what it says, yes. People occasionally question the validity of that, though, arguing that the statement was added after many people had already made contributions. Given the vast number of Linux contributors, this means that Linux won't be able to migrate to the GPLv3 when it comes out, correct? That would be the case. Is this a problem? Personally, I'd be very sceptical about releasing code under a license containing a blanket permission to use it under another yet to be written license. What if I don't at all agree with GPLv3? -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
