Custom license conditions and grant for Wordplay package (was: license compatibility)
debian.mailingli...@melachim.net writes: > What is the work we are discussing? Can we see the full source online > somewhere (to see its entire license grant)? (That was written by me in a previous message, but it's appearing in the material you wrote. I think something is failing in your message quoting set-up, which is likely to make discussion confusing. Would you like help fixing that? Contact me off-list if you need my help there.) > http://deb.debian.org/debian/pool/main/w/wordplay/wordplay_7.22.orig.tar.gz For reference in this thread, the license grant contained there appears to be, in its entirety, this text from the Read Me document: = -- Wordplay Version 7.22 Evans A Criswell 03-20-96 -- This program was written for fun and is free. Distribute it as you please, but please distribute the entire package, with the original words721.txt and the readme file. If you modify the code, please mention my name in it as the original author. Please send me a copy of improvements you make, because I may include them in a future version. I may be contacted by email at crisw...@cs.uah.edu Evans A Criswell Research Associate Computer Science Department University of Alabama in Huntsville Huntsville, AL 35899 -- = I'll comment on that text in a separate message. -- \ “It's easy to play any musical instrument: all you have to do | `\ is touch the right key at the right time and the instrument | _o__)will play itself.” —Johann Sebastian Bach | Ben Finney
Re: license compatibility
What is the work we are discussing? Can we see the full source online somewhere (to see its entire license grant)? http://deb.debian.org/debian/pool/main/w/wordplay/wordplay_7.22.orig.tar.gz Sincerely, Moshe Piekarski -- There's no such thing as a stupid question, But there are plenty of inquisitive idiots.
Re: license compatibility
Moshe Piekarski writes: > Can I re-release code written under this license as gpl-2? What is the work we are discussing? Can we see the full source online somewhere (to see its entire license grant)? -- \ “Of all classes the rich are the most noticed and the least | `\ studied.” —John Kenneth Galbraith, _The Age of Uncertainty_, | _o__) 1977 | Ben Finney
license compatibility
> This program was written for fun and is free. Distribute it as you please, >but please distribute the entire package, with the original words721.txt and > the readme file. If you modify the code, please mention my name in it as > the original author. Please send me a copy of improvements you make, because >I may include them in a future version. Can I re-release code written under this license as gpl-2? Sincerely, Moshe Piekarski -- There's no such thing as a stupid question, But there are plenty of inquisitive idiots. signature.asc Description: OpenPGP digital signature
Re: Seeking advice about PSICOV license compatibility with GPL-2
On Tue, 30 Oct 2012 19:31:22 +0100 Laszlo Kajan wrote: [...] Dear Team members! Hello Laszlo, I am a debian-legal regular and what follows is my own personal opinion on the issue (from the licensing point of view). The usual disclaimers apply (IANAL, TINLA, ...). PSICOV [1], a protein contact prediction tool, is built with a patched version of the GPL-2 Fortran source glasso [2]: gfortran -O3 psicov.c glasso_psicov.f90 -lm -lgsl -lgslcblas -o psicov This seems to create an executable binary of PSICOV, statically linked with the modified version of glasso, and dynamically linked with the GNU Scientific Library. The license of PSICOV does not seem free to me [3], with restrictions on commercial use [...] The license of PSICOV indeed seems to include a number of definitely non-free restrictions and really appears to be GPL-v2-incompatible and GPL-v3-incompatible. At the same time, glasso seems to be released under the terms of the GNU GPL v2 (only v2, I would say, since I didn't spot any or later version permission in the somewhat unclear glasso_1.7.tar.gz source archive). The GNU GSL is released under the terms of the GNU GPL v3 or later (http://packages.debian.org/changelogs/pool/main/g/gsl/current/copyright). This makes for a very odd mutually-incompatible license mix: the GNU GPL v3 is incompatible with the GNU GPL v2, and the PSICOV license is incompatible with both. If I understand GPL well, this simply is not allowed: PSICOV is not allowed to restrict what is granted by glasso's license (and that does not limit any of the above). The question is: * Do I see it correctly that PSICOV's license violates the GPL-2 terms of glasso? I think that the PSICOV binary (built as described above) is legally undistributable: its distribution appears to violate the copyright of glasso and of the GNU Scientific Library. The possible solutions I can think of are (in order of descending desirability): (A) contact the PSICOV copyright holder(s) and persuade them to re-license PSICOV under GPL-compatible terms (for instance under the terms of the GNU GPL v2 or later); at the same time contact the GNU Scientific Library copyright holder(s) and persuade them to re-license GSL under the terms of the GNU GPL *v2* or later (rather than GPL v3 or later) (B) contact the PSICOV copyright holder(s) and persuade them to re-license PSICOV under GPL-compatible terms (for instance under the terms of the GNU GPL v2 or later); at the same time contact the glasso copyright holder(s) and persuade them to re-license glasso under the terms of the GNU GPL v2 *or later* (rather than GPL v2 only) (C) refrain completely from distributing PSICOV Please note that solution (A) is unlikely, since the GNU Scientific Library, as part of the GNU Project, is supposed to promote the GNU GPL v3 (due to the FSF propaganda). Maybe solution (B) has more chances to be achievable... I hope that my own personal take on this matter helps a bit. Bye and good luck. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp3XuWL0Huhf.pgp Description: PGP signature
Re: Seeking advice about PSICOV license compatibility with GPL-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thank you very much Francesco! I would like to implement a free alternative to PSICOV, therefore I have contacted the authors of glasso and asked them to consider changing the license to GPL-2+ (2 or later), as you recommended. Best regards, Laszlo On 01/11/12 13:09, Francesco Poli wrote: On Tue, 30 Oct 2012 19:31:22 +0100 Laszlo Kajan wrote: [...] Dear Team members! Hello Laszlo, I am a debian-legal regular and what follows is my own personal opinion on the issue (from the licensing point of view). The usual disclaimers apply (IANAL, TINLA, ...). PSICOV [1], a protein contact prediction tool, is built with a patched version of the GPL-2 Fortran source glasso [2]: gfortran -O3 psicov.c glasso_psicov.f90 -lm -lgsl -lgslcblas -o psicov This seems to create an executable binary of PSICOV, statically linked with the modified version of glasso, and dynamically linked with the GNU Scientific Library. The license of PSICOV does not seem free to me [3], with restrictions on commercial use [...] The license of PSICOV indeed seems to include a number of definitely non-free restrictions and really appears to be GPL-v2-incompatible and GPL-v3-incompatible. At the same time, glasso seems to be released under the terms of the GNU GPL v2 (only v2, I would say, since I didn't spot any or later version permission in the somewhat unclear glasso_1.7.tar.gz source archive). The GNU GSL is released under the terms of the GNU GPL v3 or later (http://packages.debian.org/changelogs/pool/main/g/gsl/current/copyright). This makes for a very odd mutually-incompatible license mix: the GNU GPL v3 is incompatible with the GNU GPL v2, and the PSICOV license is incompatible with both. If I understand GPL well, this simply is not allowed: PSICOV is not allowed to restrict what is granted by glasso's license (and that does not limit any of the above). The question is: * Do I see it correctly that PSICOV's license violates the GPL-2 terms of glasso? I think that the PSICOV binary (built as described above) is legally undistributable: its distribution appears to violate the copyright of glasso and of the GNU Scientific Library. The possible solutions I can think of are (in order of descending desirability): (A) contact the PSICOV copyright holder(s) and persuade them to re-license PSICOV under GPL-compatible terms (for instance under the terms of the GNU GPL v2 or later); at the same time contact the GNU Scientific Library copyright holder(s) and persuade them to re-license GSL under the terms of the GNU GPL *v2* or later (rather than GPL v3 or later) (B) contact the PSICOV copyright holder(s) and persuade them to re-license PSICOV under GPL-compatible terms (for instance under the terms of the GNU GPL v2 or later); at the same time contact the glasso copyright holder(s) and persuade them to re-license glasso under the terms of the GNU GPL v2 *or later* (rather than GPL v2 only) (C) refrain completely from distributing PSICOV Please note that solution (A) is unlikely, since the GNU Scientific Library, as part of the GNU Project, is supposed to promote the GNU GPL v3 (due to the FSF propaganda). Maybe solution (B) has more chances to be achievable... I hope that my own personal take on this matter helps a bit. Bye and good luck. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQkquBAAoJEJvS1kCaDFL6I4sQAMypVuqLTqZk82UxOX9LN2i8 lX6GDcbynz28zSymczF7kSSo/m02K6D0fgxKB8Le3PQKdFKB0saqbidjpCxPzShE pHEjHTlrcDbwRnt3cFfFq52PjSDRDKq9xfuGFMCsglPCJwOFKgz3/kzJFxIxB/tu +PuXfAR/PLeDKJvvrqklATMASdwcSFIwpIeI7a8v8IqR7rX54OVNSguWljf9Qtoy FEsAccflPk9ImTpnsL0cPkT/dCSuTP/df0nu7h5sP0NBO4BJB2jRhKdGr2MbQT/T To1aokgru2XXc03JFM0evrp5NlnNYi+SoGeUmmUKJK7TQgRyNRPZHkmzsFdAJLSh nFwe9x1Tt6H2B9oAIzTBhhsTRZEo5PyjGz0afjeV/F8khXHtH5fdlpLycKu1oTvp ti52CS/5c0N9RM6VoslVvriuI8upy/JAIkD0UCdAJo7iLYLVf171nxb5lL2EXRff SVk03sa16A/86BAXAeRxqKFtuA7vrZcuKjTtEMkiFBDFczxYxIccn8r5BeXeUpUD wqAWyx2RXELaB3rS7Cod/uTpdCIGVPGK6LKiWPgnvzAYNq901DB7a47BjD4O69p9 T2uz81v0FhsBKvg7u8JW2hLXSOw9ZL1FeZIz7QSqxYFAosAKj2NF3/QMA7ExNWlw A4BXM6V5vo6YmB2l0gL9 =xY5d -END PGP SIGNATURE- -- 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/5092ab81.4040...@rostlab.org
Seeking advice about PSICOV license compatibility with GPL-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Team members! PSICOV [1], a protein contact prediction tool, is built with a patched version of the GPL-2 Fortran source glasso [2]: gfortran -O3 psicov.c glasso_psicov.f90 -lm -lgsl -lgslcblas -o psicov The license of PSICOV does not seem free to me [3], with restrictions on commercial use, e.g.: The Software may not be sold as a standalone package, or incorporated into a commercial software package without the written permission of the Copyright holder. ... The results produced by the Software may not be incorporated into any data banks or databases which are subject to the payment of access or license fees without the written permission of the Copyright holder. ... Incorporation of the Software into a commercial Web site or other fee paying service is not allowed without the written permission of the Copyright holder. If I understand GPL well, this simply is not allowed: PSICOV is not allowed to restrict what is granted by glasso's license (and that does not limit any of the above). The question is: * Do I see it correctly that PSICOV's license violates the GPL-2 terms of glasso? Thank you very much for your opinion in advance. Best regards, Laszlo [1] http://bioinfadmin.cs.ucl.ac.uk/downloads/PSICOV/ [2] http://cran.r-project.org/web/packages/glasso/index.html [3] http://bioinfadmin.cs.ucl.ac.uk/downloads/PSICOV/LICENSE -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQkBz6AAoJEJvS1kCaDFL6Ec0P/RhPFqhgYbb16fp4tHNZ5Fqx gSUxkTiWhjKXW1hMTi0NPpq5hqKeThhXvyBkPY8LmxqjfKpobTRCzcOQN5uHVUEN Gv0y+4rBs4noLMuauw52VoYMK66vxxs6H/I/0AG9eYvrnkBL0AKuvzXU8/fItk5G FsrQ9RR+32evKR+91lw6f/evSKmW3x5kJCPAPXxcP4f3H5K2QsA0/LriGvW6LwOi V4fdbTghipp83Fn9OVreppl/RJSG6Ipy76KCvQarLw91UfkXnBYUVjfEJN8Y27qO IV1GbajFt4R2gKTXuWOd20qJsL14h5F4ff16iVcoa1c8s1NqxBLAQSsr0kwvapjk JSVBCh0o1JVG0frq5SWQaBfXCXMk0BDYhqYeGSV96Ld40/BlOvhLB6pXyEtfADNn dMXTGjCA2VTnL60CsEfUXOAQN98/upFiyr6W1kOqIc/zgPy8Wvqf/w0z73LA0AJT pBom8qvuuN15rGdvcB9LXJ7q/RsYqQkl1E+K0wAvVZmRy501dMr/2t7cYsSZNs8b GG0eZXi3xxcY9XKcSVvKlYpOY9Mdz+8VsAfO0sXedZDLl9+T8c13AzXE86x/DwgX eI4xlzGnQxi405qNU5sBfxpJSVOe+S4FL6nMCFB/WMaMKR50ZL996HU/beX7cclj yPsmx2P89qGhwj5l49xc =FkE4 -END PGP SIGNATURE- -- 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/50901cfa.5020...@rostlab.org
IBM Public license compatibility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm currently looking into packaging a module for OpenDx. OpenDx is distributed under the IBM public license 1.0. The addon module for OpenDx currently doesn't have any specific license terms associated with it, however I've talked to the upstream author who said: b) If you could clarify what license terms it is distributed under? I've never thought about the license. I'd like GPL version 2, but I'm not sure if an external module with this license can be dynamically linked with OpenDx, that has, if I remember correctly, a GPL-incompatible license. What do you think? Anyway, I'm pretty sure it's not compatible with GPL, so does anyone have any suggestions for a similar suitable alternative that would be compatible with the IBM public license? Thanks, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIBx4X1FNW1LDdr0IRAracAJ9zAtu4uOcG76kpV3OvcTjtmJMScwCgk0ny 4nInwH4Xcd69mCN5pG7wtpo= =N8UV -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: IBM Public license compatibility
Alan Woodland [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm currently looking into packaging a module for OpenDx. OpenDx is distributed under the IBM public license 1.0. The addon module for OpenDx currently doesn't have any specific license terms associated with it, however I've talked to the upstream author who said: b) If you could clarify what license terms it is distributed under? I've never thought about the license. I'd like GPL version 2, but I'm not sure if an external module with this license can be dynamically linked with OpenDx, that has, if I remember correctly, a GPL-incompatible license. What do you think? Anyway, I'm pretty sure it's not compatible with GPL, so does anyone have any suggestions for a similar suitable alternative that would be compatible with the IBM public license? Well, if the module is not considered a derived work of OpenDx, then the GPL with aspecial linking exception would work just fine. Otherwise the code must be distributed under a an IBM public licence compatible licence, with the combined work as a whole being shipped under the IBM public licence. Of course, dual licencing the the code under the users choice of the IBM Public Licence and the GPL is also a reasonable idea if copyleft and GPL-compatibility is desired. (Both licences are copyleft. The IBM one lets extra terms be imposed or offered on the licence of an object code form of the program, but it still requires the corresponding source code to be available to users under itself.) DISCLAIMERS: IANAL. IANADD. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
License compatibility with GPLv3
Hi, I have some small problem with Gnash that might be extensible to other packages, so I'm asking here to find out if anyone else has had that problem too and how did they manage it. Gnash is GNU's free Flash player. It is now licensed under GPLv3 (it was previously GPLv2 or above). It has a really huge list of build dependencies: dpkg-dev (= 1.13.19), debhelper (= 4.0.0), quilt, autoconf, dh-buildinfo, automake1.9 | automake, libtool, libltdl3-dev, help2man, libxmu-dev, dejagnu, autotools-dev, libboost-dev, libboost-thread-dev, libxml2-dev, libjpeg-dev, libpng12-dev | libpng-dev, libagg-dev, libgstreamer0.10-dev, libkonq4-dev, libpango1.0-dev | pango-devel, libgtkglext1-dev, libmad0-dev, libdirectfb-dev, libcurl4-gnutls-dev | libcurl3-gnutls-dev | libcurl4-openssl-dev | libcurl3-openssl-dev, libcaca-dev, libboost-date-time-dev, libavcodec-dev, libavformat-dev, libming-dev, libming-util, mtasc, libgstreamer-plugins-base0.10-dev, libboost-serialization-dev, python, base-files (= 4.0.1) All these dependencies already have their own list of dependencies too, right now I'm concerned about libkonq4-dev and Qt being GPLv2 only. Even though all of these packages might be GPLv3 compatible, it is not guaranteed that their dependencies are, like: Package A (GPLv3) depends on package B (GPLv2 or above) Package B (GPLv2 or above) depends on package C (GPLv2 only) Both dependencies would be OK on their own, but I'd be effectively linking A (GPLv3) with C (GPLv2 only) which are not compatible. As you can imagine, the work of checking all the dependencies by hand would be enormous. I could check the dependencies of the resulting binary packages instead, but I'm not sure if that would be enough (or I should check their dependencies too), would it be? Any ideas? Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License compatibility with GPLv3
Hi Miriam, On 2008-01-24 13:49 +0100, Miriam Ruiz wrote: I have some small problem with Gnash that might be extensible to other packages, so I'm asking here to find out if anyone else has had that problem too and how did they manage it. Gnash is GNU's free Flash player. It is now licensed under GPLv3 (it was previously GPLv2 or above). It has a really huge list of build dependencies: dpkg-dev (= 1.13.19), debhelper (= 4.0.0), quilt, autoconf, dh-buildinfo, automake1.9 | automake, libtool, libltdl3-dev, help2man, libxmu-dev, dejagnu, autotools-dev, libboost-dev, libboost-thread-dev, libxml2-dev, libjpeg-dev, libpng12-dev | libpng-dev, libagg-dev, libgstreamer0.10-dev, libkonq4-dev, libpango1.0-dev | pango-devel, libgtkglext1-dev, libmad0-dev, libdirectfb-dev, libcurl4-gnutls-dev | libcurl3-gnutls-dev | libcurl4-openssl-dev | libcurl3-openssl-dev, libcaca-dev, libboost-date-time-dev, libavcodec-dev, libavformat-dev, libming-dev, libming-util, mtasc, libgstreamer-plugins-base0.10-dev, libboost-serialization-dev, python, base-files (= 4.0.1) All these dependencies already have their own list of dependencies too, right now I'm concerned about libkonq4-dev and Qt being GPLv2 only. Even though all of these packages might be GPLv3 compatible, it is not guaranteed that their dependencies are, like: Package A (GPLv3) depends on package B (GPLv2 or above) Package B (GPLv2 or above) depends on package C (GPLv2 only) Both dependencies would be OK on their own, but I'd be effectively linking A (GPLv3) with C (GPLv2 only) which are not compatible. You will be interested that Trolltech has released Qt 3.3.8 under GPL 3: http://trolltech.com/company/newsroom/announcements/press.2008-01-18.5377846280/pressrelease_view Cheers, Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License compatibility with GPLv3
2008/1/24, Sven Joachim [EMAIL PROTECTED]: Hi Miriam, You will be interested that Trolltech has released Qt 3.3.8 under GPL 3: Thanks, it really solves a great part of the problem, but I have no idea on how to check that there are no other GPLv2 only libraries directly or indirectly linked, apart from spending hours checking manually. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License compatibility with GPLv3
Miriam Ruiz [EMAIL PROTECTED] writes: I have no idea on how to check that there are no other GPLv2 only libraries directly or indirectly linked, apart from spending hours checking manually. This seems like an ideal case to promote the proposed format URL:http://wiki.debian.org/Proposals/CopyrightFormat for machine-parseable 'debian/copyright' files. In the absence of that, it does seem the only way to know is to manually parse the 'debian/copyright' files until you've investigated all dependencies that would count as derived work. -- \ If you define cowardice as running away at the first sign of | `\ danger, screaming and tripping and begging for mercy, then yes, | _o__)Mr. Brave man, I guess I'm a coward. -- Jack Handey | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about license compatibility
[EMAIL PROTECTED] wrote: Hope to have answered to your question. I am sorry but I did not succeed in asking Berkeley's Regents for a license change. Didn't they issue a blanket license change for _all_ code owned by them under the old bsd license? Yes. But the original spice code was not under the old BSD license. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about license compatibility
Hope to have answered to your question. I am sorry but I did not succeedin asking Berkeley's Regents for a license change. Didn't they issue a blanket license change for _all_ code owned by them under the old bsd license?
Re: Question about license compatibility
On Sun, Aug 28, 2005 at 02:26:16AM +0300, Gerasimos Melissaratos wrote: Below I include the answer I got from Mr Nenzi about the ngspice licencing. In short, I asked him about the possibility of a re-release of ngspice with the new BSD license or something else compatible with Debian. The short answer is no. Doesn't the message cited below indicate that ngspice is available under 4-clause BSD? Who ever said that the old BSD license wasn't allowed in Debian? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ --- Date: Mon, 08 Aug 2005 21:39:52 +0200 Download Re: ngspice licencing.msg From: Paolo Nenzi [EMAIL PROTECTED] Import addresses [EMAIL PROTECTED] Block email [EMAIL PROTECTED] Block SMTP Relay relay-pt4.poste.it Reply-to: [EMAIL PROTECTED] To: Gerasimos Melissaratos [EMAIL PROTECTED] Subject: Re: ngspice licencingAll headers Dear Gerasimos, Sorry for this delay in answering but I am on holidays and have some spare time to scan the messages on ngspice lists. The licensing of ngspice is quite intricated but, AFAIK ngspice cannot be packaged for official-debian. You can consider ngspice covered by the old BSD license (the one with the obnoxiuous clause). Look at the Xspice license, since ngspice includes xspice, then its license applies too. Hope to have answered to your question. I am sorry but I did not succeed in asking Berkeley's Regents for a license change. Ciao, Paolo --- On Fri, 22 Jul 2005 00:03:56 -0700, Sean Kellogg wrote On Thursday 21 July 2005 04:49 pm, Gerasimos Melissaratos wrote: I'd like to create a package for ng-spice, which seems to be governed by two licenses, which I include herein. In first reading I cannot see any real discrepancies, but of course IANAL. Pls tell me if any of them is compatible with DFSG. I'm surprised no one has responded to this yet... so I guess I'll get the ball rolling. Its my opinion that both licenses are non-free, for reasonably well established and non-controversial reasons. License 1 contains a limitation on use (educational, research and non- profit purposes, without fee) which is a violation of DFSG #6. License 2 is less obvious, but I personally believe that a provision that forbids charging a fee for distribution is non-free, or at least bad policy. Certainly having a package that prohibits charging for distribution would prevent it from being on a Debian CD sold by one of the vendors. Based on the DFSG I'd have to point to #1 and #6... but both are kind of stretches. Anyone else have thoughts? -- Sean Kellogg 3rd Year - University of Washington School of Law Graduate Professional Student Senate Treasurer UW Service Activities Committee Interim Chair w: http://probonogeek.blogspot.com So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown -- Gerasimos Melissaratos ([EMAIL PROTECTED]) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Question about license compatibility
Below I include the answer I got from Mr Nenzi about the ngspice licencing. In short, I asked him about the possibility of a re-release of ngspice with the new BSD license or something else compatible with Debian. The short answer is no. In the face of that, would it be possible to include a package of ngspice in the non-free tree? I mean, it *is* a unique package and having the geda suit without it does seem a bit strange... --- Date: Mon, 08 Aug 2005 21:39:52 +0200 Download Re: ngspice licencing.msg From: Paolo Nenzi [EMAIL PROTECTED] Import addresses [EMAIL PROTECTED] Block email [EMAIL PROTECTED] Block SMTP Relay relay-pt4.poste.it Reply-to: [EMAIL PROTECTED] To: Gerasimos Melissaratos [EMAIL PROTECTED] Subject: Re: ngspice licencing All headers Dear Gerasimos, Sorry for this delay in answering but I am on holidays and have some spare time to scan the messages on ngspice lists. The licensing of ngspice is quite intricated but, AFAIK ngspice cannot be packaged for official-debian. You can consider ngspice covered by the old BSD license (the one with the obnoxiuous clause). Look at the Xspice license, since ngspice includes xspice, then its license applies too. Hope to have answered to your question. I am sorry but I did not succeed in asking Berkeley's Regents for a license change. Ciao, Paolo --- On Fri, 22 Jul 2005 00:03:56 -0700, Sean Kellogg wrote On Thursday 21 July 2005 04:49 pm, Gerasimos Melissaratos wrote: I'd like to create a package for ng-spice, which seems to be governed by two licenses, which I include herein. In first reading I cannot see any real discrepancies, but of course IANAL. Pls tell me if any of them is compatible with DFSG. I'm surprised no one has responded to this yet... so I guess I'll get the ball rolling. Its my opinion that both licenses are non-free, for reasonably well established and non-controversial reasons. License 1 contains a limitation on use (educational, research and non- profit purposes, without fee) which is a violation of DFSG #6. License 2 is less obvious, but I personally believe that a provision that forbids charging a fee for distribution is non-free, or at least bad policy. Certainly having a package that prohibits charging for distribution would prevent it from being on a Debian CD sold by one of the vendors. Based on the DFSG I'd have to point to #1 and #6... but both are kind of stretches. Anyone else have thoughts? -- Sean Kellogg 3rd Year - University of Washington School of Law Graduate Professional Student Senate Treasurer UW Service Activities Committee Interim Chair w: http://probonogeek.blogspot.com So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown -- Gerasimos Melissaratos ([EMAIL PROTECTED]) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about license compatibility
On Saturday 23 July 2005 04:41 pm, Francesco Poli wrote: On Fri, 22 Jul 2005 00:03:56 -0700 Sean Kellogg wrote: Anyone else have thoughts? Yes, I have one: |3. The licensee agrees to obey all U.S. Government res- trictions |governing redistribution or export of the software and |documentation. That sounds non-free. Suppose I'm *not* a U.S. citizen[1]: why should I be bound to obey U.S. Government restrictions? [1] as I was born in Italy, *live* in Italy, and am an Italian citizen, this is actually the case! ;-) This is a difficult situation that is worth commentary. Assume for a moment that the U.S. has some strict export restriction. As a U.S. citizen I am bound by those laws and cannot legally violate them. Further, if I am to distribute software it is entirely possible that the law prohibits me from distributing that software to citizens of certain nations and to ensure those who receive copies do the same. I don't think the law can really require that I ensure the behavior of those I distribute copies to; after all, it's a completely impossible requirement! I was always under the impression that I was simply not allowed to export them *myself*, or *encourage* others to do so. If the law imposes a positive requirement that I police the behavior of anyone I distribute the software to, that's pretty evil. I sure hope it doesn't do that. This means I have have a responsibility to ensure others don't distribute and cause me to break the law. The only tool by which I have to do that is the license. Not that that would work. If ensure were really the requirement, surely a clause in the license would be not nearly enough; you would presumably be expected to keep track of everyone you distributed it to, monitor their behavior, etc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about license compatibility
On Sat, 2005-07-23 at 21:46 -0700, Sean Kellogg wrote: On Saturday 23 July 2005 08:04 pm, Jeff Licquia wrote: On Sat, 2005-07-23 at 17:11 -0700, Sean Kellogg wrote: This is a difficult situation that is worth commentary. Assume for a moment that the U.S. has some strict export restriction. As a U.S. citizen I am bound by those laws and cannot legally violate them. Further, if I am to distribute software it is entirely possible that the law prohibits me from distributing that software to citizens of certain nations and to ensure those who receive copies do the same. This means I have have a responsibility to ensure others don't distribute and cause me to break the law. The only tool by which I have to do that is the license. Is this really true? Sorry if I didn't make it clear that I am very much talking about hypothetical. Thanks for the clarification. My interest, I guess, is whether the DFSG will forbid a developer from having their code distributed if they live in a country with restrictive export laws? The old crypto export regulations in the US did have the effect of prohibiting Debian developers in the US from doing any work on crypto in Debian. See also the MIT Kerberos bones project, from which Heimdal Kerberos sprung. So, it would seem, the answer to your question is yes. On the other hand, in the US, there's a sense in which sharing source code has freedom of speech implications (see Bernstein v. DOJ and the various projects to print crypto code on T-shirts). This limits the extent to which the government can use export regulations to forbid citizens from participation in free software activities, assuming the linkage is upheld. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about license compatibility
On Fri, 22 Jul 2005 00:03:56 -0700 Sean Kellogg wrote: Anyone else have thoughts? Yes, I have one: |3. The licensee agrees to obey all U.S. Government res- trictions |governing redistribution or export of the software and |documentation. That sounds non-free. Suppose I'm *not* a U.S. citizen[1]: why should I be bound to obey U.S. Government restrictions? [1] as I was born in Italy, *live* in Italy, and am an Italian citizen, this is actually the case! ;-) -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgppH5eawcWpj.pgp Description: PGP signature
Re: Question about license compatibility
On Saturday 23 July 2005 04:41 pm, Francesco Poli wrote: On Fri, 22 Jul 2005 00:03:56 -0700 Sean Kellogg wrote: Anyone else have thoughts? Yes, I have one: |3. The licensee agrees to obey all U.S. Government res- trictions |governing redistribution or export of the software and |documentation. That sounds non-free. Suppose I'm *not* a U.S. citizen[1]: why should I be bound to obey U.S. Government restrictions? [1] as I was born in Italy, *live* in Italy, and am an Italian citizen, this is actually the case! ;-) This is a difficult situation that is worth commentary. Assume for a moment that the U.S. has some strict export restriction. As a U.S. citizen I am bound by those laws and cannot legally violate them. Further, if I am to distribute software it is entirely possible that the law prohibits me from distributing that software to citizens of certain nations and to ensure those who receive copies do the same. This means I have have a responsibility to ensure others don't distribute and cause me to break the law. The only tool by which I have to do that is the license. Is it Debian's stance that I cannot do so? Can the United State's Government bar me from contributing to Debian by imposing export restrictions? I wasn't on d-l at the time, but wasn't this the point of non-US. Whatever happened to that? -Sean -- Sean Kellogg 3rd Year - University of Washington School of Law Graduate Professional Student Senate Treasurer UW Service Activities Committee Interim Chair w: http://probonogeek.blogspot.com So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown
Re: Question about license compatibility
On Sat, 2005-07-23 at 17:11 -0700, Sean Kellogg wrote: This is a difficult situation that is worth commentary. Assume for a moment that the U.S. has some strict export restriction. As a U.S. citizen I am bound by those laws and cannot legally violate them. Further, if I am to distribute software it is entirely possible that the law prohibits me from distributing that software to citizens of certain nations and to ensure those who receive copies do the same. This means I have have a responsibility to ensure others don't distribute and cause me to break the law. The only tool by which I have to do that is the license. Is this really true? It is entirely possible that the law forbids our project's current work habits, especially when said work habits involve interaction with the people responsible for enforcing this law. (And didn't those same people cite us as a model for others to follow in regards to compliance?) I suppose, though, that it would be good to find out for sure. When all this came down, it is my recollection that the regulations treated freely available software differently from proprietary software, with fewer regulations placed upon it. Could you perhaps have overlooked this distinction? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about license compatibility
On Saturday 23 July 2005 08:04 pm, Jeff Licquia wrote: On Sat, 2005-07-23 at 17:11 -0700, Sean Kellogg wrote: This is a difficult situation that is worth commentary. Assume for a moment that the U.S. has some strict export restriction. As a U.S. citizen I am bound by those laws and cannot legally violate them. Further, if I am to distribute software it is entirely possible that the law prohibits me from distributing that software to citizens of certain nations and to ensure those who receive copies do the same. This means I have have a responsibility to ensure others don't distribute and cause me to break the law. The only tool by which I have to do that is the license. Is this really true? Sorry if I didn't make it clear that I am very much talking about hypothetical. I know that with embargoes American citizens have certain responsibilities to ensure the goods the ship internationally do not end up in the hands of certain nations. I can't say this applies to software, or if such an embargo is even going on (outside of our long standing Cuban embargo). My interest, I guess, is whether the DFSG will forbid a developer from having their code distributed if they live in a country with restrictive export laws? -Sean -- Sean Kellogg 3rd Year - University of Washington School of Law Graduate Professional Student Senate Treasurer UW Service Activities Committee Interim Chair w: http://probonogeek.blogspot.com So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown
Re: Question about license compatibility
On Thursday 21 July 2005 04:49 pm, Gerasimos Melissaratos wrote: X-Hellenic Ministry of Foreign Affairs-MailScanner: Found to be clean X-MailScanner-From: [EMAIL PROTECTED] I'd like to create a package for ng-spice, which seems to be governed by two licenses, which I include herein. In first reading I cannot see any real discrepancies, but of course IANAL. Pls tell me if any of them is compatible with DFSG. I'm surprised no one has responded to this yet... so I guess I'll get the ball rolling. Its my opinion that both licenses are non-free, for reasonably well established and non-controversial reasons. License 1 contains a limitation on use (educational, research and non-profit purposes, without fee) which is a violation of DFSG #6. License 2 is less obvious, but I personally believe that a provision that forbids charging a fee for distribution is non-free, or at least bad policy. Certainly having a package that prohibits charging for distribution would prevent it from being on a Debian CD sold by one of the vendors. Based on the DFSG I'd have to point to #1 and #6... but both are kind of stretches. Anyone else have thoughts? -- Sean Kellogg 3rd Year - University of Washington School of Law Graduate Professional Student Senate Treasurer UW Service Activities Committee Interim Chair w: http://probonogeek.blogspot.com So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown
Re: Question about license compatibility
Sean Kellogg [EMAIL PROTECTED] wrote: License 1 contains a limitation on use (educational, research and non-profit purposes, without fee) which is a violation of DFSG #6. License 2 is less obvious, but I personally believe that a provision that forbids charging a fee for distribution is non-free, or at least bad policy. Certainly having a package that prohibits charging for distribution would prevent it from being on a Debian CD sold by one of the vendors. Based on the DFSG I'd have to point to #1 and #6... but both are kind of stretches. That aspect of license 2 isn't a problem - the DFSG don't require that people be able to charge for an item of software, merely the aggregate work. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about license compatibility
On Friday 22 July 2005 03:28 am, Matthew Garrett wrote: Sean Kellogg [EMAIL PROTECTED] wrote: License 1 contains a limitation on use (educational, research and non-profit purposes, without fee) which is a violation of DFSG #6. License 2 is less obvious, but I personally believe that a provision that forbids charging a fee for distribution is non-free, or at least bad policy. Certainly having a package that prohibits charging for distribution would prevent it from being on a Debian CD sold by one of the vendors. Based on the DFSG I'd have to point to #1 and #6... but both are kind of stretches. That aspect of license 2 isn't a problem - the DFSG don't require that people be able to charge for an item of software, merely the aggregate work. Why is that the case? The license says: The licensee agrees not to charge for the University of California code itself. The licensee may, however, charge for additions, extensions, or support. If the license said You cannot charge for this code, nor can you charge for it in agregate with other applications outside of this license I might suggest the second part is simply unenforcable. But even if it were enforcable, how does selling code in agregate with other code not fall within the bar against charging for the code itself? The CD has value because of the code, I am charging for the CD, part of why customers are willing to pay for the CD is the value of the code... strikes me as I am, agregate or not, charging for the code. Additionally, how is this not a discrimination on use prohibited under DFSG #6? One of the uses of software is to package, modify, and resell. If I cannot do that because of the license, isn't that a use descrimination? -Sean -- Sean Kellogg 3rd Year - University of Washington School of Law Graduate Professional Student Senate Treasurer UW Service Activities Committee Interim Chair w: http://probonogeek.blogspot.com So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown
Re: Question about license compatibility
In message [EMAIL PROTECTED], Sean Kellogg [EMAIL PROTECTED] writes On Friday 22 July 2005 03:28 am, Matthew Garrett wrote: Sean Kellogg [EMAIL PROTECTED] wrote: License 1 contains a limitation on use (educational, research and non-profit purposes, without fee) which is a violation of DFSG #6. License 2 is less obvious, but I personally believe that a provision that forbids charging a fee for distribution is non-free, or at least bad policy. Certainly having a package that prohibits charging for distribution would prevent it from being on a Debian CD sold by one of the vendors. Based on the DFSG I'd have to point to #1 and #6... but both are kind of stretches. That aspect of license 2 isn't a problem - the DFSG don't require that people be able to charge for an item of software, merely the aggregate work. Why is that the case? The license says: The licensee agrees not to charge for the University of California code itself. The licensee may, however, charge for additions, extensions, or support. Actually, doesn't the GPL itself contain exactly the same restriction, just worded a bit differently? The GPL forbids charging for the code itself. It DOES permit charging (as much as you can get away with) for the effort of packaging it. I'd class packaging as support, therefore it could be included on a Debian CD because you're not charging for the code. Cheers, Wol -- Anthony W. Youngman - wol at thewolery dot demon dot co dot uk HEX wondered how much he should tell the Wizards. He felt it would not be a good idea to burden them with too much input. Hex always thought of his reports as Lies-to-People. The Science of Discworld : (c) Terry Pratchett 1999 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about license compatibility
* Anthony W. Youngman: Actually, doesn't the GPL itself contain exactly the same restriction, just worded a bit differently? The GPL forbids charging for the code itself. Only for the source code which you must make available when you distribute binaries, you may not charge for anything but your actual costs to create and ship the copy. You can charge what you want for plain source code, binaries, or a combination of source code and binaries on the same distribution medium. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trademark license compatibility with GPL and/or DFSG
On Mon, 23 May 2005, Nathanael Nerode wrote: They want their trademarks stripped from modified code that is essentially different in intent and purpose from the original code. Well, that's fine; we don't want to use their trademarks for things which aren't designed to work with their hardware, now do we? (At least, except in a historical context, which certainly wouldn't be a trademark violation.) What does trademarks stripped mean though? Does it mean they want the product not to be called trademark? Or do they want every single line of code that has the name in it removed, so, for instance, a help box or even code comments that say Based on the driver for trademark must be removed? And what if the trademark is used in a different context; would that be like the Apache license that prohibits you from using it in a program called Apache Helicpoter Simulation? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trademark license compatibility with GPL and/or DFSG
[EMAIL PROTECTED] wrote: On the other hand, any trademark license would permit us to use their trademark, which we could not do otherwise. This is a misunderstanding of trademark. It is always legal to describe the driver as being a driver by author intended for use with trademark, because that can't cause confusion about the origin of the driver. You should do this. I think that naming the driver after the trademark might indeed be a trademark violation, because it might theoretically cause confusion about the origin of the driver. Now, Linux drivers often have nonobvious names which don't match the hardware's commercial name. So I think you should go ahead and name the driver with some non-trademarked name, and just describe it as intended for use with trademark everywhere it's mentioned. If it was a debian package, you would unfortunately really want to have the trademark in the package name so that users could find the package using the standrd search facilities in dselect. However, that doesn't seem to be the issue right now, so I won't try to work out a solution for that right now. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trademark license compatibility with GPL and/or DFSG
[EMAIL PROTECTED] wrote: The company in question is willing to negotiate terms for a trademark license that is agreeable to all parties. Obviously any advertising or guarantee restrictions are unacceptable to us. Well, no; some such restrictions are acceptable. We accept the required NO WARRANTY clauses in lots of licenses. I think that a restriction which required that we note that *they* aren't guaranteeing it would be fine. Unlimited use of the trademark is unacceptable to them. Well, first of all we don't want or need that. We can use the trademark in most of the ways we want to without hitting any trademark restrictions. I don't have the case reference here, but there was a case involving TSR and products labelled Compatible with Dungeons and Dragons, and it was ruled that that was *not* a trademark violation (although TSR kept threatening people who did it with lawsuits for years anyway). Basically, we can't legally use a trademark (without a license) in ways which may cause confusion about the origin of the product; we can use it in all other ways and be on safe legal ground under current law. Putting the trademark in the name of the driver might lead people to think that the driver was from the company which owns the trademark, so that would require a license. How about this license: Anyone may use the trademark trademark as part of the name of a product designed to work with the hardware; provided that the product using the trademark in its name, and any advertising for it using the trademark, prominently mentions that the product is not produced by or supported by the makers of the hardware. Using the trademark in the name is the only thing we want which would actually hit trademark restrictions as far as I can tell, so that's all we need a license for. Disclaimers are required by a lot of licenses and should be acceptable (much like NO WARRANTY requirements). With this license, the disclaimers are the only restriction, and this restriction applies solely to usage of trademarks in an otherwise-maybe-infringing manner, not to anything else. Among other things, I believe this keeps it GPL-compatible, since the product can be distributed without agreeing to the restrictions simply by changing the name (which is not part of the copyright-covered material). They want their trademarks stripped from modified code that is essentially different in intent and purpose from the original code. Well, that's fine; we don't want to use their trademarks for things which aren't designed to work with their hardware, now do we? (At least, except in a historical context, which certainly wouldn't be a trademark violation.) So what do you think they would say about the model trademark license I just proposed? (Don't use it until debian-legal has had a few days to nitpick it, of course.) I think it's a free license, although others may disagree; the key point is that it is not trying to do anything but prevent confusion, and it doesn't overreach. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Trademark license compatibility with GPL and/or DFSG
Hello. Please accept my apologies if I am flogging a dead horse. I have ST*W but I cannot find a definitive solution to this problem. I did find a thread [1] on debian-legal from last year but it had more questions than answers ;-) [1] http://lists.debian.org/debian-legal/2004/10/msg00236.html I have been working on a Linux kernel driver for a certain wireless modem. I think it may be helpful to name the driver after the technology. Unfortunately, the company's trademark guide makes the following restrictions on the use of the trademark: (1) the product (i.e. the Linux kernel) must display the trademark on the splash screen (or in the About... box); (2) the trademark must appear in all documentation, marketing and promotional materials for the product; (3) the product must be guaranteed to be compliant with the wireless protocol; and (4) the uses of the trademark must be approved by the company before (each) distribution. I'd say we can't accept these terms ;-) What terms could we accept? Can we accept the restriction that any modification to the product must, at a minimum, first strip the trademarks from the product (or otherwise seek re-approval for their use from the company)? Can we accept the lesser restriction that any *significant* modification (whatever this means) to the product must, at a minimum, first strip the trademarks from the product (or otherwise seek re-approval for their use from the company)? I'd say the company would not license their trademark for free use without the lesser restriction, at least. It seems that these restrictions are incompatible with the GPL. On the other hand, any trademark license would permit us to use their trademark, which we could not do otherwise. With this understanding these are not restrictions at all but liberations! DFSG #4 permits licences that require derived works to carry a different name or version number but does not permit other minimum modification requirements. What do you think? Are these restrictions compatible with the GPL and/or the DFSG? How about if the trademark license could be revoked arbitrarily instead of imposing a no significant modification restriction (which is also somewhat arbitrary)? Would this fail the Tentacles of Evil test? It's a bit late for don't ask, don't tell as well ;-) Kind regards, Nicholas
Re: Trademark license compatibility with GPL and/or DFSG
[EMAIL PROTECTED] wrote: technology. Unfortunately, the company's trademark guide makes the following restrictions on the use of the trademark: (1) the product (i.e. the Linux kernel) must display the trademark on the splash screen (or in the About... box); (2) the trademark must appear in all documentation, marketing and promotional materials for the product; (3) the product must be guaranteed to be compliant with the wireless protocol; and (4) the uses of the trademark must be approved by the company before (each) distribution. I'd say we can't accept these terms ;-) What terms could we accept? If using that trademark has such restrictive conditions then I think it's obvious that we do not want to use it. It seems that these restrictions are incompatible with the GPL. On the other hand, any trademark license would permit us to use their trademark, which we could not do otherwise. With this understanding these are not restrictions at all but liberations! The trademark license applies to the trademark, not to the code, so this is not relevant. DFSG #4 permits licences that require derived works to carry a The DFSG is about copyright licenses, not trademarks. I object to using the DFSG to evaluate trademark licenses. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trademark license compatibility with GPL and/or DFSG
Nicholas Jefferson [EMAIL PROTECTED] wrote: What terms could we accept? Who cares? Why not rename it and avoid the whole debate, if the maintainer thinks their terms might be unacceptable? Can we accept the restriction that any modification to the product must, at a minimum, first strip the trademarks from the product (or otherwise seek re-approval for their use from the company)? Name changes seem fine to me, as long as it can be redistributed by others without changes without a name change (so the trademark licence is not specific to debian). Can we accept the lesser restriction that any *significant* modification (whatever this means) to the product must, at a minimum, first strip the trademarks from the product (or otherwise seek re-approval for their use from the company)? [...] That's a lawyerbomb. I wouldn't want to accept it. It seems that these restrictions are incompatible with the GPL. I agree. On the other hand, any trademark license would permit us to use their trademark, which we could not do otherwise. With this understanding these are not restrictions at all but liberations! [...] I think that's like arguing that any copyright licence is a liberation from the default no-copying-allowed, so is compatible with GPL. I don't agree. I think it is right and proper to apply DFSG to trademarks, patents and trade secrets, by the way. -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Trademark license compatibility with GPL and/or DFSG
MJ Ray wrote: Who cares? Why not rename it and avoid the whole debate, if the maintainer thinks their terms might be unacceptable? I think it would be helpful if the driver was named after the technology. If the bluetooth driver was named harold and the trident driver named poseidon it would not be obvious that the kernel supports these technologies. It adds a needless layer of abstraction onto the naming of kernel modules. This is part of the more general problem of trademarks in free software. If we don't solve this problem Debian could become a distribution of euphemisms. The company in question is willing to negotiate terms for a trademark license that is agreeable to all parties. Obviously any advertising or guarantee restrictions are unacceptable to us. Unlimited use of the trademark is unacceptable to them. We want unrestricted modification and redistribution. They want their trademarks stripped from modified code that is essentially different in intent and purpose from the original code. Necessarily the point where they want their trademarks stripped from the code is within the frontier of possible modifications under the GPL. However, code that is essentially different in intent and purpose is also likely to be original work in itself and not a derivative of the original code. This original work may not use the trademarks without permission. This restriction is therefore beyond the frontier of possible derivative works and thus is compatible with the GPL. Perhaps this is where we can find agreement with them. What do you think? Kind regards, Nicholas
Re: Trademark license compatibility with GPL and/or DFSG
On 5/19/05, Nicholas Jefferson [EMAIL PROTECTED] wrote: The company in question is willing to negotiate terms for a trademark license that is agreeable to all parties. Obviously any advertising or guarantee restrictions are unacceptable to us. Unlimited use of the trademark is unacceptable to them. We want unrestricted modification and redistribution. They want their trademarks stripped from modified code that is essentially different in intent and purpose from the original code. I'm not at all sure that all advertising or guarantee restrictions are unacceptable to us. We should have no problem, for example, with a restriction that advertising using the mark be truthful. And, anything less than that would probably be invalid under trademark law. We should have no problem, for example, with a no warrantee disclaimer. We don't have that problem with the GPL, so why should we have it with trademarks? Necessarily the point where they want their trademarks stripped from the code is within the frontier of possible modifications under the GPL. However, code that is essentially different in intent and purpose is also likely to be original work in itself and not a derivative of the original code. This original work may not use the trademarks without permission. This restriction is therefore beyond the frontier of possible derivative works and thus is compatible with the GPL. Perhaps this is where we can find agreement with them. What do you think? Asking that we rename the software if and when it's no longer a driver for the trademarked technology seems reasonable, and within the bounds of the DFSG. Since it's not a copyright issue (the copies can still be freely modified and distributed, regardless -- the GPL doesn't require that active fraud be legal), I don't think this would be a GPL issue, either. -- Raul
Re: Trademark license compatibility with GPL and/or DFSG
Isn't it always legal to use a trademark to refer to the product in question? If you have a driver for a piece of hardware that has the trademarked name X, it should be legal to name it driver for X. (Of course, what is legal and what keeps you from getting sued aren't nececssarily the same.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trademark license compatibility with GPL and/or DFSG
On 5/19/05, Ken Arromdee [EMAIL PROTECTED] wrote: Isn't it always legal to use a trademark to refer to the product in question? If you have a driver for a piece of hardware that has the trademarked name X, it should be legal to name it driver for X. (Of course, what is legal and what keeps you from getting sued aren't nececssarily the same.) Sure, the question is what is the product in question? and only the trademark holder gets to define that. If they claim that they have to ship it, or that's not the product, they can do so. Their only limitation is that whatever definition they choose they have to be cnosistent about it. -- Raul
Re: Trademark license compatibility with GPL and/or DFSG
I'm not at all sure that all advertising or guarantee restrictions are unacceptable to us. Yes ;-) It was a poor choice of words on my part. I had intended that to mean any advertising or guarantee restrictions of the kind outlined in my original email (viz. trademarks on the splash screen and all documentation, marketing and promotional materials, and a guarantee of protocol compliance). Asking that we rename the software if and when it's no longer a driver for the trademarked technology seems reasonable, and within the bounds of the DFSG. Since it's not a copyright issue (the copies can still be freely modified and distributed, regardless -- the GPL doesn't require that active fraud be legal), I don't think this would be a GPL issue, either. Okay. I will let them know. Thank you, Nicholas
Re: Trademark license compatibility with GPL and/or DFSG
On Thu, May 19, 2005 at 09:48:25AM -0700, Ken Arromdee wrote: Isn't it always legal to use a trademark to refer to the product in question? If you have a driver for a piece of hardware that has the trademarked name X, it should be legal to name it driver for X. Yes, and there should be no need to use the trademark in any way that requires a license for it. Purely descriptive, accurate use of trademarked terms is always permitted. Just be careful. You can call it driver for bluetooth, since it is. You can't call it bluetooth without permission, since it isn't. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Trademark license compatibility with GPL and/or DFSG
Nicholas Jefferson [EMAIL PROTECTED] wrote: MJ Ray wrote: Who cares? Why not rename it and avoid the whole debate, if the maintainer thinks their terms might be unacceptable? I think it would be helpful if the driver was named after the technology. If the bluetooth driver was named harold and the trident driver named poseidon it would not be obvious that the kernel supports these technologies. It adds a needless layer of abstraction onto the naming of kernel modules. Of course, the harold bluetooth driver is absurd. As absurd as the Apache HTTP Daemon or the Samba file server, indeed. :-/ [...] They want their trademarks stripped from modified code that is essentially different in intent and purpose from the original code. The licence must not try to forbid all use of the trademark in a way that exceeds what an unconnected person could do. -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trademark license compatibility with GPL and/or DFSG
On 5/19/05, Andrew Suffield [EMAIL PROTECTED] wrote: On Thu, May 19, 2005 at 09:48:25AM -0700, Ken Arromdee wrote: Isn't it always legal to use a trademark to refer to the product in question? If you have a driver for a piece of hardware that has the trademarked name X, it should be legal to name it driver for X. Yes, and there should be no need to use the trademark in any way that requires a license for it. Purely descriptive, accurate use of trademarked terms is always permitted. Not necessarily true when used as a name for other things, or in advertising and promotional materials, especially if you have been warned not to do so; see Progress Software v. MySQL and the Red Hat trademark imbroglio. I do not have the knowledge or qualifications to draw the line; do you? Just be careful. You can call it driver for bluetooth, since it is. You can't call it bluetooth without permission, since it isn't. I think (IANAL) that you are safe in going as far as: The author (who is not a vendor of Bluetooth (TM) devices or a licensee of the Bluetooth (TM) trademark) believes this driver to be compatible with certain devices that implement the Bluetooth (TM) interface. The trademark holder has not evaluated this claim. Bluetooth is a registered trademark of whomever. But naming things after a trademarked device, when the trademark holder is iffy about it, is IMHO somewhat risky. Cheers, - Michael
