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
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
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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
