Re: [Pkg-julia-devel] Linking libgit2 to OpenSSL
On Thu, Jul 28, 2016 at 10:45:18PM -0400, Peter Colberg wrote: > On Thu, Jul 28, 2016 at 05:21:59PM -0700, Josh Triplett wrote: > > On Thu, Jul 28, 2016 at 07:49:07PM -0400, Peter Colberg wrote: > > > The julia maintainers have proposed to libgit2 upstream to support > > > mbedTLS [1] as an alternative. That is a long-term solution however > > > that will take another year to ship in the form of julia 0.6.0. > > > > I don't think it'd take a year to do this. If libgit2 upstream added > > support for a new TLS transport, I'd be happy to help get the new > > upstream version of libgit2 packaged for Debian right away. I already > > need the latest upstream version for another project. > > My estimate was based on this comment [1], which refers to a solution > using MbedTLS as a custom TLS stream with libgit2 [2, 3]. This was(?) > planned for julia 0.6.0, which could indeed take a year until release. > > Transparently supporting MbedTLS in upstream libgit2 [4] seems a much > better solution and will work with julia 0.5.0 out of the box. Thanks > for advocating this proposal to the upstream maintainer. If you're interested in that approach, it would probably help to download and test the patches, and perhaps clean them up a bit. - Josh Triplett
Re: [Pkg-julia-devel] Linking libgit2 to OpenSSL
On Thu, Jul 28, 2016 at 07:49:07PM -0400, Peter Colberg wrote: > On Thu, Jul 28, 2016 at 04:34:16PM -0700, Josh Triplett wrote: > > On Thu, Jul 28, 2016 at 06:36:58PM -0400, Peter Colberg wrote: > > > I am suggesting to provide two variants of libgit2, without and with > > > support for https://, with the latter linking to OpenSSL, similar to > > > the multiple variants of libcurl. > > > > > > https://bugs.debian.org/832798 > > > > That would be a maintenance pain, and it would still mean that GPLed > > applications couldn't use libgit2 with https URLs. (It might work as a > > temporary solution, but it doesn't seem like the right long-term > > solution.) > > The julia maintainers have proposed to libgit2 upstream to support > mbedTLS [1] as an alternative. That is a long-term solution however > that will take another year to ship in the form of julia 0.6.0. I don't think it'd take a year to do this. If libgit2 upstream added support for a new TLS transport, I'd be happy to help get the new upstream version of libgit2 packaged for Debian right away. I already need the latest upstream version for another project. - Josh Triplett
Re: Linking libgit2 to OpenSSL
On Thu, Jul 28, 2016 at 06:36:58PM -0400, Peter Colberg wrote: > On Thu, Jul 28, 2016 at 03:26:46PM -0700, Josh Triplett wrote: > > Unfortunately, libgit2 also doesn't seem to support any TLS library > > other than OpenSSL. That's a serious problem for GPLed software, and > > Debian already has some GPLed software linking to libgit2 (which led to > > the switch to link against the gnutls version of libcurl). > > I am suggesting to provide two variants of libgit2, without and with > support for https://, with the latter linking to OpenSSL, similar to > the multiple variants of libcurl. > > https://bugs.debian.org/832798 That would be a maintenance pain, and it would still mean that GPLed applications couldn't use libgit2 with https URLs. (It might work as a temporary solution, but it doesn't seem like the right long-term solution.) I talked with libgit2 upstream about what it would take to support https without OpenSSL. They suggested that they weren't interested in using libcurl for HTTPS, even if it were fixed to support what they need (retrieving the original x509 certificate chain unparsed for a verification hook) and that fix became widely available. libgit2 doesn't use much of libcurl, since libgit2 only supports switching to the "smart" HTTP transport. Instead, libgit2 upstream would prefer to see a new TLS transport, selectable at compile time. They'd be willing to add support for that. Would someone experienced with either GnuTLS or NSS be up for writing a new TLS transport for libgit2? (I've CCed the maintainers of each.) - Josh Triplett
Re: Linking libgit2 to OpenSSL
On Thu, Jul 28, 2016 at 02:38:46PM -0700, Josh Triplett wrote: > On Thu, Jul 28, 2016 at 05:12:55PM -0400, Peter Colberg wrote: > > Dear Debian legal team, > > > > The next release of julia will use libgit2 (Cc'ed recent maintainers) > > to retrieve package repositories via https://. This requires libgit2 > > to be linked directly to OpenSSL [1]. > > > > libgit2 is licensed [2] under GPLv2 with this exception: > > > > -- > > > > LINKING EXCEPTION > > > > In addition to the permissions in the GNU General Public License, > > the authors give you unlimited permission to link the compiled > > version of this library into combinations with other programs, > > and to distribute those combinations without any restriction > > coming from the use of this file. (The General Public License > > restrictions do apply in other respects; for example, they cover > > modification of the file, and distribution when not linked into > > a combined executable.) > > > > -- > > > > Given the above, is libgit2 linked to OpenSSL distributable in Debian? > > I don't speak for libgit2 upstream, but yes, that license exception > allows linking libgit2 with arbitrary non-GPL-compatible software, > including OpenSSL. > > That said, libgit2-dev defaults to using libcurl for https URLs rather > than using OpenSSL directly; see THREADING.md, section "General Case". > In such a configuration, libgit2 doesn't link to any SSL library itself, > and just uses whatever libcurl and libssh2 use. In Debian, the libgit2 > package uses the variant of libcurl that uses GnuTLS (I made that change > in my NMU), and the libssh2 library uses libgcrypt, so libgit2 has no > direct *or* indirect dependencies on OpenSSL. So, packages licensed > under GPLv2 with no license exceptions can link to libgit2 in Debian. Correction: apparently this no longer holds true for current upstream versions of libgit2, even though the documentation still says it works that way. libgit2 doesn't seem to support doing TLS through libcurl; upstream mentioned that they want to support custom user certificate verification hooks, which libcurl doesn't support. Unfortunately, libgit2 also doesn't seem to support any TLS library other than OpenSSL. That's a serious problem for GPLed software, and Debian already has some GPLed software linking to libgit2 (which led to the switch to link against the gnutls version of libcurl). - Josh Triplett
Re: Linking libgit2 to OpenSSL
On Thu, Jul 28, 2016 at 05:12:55PM -0400, Peter Colberg wrote: > Dear Debian legal team, > > The next release of julia will use libgit2 (Cc'ed recent maintainers) > to retrieve package repositories via https://. This requires libgit2 > to be linked directly to OpenSSL [1]. > > libgit2 is licensed [2] under GPLv2 with this exception: > > -- > > LINKING EXCEPTION > > In addition to the permissions in the GNU General Public License, > the authors give you unlimited permission to link the compiled > version of this library into combinations with other programs, > and to distribute those combinations without any restriction > coming from the use of this file. (The General Public License > restrictions do apply in other respects; for example, they cover > modification of the file, and distribution when not linked into > a combined executable.) > > -- > > Given the above, is libgit2 linked to OpenSSL distributable in Debian? I don't speak for libgit2 upstream, but yes, that license exception allows linking libgit2 with arbitrary non-GPL-compatible software, including OpenSSL. That said, libgit2-dev defaults to using libcurl for https URLs rather than using OpenSSL directly; see THREADING.md, section "General Case". In such a configuration, libgit2 doesn't link to any SSL library itself, and just uses whatever libcurl and libssh2 use. In Debian, the libgit2 package uses the variant of libcurl that uses GnuTLS (I made that change in my NMU), and the libssh2 library uses libgcrypt, so libgit2 has no direct *or* indirect dependencies on OpenSSL. So, packages licensed under GPLv2 with no license exceptions can link to libgit2 in Debian. - Josh Triplett
Re: backporting and dual-licensing
Shriramana Sharma wrote: Say a person X writes a library libfoo. He licenses the library out under both the GPL and a commercial licence. I think you mean and a proprietary license. A person Y uses libfoo under the GPL. He goes and does a lot of improvements in the library since it is under the GPL. Now the modified version of libfoo is copyrighted by both X and Y. Assuming Y's improvements involved sufficient creativity to make them copyrightable, yes. In the absence of strong evidence to the contrary, you should assume they do. So X would not be able to import such improvements into the main distribution of libfoo since then he would not be able to dual-licence it - specifically he would not be able to licence it commercially, not owning it entirely. He must either take Y into his business or obtain a waiver from Y by one-time payment or whatever. Again, you mean proprietary, not commercial. X already has Y's permission to sell the software commercially, as long as X does so under the GPL. X just may not apply a proprietary license to the software without permission from Y. My question is: What would be considered a big enough difference/modification that X would need Y's permission for backporting the changes? Anything sufficiently creative for copyright to exist in it. You assume above that Y does hold copyright in the modified version, and if that holds true, X would need Y's permission. For the specific cases you gave, I agree with Andrew Donnellan's assessments. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: question about gpl-commercial dual licencing
Andrew Donnellan wrote: On 4/21/07, Shriramana Sharma [EMAIL PROTECTED] wrote: Say someone creates a library libfoo in the C language. The library is dual-licenced -- under the GPL and under a commercial licence. GPL is for open-source consumers and commercial licence is for closed-source consumers. Now I create Python binding to that library - pyfoo. Now I would like to dual-licence it myself, under the same terms -- GPL and a commercial licence. Now to get the right of dual-licensing, do I have to obtain a commercial licence from the author of libfoo? If yes, why? If no, why not? Please elucidate. Thanks. If you created the bindings using ctypes or similar, where there's no actual linking taking place, I think it's all OK. The specific technical mechanism used to link to libfoo doesn't matter. For the purposes of the GPL, it matters whether pyfoo forms a derivative work of libfoo. Whether that holds true for pyfoo or not depends on the details of pyfoo and libfoo. In the absence of strong technical evidence to the contrary, or specific precedent, I suggest you assume that pyfoo does derive from libfoo (regardless of the interface pyfoo uses to invoke libfoo). However, I think a nice email to the author can clear it all up anyway - your Python bindings would simply drive more sales of the commercial license anyway. Agreed. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Strange GPL licensing: most recent
Francesco Poli wrote: According to its debian/copyright[1], bootcd[2] is licensed as follows: | | License: | Most recent version of the GPL. | I've never seen anything like this. I saw GPL v2 or later, GPL v2 only, GPL (which automatically means any version[3]), even GPL v1 or later, but I've never seen GPL latest version... What does this mean? I believe you can interpret it to mean Licensed under the current version of the GPL as of when you obtain it. The GNU GPL v3 will probably be more restrictive than v2, at least in some respects. Assume I download bootcd now: I get it under the terms of GNU GPL v2. Yes. What will happen as soon as GPL v3 is out in its final form? You can then use bootcd under the terms of the GPLv3. However, since you already had the ability to use it under the GPLv2, that permits you to continue copying, modifying, and distributing under the terms of the GPLv2; once you have a GPLv2ed bootcd, you always have *that* version of bootcd under GPLv2. Will I still be able to exercise the rights granted by GPL v2 on my copy of bootcd (version 2.53)? Yes, I believe so. Or does it automagically becomes licensed under GPL v3? That too. At any given point, the most recent version license grants you the right to treat that version of bootcd under GPL v$CURRENT; meanwhile, if you already have such a license under a version of the GPL, that license can't go away. Is this possible at all? Section 9 of GPL v2 does not specify any meaning for the above-quoted permission notice. It explains the meaning of a GPL vX or later licensing and of a GPL licensing. It does not explicitly talk about GPL vX only licensing, because it is self-explanatory, I think. But nothing is said about a GPL latest version licensing... Is this a valid license statement at all? I think so, though not a particularly clear one. For example, it doesn't identify GPL as the GNU General Public License, as published by the Free Software Foundation; thus, someone could attempt to argue that their Grabbity Private License qualifies, or that the Affero General Public License qualifies. Should I ask [EMAIL PROTECTED] to provide an authoritative answer about this situation? I think that in this case, the meaning of the statement depends on the author more than the FSF. However, you might ask for confirmation of the irrevocability of a previously-granted GPL in this scenario. Should I file a bug report against the bootcd package to ask for a clarification? The license statement could certainly use clarification, but it doesn't necessarily need clarification to become free. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Open CASCADE Technology Public License
Josselin Mouette wrote: Le jeudi 08 juin 2006 à 22:37 +0200, Aurelien Jarno a écrit : Public license In short, Open CASCADE Technology Public License is LGPL-like with certain differences. You are permitted to use Open CASCADE Technology within commercial environments and you are obliged to acknowledge its use. You are also obliged to send your modifications of the original source code (if you have made any) to the Initial Developer (i.e. Open CASCADE S.A.S.). Complete text of the license is given below. The summary says the modifications should be sent to the Initial Developer (which isn't free), however nothing in the license itself says that. I think a statement acknowledging that this summary isn't binding would be a good thing to obtain. Agreed. * If you distribute or sublicense the Software (as modified by You or on Your behalf as the case may be), You cause such Software to be licensed as a whole, at no charge, to all third parties, under the terms and conditions of the License, making in particular available to all third parties the source code of the Software; No right to sell. I think this isn't good. GPL v2: 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. :) - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: libjlha-java license problem
Ying-Chun Liu wrote: Dear all, I intend to package libjlha-java which can be downloaded from http://homepage1.nifty.com/dangan/Content/Program/Java/jLHA/LhaLibrary.html . In every source files (*.java) there is a license written in Japanese: Copyright (C) 2002 Michel Ishizuka All rights reserved. 以下の条件に同意するならばソースとバイナリ形式の再配布と使用を 変更の有無にかかわらず許可する。 １．ソースコードの再配布において著作権表示と この条件のリスト および下記の声明文を保持しなくてはならない。 ２．バイナリ形式の再配布において著作権表示と この条件のリスト および下記の声明文を使用説明書もしくは その他の配布物内に 含む資料に記述しなければならない。 このソフトウェアは石塚美珠瑠によって無保証で提供され、特定の目 的を達成できるという保証、商品価値が有るという保証にとどまらず、 いかなる明示的および暗示的な保証もしない。 石塚美珠瑠は このソフトウェアの使用による直接的、間接的、偶発 的、特殊な、典型的な、あるいは必然的な損害(使用によるデータの 損失、業務の中断や見込まれていた利益の遺失、代替製品もしくは サービスの導入費等が考えられるが、決してそれだけに限定されない 損害)に対して、いかなる事態の原因となったとしても、契約上の責 任や無過失責任を含む いかなる責任があろうとも、たとえそれが不 正行為のためであったとしても、またはそのような損害の可能性が報 告されていたとしても一切の責任を負わないものとする。 There is also an English license written by the author on http://homepage1.nifty.com/dangan/en/Content/Program/Java/jLHA/LhaLibrary.html The english version is indeed an DFSG-free license, BSD-like and GPL-compatible. But the english license is NOT in the source tarball. I want to know if I can package this software into Debian main. Thanks for comments. Assuming that someone versed in Japanese can verify that the above license corresponds to a normal 2-clause BSD license, you may indeed include the software in Debian main. Debian main requires DFSG-free licenses; it does not require English licenses. That said, you might consider including the English version from the author's webpage in debian/copyright in addition to the Japanese version, appropriately identified. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Revised Bacula license
Kern Sibbald wrote: John Goerzen wrote: Can you all take a look at the below new license? I took a quick look and it looks good to me. This revised license looks DFSG-free to me. One note, though: Linking: Bacula may be linked with any libraries permitted under the GPL, or with any non-GPLed libraries, including OpenSSL, that are required for its proper functioning, providing the source code of those non-GPLed libraries is non-proprietary and freely available to the public. [...] Certain parts of the Bacula software are licensed by their copyright holder(s) under the GPL with no modifications. These software files are clearly marked as such. If those parts don't carry the exception for non-GPLed libraries such as OpenSSL, then Bacula as a whole does not have an exception for non-GPLed libraries such as OpenSSL, so distribution linked to OpenSSL would violate the GPL on those portions without the exception. This doesn't make Bacula non-free, but it does make it impossible to distribute Bacula compiled to use OpenSSL or similarly-incompatible libraries. Yes, I understood that. I added that clause at José's request to satisfy a Debian requirement, and if it is not really needed or no longer needed by Debian, I would probably prefer to remove it for exactly the reason you mention. At the same time, it made me realize that I don't have full control over certain sections of the code copyrighted by other people. If you link to OpenSSL or similarly-incompatible libraries, you definitely need such an exception, on all the GPLed code in Bacula; Debian doesn't require this, the GPL itself does. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Sun responds to questions on the DLJ
actually presents the license. This is extreemly trivial to do. Yes, and this is a feature, not a bug. One of the reasons that Debian is great is the ability to do fully automated installs and such. The point of presenting the license is that an individual, corporation, non-profit or other entity has had a chance to review and agree to the DLJ. If a user or administrator pre-seeds the key for DLJ acceptance on behalf of herself or her group then it is perfectly acceptable to install Sun Java on 1 or 10,000 nodes. Glad to hear this; I think that resolves the issues raised about this particular clause, assuming the above clarification goes into the license or otherwise becomes binding. And, as I am sure you know, Rich Green has announced a very interesting Open Source future for Java. Simon, I (and many others) are going to work very hard on that internally so that soon you will be able consider Java for main. For that, I applaud you; let me know if there is anything that I can do to help speed that process (which is infinetly more interesting to me than dealing with EULAs) along. Fully seconded; I would gladly help with this as well. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: [draft] Re: Sun Java available from non-free
Jeroen van Wolffelaar wrote: On Wed, May 17, 2006 at 11:09:30PM -0700, Don Armstrong wrote: (b) the Software is distributed with your Operating System, and such distribution is solely for the purposes of running Programs under the control of your Operating System and designing, developing and testing Programs to be run under the control of your Operating System; non-free is not part of Debian so we definetly don't distribute it as part of the Operating system. Note that the license says ... is distributed *with* your Operating System, and not is part of. I don't know where you read the part of bit? Anyway, we definitely do distribute non-free *with* our OS, it's in debian/pool/non-free on all our mirrors alongside debian/pool/main, and distributing it in the same directory hierarchy is definitity with in my book. Does that imply, though, that one cannot mirror non-free separately from Debian, or put it on a separate CD which one can purchase or distribute separately? For example, such a clause would prevent Debian from distributing non-free on a separate server, as proposed a while back. (c) you do not combine, configure or distribute the Software to run in conjunction with any additional software that implements the same or similar functionality or APIs as the Software; This means that we can't distribute eclispse or anything else which implements part of the Java API (or if you're going to read this clause as broadly as possible,[1] things like perl which implement similar functionality in that perl is an implementation of a cross platform language Perl.) The license says distribute [...] to run in conjunction with. We do distribute eclipse, kaffe, gcj, and various others tools and applications, but not to run in conjunction with the Sun Java. As I mentioned elsewhere in this thread, the alternatives system means that any Java library in Debian could fall under configure [...] to run in conjunction with. Thus, what about software like SWT, which provides similar functionality, or SwingWT, which provides the Swing API on top of SWT? Does this clause prevent us from shipping those? What this clause seeks to prevent is using Sun's JVM with the Classpath java library, or to use the Java library code together with Kaffe. So, for example, Debian would need to stop shipping the jikes-sun package http://packages.debian.org/jikes-sun which uses the Jikes compiler to compile against the Sun Java library? 4. COMPATIBILITY. If you exercise the license in Section 2, and Sun or a licensee of the Software (under section 4(b)) notifies you that there are compatibility issues [...] caused by the interaction of the Software with your Operating System, then within ninety (90) days you must either: (a) modify the Operating System in a way that resolves the compatibility issue (as determined by Sun) and make a patch or replacement version available [...] Oh, right... so if the Sun JDK is buggy, we have to modify our operating system to make it unbuggy in some way that makes Sun happy. Makes sense to me. Or option (b), remove the Sun packages. If we were to face this situation, there's always this option if there isn't a better one. And if a problem comes up with the Sun Java package shipped in stable, or oldstable? Speaking realistically, such a move of Sun would be spectacularly bad PR for them esp. considering their statements about future Java licensing efforts they have committed to. I agree. However, that doesn't prevent them from doing it, once. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Sun responds to questions on the DLJ
Tom Marble wrote: Josh Triplett wrote: Tom Marble wrote: Don Armstrong wrote: On Fri, 19 May 2006, Tom Marble wrote: + SECTION 2(c) There have been a series of speculations about this, despite the clarifications of FAQ #8. The term alternate technologies refers to projects such as kaffe, gcj, classpath, harmony and the like. We want Debian users that include non-free to be able to have a choice which includes Sun Java. We don't want to put wacky restrictions on every programming language. Right, but from what I can tell the 2a does this as well... what additional restrictions does Sun gain by adding 2c in addition to 2a? 2c is the please don't mix and match with 'alternate technologies' provision. Right. So, what precisely does this intend to ban? The clause reads: (c) you do not combine, configure or distribute the Software to run in conjunction with any additional software that implements the same or similar functionality or APIs as the Software; Since the Sun Java packages use the alternatives system (which they clearly should do), we could reasonably consider any Java software shipped by Debian as configured to run in conjunction with Sun Java. Thus, this clause prevents Debian from shipping any Java software which implements the same or similar functionality or APIs as Sun Java. For example, this could prevent Debian from shipping SWT, which provides similar functionality to Swing, or even more clearly SwingWT, which provides the Swing API on top of SWT. From FAQ #8, there is nothing in the DLJ intended to prevent you from shipping alternative technologies with your OS distribution. When I say mix and match I mean please don't take bits from the alternate technologies (see above) and put them into use with the Java platform (e.g. replace rt.jar which is part of the platform with an alternate rt.jar). In a similar way please don't take bits from the Java platform and use them as part of or to complete alternate technologies (e.g. plugin.jar). That much, as stated, sounds reasonable. However, it doesn't seem clear from the clause in question. Also, what does this mean for packages like jikes-sun http://packages.debian.org/jikes-sun, which uses the Jikes compiler with the Sun Java library, by depending on Sun Java and setting Jikes' classpath to include it? This doesn't copy or move any files from the Sun Java package, and it doesn't replace any bits in the Sun Java package; it just points a variable to a file in the Sun Java distribution. And does this prevent a package from (for example) build-depending on sun-java and jikes and invoking jikes with the appropriate arguments to do the same thing? Or, in general, from build-depending or depending on sun-java and $OTHER_JAVA_IMPLEMENTATION, and invoking pieces of both to build or run? So you can distribute alternate technologies or SWT on your OS and still ship Sun Java. If this is still unclear please let me know. So, to clarify, no package that Debian could ship in main or contrib (assuming it didn't dpkg-divert anything from the Sun Java package) could by itself suddenly put Debian in violation of this clause, even though Sun Java ships using Debian's normal mechanisms which allow it to work with any random Java stuff a user installs? Only modifications to the Sun Java packaging (which mixed-and-matched pieces with other implementations) could violate the license? If so, that seems fine, but not obvious from the license clause. Furthermore, the alternatives system allows a user to choose between programs based on priority, on a program-by-program basis. Suppose we shipped packages in main with alternative priorities set such that if a user installed certain of those packages along with Sun Java, they'd end up with parts of the JDK pointing to Sun Java and others pointing to software in main. For example, with java pointing to Sun's Java but javadoc pointing to gjdoc, and gjdoc in turn running with whatever java pointed to, namely Sun Java. Since Sun Java also ships a javadoc implementation, that sounds very clearly like configuration or distribution to run in conjunction with additional software that implements the same functionality. Yes this is a potential problem that was raised this week. AFAIK a fix is in progress with a complete set of noop alternatives so the update-java-alternatives script (in java-common) will not accidentally mix Java with alternate technologies. That doesn't sound sufficient. Imagine the following case: * I write a package foodoc which implements javadoc. * My package uses update-alternatives to install an alternative for just the javadoc binary. * A user does apt-get install sun-java foodoc * sun-java gets unpacked and configured first, and sets all the alternatives (java, javac, javadoc, ...) to point to its implementations. * foodoc gets unpacked and configured next, and sets the javadoc alternative to point to foodoc
Re: Revised Bacula license
John Goerzen wrote: Can you all take a look at the below new license? I took a quick look and it looks good to me. This revised license looks DFSG-free to me. One note, though: Linking: Bacula may be linked with any libraries permitted under the GPL, or with any non-GPLed libraries, including OpenSSL, that are required for its proper functioning, providing the source code of those non-GPLed libraries is non-proprietary and freely available to the public. [...] Certain parts of the Bacula software are licensed by their copyright holder(s) under the GPL with no modifications. These software files are clearly marked as such. If those parts don't carry the exception for non-GPLed libraries such as OpenSSL, then Bacula as a whole does not have an exception for non-GPLed libraries such as OpenSSL, so distribution linked to OpenSSL would violate the GPL on those portions without the exception. This doesn't make Bacula non-free, but it does make it impossible to distribute Bacula compiled to use OpenSSL or similarly-incompatible libraries. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: [draft] Re: Sun Java available from non-free
Steve Langasek wrote: On Sat, May 20, 2006 at 02:18:57PM -0700, Josh Triplett wrote: Note that the license says ... is distributed *with* your Operating System, and not is part of. I don't know where you read the part of bit? Anyway, we definitely do distribute non-free *with* our OS, it's in debian/pool/non-free on all our mirrors alongside debian/pool/main, and distributing it in the same directory hierarchy is definitity with in my book. Does that imply, though, that one cannot mirror non-free separately from Debian, or put it on a separate CD which one can purchase or distribute separately? For example, such a clause would prevent Debian from distributing non-free on a separate server, as proposed a while back. It may imply this, but this is not a barrier to Debian's inclusion of the packages under the current non-free regime. The only real requirement for a package's inclusion in non-free is: can we distribute it? We don't make any guarantees that other people can also distribute it outside of a Debian mirror, or on CDs, or anything else. There have definitely been non-free packages in the past that could *not* be distributed separately from the Debian mirrors or that could not be distributed on CDs. I certainly didn't mean to suggest otherwise. Just raising a point for discussion. Even non-free licenses could stand improvement towards becoming less non-free. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Help Selecting License for Bacula Documentation
Kern Sibbald wrote: Benjamin Seidenberg wrote: Kern Sibbald wrote: John Goerzen wrote: I'm forwarding, with permission, parts of a message from Kern Sibbald, author of Bacula and its manual. The current manual, which has a license listed at http://www.bacula.org/rel-manual/index.html, is not DFSG-free. However, Kern has indicated a willingness to consider other license arrangements. Kern's main concern (correct me if I'm wrong, Kern) is that he doesn't want someone to be able to publish and sell paper versions of the manual. Yes, this is correct, but with the nuance, that I would be very happy to see the manual published in physical form provided there is an agreement for a reasonable financial contribution to the project, which should take into account normal royalties and how much work the publisher (or whoever transforms it) has to do to get it in a publishable form. In my other email, I attempt to explain my reasoning behind this. While this is an understandable viewpoint, and one that I can sympathize with, any license that would provide protection such as you describe would most definitely be in violation of the DFSG, and as such, not distributable by debian, at least in the main section (though possibly in non-free). On the other hand, note that the GPL requires that distributors notify recipients about the Free Software status of the work, which would allow people to know hey, I could get this for free online; this might achieve a similar effect to what you desire. Furthermore, I don't know for sure, but a carefully worded license *might* manage to require a specific notice as to the unofficial, non-endorsed status of the manual, while still remaining DFSG-free. You could then specifically grant distributors the rights to call themselves an official and/or endorsed manual in exchange for whatever auxiliary licensing terms you want. Hmmm. Possibly having an invariant section (or whatever it is called) stating the unofficial, non-endorsed status of any commercially printed version of the manual would do what you suggest. I didn't mean to suggest an invariant section; DFSG-free works can't have invariant sections. I simply meant requiring some form of notice, much like the GPL requires that you include appropriate copyright and license notice. I'm going to try to come up with some such wording over the next week, but if you or someone else could suggest such a carefully worded license for the Bacula manual that would be acceptable to Debian, it would for me be a good solution, and I would very likely accept it -- obviously, I would like to see the wording before making a firm commitment ... How about something vaguely along the lines of this: If you publish this work in paper form, you must conspicuously and appropriately publish on each copy a notice of the unofficial, non-endorsed status of the work. Notice the intentional lack of specific wording or placement required for such a notice. I modelled this after the GPL's clause 1. Note, though, that any such clause will likely make your documentation GPL-incompatible, which will likely cause problems down the road given that Bacula uses the GPL. I personally would suggest just using the GPL on the manual, and relying on the fact that the GPL requires a conspicuous and appropriate notice as to the GPL status of the work; and furthermore, that any distributor would need to either include the full source to the manual or an offer for such. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: License of wget.texi: suggest removal of invariant sections
Hrvoje Niksic wrote: Don Armstrong [EMAIL PROTECTED] writes: On Thu, 18 May 2006, Hrvoje Niksic wrote: Including the text of the GPL in Wget's manual serves the purpose of explaining Wget's copying terms to the user. As such, it seems pertinent regardless of whether Wget is actually distributed along with the manual. To reiterate what you said above, our problem is that the GPL can't be removed at all,[1] even when it's no longer applicable, not that it's being included by wget.texi in the first place. What I don't understand is how the GPL can be no longer applicable, given that it's not possible to change Wget's license. If the copyright holder (in this case the FSF) decided to change the license, surely they could also remove the invariant section? Don't just think in terms of the software the current manual describes (namely Wget), which of course remains GPLed. First, you could distribute the Wget manual without distributing Wget, in which case the GPL itself no longer obligates you to include it since you don't distribute GPLed software, but the Wget manual license notice requires you to continue distributing it. Second, you might modify the manual to make a smaller form, such as a manual page, and want to avoid including more extra text than you need to. Third, someone might want to adapt some part of the Wget manual for their own documentation, which might document an LGPLed library, or a MIT-licensed work, and thus shouldn't have to include a potentially confusing third license. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Help Selecting License for Bacula Documentation
Benjamin Seidenberg wrote: Kern Sibbald wrote: John Goerzen wrote: I'm forwarding, with permission, parts of a message from Kern Sibbald, author of Bacula and its manual. The current manual, which has a license listed at http://www.bacula.org/rel-manual/index.html, is not DFSG-free. However, Kern has indicated a willingness to consider other license arrangements. Kern's main concern (correct me if I'm wrong, Kern) is that he doesn't want someone to be able to publish and sell paper versions of the manual. Yes, this is correct, but with the nuance, that I would be very happy to see the manual published in physical form provided there is an agreement for a reasonable financial contribution to the project, which should take into account normal royalties and how much work the publisher (or whoever transforms it) has to do to get it in a publishable form. In my other email, I attempt to explain my reasoning behind this. While this is an understandable viewpoint, and one that I can sympathize with, any license that would provide protection such as you describe would most definitely be in violation of the DFSG, and as such, not distributable by debian, at least in the main section (though possibly in non-free). On the other hand, note that the GPL requires that distributors notify recipients about the Free Software status of the work, which would allow people to know hey, I could get this for free online; this might achieve a similar effect to what you desire. Furthermore, I don't know for sure, but a carefully worded license *might* manage to require a specific notice as to the unofficial, non-endorsed status of the manual, while still remaining DFSG-free. You could then specifically grant distributors the rights to call themselves an official and/or endorsed manual in exchange for whatever auxiliary licensing terms you want. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Bug#346354: AW: Bug#346354: Is distribution of the maxdb-doc package a GPL violation?
Steve Langasek wrote: On Thu, Apr 27, 2006 at 05:35:51AM -0700, Walter Landry wrote: [EMAIL PROTECTED] wrote: I have verfified that the actual sources for the generated HTML are Microsoft Word documents and that those will not be distributed. Does the mean that the maxdb-doc package will have to be pulled from the repository? Yes, unless you get a license exemption from the copyright holder allowing Debian and its mirrors to distribute the HTML as is. They will probably agree. In that case, it goes into non-free. It's not obvious to me that either the license exemption or the non-free categorization are necessary here. GPL requires the preferred form for modification, which for most people working on derivative works would probably *not* be the Word docs? As I understand it, preferred form for modification means the preferred form by a person who made modifications (in other words, upstream), not the preferred form of those who would like to make modifications (in other words, downstream). In any case, I'd sooner edit a Word document (using OO.o, Abiword, or similar) than the HTML that Word outputs. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Implicit granting of rights?
Frank Küster wrote: Ralf Stubner [EMAIL PROTECTED] wrote: On Fri, Apr 14, 2006 at 15:14 +0200, Frank Küster wrote: , | %%% Copyright (C) 1994 Aloysius G. Helminck. All rights reserved. | %%% Permission is granted to to customize the declarations in this | %%% file to serve the needs of your installation. However, no permission | %%% is granted to distribute a modified version of this file under | %%% its original name. ` That would be just on the right side of the border set by DFSG #4 (note that it's a TeX input file, so it is both source and used form), but No, it falls just on the wrong side; licenses can restrict the name of the *work*, as in the human-parsable name, but filenames serve as a functional component of a work. This issue came up with the previous version of the LPPL. For example, would you accept as DFSG-free a license which said you must change the SONAME of a library if you changed the library? That would mean you could not legally create a compatible work. But it doesn't even allow use - don't know whether this is implicitly granted? I would vote for implicitly granted usage rights, but IANAL. Can we in fact assume such implicit granting of rights? It seems logic to me, because there are no needs of your installation if all I may do is meditate over the contents of the file. But I'm not sure whether what seems logic to me is logic in IP law... Generally, I think you can assume the right to *use* something. However, you can't assume the right to modify or distribute, and this license does not grant any permission to distribute. It also seems to restrict which modifications you can make; among other things, you can't modify it to serve the needs of *other* installations, or modify anything other than declarations. It may well *intend* to grant the right to distribute (unmodified or with another filename) and the right to all possible modifications, but it doesn't appear to actually do so. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: cube-data package
Gonéri Le Bouder wrote: To clarify: game engine: zipped file that containt source code of the engine without the network modified code. data tarball: targziped file that containt music/textures/models and precompliled client/server with modified network code. 0. please copy and paste the full license text in your reply The full license of the game engine is here. http://goneri2.free.fr/cube/ 1. please specify clearly which parts it applies to (game engine? game data? both?) The game engine is provided under the ZLIB license. The data tarball is provided under the license i pasted in the first mail and some others different license (Cf: URL to svn.debian.org). It contain precompiled client and server for Linux/FreeBSD i386. I want to provied them since they have a modified network code to avoid cheat and they are needed to connect to some public server. Of course, they are not free. Ignoring the precompiled modified client and server, it looks like the data file licenses range from Free to non-free to permission-required to no license given at all. Unfortunately, it doesn't look like the Free data files provide nearly enough to play the game, so the data needs to go to non-free; some of the files cannot even go in non-free. From your copyright file, some of the licenses requiring permission (beyond that presumably already given to cube): *- packages/spen Map design is copyright 2004 Bill Spencer. You're free to distribute this map pack as you wish as long as: you make no profit, and leave the entire archive intact. However, Internet distribution is to be only through web sites of my choosing as long as one exists. *Elements* of the map may be used only as provided below. So this one needs permission from that author in order to distribute; that permission would need to cover the entire Debian mirror network, including both official and unofficial mirrors. *- packages/dcp_the_core all included data is designed for the cube game engine. any other use or any form of redistribution requires my permission. Same problem. Some of the licenses also state that distribution can occur via electronic media (Internet, FTP, BBS) only; that may not pose a problem for non-free, since I think distributors of non-free CDs already need to take caution and check individual packages, but I don't know the policy on that. Also note that several of the packages require distribution of an unmodified archive. It looks like a few of the data files do fall under Free licenses, though; I wonder if one could scrape together enough of them to play a full level? Let's start by checking whether this package *can* enter main. If (and only if) it turns out it cannot, we'll discuss whether it's distributable from the non-free repositories... OK? IMO the engine can't enter main since it depends on its data to work. Right; the Free engine would need to go to contrib, if you decide to package it. What i want to do: From source: - cube-client - cube-server From data: - cube-client-nonfree - cube-server-nonfree - cube-data Seems reasonable. If enough Free data existed to play the game (even with a vastly reduced dataset), you could split the data into cube-data and cube-data-nonfree packages, and put the Free client and server in main. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: MPL and Source Code
Craig Southeren wrote: On Tue, 04 Apr 2006 23:13:32 -0400 Anthony DeRobertis [EMAIL PROTECTED] wrote: Craig Southeren wrote: This means theoretically that the lifetime of a source release under the GPL is the same as a binary release. Once the binary is no longer distributed, then the source no longer has to be distributed either. As a user, the seems more than a little unreasonable, but if that's what the license says.. The MPL requirement for 12 months seems quite reasonable, and I can't see that any packager (Debian included) would have a problem with meeting it. Well, first off, we have to set a boundary somewhere: While 1 year may seem reasonable, certainly 100 is not. Debian has chosen for as long as the binary is being distributed as our line between reasonable and unreasonable. There are several reasons that spring to mind: Not sure where the 100 years came from - I certainly never proposed it! :) The MPL states 12 months, and the GPL had three years (for certain methods of distribution) but I don't know of any license that required 100 years. I agree that any such period of time would be unfairly onerous. Quantitative points rarely make the difference between free and non-free. If requiring source 100 years after you stop providing the binary would clearly classify a license as non-free, then generally so would 3 years or 1 year. [snip Anthony's excellent practical arguments against requiring source longer than binaries] I don't see that the MPL (or the GPL) requires that there are pre-packaged source packages available that correspond one-to-one basis for executable packages. Most likely not, given sufficient care taken with the repository. As such, I think that the Debian CVS/SVN server meets the definition of electronic distribution for the terms of the MPL - provided that there are appropriate tags/revision markers available for each identified release, AND provided the revision control system is publically available, AND provided the revision control system contains all of the sources, AND provided historical revision information is not purged within 12 months of a release. Is there is any reason why any of these requirements would not be met? Is there any disagreement as to whether this would apply? I think the Debian CVS/SVN server meets the definition and would most likely satisfy the license, though it could potentially cause problems for our mirror operators. But the question of whether Debian can satisfy the license stands completely independent of whether Debian considers the license Free. We can satisfy the licenses of every piece of software in non-free, or we couldn't legally distribute them. I think you have successfully argued that we can satisfy this requirement of the license, and thus we could probably legally distribute MPLed software; however, distributability only gets you as far as the non-free archive. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: MPL and Source Code
Craig Southeren wrote: On Wed, 05 Apr 2006 01:18:34 -0700 Josh Triplett [EMAIL PROTECTED] wrote: I think the Debian CVS/SVN server meets the definition and would most likely satisfy the license, though it could potentially cause problems for our mirror operators. I don't see why. Because they then depend on us to continue providing source, rather than mirroring it themselves. I think you have successfully argued that we can satisfy this requirement of the license, and thus we could probably legally distribute MPLed software; however, distributability only gets you as far as the non-free archive. Given that the Debian definition of free basically means GPL compatible, I never really expected anything else :) No, it doesn't. Debian's definition of Free provides considerably more leeway than GPL-compatibility. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: MPL and Source Code
Anthony DeRobertis wrote: On Sun, Apr 02, 2006 at 08:54:53PM +1000, Craig Southeren wrote: A problem would only occur if there was a Debian release that contained source code that is is not in the SVN archive. Does this ever occur? Security updates and NMU's come to mind. As do non-Debian distributors and CDDs, who can currently rely on the fact that if they mirror/distribute source along with binaries, they satisfy all relevant licensing requirements. Furthermore, any CDD modifying Debian packages could not rely on Debian's SVN repository. Also, if you ever stopped maintaining the software, and some other maintainer wanted to work on it, they would then need to make use of a version control system or similar mechanism as well. If a license said you must develop the software in a version control system, I don't think we'd quibble over its non-freeness; this requirement constrains development practices only slightly less. I think any mirror operator, CD distributor, system distributor, or other distributor of Debian could face a lawsuit if Debian's systems go down or Debian stops distributing source falls pretty clearly on the non-free side. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: RFC: the new license for IBPP
Damyan Ivanov wrote: === The problematic? clause === Permission is hereby granted, free of charge, to any person or organization (”You”) obtaining a copy of this software and associated documentation files covered by this license (the “Software”) to use the Software as part of another work; to modify it for that purpose; to publish or distribute it, modified or not, for that same purpose; to permit persons to whom the other work using the Software is furnished to do so; subject to the following conditions: the above copyright notice and this complete and unmodified permission notice shall be included in all copies or substantial portions of the Software; You will not misrepresent modified versions of the Software as being the original. === Francesco Poli wrote: What if I want to modify the library itself and distribute the result by itself? This is not permitted, AFAIU. Why have I to be annoyed by this wrap it in some silly container work requirement? Better to adopt the actual Expat license (http://www.jclark.com/xml/copying.txt), IMHO. I see your point and I agree. But the author deliberately modified Expat license to include the above terms. So the questions is: Is this DFSG-free or not? Please bear in mind that IBPP is really to be used in FlameRobin's packaging, not by itself. That particular point, that you only plan to use it with one particular piece of software, has no bearing on DFSG-freeness. This license itself seems highly suboptimal, but it *may* follow the letter of the DFSG: The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale. as a component of an aggregate software distribution containing programs from several different sources does indeed permit pieces of software which do not permit solo distribution, since you can always bundle them with a hello world program to make them distributable. (This also makes such licensing relatively worthless.) One question however: does the author intend use the Software as part of another work to imply that the work must incorporate or derive from the Software, or simply that the Software must occur as part of a larger work of some kind, including potentially an aggregate with unrelated programs, such as the Debian distribution? The latter follows the letter of the DFSG; the former places a stronger requirement that I don't believe the DFSG permits. - Josh Triplett signature.asc Description: OpenPGP digital signature
Mozilla relicensing complete
According to Gervase Markham, the mozilla relicensing process has now completed; all source files now fall under the GPL, LGPL, and MPL: http://weblogs.mozillazine.org/gerv/archives/2006/03/relicensing_complete.html - Josh Triplett signature.asc Description: OpenPGP digital signature
The LGPL's GPL upgrade clause and or later
Useful piece of information for those concerned about using open-ended or later licensing on their software: the upgrade clause in the LGPL2.1, clause 3, allows the use of GPL version 2 or later: 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Thus, even if you license your software under the LGPL2.1 only, sans or later, the license itself will permit use under GPL2 or later. Because this appears in the license text rather than in the recommended license notice, an individual licensing their software cannot remove the or later in any way without creating an incompatibility with the LGPL. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: GFDL'ed documents with Front Cover text
Steve M. Robbins wrote: Frank said: assume a document licensed under GFDL, with no invariant sections (and ...) has a front cover text (like A GNU Manual) and a back cover text [...] What should the developers do in order to make it DFSG-free [...] This implies that a document with no invariant sections, but with one-sentence front- and back-cover sections does not meet the DFSG? Is that Debian's position? Yes, by the project-wide GR such a document does not meet the DFSG: This means that works that don't include any Invariant Sections, Cover Texts, Acknowledgements, and Dedications (or that do, but permission to remove them is explicitly granted), are suitable for the main component of our distribution. Steve M. Robbins wrote: For example, GMP has Front-Cover Text A GNU Manual and Back-Cover Text You have freedom to copy and modify this GNU Manual, like GNU software and no invariant sections. Must I really throw this document out of Debian (BTS 335403)? Yes. You could package it separately in non-free, however. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: RFH: Non-free files in Emacs
Jérôme Marant wrote: After cautiously reading you message, here are my intends about the listed files. Please correct me if you think I'm wrong. [CRUFT] Remove from any package [NON-FREE] Move to non-free [MAIN] Keep in main I agree with all of these, except: [EMAIL PROTECTED] (Nathanael Nerode) writes: [...] COPYING -- Non-free (verbatim only), but we make an exception for it because it's the license for the program. [MAIN] [CRUFT]; packages should not include copies of the GPL, but should instead refer to /usr/share/common-licenses/GPL. yow.lines -- large numbers of quotations from Bill Griffith's Zippy comics, without permission. There are so damn many of them that it worries me. (Unlike the other lists, which don't consist entirely of work by one author.) I'd remove it. Any other people want to weigh in? [CRUFT] Emacs actually does use this; M-x yow and M-x psychoanalyze-pinhead draw Zippy quotes from this file. That doesn't necessarily change the freeness status of it (though the quotes may still fall under fair use or similar), but it probably changes it to [NON-FREE] at least. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Interpreting the GFDL GR
Henning Makholm wrote: Scripsit Jeremy Hankins [EMAIL PROTECTED] Henning Makholm [EMAIL PROTECTED] writes: Therefore my proposal is to narrow the licensor's-intent principle to clauses of the general kind that are problematic in the GFDL. The description in point (a) above is my best attempt to define such a general kind of restrictions without being too much a GFDL-specific exemption. I think your suggestion is the best chance at making sense of the GR that I've seen so far, but I would make one change: it *should* in fact be applicable only to the GFDL. Doing so would mean that we'd need to have a separate GR for each problematic license we encounter. We have to try to extract some general principles from it, or everything becomes a farce. I agree with your premise, but not your conclusion. The GR did not specify any general principles. If you'd like to advocate some general principles on their own merits, that's fine; don't attribute them to the project as a whole, or attempt to guess the intent of a voting body with likely many individual intents. I don't believe it's a farce to take the approach of interpreting the DFSG in a reasonable manner, and require a GR if the project wants to say Regardless of any license reasoning or possible issues, this license shall be considered free under these circumstances, which is exactly what the GR did. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Interpretation of the GR
Nathanael Nerode wrote: Glenn Maynard wrote: On Wed, Mar 15, 2006 at 09:31:04PM -0500, Nathanael Nerode wrote: So the GR promotes a do what I mean, not what I say approach to license interpretation for the GFDL -- it does *not* claim that the literal reading of the DRM restriction is free. But GRs don't get to say what licenses mean. Right. trouble, but it seems to be the preferred choice of the developers. At least Debian still believes in removing stuff without free licenses from Debian if the licensors decide to actually enforce their licenses as written. ... but at that point, it's too late. Debian and/or its users may already be liable. Such a claim by a licensor would not be a guaranteed victory, of course, but it does feel like Debian would genuinely be in the wrong. Well, at least Debian and/or its users would only be liable for past uses. :-P Normally copyright holders send cease-and-desist letters before making claims. So I guess it's fairly unlikely that anyone would actually sue or file charge without sending one first. But I agree with you, it feels very much like Debian and/or its users would be in the wrong. I think it would be Debian in the GFDL case, because the copies stored on ftpmaster are rendered inaccessible to the general public, by means of technical measures. Only the copies of those copies on the mirrors are accessible. Actually, I'm surprised I didn't notice that before -- GFDL documents can't be legally distributed by Debian if you actually read what the license says. They're *undistributable*. Agreed. There's absolutely nothing stopping developers from saying OK, fine, by the GR it's DFSG-free, whatever that means now; we still have no legal right to distribute it unless we change our modes of distribution to not violate the license. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: All rights reserved?
Francesco P. Lovergine wrote: On Wed, Mar 15, 2006 at 08:57:36PM -0500, Glenn Maynard wrote: See http://lists.debian.org/debian-legal/2005/10/msg00198.html for previous discussion (from Googling for 'all rights reserved debian-legal'). It's not a problem. And what if a script has that clause and not a license at all? Wouldn't be considered public domain, I think... This is a real case for a tiny script (published on a web site) whose author is not reachable. This is exactly the same case as if it has a copyright notice and no license at all. The default is that any right restricted by copyright is restricted. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Interpreting the GFDL GR
Henning Makholm wrote: Scripsit MJ Ray [EMAIL PROTECTED] I assert that their arguments are not part of the position statement (= not part of what was approved by vote) and that trying to interpret hidden meanings of the position statement is daft. As far as I can see our choices are: (1) Ignoring the GR, which would mean that our advice would not say anything about how the Debian Project feels about licences. (2) Accepting the GR as a statement about the literal meaning of the GFDL, which is simply untrue. (3) Trying to find some way of understanding the GR that is neither false nor self-contradictory. If you have a fourth option that I have overlooked, I would love to hear about it. (4) Not interpreting the GR to specify any particular interpretation of either the GFDL or the DFSG, and simply taking it at face value as a statement that the GFDL should be considered DFSG-free without affecting the interpretation of any other license. This position is not self-contradictory. We don't get to interpret the GFDL. It isn't a set of guidelines; it's a license, and what it literally says is what it means. However, this doesn't mean that the GR said the particular clauses in the GFDL are free; the GR just *defined* the GFDL *as a whole* to be free. It would thus not contradict the GR at all if we continued to interpret any identical clause in another license as non-free. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Results for Debian's Position on the GFDL
Anthony DeRobertis wrote: olive wrote: Some might argue that a court will read the GFDL in a more litteral sense. I do not think that because it seems very obvious that the copyright holder of a GFDL document don't want to restrict what you do with your own copy. Of course I might be wrong but for every license there is always a risk that a juge read it in a different way; Debian must read the license in the most probable way. Debian-legal has traditionally read licenses in a more pessimistic light; we didn't want to leave Debian — or its users — in danger of being sued for copyright infringement. I don't believe it's pessimistic to avoid attempting to attribute interpretations to a license which are not explicitly stated in the license itself. I don't believe that it is very obvious that the copyright holder of a GFDL document don't want to restrict what you do with your own copy, because the license they chose explicitly does so. We don't stretch interpretations of obviously free licenses to be non-free unless the copyright holder has explicitly stated that interpretation to be true (such as UW with PINE: oh, when we said 'and' we really meant 'or'). Similarly, we shouldn't stretch interpretations of non-free conditions to be Free if in the absence of a clarifiation from upstream, which we don't have here. (Note that my use of the phrase non-free conditions does not contradict the GFDL GR, which just states that the GFDL as a whole is defined to be DFSG-free without unmodifiable sections; the individual clauses can and should still be considered non-free in any other context, and may still render works non-distributable which would make the question of defined DFSG-freeness irrelevant.) - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: RFH: Non-free files in Emacs
Nathanael Nerode wrote: Files in the /etc directory of emacs21 which may be legally problematic follow. * There are a lot of files without any copyright or licensing information, and upstream probably will want to fix this. I would remove a lot of these even if they turn out to be free, as much of it is useless cruft. Upstream will almost certainly *not* want to fix this, as much as we might want them to. I don't think duplicating gnu.org/philosophy in the emacs source tarball is a particularly good idea, but the emacs authors (or at least those with a say in the matter) seem to. ObLicense: I hereby give permission to forward this message or any part of it (verbatim) to anyone who you think might find it useful. Heh. Second, files with explicit license notices which aren't standard free licenses, apart from the non-free files you already identified [...] COPYING -- Non-free (verbatim only), but we make an exception for it because it's the license for the program. Even if not a freeness issue, it should be removed in favor of /usr/share/common-licenses/GPL. [...] Finally, files with no explicit license notice. These are either free or non-distributable. The upstream emacs maintainers might want this list. GNU policy is generally to put a copyright and license notice in every file, and I suspect the absence from some of these files (like README and Makefile) is simply an oversight, and that these files are in fact FSF copyright. Frankly this directory could do with a good spring cleaning: anonymous cookie recipes are really not necessary, and 8-year-old order forms are ridiculous. That line of reasoning seems quite reasonable; at a minimum, perhaps they'd at least change it from legally ambigious to verbatim copying only, which would at least clarify the situation. [...] LPF -- does the organization even exist anymore? The most recent news item on http://lpf.ai.mit.edu/ dates from 2005-10-22, so they seem to still exist, if not with a great deal of activity. ISTR seeing this on gnu.org somewhere with a verbatim only license attached, but I could be wrong, and google doesn't seem to see it at the moment. Makefile I don't have this in my copy. celibacy.1 condom.1 -- Post-1988 (1992). Probably a better fit for the funny-manpages package than the emacs package. echo.msg -- Released 1985 in US without copyright notice, so public domain. Potentially modified since then; the CVS logs for emacs only go back to Sun Oct 3 12:34:45 1999, and that still leaves 14 years for potentially copyrightable modifications. In any case, more suited for the funny-manpages package than the emacs package. sex.6 -- Issued without copyright notice prior to 1988 (1987), so it's in the public domain. Modified since then, according to emacs CVS. In any case, more suited for the funny-manpages package than the emacs package. spook.lines -- unlikely to be copyrightable, so I would assume it is public domain Word lists can be copyrightable if the selection of the words involved actual creativity rather than an exhaustive list; that list certainly seems to qualify. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: RFH: Non-free files in Emacs
Jérôme Marant wrote:
Far away from flamewars and heated discussions, the Emacs maintainers
(Rob Browning and I) are in a process of moving non-free files to
a dedicated package.
Thank you very much for working on this.
In order to avoid repackaging as much as possible once done, we would
like to make sure that any problematic file has been identified
(they are all located in /usr/share/emacs/21.4/etc), so a second
review would be welcome.
The following files have already been identified as offending:
etc/{CENSORSHIP,copying.paper,INTERVIEW,LINUX-GNU,THE-GNU-PROJECT,WHY-FREE}
Thanks in advance for your help.
Just to confirm the parameters of this review, are you assuming that any
file not explicitly licensed falls under the GPL of Emacs? Or should we
flag files which have no explicit license? Quite a number of the files
in etc/ have no explicit license.
Also, etc/MOTIVATION contains:
[reprinted with permission of the author
from the Monday 19 January 1987 Boston Globe]
with no license notice given, and authorization to reprint does not
necessarily include authorization to modify.
- Josh Triplett
signature.asc
Description: OpenPGP digital signature
Re: Results for Debian's Position on the GFDL
MJ Ray wrote: Personally, I find it disappointing that so many people ranked opposite views high, then FD below them. I think the no, no matter what description of FD in the ballot is unhelpful and deters compromise attempts. I also tend to think that the presence of the absurd free in all cases (including invariant sections) option contributed to the belief that the free without invariant sections option was the compromise position, rather than the opposing view. Furthermore, I suspect that outside of debian-legal many people had long believed that invariant sections were the only issue with the GFDL, and that the call for a vote was thus the first exposure to the idea that the GFDL had other serious problems. Finally, I agree entirely with the suggestions that both of the GFDL is free options should have had a 3:1 requirement. Then only a handful of voters would need to have voted it below Further Discussion for it to have failed, which doesn't seem at all unlikely in the face of the above two points. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Antique RC bugs (many about licensing)
Nathanael Nerode wrote: Package: xserver-xorg (optional; Debian X Strike Force et al.) [xorg-x11/6.9.0.dfsg.1-4 ; =] [add/edit comment] 211765 [ ] xfree86: material under GLX Public License and SGI Free Software License B is not DFSG-free As far as I can tell, the philosophy of the most recent GR is that Debian should look for the spirit of the license -- and assume that licensors don't really mean what they say when they say things which contradict the spirit. While I think this is legally stupid, it is exactly what Adeoato said when he said that he didn't believe that the GFDL actually contained the restrictions on encryption etc. which it contains if read literally. As far as I can tell, the most recent GR states no more and no less than the idea that the GFDL should be considered DFSG-free without unmodifiable parts. Let's not compound the insanity by attempting to extrapolate these results to other licenses. Package: libnss-ldap (extra; Stephen Frost) [libnss-ldap/238-1.1 ; =] [add/edit comment] 199810 [ ] [NONFREE-DOC:RFC] Includes non-free documentation (RFC2307) More unmodifiable material. The do what I mean not what I say philosophy promoted by the recent GR may mean that this should not be considered unmodifiable, however. I'm not sure. See above, and also note that the GR specifically proscribed unmodifiable material. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Results for Debian's Position on the GFDL
Anthony DeRobertis wrote: The Project essentially told us our conclusion — the GFDL is not free — is wrong in the case where there are no invariant sections. The Project did not tell us why. There are several ways we can take this: 1. The Project intends this to be a one-time thing, applying only to the GFDL: No effect on future judgements of licenses is intended. I don't believe this is a valid interpretation of the GR as that'd require a 3:1 supermajority to achieve (just like Amendment B), and the ballot option did not require that. I believe this is a perfectly valid interpretation of the GR. The GR made no statement on the DFSG-freeness of any license other than the GFDL, and I see no good reason why we should extrapolate it. Let those who desire more permissive interpretations argue those interpretations and/or pass GRs; let's not play devil's advocate and argue their points for them. 2. The Project intends us to change how we interpret licences as they believe we have come to an incorrect conclusion. I believe this is the correct way to understand and act on the GR. I don't see how this can be read from the GR. A plurality of the Project has stated that the GFDL is DFSG-free. I don't believe we should take this as a reason to change our interpretations of other licenses as well, nor do I believe that we should attempt to guess the *intent* of the Project, particularly since such intent may vary greatly between various developers. To use the mathematical hyperbole: just because the project has legislated pi=3.14 doesn't mean we should start arguing e=2.72 and sqrt(2)=1.41 for them. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Packaging fst and dssi-vst
Free Ekanayaka wrote: |--== Stephen Gran writes: SG dssi is already in Debian, and doesn't use non-free software to build. SG For the other, I have no idea, but if it really needs non-free software SG to build, it's not suitable for main, at least. And indeed I was thinking to contrib, but I'm wondering if packages in contrib are allowed to build depend on non-free headers which are *not* in Debian due to license issues (this is the case of the VST SDK which I mentioned). Cleary this would imply that the package can't be build from source by build daemons, but should be built manually by the maintainer, who has agreed the VST SDK license and downloaded the headers. Yes, a package in contrib may require things which are not in Debian at all; for example, many Java packages in contrib require the Sun JDK, which Debian cannot distribute even in non-free. Not being able to autobuild is also OK; that's expected for many packages in contrib and non-free. Given that the package is specifically designed to run VST plugins from Windows, it seems pointless to go to a lot of effort to attempt to get it into main if most people will be using it with proprietary software anyway. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Missing documentation for autoconf
Simon Huerlimann wrote: Hi Frank On Monday, 20. February 2006 18:08, Frank Küster wrote: Frank Küster [EMAIL PROTECTED] wrote: How do you explain that you would like to continue to use GFDL'ed (or OPL'ed, for that matter) documentation, but refuse to add non-free to you sources list? Because I don't like packages that are considered non-free by Debian. I generaly support it's decissions on freeness and it's social contract. But I don't regard GFDL and OPL as non-free. (No need to react to this statement, as it's just a personal interpretation. I fully recognize the decission taken by the Debian developers.) As a technical solution to your problem, you could use /etc/apt/preferences to ensure that you don't get any non-free packages except those you specifically consider free enough, such as autoconf-doc. The following (untested) snippet should work: Package: * Pin: release c=non-free Pin-Priority: -1 Package: autoconf-doc Pin: release c=non-free Pin-Priority: 500 - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: portaudio in Debian, license updates?
Junichi Uekawa wrote: However, portaudio looks non-free to me. http://www.portaudio.com/license.html: * Any person wishing to distribute modifications to the Software is requested to send the modifications to the original developer so that they can be incorporated into the canonical version. Sounds quite clearly like a request to me, not a requirement. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Distriution of GPL incompatible libraries
Glenn L. McGrath wrote: This question doesn't directly relate to debian, but i hope you can help straighten me out with this. I'm trying to understand licensing obligations in regard to GPL'ed binaries that link to GPL incompatible libraries. OK. The current situation. A GPL'ed binary links to a shared library that is under the revised BSD license, the licenses are compatible so the distributer of unmodified GPL binaries must make the source to both projects available. The questionable situation A company distributes a GPL incompatible shared library that replaces the above mentioned BSD license library. A customer who downloads and installs this GPL incompatible library then has GPL'ed apps linked to GPL incompatible library. My understanding is that licences havent been violated by either the company or customer at this stage. Correct. The company hasn't distributed anything GPLed at all, and the customer is free to link together whatever they wish if they don't distribute the result. However, what if the customer then wanted to sell the machine, or if the company wanted to sell machines with this incompatible binary and library preinstalled. Would this violation the GPL, or is it possible that the companies modifcations are hiding behind the BSD license library ? This would violate the GPL. The violation occurs once you want to distribute a GPLed binary linked to a GPL-incompatible library. The fact that your distribution medium is an entire computer system does not change this. The confusing part for me is that the library is ABI compatible with a pre-existing compatible library, so I'm not sure when and by whom any problem occurs. The problem only occurs once you *distribute* the GPLed binary linked to the GPL-incompatible library. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Affero General Public License
Glenn Maynard wrote: A real example (from my own field) where this would cause serious practical problems is arcade machines. It's clearly public performance, and players in arcades really are using (and interacting with) the software directly. We include sources to GPL stuff on the machine's drive itself (though nobody cares, since none of it is modified except for the kernel, and that particular code is available on our webpage too). That's for the arcade operator (the owner of the machine). I have no idea how one might satisfy a requirement that the *users* be given GPL-like access to the source. Would it be an excessive requirement to provide an offer for source (at up to 10 times your cost of providing source)? The offer could easily be stuck in the fine print next to the copyright notices. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Affero General Public License
Glenn Maynard wrote: On Tue, Feb 07, 2006 at 02:10:23PM -0800, Josh Triplett wrote: They may require that if the work interacts with users, but the interface is such that those users do not receive a copy of the software, you must still satisfy the requirements of clause 6 (Non-Source Distribution) as though you had distributed the work to those users in the form of Object Code. Although the interface is such that bit feels a little awkward, this is a step forward. If I use a source file from eg. Apache in a tiny embedded device, allow me to supply the source (that won't even fit on the device, never mind that the device has no I/O suitable for sending source) on an included CD. I'm assuming here that this tiny embedded device is not a product being provided to users, right? That case is already covered by GPLv2 and GPLv3 without the need for any clause of this nature: distributing a product containing GPLed code is distributing the GPLed code, and thus you must provide the source code, which you may on an included CD or via a 3-year offer. So you're talking about a tiny embedded device which interacts with a user but isn't distributed to that user? It excludes from users (still ill-defined) people who don't interact, which is an improvement. I'm inclined to say that we can leave users undefined here, and rely on the common-sense definition (people who use the software), because we're defining a particular set of uses, namely interaction. Even with the broadest possible reading of users, you still take the subset of those who interact with the software. The more important issue is the use of interact, as you mentioned: What about supermarket self-check-out, ATMs, self-service gas stations, toll booths, voicemail, arcade machines? Software interacts with users in every way imaginable ... Well, to start with, it sounds like you agree that there's a subset of interact which is free, namely interact over a computer network. That alone would cover many of the cases people care about when they want this type of clause, so going with that option is worth considering. Going slightly broader, in most cases it doesn't seem particularly problematic to provide a 3-year-offer or a CD; in many of the cases, the source distribution mechanims must already exist in order to provide source to those who originally put those fixtures in place. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Affero General Public License
Mark Rafn wrote: On Tue, 7 Feb 2006, Josh Triplett wrote: They may require that if the work interacts with users, but the interface is such that those users do not receive a copy of the software, you must still satisfy the requirements of clause 6 (Non-Source Distribution) as though you had distributed the work to those users in the form of Object Code. My first suggestion would be to try to word a license clause you believe meets the requirements, THEN figure out how to word GPLv3 to be compatible with it. The extra layer of indirection is confusing. The extra layer may be slightly confusing, but there's a good reason to attempting to frame a compatibility clause in this manner. If we phrase a particular clause, that won't necessarily help us judge another such clause. If we craft a description of the type of such clauses which we find acceptable, then we have a useful gauge to use when evaluating licenses, as well as useful text for the GPLv3. My second is that you will need to define interacts and users pretty carefully here. I have a lot of code I wrote that doesn't interact with users, but with other programs (say, Apache) that interact with other programs (say, a TCP/IP stack) that interact with other programs (routers, other tcp/ip stacks, and finally a browser program) that may have a user. I believe I could reasonably claim that I am the sole user of the software, as I caused it to be run. I agree somewhat with this issue. We may need to clarify the distinction between software which interacts and software which provides a transport for unmodified data. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Affero General Public License
Benj. Mako Hill wrote: The second argument is it fails the much more generic DFSG3 must allow modification argument. Barring modification of the license and copyright statement seems completely uncontroversial for obvious reasons. Similarly, there is consensus that barring modification of significant pieces of functionality seems to encroach users' freedom. The GPL(2)(c) seems OK although there are a number of interpretations why that is. [...] Many/most others have gone with the second argument and are saying that the problem is primarily with the way the AGPL has done it. I'd love to hear suggestions for a better way to do it. I believe the AGPL fails the DFSG due to being technology-specific. By requiring HTTP, and requiring that you must transmit the source *via the software itself*, it prohibits derived works which don't include an HTTP server, failing DFSG3. As a practical matter, it also makes it impossible to distribute a compiled version which doesn't include its own source in the binary package (For that matter, a strict reading of the AGPL and the words must not remove that facility might actually suggest that you can't change that particular chunk of code at all, even if you continue to offer the source via HTTP.) Similarly, the compatibility clause in GPLv3, They may require that the work contain functioning facilities that allow users to immediately obtain copies of its Complete Corresponding Source Code. has the problem of allowing a requirement for immediate distribution, which is far more restrictive than the general source distribution requirement for other types of distribution, and depending on the interpretations of immediate and users (which in turn depend on the license someone writes to fit this compatibility clause), quite possibly non-free. A clause of this form which satisfies DFSG3 needs to avoid requiring particular technologies. Furthermore, it needs to avoid being more restrictive about requiring source distribution to users compared to the case of distributing source to those who have a binary distributing a binary. I suggest the following, phrased in the form of a GPLv3-style compatibility clause: They may require that if the work interacts with users, but the interface is such that those users do not receive a copy of the software, you must still satisfy the requirements of clause 6 (Non-Source Distribution) as though you had distributed the work to those users in the form of Object Code. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Affero General Public License
Benj. Mako Hill wrote: Thanks, Josh. This was a pretty cogent and helpful explication. Thank you. :) quote who=Josh Triplett date=Mon, Feb 06, 2006 at 11:02:20PM -0800 There are two separate, mostly-independent issues with the AGPL: 1) The issue of whether this type of clause is OK at all. This is certainly an open issue. I lean towards saying that it is theoretically possible for such a clause to be free but that no such clause has been written in an existing license. I think the most likely way to achieve a free clause of this type would be to base it on the GPL and phrase it in such a way as to impose exactly the same clauses which apply to distribution, along with all the proposed alternatives. Would you be willing to work on drafting an example of such language for the GPLv3? Gladly. See my previous response to you elsewhere in this thread for specific text, as well as answers to several of the other points you raised in this mail. I've also provided that specific text as a comment to that clause on the GPLv3 site (though since I sent it via email, it may take some time to appear). - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Affero General Public License
Benj. Mako Hill wrote: quote who=Steve Langasek date=Mon, Feb 06, 2006 at 06:20:25PM -0800 On Tue, Feb 07, 2006 at 02:00:03AM +, Kai Hendry wrote: There is a python library I want to package (#349763) that uses the Affero General Public License (AGPL). http://www.affero.org/oagpl.html I thought I should just check with you guys if the license is OK for Debian. No, it is not. The requirement of source redistribution to third parties that you are not distributing binaries to is incompatible with the DFSG. I don't think that issue is a closed one. As you and others have mentioned in other threads, the GPLv3 will probably have a Affero-type clause. Several people, at least, have spoken up in favor of this sort of clause being both in the spirit of the GPL and the DFSG. There are two separate, mostly-independent issues with the AGPL: 1) The issue of whether this type of clause is OK at all. This is certainly an open issue. I lean towards saying that it is theoretically possible for such a clause to be free but that no such clause has been written in an existing license. I think the most likely way to achieve a free clause of this type would be to base it on the GPL and phrase it in such a way as to impose exactly the same clauses which apply to distribution, along with all the proposed alternatives. 2) The specific clause written in the AGPL. Even if the answer to (1) is that such clauses are fine in general, the particular clause in the AGPL makes restrictions pertaining to particular technologies. It is not possible to modify AGPLed software in such a way that it no longer contains an HTTP server. This seems quite obviously non-free. Even if there was some sort of rough consensus on the AGPL in the past, I think that we need to *at least* discuss this a bit more and and a bit more widely before we risk writing off some large future subset of GPL works as being non-free. I believe issue 1 merits further discussion. However, regarding issue 2, I don't believe the clause in the AGPL is anywhere near free, and I don't see how any possible reading of the DFSG could permit it. As it turns out, I tend to be of the opinion that it is important enough that users be able to have access to the source code of the programs they use that we can probably sustain a strictly targetted and flexibly defined limit on modification that serves only to protect this freedom. Are you suggesting that such restrictions are acceptable under the DFSG, or are you suggesting that such restrictions might be beneficial and thus we should adapt the DFSG to permit them? We did something similar both for copyleft in general True. However, note that copyleft seems to be specifically permitted by the DFSG, since it only requires that modifications and derived works be distributable under the same terms as the license of the original software. and for GPLv2(2)(c) in particular. Bad example; if that clause were in any other license, it probably would have been declared non-free a long time ago. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: gpl and hosted apps
David M.Besonen wrote: does the gpl (v2 or v3-draft) address the issue of hosted apps? specifically, does the gpl prevent someone from taking code, modifying it, and putting it on a server and charging people to use the app without making the source available? The GPL version 2 does not. The GPL version 3 does not directly, but it permits licensors to add such a condition without being incompatible with the GPL version 3. In any case, such a condition may or may not be considered Free by Debian, but I suspect that debate will wait until someone wants to package a piece of software using such a clause on top of the GPL version 3. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: gpl and hosted apps
David M.Besonen wrote: On Fri, 03 Feb 2006 17:51:25 -0800, Josh Triplett [EMAIL PROTECTED] wrote: The GPL version 2 does not. The GPL version 3 does not directly, but it permits licensors to add such a condition without being incompatible with the GPL version 3. could you point me to this optional clause? See section 7, and in particular clause d, at http://gplv3.fsf.org/draft. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Creative Commons negotiations
Evan Prodromou wrote: Here's the poop, in a nutshell: after a few months of back-and-forths, we worked out a draft license that the working group felt was compatible with the DFSG. CC hopes to apply the changes to the upcoming CC 3.0 license suite draft, and that version will be available for public review. Unless there are other changes that make the licenses non-free (they're dealing with other groups besides Debian, of course), the 3.0 Attribution and Attribution-ShareAlike licenses should be DFSG-compatible and we should allow works available under those licenses in main. Excellent! Thank you very much for your work on this issue. Works under CC licenses with the NoDerivs or NonCommercial elements will still be incompatible with the DFSG, of course, and works under 1.0, 2.0, and 2.5 versions of the Attribution and Attribution-ShareAlike licenses will still be incompatible. But for upstream projects that use earlier versions of by or by-sa, there should be a clear upgrade path. This seems like one case where it is rather unfortunate that CC didn't standardize on an or any later version model. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Anti-DMCA clause (was Re: GPL v3 Draft
Walter Landry wrote: Nathanael Nerode [EMAIL PROTECTED] wrote: Walter Landry [EMAIL PROTECTED] wrote: That is the basic problem with these anti-DRM clauses: differentiating between DRM and legitimate privacy controls is basically impossible. I think it is possible. It requires a sharp focus on the *legal* issues, since the technology is not different, but the legal basis is. A legitimate privacy control may control access to many things -- but it does *not* exert control over works you have published (since they're, well, *public*.) A legitimate privacy device may function very much like DRM. Consider classified environments, where you really don't want people to copy things around willy-nilly. Making it hard to copy information won't eliminate leaks, but it will reduce them. I don't see why making a system to handle classified documents should be disallowed by the GPL. Again, the goal of this clause isn't to prohibit the creation of such systems. The goal is merely to curtail the application of laws such as the DMCA which would give such systems the force of law. I believe the best solution to this confusion would be to frame the clause with something like For the purposes of [laws like the DMCA, stated in some generic manner] This does raise another interesting point: there are laws in some jurisdictions which mandate the use of certain measures to protect privacy in certain situations, such as patient medical records. It would be problematic if this clause was taken as a legal definition in those cases as well, preventing the use of GPLed software for that purpose. Thus, the above indication of scope might actually be necessary, with a sufficiently narrow description of DMCA-like laws. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Bug#349279: tailor: _process.py seems under non-GPL license
Osamu Aoki wrote: Thanks for saving lost soul. On Sun, Jan 22, 2006 at 12:58:28AM -0800, Josh Triplett wrote: This clause is universally interpreted to mean that the permission is granted and you don't need to pay a fee to get that permission; in other words, for any purpose and without fee is granted is equivalent to for any purposes is granted without fee. A quick google over the debian-legal archives shows that this issue has been discussed and resolved as early as 1999, and that it nevertheless comes up numerous times after that. Hmmm. I see. Good explanation, thanks. I also found: http://lists.debian.org/debian-legal/1999/08/msg00049.html Good old BSD license variants... Further check dropped me to: http://lists.debian.org/debian-legal/2004/02/msg00102.html This was good reference. So this license in _process.py is GPL incompatible as is. subprocess.py one is GPL compatible. I don't see how those messages give you the impression that this license is not GPL-compatible. The license is in fact a BSD license, sans advertising clause, and is thus GPL-compatible. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Bug#349279: tailor: _process.py seems under non-GPL license
Osamu Aoki wrote: On Sat, Jan 21, 2006 at 04:52:23PM -0800, Walter Landry wrote: Osamu Aoki [EMAIL PROTECTED] wrote: This license only gives permission when fee is not charged. That seems to be DSFG1 violation. Also mixing code of GPL and this seems to be incompatible. This is a fairly standard license. The usual way of interpreting it is that you need not pay any fees in order to copy, modify, or distribute. Hmmm... I disagree. Do you have any reference to substantiate this? Making unsubstantiated judgment on this list is not a good idea. Please reread the license of this file:(Emphasis, me) # Permission to use, copy, modify, and distribute this software and # its associated documentation for any purpose and without fee is ^^^ # hereby granted, provided that the above copyright notice appears in # all copies, and that both that copyright notice and this permission # notice appear in supporting documentation, and that the name of the # author not be used in advertising or publicity pertaining to # distribution of the software without specific, written prior # permission. This means there is no explicit permission if fee is charged. Permission is granted for without fee only. So this software is without license and undistributable for my understanding for people who charge fees. I think lha in non-free is a good reference for my judgement. Can you point me to a package in main with this kind of license only? Quite a number of them: $ grep 'without fee' -irl /usr/share/doc/*/copyright | wc -l 324 And that's just on my system, containing no non-free packages. (A few of those occurrences use clearer variants of the wording; most do not.) A few random examples include aspell-en, classpath, curl, docbook, fontconfig, gimp-data, groff, libboost*, libpng, netpbm, ntpdate, python, reportbug, and most of X. This clause is universally interpreted to mean that the permission is granted and you don't need to pay a fee to get that permission; in other words, for any purpose and without fee is granted is equivalent to for any purposes is granted without fee. A quick google over the debian-legal archives shows that this issue has been discussed and resolved as early as 1999, and that it nevertheless comes up numerous times after that. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: GR: GFDL Position Statement
Francesco Poli wrote: Or otherwise, povray upstream authors could be persuaded to relicense in a DFSG-free manner, so that we would *gain* one new interesting package for main, rather than *losing* one (that was wrongly placed in main). ;-) povray upstream actually *wants* to change the license to be open; they simply have the standard problem of being unable to get permission from all contributors. Thus, the only way to relicense is to rewrite. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: GR: GFDL Position Statement
Francesco Poli wrote: On Wed, 18 Jan 2006 17:32:48 +0100 Gerfried Fuchs wrote: * Anthony Towns aj@azure.humbug.org.au [2006-01-18 11:01]: As an example I want to question if I would have to move xblast* to contrib, because the graphics are rendered with povray, or if there is no need for it? There are for sure other graphics that fall under the same thing; at least I can say for xblast that I'm in the good position to have the povray source available with which the images were rendered. But would producing them on build-time really raise the quality, moving xblast* to contrib? If this is done then please think of other packages with the same problem, too. I think it should be moved to contrib and graphics should be rerendered from its actual source at build time. Consider this: if I wanted to fork xblast by modifying the graphics, I would need the povray source (and the povray program, which is unfortunately non-free). Every attempt to change (for example) the camera positioning would from hard to nearly impossible without povray source files. Hence, the preferred form for making modification to xblast graphics is the corresponding povray files (unless they are on their turn automatically generated from something else...). One useful point here is that there exist Free renderers for POVRay files, such as KPovModeler. I don't know to what extent they implement the features of POVRay. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: GR: GFDL Position Statement
Andrew Donnellan wrote: Umm, Kpovmodeler isn't a renderer, it's a modelling program that calls POVRay to actually render it. So KPovModeler should be in contrib. Hmmm. The description certainly didn't give that indication, nor did the fact that povray was only in Suggests. If it has no functionality without povray, I agree that it should be in contrib; if it can be useful without povray, the current situation is fine. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Clause 7d (was Re: Ironies abound (was Re: GPL v3 draft)
Nathanael Nerode wrote: The key point here was that the clause suffered from specifying means rather than ends, which we have diagnosed as a major source of license drafting errors. By restricting the functionality of the program and all derivative works, it causes endless trouble. That perfectly describes my problem with the clause as written. Instead, I attempted to rewrite this as a restriction which could be imposed on the recipients of the license. So here it is: 7d. They may require that propagation of a covered work which causes it to have users other than You, must enable all users of the work to make and receive copies of the work. This leverages the careful definition of propagate up top, so that it avoids restricting any acitivities which do not require a copyright license. A restriction along these lines would mean that (1) it imposes no restrictions on the *writers* of derivative works (2) If you've already distributed (or offered to distribute) the work to all its users (the normal case and the troublesome one for the original clause), you have no additional obligations (3) making the program available for users over the Internet (or on a local server) -- if and only if that requires a copyright license, which it probably does -- requires that you provide access to the source code to those users, according to the usual GPL v3 clauses regarding distributing copies. What do other people think of this? It's sort of a forced distribution clause, but it only forces distribution to the people you're already allowing to use the program. If it's considered acceptable, we could push to have this replace the proposed (7d). I believe this clause addresses the issue perfectly, and I agree with proposing it as a replacement. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Ironies abound (was Re: GPL v3 draft)
Matthew Garrett wrote: Glenn Maynard [EMAIL PROTECTED] wrote: I also don't understand why anyone would actually want to defend patch clauses. There are very few of them left, so I don't think there's much of that don't want my pet package declared non-free agenda going on, and it seems like an obviously unreasonable hurdle to reuse. It seems like a compromise whose time has passed. I'm not going to defend patch clauses. I think they're massively horrible things, and the world would be a better place without them. But deciding that they're not free any more would involve altering our standards of freedom, and I don't see any way that we can reasonably do that. Why not? There is an established procedure in place for doing so. Obviously such a thing should not be done lightly, but that doesn't mean it cannot be reasonably done at all. It would be useful, before proposing a GR to do so, to have a list of all the packages currently in main which would become non-free if this clause were abolished, as well as any well-known licenses which might be affected. Offhand, the only package I know of which is currently in main and under a patch-clause license is gnuplot, and I don't know of any well-known DFSG-free licenses (used on more than one project) which include a patch clause. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: GPL v3 Draft
Florian Weimer wrote: * Glenn Maynard: a) The modified work must carry prominent notices stating that you changed the work and the date of any change. This is so widely violated that it's clear that it's not working; it'd be nice if they would acknowledge this and remove it. Yes, this is indeed a problematic thing in version 2 that can and should be fixed. This has actually been improved in GPLv3: version 2 says the modified files, whereas version 3 says the modified work. Their rationale document states that this should permit people to keep a separate changelog, rather than keeping changes in individual source files. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: GPL v3 Draft
Bas Zoetekouw wrote: Hi Glenn! You wrote: 3. Digital Restrictions Management. As a free software license, this License intrinsically disfavors technical attempts to restrict users' freedom to copy, modify, and share copyrighted works. Each of its provisions shall be interpreted in light of this specific declaration of the licensor's intent. Regardless of any other provision of this License, no permission is given to distribute covered works that illegally invade users' privacy This is a butterknife being boxed with a you may not sharpen this knife and stab people with it notice: that's already illegal, and it just serves to complicate the license. I don't agree. The _use_ of a program can be illegal in some jurisdiction, while the program itself and its distribution need not be illegal. Also, does this clause apply if I use GPLv3 code to write a spyware program that is illegal in (e.g.) the US, but not in my home country? IMO, this is a clear violation of DFSG 6. If we allow terrorists to use our code, and allow it to be used in biological weapons research, clearly also black hat hackers must be allowed to use it to produce spyware. It seems particularly hypocritical in light of http://www.gnu.org/licenses/hessla.html: The restrictions in the HESSLA prohibit specific activities that are inexcusable: violations of human rights, and introduction of features that spy on the user. People might ask why we do not declare an exception for these particular restrictions--why do we stick to the general policy of rejecting all restrictions on use and on the functionality of modified versions? If we were ever going to make an exception to our principles of free software, here would be the place to do it. But it would be a mistake to do so: it would weaken our general stand, and would achieve nothing. Trying to stop those particular activities with a software license is either unnecessary or ineffective. In regard to modified versions, the HESSLA's restrictions are unnecessary. The GNU GPL is sufficient protection against privacy-violating features, because it ensures that someone can get the source code, find the spyware feature, and publish an improved version of the software which does not have the feature. Users can then switch to that version if they don't want their personal information to be reported. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Translation of a license
Tobias Toedter wrote: On Sunday 15 January 2006 21:12, Andrew Donnellan wrote: I think you can, except the FSF requires that you place a notice, in English, saying 'This is an unofficial translation and the original English version is the only legal one', which obviously doesn't look very good on the program's copyright notice. So in summary it would probably be better to leave the license untranslated, right? Yes. Furthermore, given that the license notice should not be translated, I would suggest that the use of gettext on the license notice strings is a bug. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Is libreludedb DFSG compliant?
Marco Franzen wrote: Josh Triplett wrote: Mickael Profeta wrote: If you link LibPreludeDB against other code all of which is itself ^^^ licensed under the terms of the GNU General Public License version 2 dated June 1991 (GPL v2) or compatible, then you may use LibpreludeDB under the terms of the GPL v2,as appearing in the file COPYING. If the ^ file COPYING is missing, you can obtain a copy of the GPL v2 from the Free Software Foundation Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA. This looks fine to me. What if I don't want to link it? I may want to - just publish (parts of) the source code (or (of) a modified version) - modify it into something that isn't a library and publish the source - paste code fragments into an embedded/free-standing application (which does not link against anything, not even libc), maybe with some modifications to fit the new environment - copy code fragments into documentation With the above I have no license to do any of that. I am not even sure I am allowed to make a private copy (jurisdiction dependency?). This may not look like a freeness issue because one could always do some trivial linking first to get the GPL grant. But if the code does not compile on any system available to me, then I have no licence to change it into something that I can compile and link... I think what the licensor really means is to license it under the GPL, so they should do just that rather than trying to paraphrase the GPL in one sentence or trying to grant the GPL licence conditionally or whatever it is they are trying there. I think they just mean to say that the GPL is not the LGPL. If they feel they really need to say that, they can do so outside the formal licence grant: use the standard This is free software... boilerplate and then add something not legally binding, like Note that the GNU GPL requires you... if they must. Although I'd prefer they didn't. Hmmm. When I read this statement, I interpreted link broadly here, in the sense which includes combinations with other code that do not necessarily involve invoking a linker. Furthermore, I read it not as you must link it with GPL or compatible software in order to be used under this license, but as for all software linked to it, that software must be GPL or compatible, making it still vacuously true that the software is GPL if linked with nothing else. Thus, the statement seemed compatible with (and redundant given) the GPL. If either of those two assumptions was not the intended reading of the statement, then I agree entirely with your argument that the statment renders the software non-free. In any case, yes, the simplest solution is to avoid making such explanations in a form that makes them look like additional conditions of the license. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Is libreludedb DFSG compliant?
Glenn Maynard wrote: On Mon, Jan 02, 2006 at 02:50:23PM +0100, MJ Ray wrote: Mickael Profeta [EMAIL PROTECTED] If you link LibPreludeDB against other code all of which is itself licensed under the GNU General Public License, version 2 dated June 1991 This should probably say available under the terms of BSD-licensed software is not licensed under the GPL; it's licensed under a GPL-compatible license. licensed under is fine, because this new modified version adds or compatible license, making the net result licensed under [GPL], or compatible license: (GPL v2), or compatible license, then you may use Libprelude under the ^ - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Trolltech GPL violation?
Brian Nelson wrote: [EMAIL PROTECTED] writes: Trolltech releases the Open Source Edition of Qt under the GPL. The complete package downloadable from their website includes the libraries, tools like qtdesigner, and documentation in .html format. Source code for the libraries and tools is provided. However, no source code is provided for the .html documentation files. The source code for the documentation is embedded as comments in the program source code, in a doxygen-like way. Trolltech has not, to my knowledge, released the tool they use to generate the HTML from the comments. I think their plan for Qt4 was to convert to using doxygen since that's a more robust tool than their internal stuff anyway. I'm not sure if that ever happened though. Rather than immediately jumping to qt is non-distributable, perhaps someone could just *ask* Trolltech if they could provide the tool they use to generate the HTML from the comments. Preferably without bringing up the legal issue, since this is also a simple technical issue. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Is libreludedb DFSG compliant?
Mickael Profeta wrote: Florian Weimer wrote: * Mickael Profeta: If you link LibPreludeDB against other code all of which is itself licensed under the GNU General Public License, version 2 dated June 1991 (GPL v2), then you may use Libprelude under the terms of the GPL v2, as appearing in the file COPYING. It seems that libpreludedb links against the libpq, the PostgreSQL client library, which is not licensed under the GPL (only under a GPL-compatible license). This means that Debian would need a commercial license. However, I doubt that this is what upstream intended. Just got the answer of upstream: The LICENSE.README file highlight the fact that is is not legal to link a non GPL work (meaning proprietary work) to libpreludedb. LibpreludeDB itself is GPL. But proprietary program can't link against libpreludeDB unless they get a commercial license. I think the LICENSE.README file could be modified to add the missing bit about the GPL compatible license. Would that be acceptable ? Would such a modification be enough, or should it be more deeply modified? That would be sufficient, assuming all copyright holders of the work agree to the change. It would also help to make it clear that the information in LICENSE.README is phrased simply as a description of the effect the GPL already has, rather than as a separate condition imposed in addition to the GPL. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Bug#344707: ITP: ispell-et -- Estonian dictionaries for ispell, aspell, myspell
Justin Pryzby wrote: On Sun, Dec 25, 2005 at 01:05:44PM +1100, An?bal Monsalve Salazar wrote: On Sun, Dec 25, 2005 at 01:50:32AM +0200, Martin-?ric Racine wrote: Package: wnpp Severity: wishlist Owner: Martin-??ric Racine [EMAIL PROTECTED] Package name : ispell-et Version : 20030606 URL : http://www.meso.ee/~jjpp/speller/ aspell-et - Estonian dictionary for aspell iestonian - Estonian dictionary for ispell myspell-et - Estonian dictionary for myspell openoffice.org-hyphenation-et - Estonian hyphenation pattern for OpenOffice.org The ispell affix and wordlists, as well as the OOo hyphenation were found as standalone files at the above URL, along with explanations in Estonian about the origin of all files. Everything else is generated by my own debian/rules. The above version is timestamp of the last update produced by Jaak Pruulmann. I already have packages ready to upload. I however need to verify whether the software license of the Institute of the Estonian Language is considered free according to Debian policies, before I proceed with the upload. Copyright: 2003-2005, Jaak Pruulmann [EMAIL PROTECTED] (updated wordlist) 1996-1999, Institute of the Estonian Language [EMAIL PROTECTED] (original wordlist) 1993, Enn Saar [EMAIL PROTECTED] (TeX hyphenation, converted for OpenOffice by Jaak) License: The present Licence Agreement gives the user of this Software Product (hereinafter: Product) the right to use the Product for whatever purpose (incl. distribution, copying, altering, inclusion in other software, and selling) on the following conditions: 1. The present Licence Agreement should belong unaltered to each copy ever made of this Product; 2. Neither the Institute of the Estonian Language (hereinafter: IEL) nor the author(s) of the Product will take responsibility for any detriment, direct or indirect, possibly ensuing from the application of the Product; 3. The IEL is ready to share the Product with other users as we wish to advance research on the Estonian language and to promote the use of Estonian in IT-technology now rapidly developing, yet we refuse to bind ourselves to any further obligation, which means that the IEL is not obliged either to warrant the suitability of the Product for a concrete use, to improve the program, or to provide a more detailed description of the underlying algorithms. (Which does not mean, though, that we may not do it.) 4. Whenever you use the Product, we request that you inform us by writing to the e-mail address [EMAIL PROTECTED] or to street address listed below. Non-free clause. Every time you use it, you will have to send an email or a letter to them. Really? Isn't 'request' the phrase often recommended on -legal for such things? (though I understand that the license isn't the right place). Yes. As phrased, it sounds like a non-binding request to notify them, not a demand. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: kaid license non-free?
Andrew Donnellan wrote: On 12/21/05, Henning Makholm [EMAIL PROTECTED] wrote: Scripsit Cameron Dale [EMAIL PROTECTED] * Any form of redistribution which connects to the published Team XLink Orbital Server list resource, for Orbital Server aquisition, or otherwise, or which interoperates with any existing software used by other member(s) of the XLink Kai: Evolution VII service, must be provided to end users at no cost, and may not contain advertising information of any sort, aside from one permitted link in an About dialog window which is not displayed unless the user explicitly directs the software to display it. This is a non-free condition. It must be possible to sell copies of Debian packages. It only causes problems when you are connecting to the XLink Kai: Evolution VII service, but I assume that the main point of the software is to connect to that service, so unless someone else starts up an alternative server, for pratical reasons, it's non-free. Actually, the last part of the clause is far broader than that: or which interoperates with any existing software used by other member(s) of the XLink Kai: Evolution VII service needs no stretch of interpretation to apply to almost any modified version. As for the rest of it, restrictions on what you can connect to a particular service should be in the terms of use for that service, not in a software license. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: EPICS Open License
Carlo Segre wrote: It seems to me that the EPICS Open License is DFSG Compliant. The only difference from a BSD-type license is that the U.S. Govenment has a nonexlusive irrevocable license and that any changes to the source must contain a statement of such changes having been made. I agree with your assessment; this license appears to be DFSG-free. I include the text of the license below. Full quote of license text retained for context. - Josh Triplett -- EPICS Open License Terms The following is the text of the EPICS Open software license agreement which now applies to EPICS Base and many of the unbundled EPICS extensions and support modules. Copyright (c) University of Chicago and other copyright holders. All rights reserved. PRODUCT is distributed subject to the following license conditions: SOFTWARE LICENSE AGREEMENT Software: PRODUCT 1. The Software, below, refers to PRODUCT (in either source code, or binary form and accompanying documentation). Each licensee is addressed as you or Licensee. 2. The copyright holders shown above and their third-party licensors hereby grant Licensee a royalty-free nonexclusive license, subject to the limitations stated herein and U.S. Government license rights. 3. You may modify and make a copy or copies of the Software for use within your organization, if you meet the following conditions: a. Copies in source code must include the copyright notice and this Software License Agreement. b. Copies in binary form must include the copyright notice and this Software License Agreement in the documentation and/or other materials provided with the copy. 4. You may modify a copy or copies of the Software or any portion of it, thus forming a work based on the Software, and distribute copies of such work outside your organization, if you meet all of the following conditions: a. Copies in source code must include the copyright notice and this Software License Agreement; b. Copies in binary form must include the copyright notice and this Software License Agreement in the documentation and/or other materials provided with the copy; c. Modified copies and works based on the Software must carry prominent notices stating that you changed specified portions of the Software. 5. Portions of the Software resulted from work developed under a U.S. Government contract and are subject to the following license: the Government is granted for itself and others acting on its behalf a paid-up, nonexclusive, irrevocable worldwide license in this computer software to reproduce, prepare derivative works, and perform publicly and display publicly. 6. WARRANTY DISCLAIMER. THE SOFTWARE IS SUPPLIED AS IS WITHOUT WARRANTY OF ANY KIND. THE COPYRIGHT HOLDERS, THEIR THIRD PARTY LICENSORS, THE UNITED STATES, THE UNITED STATES DEPARTMENT OF ENERGY, AND THEIR EMPLOYEES: (1) DISCLAIM ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE OR NON-INFRINGEMENT, (2) DO NOT ASSUME ANY LEGAL LIABILITY OR RESPONSIBILITY FOR THE ACCURACY, COMPLETENESS, OR USEFULNESS OF THE SOFTWARE, (3) DO NOT REPRESENT THAT USE OF THE SOFTWARE WOULD NOT INFRINGE PRIVATELY OWNED RIGHTS, (4) DO NOT WARRANT THAT THE SOFTWARE WILL FUNCTION UNINTERRUPTED, THAT IT IS ERROR-FREE OR THAT ANY ERRORS WILL BE CORRECTED. 7. LIMITATION OF LIABILITY. IN NO EVENT WILL THE COPYRIGHT HOLDERS, THEIR THIRD PARTY LICENSORS, THE UNITED STATES, THE UNITED STATES DEPARTMENT OF ENERGY, OR THEIR EMPLOYEES: BE LIABLE FOR ANY INDIRECT, INCIDENTAL, CONSEQUENTIAL, SPECIAL OR PUNITIVE DAMAGES OF ANY KIND OR NATURE, INCLUDING BUT NOT LIMITED TO LOSS OF PROFITS OR LOSS OF DATA, FOR ANY REASON WHATSOEVER, WHETHER SUCH LIABILITY IS ASSERTED ON THE BASIS OF CONTRACT, TORT (INCLUDING NEGLIGENCE OR STRICT LIABILITY), OR OTHERWISE, EVEN IF ANY OF SAID PARTIES HAS BEEN WARNED OF THE POSSIBILITY OF SUCH LOSS OR DAMAGES. signature.asc Description: OpenPGP digital signature
Re: Bioapi license DFSG free ?
Arnaud Fontaine wrote: With this kind of license, all the GPL'ed software that using this API (for instance pam-bioapi which is using bioapi) should have : Specific permission is granted for the GPLed code in this distribition to be linked to BioAPI without invoking GPL clause 2(b). in the copyright file in order to be put in main debian section, right ? Not necessary; the license you posted is compatible with the GPL. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: pymedia DFSG compliant ?
Arnaud Fontaine wrote: Pymedia can also use mp3lame or libfaad2, but it is optional, however could pymedia be package with these features ? If you can build the package in such a way that it makes use of these libraries if they are available on the user's system, without actually needing the libraries present in order to build pymedia, then you could ship pymedia with those features enabled such that any user with the appropriate packages installed would have that functionality. The same thing is done by packages which want libdvdcss. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Bug#335898: bogus all rights reserved message
Robert Millan wrote: On Wed, Oct 26, 2005 at 11:16:14AM -0500, Jeffrey L. Taylor wrote: Quoting Robert Millan [EMAIL PROTECTED]: Package: kfreebsd-5 Severity: normal The following lines are printed by kFreeBSD when boot starts: Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. I think there two problems with that: - All rights reserved would imply that the software is not licensed at all, which isn't true. The answers I got from #debian-devel indicate it's perfectly legal to remove this message for clarification. Not unless you are the copyright holder. IIRC, the phrase All rights reserved. is required for copyrighted material in some Latin American countries. Without it, it isn't copyrighted. I.e., All rights reserved. is the equivalent of Copyright 2005 I. Author. Of course, IANAL. That is correct. According to what I've been told in #debian-devel (which makes sense to me), all rights reserved means you have no right to use this software. In the absence of some additional terms constituting a Free license: yes, the same way that Copyright 2005 J. Random Hacker means you have no right to use the software. However, the licensing terms in the source code should take preference. Correct. If additional clarification is desired at boot time, a note could be added saying that the software was available under the BSD license; alternatively, you could remove the copyright notice *from the boot messages* (since it is not the copyright notice which is governing the work). - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Bug#335898: bogus all rights reserved message
Robert Millan wrote: On Wed, Oct 26, 2005 at 10:21:40AM -0700, Josh Triplett wrote: - All rights reserved would imply that the software is not licensed at all, which isn't true. The answers I got from #debian-devel indicate it's perfectly legal to remove this message for clarification. ^ Not unless you are the copyright holder. I meant to say from the boot message here. Does this also apply to the boot log? Your other response below seems to indicate otherwise: [...] alternatively, you could remove the copyright notice *from the boot messages* (since it is not the copyright notice which is governing the work). Right; you can't remove the copyright notice or the all rights reserved notice that actually governs the work itself, but you can definitely remove a random print statement from the boot messages. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Java License
João Pinheiro wrote: I'm currently working on a Debian/Ubuntu-based Linux LiveCD Distribution to be used by the students at my university. The goal of this distro is to provide students with a development environment featuring everything they might need to use for all of their subjects throughout the entire semester. This would obviously require me to bundle Sun's JDK along with the distro. I would seriously question the obviously there. Perhaps a technical solution might serve better than a legal one here. Are these computer science students needing to write Java code, or is there some Java application that your university wants students to use? In the former case, almost any Java software that a student might need to write is highly likely to work on most of the Free JDKs available in Debian; try gcj, gij, sablevm, kaffe, or jamvm. If they are specifically learning the Java language (and not just using it for a standard CS class), then try the Jikes compiler, as it will quote chapter and verse of the Java specification to explain compiler errors. Even Swing code is relatively likely to work nowadays. Ant is available for building Java software, and many Java libraries and applications are packaged in main. In the latter case, you should still try using the various Free JDKs; they work well for a large range of Java software. If you have trouble getting a particular application to work, you might try working with the developers to add and/or fix the functionality that application needs. If that doesn't work, you could also look into Free replacements for the software itself. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Asking for advice regarding the Sleepy Cat's dbxml license
Tomas Fasth wrote: Hello List, I intend to pack Berkeley DB XML toolkit for Debian. I need help to evaluate the license to determine if it's DFSG-free or not. You will find the license text attached to this message. That license appears DFSG-free to me. Furthermore, the same license applies to the libdb4.2 package, already in main. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: pre-ITP advice?
Ken Arromdee wrote: If someone takes the Linux version, and modifies it to run under MSDOS again, can they then distribute that? From this exchange it sounds like the answer is no, which would disqualify it from being free software. I disagree; the author specifically stated: but if you want to port HelpDeco to Linux, just do it, add your copyright to mine, and release your port with source under GPL, so that Debian and all other Linux distributers can include it if they want. He specifically permitted release under the GPL. I see no reason to believe that he intends to restrict the use of the source to GNU/Linux only, or that he otherwise does not genuinely intend to grant all the rights permitted by the GPL. In particular, after you've assembled the appropriate source release including the GPL notice as suggested by the author, then you should mail the maintainer of the NetBSD port telling them the software is available under a Free Software license (as they currently have a note about the non-commercial-use restriction). This is an astounding success; thank you. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Which license for a dictionary or GFDL with clause == free?
for a complete list of all words, which is most likely not copyrightable.) 5. Is there a suited license for wordlists (that keeps the list non-proprietary)? Is there a suited license for an explainatory dictionary? See above; the GPL should work just fine for a wordlist and for a dictionary. Hope this helps, - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: public domain
David Mandelberg wrote: Hi, I'm writing a backup program for GNOME on Debian-ish distros (specifically Debian and Ubuntu) and I want the some of the documentation to be public domain, however I can't find any good resources on how to relinquish copyright. The closest thing I've found so far is http://creativecommons.org/licenses/publicdomain/, but it has one part I don't think is relevant to copyright law and I definitely don't want in the docs: Dedicator makes this dedication for the benefit of the public at large and to the detriment of the Dedicator's heirs and successors. (the detriment part specifically as this seems to me as if it would make it possible for anybody except my heirs to use the docs) Also, I don't want to be held responsible for ensuring that it's a benefit to the public, as somebody might e.g. find the word 'backup' offensive. TIA, David Mandelberg P.S. debian-legal: please CC me on all replies as I'm not subscribed. I suggest using the wording suggested by Branden Robinson in http://lists.debian.org/debian-x/2004/05/msg00235.html ; the part starting with I refuse to assert copyright. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Draft summary of Creative Commons 2.0 licenses (version 3)
Henri Sivonen wrote: You do not have to provide a copy of the Work or the Derivative Work to everyone, but when you do provide a copy to someone, you must not take measures the circumvention of which would be both illegal in the supported jurisdictions and required for exercising the rights given by the license, unless you also simultaneously provide a copy without such measures. I agree entirely with this proposed text; it clearly states both the problem the clause is trying to prevent, and a solution that requires the distributor to provide only what is needed to avoid that problem. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Debian and Cuba
Steve Langasek wrote: On Sat, Mar 26, 2005 at 12:44:11AM -0400, Maykel Moya wrote: Today I attended at 'I Taller de Software Libre' in the most important university here in Cuba. Some guys there are creating a Distro optimized for our country, and they are taking Gentoo as base. In their talk they said they didn't choose Debian because of legal restrictions due to the USA embargo. The obvious question is: is it illegal to use Debian in Cuba? Could you please clarify me? It is my understanding that it is illegal under US law to knowingly export software (free software or otherwise) from the US to Cuba, or to Cuban nationals. It is my understanding that this applies to Gentoo just as much as it applies to Debian. To the best of my knowledge (IANAL), there is no issue with someone in Cuba or another embargoed country downloading Debian from ftp.xx.debian.org, for values of xx != us or probably a few others. Key issue here: it is *not* illegal to use Debian in Cuba[1]; it is only illegal for someone in the US to export it to Cuba or provide it to someone expected to do so. [1] (barring some strange regulation of Cuba; for example, some countries restrict encryption) - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: The BitTorrent Open Source License
MJ Ray wrote: Josselin Mouette [EMAIL PROTECTED] wrote: * The requirement to maintain a LEGAL file. I don't think this one is really a problem; it's similar to the GPL saying you must mark your modifications as such. This LEGAL file doesn't seem to say that we have to leave the contents we got untouched, does it? Then it seems OK. That's not the issue: the main issue is that If you obtain such knowledge after you make any Modifications available as described in Section 4(b), you shall promptly modify the LEGAL file in all copies you make available thereafter and shall take other steps (such as notifying appropriate mailing lists or newsgroups) reasonably calculated to inform those who received the Licensed Product from you that new knowledge has been obtained. (It's also obnoxious that it specifies the exact mechanism by which you must include these notices, right down to the filename, rather than just speaking in general about clear and conspicuous notices or similar; I'm not sure if that's non-free or not though.) - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: License conflict for VM screensaver (kdeartwork)
Christopher Martin wrote: I'd like to get a debian-legal opinion on a potential issue with the kdeartwork package. debian-legal was CCed (http://lists.debian.org/debian-legal/2004/10/msg00235.html) on an earlier discussion of the problem problem by Ben Burton, but didn't receive much feedback from this list. Thus I'm raising the issue again. Ben Burton summarized the problem as follows: --- The problem here is a potential conflict between GPL and BSD-with-advertising-clause; see http://lists.kde.org/?l=kde-core-develm=109779477208076w=2 for my original post. The question now is whether the advertising clause can be assumed to be rescinded. The UC Regents rescinded the advertising clause in 1999, but the vm_random.c used in kdeartwork appears to have been taken and modified from BSD before then. Certainly the change in 1999 applies to BSD software distributed since then, as evidenced by the fact that they removed the advertising clause from the corresponding source files. But it's not obvious to me that the change applies to software distributed beforehand (such as random.c from which vm_random.c was modified, in kdeartwork). There's also the trouble that the license they are modifying in your link is similar to but not the same as the license on vm_random.c (presumably because vm_random.c was from a much older BSD). And aside from this, there's the problem that vm_random.c was modified since it was taken from BSD, and the modifications are presumably also under the BSD-with-advertising-clause (since that's what vm_random's copyright notice says). In this case, my understanding is that UC Berkeley cannot change the licensing for someone else's modifications. --- README.Impt.License.Change has come up here before, and the conclusion was that it does retroactively rescind the clause for all software copyrighted by UC Berkeley, including older versions. However, it certainly can't affect software copyrighted by others; for such software, you need to get permission from the copyright holders. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Modifications under Different Terms than Original
Anthony DeRobertis wrote: [Yeah, I haven't read -legal for a while...] :) Glenn Maynard wrote: On Sun, Jan 16, 2005 at 01:33:08PM -0800, Josh Triplett wrote: If you can't release your modifications under the same terms as the original, then it isn't DFSG-Free. Indeed, I agree that it's extremely distasteful for a license to do this; I'd never contribute to such a work. I can't come up with any strong argument of why it's non-free, though (distasteful really isn't enough), and nobody else is doing so, either--the only argument I've seen is that it's a payment to the upstream author, but that's not true in the above case. I agree this seems quite distasteful. However, as you note, it doesn't seem like a payment to upstream. Let's compare two clauses: If you make modifications to this software, you must release those modifications under the MIT X11 License. (Clause A) vs. If you make modifications to this software, you must assign copyright of those modifications to AUTHOR. AUTHOR grants everyone a license to use these modifications under the license this program is distributed. (Clause B) Clause B, I think, we'd all consider a payment: In exchange for the privelege of making modifications, you must give the author something of value. However, clause A and clause B have the exact same effect, as far as what rights people have with the program, AFAICT. I don't believe two clauses which have the exact same practicle effect should have different freenesses. I think that while (A) does not violate the letter requiring no payment, it does violate the spirit. Actually, A violates the precise letter of the DFSG: The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. The MIT X11 License is not the same terms as the license of the original software, so clause A does clearly violate both the letter and spirit of DFSG3. In addition, I have one other objection: In setting a particular person (or company, or whatever) with special rights over the program, it discriminates, also in violation of the DFSG. Copyright law certainly gives the copyright holder more rights than anyone else; however, these clauses ensure that only a certain copyright holder --- the original's copyright holder --- can ever have that status, no matter how significant my patch. True; it also fails the no-discrimination requirement. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: The BitTorrent Open Source License
Francesco Poli wrote: On Wed, 09 Mar 2005 10:21:57 +0100 Josselin Mouette wrote: [...] You and Licensor expressly waive any rights to a jury trial in any litigation concerning Licensed Product or this License. Is this a bad thing? I mean: does it do any harm? This term came up during previous discussions of the IBM Public License, and the clear consensus was that forcing the licensor to waive their right to a jury trial is definitely non-free. Thanks for catching that one. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: GPL for documentation ?
Daniel Carrera wrote: Humberto Massa wrote: Yes, you could start with this document is (C) its contributors as defined in the file AUTHORS ... Okay, how about this : This document is (C) 2004 its contributors as defined in the section titled AUTHORS. This document is released under the terms of the GNU General Public License (http://...), or under the terms of the Creative Commons Attribution License (http://...), at the option of any part receiving it. So, the document would have a section (e.g. an appendix) with a list of contributors. This should meet the requirements of both the GPL and CC-BY, while making it easy for other people to meet the requirements also. They'd only have one file to distribute to maintain attribution. Two suggestions: * The GNU GPL and the CC-BY both have several versions. For the GPL, you should explicitly say GNU General Public License, version 2, or GNU General Public License, version 2 or later. For the CC-BY, do something similar, depending on the versions you want. * (C) has no legal significance; only Copyright and a C in a circle do. Use the full word Copyright. Also, for the URLs, http://www.gnu.org/licenses/gpl.html works for the GPL, though in the ideal case you should include a copy of the GPL with the work. Other than that, it looks fine. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: The BitTorrent Open Source License
Josselin Mouette wrote: BitTorrent 4.0 is distributed under a new license of its own. Section 6 of the preamble states: 6. If you sublicense the Licensed Product or Derivative Works, you may charge fees for warranty or support, or for accepting indemnity or liability obligations to your customers. You cannot charge for the Source Code. This looks non-free, but it doesn't seem to be backed by the actual terms of the license. There is also an anti-patent clause, but it only applies to the licensed software itself. The patent clause does indeed look fine, and is the ideal form of such a clause: it only activates if you sue saying the software itself violates a patent, and it only terminates the rights granted by the people you sue. As you said, the clause above isn't actually reflected in the license text, and the Preamble states that this Preamble is not a part of this license. The legal effect of this License is dependent only upon the terms of the License and not this Preamble., so while it is confusing, it isn't relevant to Freeness. The issues I see related to Freeness are: * The requirement to keep source code available for 12 months, even if you are no longer distributing the binary, and even if you distributed the source code along with the binary. * The requirement to maintain a LEGAL file. * The choice of venue clause. I also have a suggestion for how to deal with these issues. Given that the license change is recent (two days ago), why don't we just point out to upstream that the license is not GPL-compatible, which would pose a problem for anyone building GPLed frontends to BitTorrent or other software that builds on BitTorrent (such software already exists), and request that he dual-license BitTorrent under this license and the GPL? We could point out that Mozilla, previously under the MPL, decided to dual-license (and later tri-license) for the same reason. This will prevent us from having to go into detail on these license issues, which are harder to explain (and harder to convince people that they aren't just Debian ranting, which seems to be a far-too-common opinion :( ). - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Let's stop feeding the NVidia cuckoo
Francesco Poli wrote: On Fri, 4 Mar 2005 00:21:39 + Matthew Garrett wrote: Do you think that figuring out the LaTeX markup by looking at the resulting PDF is easy? As a practical example of this, Python ships HTML documentation. This is in a pre-built tarball in the Debian source package, because the original docs are in latex and require latex2html to turn them into HTML. latex2html is non-free, so can't be a build-depend. Should the python docs be moved to contrib, or is the HTML sufficiently modifiable that they can stay in main? Yes, this seems to be a sarge-ignore bug. Possible solutions: * python-doc is moved to contrib[1] and with HTML actually built from actual LaTeX source by latex2html (non-free Build-Depends:) * python-doc is rebuilt from LaTeX source by a DFSG-free LaTeX-HTML compiler (TeX4ht?) [1] note that python only Suggests: python-doc, so pythin would stay in main * latex2html is released under the GPL and moved to main. The author has already said he would do this with the next version, but that next version may be a long time off; the best solution would be a permission statement. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: asterisk and mysql_cdr
Tzafrir Cohen wrote: format_mp3: License is GPL according to format_mp3.c and to MPGLIB_README . The mp3 code is based on libmpg from http://www.mpg123.org/ . However the front-page of that site claims: News 12. Jan. 2005 Yes! The project is not maintained at the moment and there are some serious security problems in the latest player versions. It is highly recommended to not use the source code you can download from this site. Check Debian Advisory[1] or Gentoo Advisory[2] for more information. Thanx. Old News 2004 FAQ: The license of the mpg123 player is GPL and the license of the mpglib/ inside the mpg123 package is LGPL. [1] http://packages.debian.org/changelogs/pool/non-free/m/mpg123/mpg123_0.59r-18/changelog [2] http://www.gentoo.org/security/en/glsa/glsa-200501-14.xml The Debian package mpg123 is still in non-free. I figure it had enough attention with that advisory, and if the license change were relevant it would have been moved to main. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=292260 , which requests that mpg123 be moved to main on the basis of this statement. The maintainer responded to that bug on January 26, 2005, stating that they felt that a statement on a website was not sufficient to supercede the license distributed with the code itself.. (They were open to being convinced otherwise.) - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Let's stop feeding the NVidia cuckoo
Ben Johnson wrote: Maybe debian-x, maybe debian-devel or maybe you need a new list. Ok, debian-wankers, got it. If some people feel the topic is so absurd, why do they waste their time answering rudely ? I really don't know the answer to that question. I don't think MJ Ray was answering rudely there, but it is pretty clear that Marco d'Itri was with the debian-wankers remark. debian-legal has picked up a handful of people who seem to find it important to reply to every other thread with an attack on debian-legal, on the legitimacy thereof, on the recent GR regarding non-programs and the DFSG, or on anyone who doesn't support reading the DFSG as a checklist. Perhaps it's a milestone: we've become a sufficiently well-established forum to have picked up regular trolls. :) Please don't let a few people spoil your outlook on debian-legal as a whole. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Let's stop feeding the NVidia cuckoo
Matthew Garrett wrote: Don Armstrong [EMAIL PROTECTED] wrote: It's not either. It's a hypothetical. That is, if, hypothetically, the source provided is the result of a obfuscation regex, then it's not source. [IE, we aren't provided the real prefered form for modification.] While the GPL defines source as the prefered form for modification, that definition doesn't exist in the DFSG. There's no reason to believe that we need the preferred form for modification, merely an acceptable form for modification. Otherwise we run into all sorts of issues with JPEGs and suchlike... acceptable form for modification will get you in even worse trouble than (author's) preferred form for modification. The former is a subjective criteria, and could raise issues with any code that someone claims is difficult to maintain (due to lack of documentation, poor programming practices, obscure language, any arbitrary criteria you might think of for unmaintainability). The latter is an objective criteria, which will only ever trigger in cases of obfuscation and/or compilation. We do need some ability to determine if we have real source code available; preferred form for modification seems like a well-established definition, and far better than the alternatives. I don't think we'd be having this conversation if the code was truly obfuscated, in the sense of deleting all whitespace, using #defines to obscure code structure, changing all control structures to gotos, etc. The only reason we're hesitating is that we aren't 100% sure that the author hasn't just written the code this way because they have the documentation in front of them and it all makes perfect sense to them. I don't think intentionally obfuscated code passes the source code requirement of the DFSG any more than a compiled binary does; if it does, we have a problem. Undocumented code, on the other hand, while rather annoying, is not an issue of freedom. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: ECW License
Steve Halasz wrote: I would appreciate a thumbs up or down on the dfsg compliance of the attached license before I put time into packaging. I suspect there might be issues with these requirements: iii)You are not permitted to change the ECW file format. iv) You are not permitted to use Software Product for development or distribution of Server Software that provides services or functionality on a computer acting as a server. You are correct: those two restrictions are indeed non-free. There is a third non-free requirement as well, item 1) e) iii) If the items are not available to the general public, and the initial developer of the Software requests a copy of the items, then you must supply one. Each of those three restrictions is sufficient to make the software non-free. Note that I only considered the version of their license that was targetted at Free Software, specifically GPLed software; the other two are clearly non-free. Furthermore, it should be noted that while their license seems to grant permission to build GPLed software based on their system, the GPL itself does *not* grant that permission (since this license is non-free), so any such GPLed software would need an exception clause to be distributable. And is it ok to link GDAL(MIT license) against this library? As Andrew Suffield said, the MIT license does not prohibit you from linking MIT-licensed software against another work. The other software license could theoretically do so, but does not in this case. This would imply that GDAL would have to go into contrib, since this library is non-free. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: SableVM/Kaffe pissing contest
Walter Landry wrote: Suppose I have a program Foo which uses either GNU readline. I can compile Foo against GNU readline (but not link it), and distribute the result. I can also distribute GNU readline separately. But I can not distribute foo and GNU readline together. How is this different from your case? Hold on a second. You seem to be arguing against the established interpretation of the GPL here: at least according to the FSF, you may not distribute the GPL-incompatible Foo compiled against GNU readline, linked or not. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: GPL as a license for documentation: What about derived works?
Frank Küster wrote: I hope I have understood most of the things you wrote, and it seems clearer to me now what you can do, and what you can't do, by releasing a text under GPL. But still there's a lot of cruft in it that might be just confusing for an author who considers GPL for his text, or even add confusion to a possible lawsuit. Would it be possible to create something like a reduced form of the GPL, with program replaced by text, object code by typeset form, and with all the executable-specific cruft rippeed off (or replaced)? You could (if you removed the GPL preamble as required by the FSF), but the resulting license is very likely to be incompatible with the GPL. I strongly recommend just using the standard GPL. If you really feel that such clarifications are necessary, you could add a (non-binding) clarification stating that program corresponds to text and object code corresponds to typeset form, and add an exception to any clauses you don't care about. However, I don't think that's a good idea, and I don't think people will be confused by a GPLed document. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: new .deb was done
MJ Ray wrote: US-knowers: does government work attract any copyright? Works by the US government are not entitled to copyright; they are immediately public domain. Works done by contractors for the US government may be subject to copyright; the government may *hold* copyrights, they just don't get copyrights for works they author. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Brian Thomas Sniffen wrote: Michael Poole [EMAIL PROTECTED] writes: Brian Thomas Sniffen writes: But why do you think RMS is so keen to have a working, FSF-owned Hurd? NIH syndrome. What is your explanation? I'm sure he'd like to make a system with guaranteed only free programs. As would many Free Software users and developers, but I seriously doubt that goal has anything to do with the HURD. Apart from the idea that that would run counter to the logic proposed in the decision to make glibc LGPLed, there is the issue of whether a program is a derived work or not. Linus has stated on several occasions that the statement he has made regarding the user/kernel boundary and the GPL was simply a clarification regarding derived works: a program written to standard UNIX interfaces is clearly not a derivative of Linux, HURD, or any other particular UNIX system. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: why is graphviz package non-free?
Brian Thomas Sniffen wrote: Matthew Garrett [EMAIL PROTECTED] writes: Does anyone actually have any compelling reason for believing that the literal interpretation is what was meant? I don't know what was meant, but I know what it should mean: imagine a work under a copyleft-like license, which insisted that all modifications and derived works had to be distributed under BSD-like licenses. It's sort of a copywrong, since the original author can collect all the modifications and sell proprietary licenses to them. Should this be considered free? I can't see it as free. It's very clear that recipients are being charged for the ability to modify the software. They aren't on a plane with the original author. This is a root problem similar to that of the FSF's shenanigans with GFDL and GPL'd text, and the reason I object to their use of the GFDL: when only a copyright holder can do some things, that's non-Free. If I interpret what you said literally, then *nobody* has the right to take the code proprietary, because it must stay copyleftBSD-licensed. There seem to be two possible cases in a scenario like what you suggest could occur: * If the licensor required copyright assignment. This would permit the licensor (and sole copyright holder) to take everyone's software proprietary, regardless of what the license says. However, the licensor requiring such assignment in the license would certainly be non-free, and if they do not, then they cannot compel you to transfer the copyright on your modifications to them. Therefore this case does not seem to be relevant * If this copyleftBSD license permitted distribution under either the same license or under a non-redistributable proprietary license (with various definitions for proprietary). In this case, there are no actions which may only be performed by the original copyright holder; *everyone* could take the code proprietary. This license seems obnoxious, but not non-free. Is there some other scenario (or facet of these scenarios) that you had in mind? - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: why is graphviz package non-free?
Glenn Maynard wrote:
On Fri, Jan 14, 2005 at 01:05:27AM -0800, Josh Triplett wrote:
Brian Thomas Sniffen wrote:
I don't know what was meant, but I know what it should mean: imagine a
work under a copyleft-like license, which insisted that all
modifications and derived works had to be distributed under BSD-like
licenses. It's sort of a copywrong, since the original author can
collect all the modifications and sell proprietary licenses to them.
Should this be considered free? I can't see it as free. It's very
clear that recipients are being charged for the ability to modify the
software. They aren't on a plane with the original author. This is a
root problem similar to that of the FSF's shenanigans with GFDL and
GPL'd text, and the reason I object to their use of the GFDL: when
only a copyright holder can do some things, that's non-Free.
If I interpret what you said literally, then *nobody* has the right to
take the code proprietary, because it must stay copyleftBSD-licensed.
No, that's not it.
A work (say, GlennEmacs) is placed under a license that says include source
with all distribution {other GPL-ish don't-take-my-stuff-proprietary
requirements}. Any modifications must be placed under the BSD license.
Ah, I see; yes, that's non-free.
- Josh Triplett
signature.asc
Description: OpenPGP digital signature
Re: why is graphviz package non-free?
Brian Thomas Sniffen wrote: Matthew Garrett [EMAIL PROTECTED] writes: Does anyone actually have any compelling reason for believing that the literal interpretation is what was meant? I don't know what was meant, but I know what it should mean: imagine a work under a copyleft-like license, which insisted that all modifications and derived works had to be distributed under BSD-like licenses. It's sort of a copywrong, since the original author can collect all the modifications and sell proprietary licenses to them. Should this be considered free? I can't see it as free. It's very clear that recipients are being charged for the ability to modify the software. They aren't on a plane with the original author. This is a root problem similar to that of the FSF's shenanigans with GFDL and GPL'd text, and the reason I object to their use of the GFDL: when only a copyright holder can do some things, that's non-Free. If I interpret what you said literally, then *nobody* has the right to take the code proprietary, because it must stay copyleftBSD-licensed. There seem to be two possible cases in a scenario like what you suggest could occur: * If the licensor required copyright assignment. This would permit the licensor (and sole copyright holder) to take everyone's software proprietary, regardless of what the license says. However, the licensor requiring such assignment in the license would certainly be non-free, and if they do not, then they cannot compel you to transfer the copyright on your modifications to them. Therefore this case does not seem to be relevant * If this copyleftBSD license permitted distribution under either the same license or under a non-redistributable proprietary license (with various definitions for proprietary). In this case, there are no actions which may only be performed by the original copyright holder; *everyone* could take the code proprietary. This license seems obnoxious, but not non-free. Is there some other scenario (or facet of these scenarios) that you had in mind? - Josh Triplett signature.asc Description: OpenPGP digital signature
