Re: cdrecord: weird GPL interpretation
Bernhard R. Link wrote: * M?ns Rullg?rd [EMAIL PROTECTED] [040902 17:11]: In particular, he seems to be relying on German Authors' Rights, and claims to be in discussion with Debian people. That's nearly a month ago. More specifically, he claims to be in discussion with Debian how to stop SuSE from doing what they have every right to do. I know nothing about German law, so I can't comment on that bit. Only thing in German law I could imagine is that he could withdraw some of his work. Which would require him to pay everyone what it is currently worth before the ban can take effect and make it impossible for him to allow others to use it. Anyone knows some reading if there is any other possibility and if this possibilty is even applicaple to software? I think he's trying to say that his moral rights were violated by SuSE when they made a broken version of cdrecord. You are indeed not allowed under German law to modify a work in such a way as to damage the original author's reputation or good name. However that doesn't cancel the license. It merely is a ground for a civil lawsuit to obtain damages. Arnoud -- Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/
Re: cdrecord: weird GPL interpretation
On Thu, Sep 02, 2004 at 02:12:54PM -0700, Adam McKenna wrote: On Thu, Sep 02, 2004 at 04:30:04PM -0400, Glenn Maynard wrote: [1] http://www.washington.edu/pine/faq/legal.html#10.2 (Accusing Free Software programmers of perverting the license by doing things they were clearly granted permission to do; that's wonderful.) Wasn't the force behind the license re-interpreation to stop people from distributing Pine with a maildir patch? Like cdrecord with a dvdrecord patch, and yaboot with anything but pristing upstream source ? Altough at lest in the yaboot case, it is not licencing that is used, but threat to remove the debian yaboot mention from the official yaboot web page of supported yaboto versions. Friendly, Sven Luther
Re: cdrecord: weird GPL interpretation
Brian Thomas Sniffen bts at alum.mit.edu writes: [...] On the other hand, I find this message interesting: http://lkml.org/lkml/2004/8/19/111 In particular, he seems to be relying on German Authors' Rights, and claims to be in discussion with Debian people. That's nearly a month ago. Hello, This was about the recent change of license in a36 that was widely covered in the news, e.g. lwn or heise.de http://weblogs.mozillazine.org/gerv/archives/006193.html We (cdrools Debian maintainers) were in indeed private contact with Joerg about this and successfully managed to resolve this, a38 undid the newly introduced non-freeness issue, the code in question (linuxcheck()) is not encumbered by a specific license anymore, it may be removed like anything else. This is resolved and completely orthogonal to this thread, so please ignore it. cu andreas
Re: cdrecord: weird GPL interpretation
Raul Miller moth at debian.org writes: [...] I've taken a look at a copy from January, and it has the same problem. I don't know how far back we'd have to go to find a legally distributable copy. Probably February or January 2002. cu andreas
Re: cdrecord: weird GPL interpretation
Andreas Metzler [EMAIL PROTECTED] writes: Brian Thomas Sniffen bts at alum.mit.edu writes: Raul Miller moth at debian.org writes: [...] There's an additional problem: cdrtools, at least as Debian distributes it, uses some code for which Schilling is not the copyright holder. The HFS support, for example, is copyright Robert Leslie, and licensed under the normal, sanely interpreted GPL. cdrecord is not distributable by anybody, including Schilling, in this state. [...] cdrtools consists of a bunch of largely independent applications and libraries (e.g cdrecord, readcd, mkisofs, cdda2wav), debian/copyright lists the licenses and copyright holders in detail. The two issues mentioned in this thread influence different parts of cdrtools: * defaults.c /* * WARNING you are only allowed to change this filename if you also snip This one is used and linked against all applications of cdrtools since 2.01a26 (previously only in cdrecord). If it is GPL incompatible it indeed breaks the e.g. mkisofs' and cdda2wav's original copyrights. That's certainly GPL-incompatible. It's an extra restriction. Since it affects functional behavior, I'd call it non-free. You must change this filename requirements are generally considered non-free, so I'd expect You may not change this filename without paying this fee requirements to be non-free. The second issue * If you modify cdrecord you need to include additional version * printing code that [...] in cdrecord/cdrecord.c only applies to cdrecord which is completely copyrighted by JS. Therefore he is able to license it as GPL+restrictions and if the restrictions are still DFSG free we are able to ship it as part of Debian/main. - If cdrtools stopped being distributed as whole and would be split into separate tarballs for the different applications, because otherwise this part of GPL ... I think if that could easily be done, and the packages didn't Depend on each other, then you could say that they're separate works and merely aggregated into one package. -- But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. -- ... could give us a headache. cu andreas -- Brian Sniffen [EMAIL PROTECTED]
Re: cdrecord: weird GPL interpretation
On Fri, Sep 03, 2004 at 09:24:00AM -0400, Brian Thomas Sniffen wrote: The two issues mentioned in this thread influence different parts of cdrtools: * defaults.c /* * WARNING you are only allowed to change this filename if you also snip This one is used and linked against all applications of cdrtools since 2.01a26 (previously only in cdrecord). If it is GPL incompatible it indeed breaks the e.g. mkisofs' and cdda2wav's original copyrights. That's certainly GPL-incompatible. It's an extra restriction. Since it affects functional behavior, I'd call it non-free. You must change this filename requirements are generally considered non-free, so I'd expect You may not change this filename without paying this fee requirements to be non-free. Why do we have to use the word fee to describe this sort of requirement? It's unnatural, and seems contrived to fit DFSG#1, which is unnecessary, since fees are not the only sort of restrictions prohibited by DFSG#1. I agree that this is non-free, as is any requirement that I explain myself before distributing a modification. -- Glenn Maynard
Re: cdrecord: weird GPL interpretation
On Fri, Sep 03, 2004 at 10:09:31AM +, Andreas Metzler wrote: The second issue * If you modify cdrecord you need to include additional version * printing code that [...] in cdrecord/cdrecord.c only applies to cdrecord which is completely copyrighted by JS. Therefore he is able to license it as GPL+restrictions and if the restrictions are still DFSG free we are able to ship it as part of Debian/main. Only if the implementation of that license is clear and consistent. I don't believe a work under the GPL with clarifications that don't follow from the GPL in any way is either. If he wants something like the GPL with extra restrictions, he should follow the procedure for modifying the GPL: rename it (the CDRPL), remove the preamble, and actually modify the text of the license. -- Glenn Maynard
status of license for pyMPI
Hi, The pyMPI (http://sourceforge.net/projects/pympi/) license says the following. I think this is non-free under the DFSG, but I would like a confirmation. I think that the non-commercial clause by itself violates point 6, No Discrimination Against Fields of Endeavor, right? But the wording seems a little ambiguous. It does not actually *restrict* use, just requires notification, so I'm not sure. Please CC me, I'm not subscribed. Thanks. Faheem. *** Copyright (C) 2000 University of California Regents This work was produced at the University of California, Lawrence Livermore National Laboratory (UP LLD) under contract no. W-7405-ENG-48 (Contract 48) between the U.S. Department of Energy (DOE) and The Regents of the University of California (University) for the operation of UP LLD. The rights of the Federal Government are reserved under Contract 48 subject to the restrictions agreed upon by the DOE and University as allowed under DOE Acquisition Letter 97-1. DISCLAIMER This work was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately-owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer or otherwise does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes. NOTIFICATION OF COMMERCIAL USE Commercialization of this product is prohibited without notifying the Department of Energy (DOE) or Lawrence Livermore National Laboratory (LYNN).
Re: Suggestions of David Nusinow, was: RPSL and DFSG-compliance - choice of venue
On Aug 25, 2004, at 16:52, Matthew Garrett wrote: You believe that there are some languages that are inherently non-free? I'm still waiting to hear an example of something that patch clauses actually make impossible. I saw, at one point, a book (i.e., an actual dead tree book) which contained annotated source code for the Linux kernel. If the kernel were under a verbatim+patches license, how would you do that? Last I checked, GNU diff didn't have a dead-tree mode.
Re: status of license for pyMPI
On Sep 3, 2004, at 16:26, Faheem Mitha wrote: Hi, The pyMPI (http://sourceforge.net/projects/pympi/) license says the following. I can't find anything in there that grants rights to distribute this software. Without that, it can't even go into non-free. [cc'd as requested to [EMAIL PROTECTED]
Re: cdrecord: weird GPL interpretation
Because fee is an English word meaning a payment for a good or service. It really doesn't mean money only, in any context where precise language is used. If I have to perform in some way to obtain a license, then that's a fee. Do you have a better word, taking brevity and clarity into account? -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: cdrecord: weird GPL interpretation
On Fri, Sep 03, 2004 at 08:16:27PM -0400, Brian Thomas Sniffen wrote: Because fee is an English word meaning a payment for a good or service. It really doesn't mean money only, in any context where precise language is used. If I have to perform in some way to obtain a license, then that's a fee. Do you have a better word, taking brevity and clarity into account? Requirement. -- Raul
Re: cdrecord: weird GPL interpretation
On Fri, Sep 03, 2004 at 08:16:27PM -0400, Brian Thomas Sniffen wrote: Because fee is an English word meaning a payment for a good or service. It really doesn't mean money only, in any context where precise language is used. If I have to perform in some way to obtain a license, then that's a fee. Do you have a better word, taking brevity and clarity into account? Restriction. It includes all fees, and also includes things which are obviously not fees (such as, again, only on Tuesday), and is also directly tied to DFSG#1. I prefer it because contrived-feeling (whether legitimate or not) use of fee may spread the notion that only fees are covered by DFSG#1, and not other restrictions; and lead to more pointless dictionary- lawyering over whether something is a fee or not. -- Glenn Maynard
Re: status of license for pyMPI
On Fri, 3 Sep 2004, Anthony DeRobertis wrote: On Sep 3, 2004, at 16:26, Faheem Mitha wrote: Hi, The pyMPI (http://sourceforge.net/projects/pympi/) license says the following. I can't find anything in there that grants rights to distribute this software. Without that, it can't even go into non-free. [cc'd as requested to [EMAIL PROTECTED] There is also a file called COPYING. It says ** See LICENSE.TXT for copying information. It boils down to freely distributable, but notification of commercial distribution. ** The text quoted earlier is that of LICENSE.TXT in its entirety. Faheem.
Re: cdrecord: weird GPL interpretation
Raul Miller [EMAIL PROTECTED] writes: On Fri, Sep 03, 2004 at 08:16:27PM -0400, Brian Thomas Sniffen wrote: Because fee is an English word meaning a payment for a good or service. It really doesn't mean money only, in any context where precise language is used. If I have to perform in some way to obtain a license, then that's a fee. Do you have a better word, taking brevity and clarity into account? Requirement. That's a much broader word. For example, a license which says I may only make modifications in French has a requirement, but that is not a fee. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: status of license for pyMPI
In any case, a requirement for notification is non-free. Even if it weren't strictly required, that kind of fuzzy undefined use of commercial distribution is a bit worrisome. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: cdrecord: weird GPL interpretation
On Fri, Sep 03, 2004 at 11:00:28PM -0400, Brian Thomas Sniffen wrote: On Fri, Sep 03, 2004 at 08:16:27PM -0400, Brian Thomas Sniffen wrote: Because fee is an English word meaning a payment for a good or service. It really doesn't mean money only, in any context where precise language is used. If I have to perform in some way to obtain a license, then that's a fee. Do you have a better word, taking brevity and clarity into account? Requirement. That's a much broader word. For example, a license which says I may only make modifications in French has a requirement, but that is not a fee. The point was that fee is a narrower word, and its use in this context (explaining rationale) is awkward, and only invites dictionary debates. I believe both requirement and restriction are better choices here (personally preferring restriction for its easy relationship to may not restrict in the DFSG). I don't think having to explain to the world at large in the readme why you did something is a fee or payment. We don't need to agree on this point, though; it's clearly a restriction. What matters is whether the restriction is considered onerous or not; whether it's a fee is irrelevant. -- Glenn Maynard
