Re: DFSG#10 [was: Re: Draft Debian-legal summary of the LGPL]
On Thu, Jun 03, 2004 at 03:19:55PM -0400, Glenn Maynard wrote: On Thu, Jun 03, 2004 at 10:37:43AM -0500, Branden Robinson wrote: Some require it in the end-user documentation (Apache), which seems stronger. That's a problem, then. The full clause: 3. The end-user documentation included with the redistribution, if any, must include the following acknowledgment: This product includes software developed by the Apache Software Foundation (http://www.apache.org/). Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear. Some discussion on this down in one of the other threads observed that may appear in the software itself does clearly include /usr/share/doc/foo/copyright, or wherever the license text is--it doesn't say in the binary itself. So, if this interpretation is valid, it's still an annoying verbatim requirement, but without contamination issues. How does the ASF interpret the clause? -- G. Branden Robinson| I'm a firm believer in not drawing Debian GNU/Linux | trend lines before you have data [EMAIL PROTECTED] | points. http://people.debian.org/~branden/ | -- Tim Ottinger signature.asc Description: Digital signature
Re: DFSG#10 [was: Re: Draft Debian-legal summary of the LGPL]
On Thu, Jun 03, 2004 at 11:54:03AM -0400, Raul Miller wrote: On Sun, May 30, 2004 at 05:36:42PM -0400, Anthony DeRobertis wrote: i.e., we include it in the supporting documentation /usr/share/doc/PACAGE/copyright, which we have to include anyway. On Thu, Jun 03, 2004 at 10:34:47AM -0500, Branden Robinson wrote: We have imposed that requirement upon ourselves[1]. We should not be forced into it. That we have to distribute the copyright notice and license statement, which is a reasonable requirement, is not the same thing as requiring us to distribute them in a particular way. This may be a nit, but we don't distribute the copyright notice in /usr/share/doc/*/$FILENAME -- instead, that's the default location for it to be unpacked. Fair enough. -- G. Branden Robinson| Never attribute to human stupidity Debian GNU/Linux | that which can be adequately [EMAIL PROTECTED] | explained by GNU Libtool. http://people.debian.org/~branden/ | -- Scott James Remnant signature.asc Description: Digital signature
Re: DFSG#10 [was: Re: Draft Debian-legal summary of the LGPL]
On Mon, Jun 07, 2004 at 11:20:56PM -0500, Branden Robinson wrote: 3. The end-user documentation included with the redistribution, if any, must include the following acknowledgment: This product includes software developed by the Apache Software Foundation (http://www.apache.org/). Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear. Some discussion on this down in one of the other threads observed that may appear in the software itself does clearly include /usr/share/doc/foo/copyright, or wherever the license text is--it doesn't say in the binary itself. So, if this interpretation is valid, it's still an annoying verbatim requirement, but without contamination issues. How does the ASF interpret the clause? I don't know, but if you think this clause is ambiguous enough that clarification from Apache is worthwhile, remember that they're not the only ones that use this license, and their interpretation of it is only meaningful for Apache. -- Glenn Maynard
Re: Bug#251983: libcwd: QPL license is non-free; package should not be in main
On Sat, Jun 05, 2004 at 01:38:26AM -0400, Nathanael Nerode wrote: snip If this is agreed upon by everyone - then it makes sense to talk about the choice of venue versus choise of law thing. Provided that libcwd WILL be included in Debian, I am willing to change the wording of the last sentence into one that only states a choice of law, not venue. But then it must be very clear that that is enough for making the license pass DFSG as such a change would be irrevocable. First of all, the Debian Project is not in a position to form a contract with you, explicit or otherwise, as to whether we will distribute any particular work as part of our operating system. Please do not undertake any change in your licensing with the understanding that there is a binding agreement between you and the Debian Project -- e.g., you change your license, we promise to distribute your work forever. Apart from any principled reasons we might have to avoid making such committments, as a practical matter, it would be nearly impossible for us to hold to such a promise, as we are comprised entirely of volunteers. We are not in a position to, for example, make it a condition of someone's employment that they keep libcwd packaged and fit for shipment with the next release of Debian GNU/Linux at all times. Well, we went over it very carefully, and those two were the only problem issues we saw. Second of all, the choice-of-law and choice-of-venue clauses were not the only problem issues we saw. Clause 6c[1] of the QPL fails the desert island test[2]. Clause 3b[4] of the QPL forbids free-as-in-beer modification. That is, it demands consideration from the author of modifications -- even if those modifications are distinctly copyrightable -- that are extended exclusively to the copyright holder in the QPLed work, and not to the downstream licensees of the modified version. It is not Free to use your license to compel people to extend a license to their works to you, above and beyond the reciprocity of your license to them. Finally, as a practical matter, the QPL is not GPL-compatible, and any library licensed under its terms is going to pose exactly the same problems to the Debian Project as KDE did[5] before the Qt library waas dual-licensed under the GPL. When Debian began distributing KDE, that meant nothing more than that the GNU GPL was DFSG-free, not that the QPL was[6]. I would strongly encourage anyone using the QPL to dual-license their work under the GNU GPL as well. (And/or possibly the GNU LGPL, depending on the problem space their work is meant to attack.) But don't just take my word for it. Ask TrollTech: Why does Trolltech dual-license its products? Trolltech aims to make the best multiplatform development tool in the world. By selling a commercial license, we are able to staff a full-time dedicated development team and are able to provide first class support. By licensing our products under open source licenses, we are also an active part of the open source community. This community has played an important role in ensuring the stability and quality of our products. Free software developers around the world actively participate in our beta testing cycle. As a result, our products reach commercial stability far more quickly (and are more thoroughly tested) than standard frameworks. We call this our Virtuous Cycle. Additionally, the open source community provides: An extensive pool of knowledge and expertise Free add-on applications, libraries, components and tools (for both commercial and free development) Books and tutorials[7] [1] 6. You may develop application programs, reusable components and other software items that link with the original or modified versions of the Software. These items, when distributed, are subject to the following requirements: [...] c. 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. [2] Q: How can I tell if a license is a free software license, by Debian's standards? A: The process involves human judgement. The DFSG is an attempt to articulate our criteria. But the DFSG is not a contract. This means that if you think you've found a loophole in the DFSG then you don't quite understand how this works. The DFSG is a potentially imperfect attempt to express what freeness in software means to Debian. It is not something whose letter we argue about. It is not a law. Rather, it is a set of guidelines. That said, the DFSG is a good start. You might also consider a few thought experiments which we often apply. But do keep in mind that passing some set of tests is not all there is to freeness. These tests aren't the final word either - some other tricky bit of nonfreeness might be invented which is not covered by any of our
Re: A radical approach to rewriting the DFSG
On Sun, May 30, 2004 at 06:28:12AM +0100, Henning Makholm wrote: I have been toying with the possibility of rewriting the DFSG such that it enumerates which things a free license *can* do, rather than just give examples of things it *cannot*. I think that such a revision could get the guidelines to be much closer to the *actual* practise of how we evaluate licenses than if we simply make local adjustments to the current DFSG. The downside is that the whole truth cannot be condensed into the ten commandments schema of the current DFSG. I personally do not think it is a good idea to undertake this endeavor as a DFSG replacement. I explicated my theory of DFSG operation in a mail to this list in March of 2003: http://lists.debian.org/debian-legal/2003/03/msg00211.html That said, I do very much appreciate your work in very methodically documenting the many silly loopholes and exceptions we have accreted over the years to due to our haste and carelesness -- and also the many slick tricks licensors have tried to play to undermine the spirit of free software while abiding by some expressions of its letter.) I think your document will end up being very valuable to us, but I personally do not feel that its approach makes it suitable as a replacement for the DFSG. Please don't interpret anything in this message as a backhanded compliment, though I am sure we probably disagree as to what the DFSG should be. It was obviously a lot of hard work to prepare this document, and reading it was like a trip down the debian-legal flamewar memory lane, with the outcomes neatly boiled down. I think your work on this document is a valuable service to the Project. -- G. Branden Robinson| Psychology is really biology. Debian GNU/Linux | Biology is really chemistry. [EMAIL PROTECTED] | Chemistry is really physics. http://people.debian.org/~branden/ | Physics is really math. signature.asc Description: Digital signature
Re: Which license for a documentation?
On Sat, Jun 05, 2004 at 11:50:31AM +0200, Måns Rullgård wrote: I know what please means. What I fail to understand is what it is that is so terrible about asking for credit for your work. Nothing at all is wrong with that, and anyone who characterizes the Debian Project as asserting this is wrong, and may be being deliberately deceptive. There is a distinction between asking for credit for one's work, and requiring that those who use your work pay homage to in you some particular way. -- G. Branden Robinson|The first thing the communists do Debian GNU/Linux |when they take over a country is to [EMAIL PROTECTED] |outlaw cockfighting. http://people.debian.org/~branden/ |-- Oklahoma State Senator John Monks signature.asc Description: Digital signature
Re: Which license for a documentation?
Branden Robinson [EMAIL PROTECTED] writes: On Sat, Jun 05, 2004 at 11:50:31AM +0200, Måns Rullgård wrote: I know what please means. What I fail to understand is what it is that is so terrible about asking for credit for your work. Nothing at all is wrong with that, and anyone who characterizes the Debian Project as asserting this is wrong, and may be being deliberately deceptive. That was not what I meant to say. However, someone did suggest that such a request would make the program non-free. There is a distinction between asking for credit for one's work, and requiring that those who use your work pay homage to in you some particular way. Definitely. I still think a one-line mention of the author is a rather low price for quality software. I understand that it could be an inconvenience, but that inconvenience is for the author of the program, not the users. If the author is willing to deal with it, he should have the choice, calling anything else freedom is hypocritical at best. If you would like to distribute a modified version, but are unable to comply with the requirements you will simply have to refrain from doing it. This may seen non-free, but if the program was not even allowed to exist you would still not be able to distribute your modifications, there being nothing to modify. Allowing the existence of the program will give you more options, which you may or may not choose to use. I can understand that a distribution like Debian can desire to only include software meeting some criteria for freedom, but this is entirely separate from the question of allowing or disallowing software failing some of these criteria. There are many, especially on this list, who disagree with me. I will simply have to accept this and respect their opinions, since neither of us are likely to change our opinions easily. This being the case, continuing this discussion is probably pointless. -- Måns Rullgård [EMAIL PROTECTED]
Re: Which license for a documentation?
* Måns Rullgård [EMAIL PROTECTED] [040608 09:14]: Nothing at all is wrong with that, and anyone who characterizes the Debian Project as asserting this is wrong, and may be being deliberately deceptive. That was not what I meant to say. However, someone did suggest that such a request would make the program non-free. Well, placing adding requirements removes freedom from the user. Thus it can make things non-free. (Note that the author has the freedom to deny this freedom, but we have the duty to not call free what is not free). There is a distinction between asking for credit for one's work, and requiring that those who use your work pay homage to in you some particular way. Definitely. I still think a one-line mention of the author is a rather low price for quality software. I understand that it could be an inconvenience, but that inconvenience is for the author of the program, not the users. Sorry, I do not seem to understand what you mean. Are you talking about some form of advertising clause or about the author who has to write his name correctly in the work? If the author is willing to deal with it, he should have the choice, calling anything else freedom is hypocritical at best. ??? If you would like to distribute a modified version, but are unable to comply with the requirements you will simply have to refrain from doing it. This may seen non-free, but if the program was not even allowed to exist you would still not be able to distribute your modifications, there being nothing to modify. Allowing the existence of the program will give you more options, which you may or may not choose to use. This looks like you are confused that even things beeing non-free can be more free than other things beeing non-free. I can understand that a distribution like Debian can desire to only include software meeting some criteria for freedom, but this is entirely separate from the question of allowing or disallowing software failing some of these criteria. Sorry, I cannot find any sense in this sentence. Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
gens License Check - Non-free
I'm pretty sure the following is at the very least non-free, but I wanted to run it by here first because I don't want to waste any more time trying to package this unless it can at least go in non-free. I already had to close the ITP[1] once I discovered that some of the code was lacking a license. Once I was able to track it down, I rebuilt the package, but I'm not reopening the ITP until I'm sure it's actually sure this is even packagable. I suspect it is, but no harm in being sure... Attached is a verbatim copy of the debian/copyright file I put together for the package. Most of the code is GPL, but the code from a couple of directories falls under other licenses. (I ended up copying the README and COPYING from the mpg123 source package, once I found out that was where some of the code originally came from.) [1] http://bugs.debian.org/253095 This package was debianized by Benjamin Cutler [EMAIL PROTECTED] on Sun, 6 Jun 2004 20:22:43 -0700. It was downloaded from http://sourceforge.net/projects/gens/ Upstream Authors: Stephane Dallongeville (Win32 Version) ([EMAIL PROTECTED]) Stephane Akhoun (SDL Version) ([EMAIL PROTECTED]) See http://gens.consolemul.com/ for more info. Main code licensed under the GPL. On Debian systems, the complete text of the GNU General Public License can be found in `/usr/share/common-licenses/GPL'. src/gens/mp3_dec/* license: Copyright (c) 1995-99 by Michael Hipp, all rights reserved. Parts of the software are contributed by other people, please refer to the README file for details! DISTRIBUTION: This software may be distributed freely, provided that it is distributed in its entirety, without modifications, and with the original copyright notice and license included. You may distribute your own seperate patches together with this software package or a modified package if you always include a pointer where to get the original unmodified package. In this case you must inform the author about the modfied package. The software may not be sold for profit or as hidden part of another software, but it may be included with collections of other free software, such as CD-ROM images of FTP servers and similar, provided that this software is not a significant part of that collection. Precompiled binaries of this software may be distributed in the same way, provided that this copyright notice and license is included without modification. USAGE: This software may be used freely, provided that the original author is always credited. If you intend to use this software as a significant part of business (for-profit) activities, you have to contact the author first. Also, any usage that is not covered by this license requires the explicit permission of the author. DISCLAIMER: This software is provided as-is. The author can not be held liable for any damage that might arise from the use of this software. Use it at your own risk. src/starscream/* license: Starscream refers to the following files: * STAR.C * STARCPU.H * CPUDEBUG.C * CPUDEBUG.H * STARDOC.TXT * any object file or executable compiled from the above * any source code generated from STAR.C, or object file assembled from such code Starscream may be distributed freely in unmodified form, as long as this documentation is included. No money, goods, or services may be charged or solicited for Starscream, or any emulator or other program which includes Starscream, in whole or in part. Using Starscream in a shareware or commercial application is forbidden. Contact Neill Corlett ([EMAIL PROTECTED]) if you'd like to license Starscream for commercial use. Any program which uses Starscream must include the following credit text, in its documentation or in the program itself: Starscream 680x0 emulation library by Neill Corlett ([EMAIL PROTECTED])
Re: Which license for a documentation?
On 2004-06-08 08:14:13 +0100 Måns Rullgård [EMAIL PROTECTED] wrote: [...] However, someone did suggest that such a request would make the program non-free. [...] Do you mean Josh Triplett? He accepted Lewis Jardine's correction. Why won't you? I understand that it could be an inconvenience, but that inconvenience is for the author of the program, not the users. It also inconveniences all distributors, does it not? If the author is willing to deal with it, he should have the choice, calling anything else freedom is hypocritical at best. Was anyone arguing against author's choice, or are you attacking a position no-one holds? If you would like to distribute a modified version, but are unable to comply with the requirements you will simply have to refrain from doing it. That's exactly what debian does, isn't it? I can understand that a distribution like Debian can desire to only include software meeting some criteria for freedom, but this is entirely separate from the question of allowing or disallowing software failing some of these criteria. Cobblers. Debian makes a promise to its users about what it will include. It must either disallow software which doesn't meet the criteria, or change the promise. The path to change the promise is well-known. There are many, especially on this list, who disagree with me. [...] I'm not surprised. You appear to ignore the social contract. -- MJR/slef My Opinion Only and possibly not of any group I know. http://www.ttllp.co.uk/ for creative copyleft computing Help hack the EuroParl! http://mjr.towers.org.uk/proj/eurovote/
Re: gens License Check - Non-free
Not only is that non-free, it may not be distributable. A single work, parts of which are GPL'd and parts of which are non-free, can't be distributed because the GPL requires that the entire thing be under the terms of the GPL. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: oaklisp: contains 500kB binary in source
This is a technical issue related to ease of bootstrapping on a new architecture, and not a legal issue. As a technical measure, the circular dependency could be broken and the alternative prebuild-world-in-source kludge eliminated by writing an Oaklisp interpreter in another language (say, RnRS Scheme, or Haskell) for invocation when an already-built Oaklisp is not available on the build platform. I'm absolutely positive the upstream maintainer would welcome any such patch. But, this has nothing to do with the legal status of the package. -- Barak A. Pearlmutter [EMAIL PROTECTED] Hamilton Institute, NUI Maynooth, Co. Kildare, Ireland http://www-bcl.cs.may.ie/~barak/
Re: Which license for a documentation?
This is not the first time that this has come up. Perhaps there could be a FAQ at www.debian.org/legal? Great idea. Perhaps the draft FAQ I started could be moved? http://people.debian.org/~bap/dfsg-faq.html (Just added this question to it.) It is in pretty good shape, with contributions from many people, and I think represents a rough consensus view with no glaring flaws. I'd welcome its being taken over by the Debian www team, or whatever. -- Barak A. Pearlmutter [EMAIL PROTECTED] Hamilton Institute, NUI Maynooth, Co. Kildare, Ireland http://www-bcl.cs.may.ie/~barak/
Re: gens License Check - Non-free
Brian Thomas Sniffen wrote: Not only is that non-free, it may not be distributable. A single work, parts of which are GPL'd and parts of which are non-free, can't be distributed because the GPL requires that the entire thing be under the terms of the GPL. -Brian I guess I'm missing something, I just read through the GPL and I'm having trouble locating the specific clause that states this... not that I'm doubting you, I just was not aware of this. Would this mean that even the source tarball is not distributable as well?
Re: gens License Check - Non-free
Benjamin Cutler [EMAIL PROTECTED] writes: Brian Thomas Sniffen wrote: Not only is that non-free, it may not be distributable. A single work, parts of which are GPL'd and parts of which are non-free, can't be distributed because the GPL requires that the entire thing be under the terms of the GPL. -Brian I guess I'm missing something, I just read through the GPL and I'm having trouble locating the specific clause that states this... not that I'm doubting you, I just was not aware of this. The entire work is derived from the code licensed to Debian only under the GPL. So this section applies: These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Would this mean that even the source tarball is not distributable as well? Looks that way, doesn't it? The original author can distribute this, because *he* wrote all the bits we have only under the GPL, and so he isn't bound by this part of the GPL. But Debian can't distribute this -- nobody but the original author can do so. And if he didn't write 100% of the GPL'd parts, he can't distribute it either. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: gens License Check - Non-free
@ 08/06/2004 12:10 : wrote Benjamin Cutler : Brian Thomas Sniffen wrote: Not only is that non-free, it may not be distributable. A single work, parts of which are GPL'd and parts of which are non-free, can't be distributed because the GPL requires that the entire thing be under the terms of the GPL. -Brian Just to nitpick a little: A single work, parts of which are GPL'd and parts of which are _GPL_ _incompatible_ in terms of licensing. If the other parts were GPL compatible, licensing-wise, then the whole work could be considered GPL'd. (like using a BSD/MIT/2clause license to a library to be incorporated in a GPL'd program). I guess I'm missing something, I just read through the GPL and I'm having trouble locating the specific clause that states this... not that I'm doubting you, I just was not aware of this. GPL#6: Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. What this means is: for some GPLed-code derived work, all the distributions of such code *must* be done under the terms of the GPL (non-derived parts may be licensed _if_ _distributed_ _separately_, but if distributed as a single work, the single work must be distributed under the terms of the GPL, without additional restrictions on the rights granted by the GPL). Would this mean that even the source tarball is not distributable as well? Well, it is if you yank off the non-GPL parts. If you meant the _pristine_, untouched source tarball, yes, it's not distributable. If gens is still usable/useful without the non-free parts, you can package it this way (/vide/ all the flam^W healthy discussions about the non-free parts in the kernel over this list). -- best regards, Massa
Re: gens License Check - Non-free
Humberto Massa wrote: Well, it is if you yank off the non-GPL parts. If you meant the _pristine_, untouched source tarball, yes, it's not distributable. If gens is still usable/useful without the non-free parts, you can package it this way (/vide/ all the flam^W healthy discussions about the non-free parts in the kernel over this list). The mpg123 portions would probably be replacable with SMPEG with some work, but Starscream is the main CPU emulation core, so, no, that won't work. MAYBE I could figure out some way to split it off as a non-free shared library and have gens depend on it... that might be worth looking into. I can't even find the original source page for Starscream any more...
Re: gens License Check - Non-free
Benjamin Cutler wrote: Brian Thomas Sniffen wrote: Not only is that non-free, it may not be distributable. A single work, parts of which are GPL'd and parts of which are non-free, can't be distributed because the GPL requires that the entire thing be under the terms of the GPL. -Brian I guess I'm missing something, I just read through the GPL and I'm having trouble locating the specific clause that states this... not that I'm doubting you, I just was not aware of this. As I understand it (IANAL) : 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: 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. Causes the conditions of the GPL to apply to the entire work (in addition to any restrictions that any code from a third-party may already have) 6. ...You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. Means that if any restrictions imposed by the third party are in addition to restrictions in the GPL, the derived work is in contravention of the license on the GPL code 7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. *If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all.*... Together with 2b and 6, 7 means that a work combining parts licensed under the starscream license and the GPL is not distributable. However, it may be possible to get the upstream authors (if there really are only two as the readme suggests) to add a special exception allowing linking with mp3dec and starscream. This would make the work distributable in non-free. Would this mean that even the source tarball is not distributable as well? In my opinion, the starscream processor emulator can be reasonably considered an independent and separate work in itself, thus the GPL does not apply to the starscream source files. Similarly, there is no starscream code in the GPL files, thus the starscream license does not apply to the GPL files. The same applies with GPL/starscream and the mp3dec license. Thus the source tarball can be distributed (in my opinion). As I understand it, individual source files are not derived works of each other, merely aggregated in the same archive. This means that the source tarball is distributable, as long as all the files containing GPL code are unmodified, or only have modifications which are licensed under the GPL. These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. -- Lewis Jardine IANAL IANADD
Creative Commons Attribution license element
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm writing because I've just been made aware of this summary of the Creative Commons Attribution 1.0 license: http://lists.debian.org/debian-legal/2004/04/msg00031.html Let me first note that Creative Commons uses a suite of licenses, with a number of mix-and-match license elements (Attribution, ShareAlike, NonCommercial, NoDerivatives). So any CC license that would require Attribution would also fall under this analysis. Second, let me note how poorly timed the analysis is. Creative Commons revised their suite of licenses this year (from 1.0 to 2.0), and this list was asked to provide comment: http://lists.debian.org/debian-legal/2004/01/msg00241.html Making our organization's ideas known to Creative Commons could have meant a better suite of licenses for the 2.0 release. Instead, the opportunity was missed. As far as I know, the above-mentioned analysis wasn't forwarded to Creative Commons before today. Thirdly, let me say that I disagree with most of the summary. I'll try and cover the points in detail below: 1) Many DFSG-free licenses require that small portions of text be kept intact or added to the source code or output of the program. The most notable examples would be copyright notices, license notification, warranty disclaimer, and notice of modifications made; the BSD license(s) and the GPL come to mind immediately. Putting conditions on modification does not make a license non-free. We even codify this in DFSG point 4. Patch-only modification is a condition on modification that we consider acceptable if not ideal. Conditions on modification are, of course, a matter of degree. If conditions are _so_ burdensome as to make modification and redistribution _impracticable_ -- You may distribute modified versions if you square the circle, jump Snake River Canyon on a motorcycle, travel faster than light -- then the right to modify is for all practical purposes not granted. But requiring attribution to the original author does not appear to me to be that kind of burden. In particular, the license makes it clear that you must give the Original Author credit reasonable to the medium or means You are utilizing. A Licensor could not abuse this requirement by making Attribution impractical -- say, by providing a 5-terabyte name or title. Licensees are only required to give Attribution in a reasonable way. Let me note here that, although the Open Source Definition is not identical to the DFSG, the OSI has approved a few licenses that have equivalent or greater attribution requirements. Most notable is the Attribution Assurance License template: http://www.opensource.org/licenses/attribution.php This is not, of course, canonical for Debian, but it does provide some suggestion that a group following guidelines similar to ours don't see a serious problem with requiring attribution. Apache 2.0 also requires attribution (in the NOTICE file). 2) I agree with this one. The intention appears to be to allow copyright holders to avoid having their name used in advertisement, a la the BSD, but in an opt-out rather than opt-in fashion. However, as stated, it would indeed allow a license holder to prevent _any_ mention of themselves in derivative works. This could severely limit the licensee's freedom. An example would be an annotated version of a work that critiques the writer, or an autobiography that is revised to include critical comments or facts about the writer. It would probably be useful to modify the license to show that the licensor can revoke the Attribution requirements, but not prevent other mention of their name. 3) As for the trademark clause, I agree that the trademark requirement is burdensome. HOWEVER, considering that Creative Commons is _not_ a party to the license, no action by that organization to overstep trademark bounds could invalidate the license. If A grants B the rights outlined in Attribution 1.0, no increase in trademark restrictions by the third-party Creative Commons could revoke those rights. So, that's my feedback. I'd like to know what can be done to amend the analysis and re-open this license (as well as Attribution 2.0, ShareAlike 1.0, and Attribution-ShareAlike 1.0 and 2.0) for consideration. On the Creative Commons side, I'd wonder what opportunity there is to get Debian's very tardy comments and critiques applied to new versions of the CC licenses. ~ESP - -- Evan Prodromou [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAxeP/ozwefHAKBVERAmHxAJ9Qna+IwzXTEXnGJm+pJD3vPdeQ7ACeNOCC 4FMc8pCK4bDxmzyefv6wlN4= =xyLh -END PGP SIGNATURE-
Re: gens License Check - Non-free
@ 08/06/2004 12:58 : wrote Benjamin Cutler : Humberto Massa wrote: Well, it is if you yank off the non-GPL parts. If you meant the _pristine_, untouched source tarball, yes, it's not distributable. If gens is still usable/useful without the non-free parts, you can package it this way (/vide/ all the flam^W healthy discussions about the non-free parts in the kernel over this list). The mpg123 portions would probably be replacable with SMPEG with some work, but Starscream is the main CPU emulation core, so, no, that won't work. MAYBE I could figure out some way to split it off as a non-free shared library and have gens depend on it... that might be worth looking into. I can't even find the original source page for Starscream any more... Other (better!) option would be try the Starscream original author to release under a more liberal license (BSD/MIT/2clause or even the GPL). As to mpg123, what about mpg321 ?? -- br,M
Re: gens License Check - Non-free
On Tue, Jun 08, 2004 at 09:58:57AM -0600, Benjamin Cutler wrote: Humberto Massa wrote: Well, it is if you yank off the non-GPL parts. If you meant the _pristine_, untouched source tarball, yes, it's not distributable. If gens is still usable/useful without the non-free parts, you can package it this way (/vide/ all the flam^W healthy discussions about the non-free parts in the kernel over this list). The mpg123 portions would probably be replacable with SMPEG with some work, but Starscream is the main CPU emulation core, so, no, that won't work. MAYBE I could figure out some way to split it off as a non-free shared library and have gens depend on it... that might be worth looking into. No amount of hoop-jumping will help you here. It's still clearly a derivative work of starscream. m68k is not a difficult chip to emulate, and there are plenty of other emulators for it out there. There's probably something which could replace it, resulting in a package which is both distributable and DFSG-free (given that mpg123 is easy to replace). -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: gens License Check - Non-free
Humberto Massa wrote: I can't even find the original source page for Starscream any more... Other (better!) option would be try the Starscream original author to release under a more liberal license (BSD/MIT/2clause or even the GPL). As to mpg123, what about mpg321 ?? I should also have mentioned that the e-mail address for Starscream bounced when I tried it. So I really have no idea how to reach the guy who wrote it in the first place. I had another idea, though. I've noticed a few packages in contrib don't actually assemble the package until postinst... could I seperate gens into gens (all the GPL code) and gens-nonfree (mpg123 and Starscream), and have gens postinst call ld at install-time? The two packages would contain the relevant .o files... and would techinically be seperate packages.
Re: gens License Check - Non-free
Andrew Suffield wrote: No amount of hoop-jumping will help you here. It's still clearly a derivative work of starscream. Not even something like what I mentioned in my other message? Seperating the source packages wouldn't help either? m68k is not a difficult chip to emulate, and there are plenty of other emulators for it out there. There's probably something which could replace it, resulting in a package which is both distributable and DFSG-free (given that mpg123 is easy to replace). I'd be willing to tackle this if you were able to point one out, it seems the only ones I could find weren't any more DSFG-free than Starscream. I really want to see this package in Debian, can you tell? ;p
Re: Creative Commons Attribution license element
On Tue, Jun 08, 2004 at 12:06:25PM -0400, Evan Prodromou wrote: I'm writing because I've just been made aware of this summary of the Creative Commons Attribution 1.0 license: http://lists.debian.org/debian-legal/2004/04/msg00031.html Let me first note that Creative Commons uses a suite of licenses, with a number of mix-and-match license elements (Attribution, ShareAlike, NonCommercial, NoDerivatives). So any CC license that would require Attribution would also fall under this analysis. Right, the CC licenses are generally known to be a collection of non-free licenses. Conditions on modification are, of course, a matter of degree. No, actually, they are matters of form. Not degree. Unacceptable forms will always be unacceptable regardless of how large or small the relevant restriction is. Let me note here that, although the Open Source Definition is not identical to the DFSG, the OSI has approved a few licenses that have equivalent or greater attribution requirements. Yes, OSI does approve of some licenses which we do not. This is not new. They require less freedom than Debian. So, that's my feedback. I'd like to know what can be done to amend the analysis and re-open this license (as well as Attribution 2.0, ShareAlike 1.0, and Attribution-ShareAlike 1.0 and 2.0) for consideration. We've done these to death already, starting in 2003. They're non-free. That won't change. Future versions of the licenses will be considered the same as any license. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: gens License Check - Non-free
On Tue, Jun 08, 2004 at 11:01:23AM -0600, Benjamin Cutler wrote: Andrew Suffield wrote: No amount of hoop-jumping will help you here. It's still clearly a derivative work of starscream. Not even something like what I mentioned in my other message? Seperating the source packages wouldn't help either? No. It's still a derivative work. There can exist no transformations on the source which would change this that do not involve writing or replacing code - that's more or less definitive. m68k is not a difficult chip to emulate, and there are plenty of other emulators for it out there. There's probably something which could replace it, resulting in a package which is both distributable and DFSG-free (given that mpg123 is easy to replace). I'd be willing to tackle this if you were able to point one out, it seems the only ones I could find weren't any more DSFG-free than Starscream. A quick search of the Packages file reveals basilisk2, an emulator for m68k macs. I know there are more m68k emulators out there, which haven't been packaged. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: gens License Check - Non-free
On Tue, Jun 08, 2004 at 10:58:04AM -0600, Benjamin Cutler wrote: Humberto Massa wrote: I can't even find the original source page for Starscream any more... Other (better!) option would be try the Starscream original author to release under a more liberal license (BSD/MIT/2clause or even the GPL). As to mpg123, what about mpg321 ?? I should also have mentioned that the e-mail address for Starscream bounced when I tried it. So I really have no idea how to reach the guy who wrote it in the first place. I had another idea, though. I've noticed a few packages in contrib don't actually assemble the package until postinst... could I seperate gens into gens (all the GPL code) and gens-nonfree (mpg123 and Starscream), and have gens postinst call ld at install-time? The two packages would contain the relevant .o files... and would techinically be seperate packages. Intent is what counts. You can't try to find loopholes like this unless you have an expensive lawyer. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: gens License Check - Non-free
Benjamin Cutler wrote: I had another idea, though. I've noticed a few packages in contrib don't actually assemble the package until postinst... could I seperate gens into gens (all the GPL code) and gens-nonfree (mpg123 and Starscream), and have gens postinst call ld at install-time? The two packages would contain the relevant .o files... and would techinically be seperate packages. That is commonly done for packages that allow distribution as source only, or do not allow distribution of binaries built from modified source. It does not get around the GPL's requirements. Quoting from http://www.gnu.org/philosophy/pragmatic.html : Consider GNU Objective C. NeXT initially wanted to make this front end proprietary; they proposed to release it as .o files, and let users link them with the rest of GCC, thinking this might be a way around the GPL's requirements. But our lawyer said that this would not evade the requirements, that it was not allowed. And so they made the Objective C front end free software. I would suggest finding another m68k CPU emulator, and modifying Gens to use it. There are several available as part of Free Software system emulators for systems based on the m68k, such as UAE (found via a quick Google search, which turned up many more results that looked promising). - Josh Triplett
Re: gens License Check - Non-free
Benjamin Cutler wrote: I can't even find the original source page for Starscream any more... A search for the author's name turns up http://www.neillcorlett.com/ , which has a page http://www.neillcorlett.com/star/ about Starscream. There is an email address on that site's contact page; is it the same one you already tried? - Josh Triplett
Re: gens License Check - Non-free
Andrew Suffield wrote: A quick search of the Packages file reveals basilisk2, an emulator for m68k macs. I know there are more m68k emulators out there, which haven't been packaged. Looking at Basalisk it says that it uses UAE's emu core for m68k... sounds like it's worth looking into, but porting Gens to use UAE's m68k core will *probably* be a non-trivial task. Plus last time I tried to build UAE (from official source, not Debian) I got an ICE. This could get interesting. ;p
Re: gens License Check - Non-free
@ 08/06/2004 13:58 : wrote Benjamin Cutler : Humberto Massa wrote: I can't even find the original source page for Starscream any more... Other (better!) option would be try the Starscream original author to release under a more liberal license (BSD/MIT/2clause or even the GPL). As to mpg123, what about mpg321 ?? I should also have mentioned that the e-mail address for Starscream bounced when I tried it. So I really have no idea how to reach the guy who wrote it in the first place. I had another idea, though. I've noticed a few packages in contrib don't actually assemble the package until postinst... could I seperate gens into gens (all the GPL code) and gens-nonfree (mpg123 and Starscream), and have gens postinst call ld at install-time? The two packages would contain the relevant .o files... and would techinically be seperate packages. You still have to *prove* that the gens package is not a derived work on the gens-nonfree package. Your better bet would be getting another m68k emulator to work. -- br,M
Re: gens License Check - Non-free
Josh Triplett wrote: Benjamin Cutler wrote: I can't even find the original source page for Starscream any more... A search for the author's name turns up http://www.neillcorlett.com/ , which has a page http://www.neillcorlett.com/star/ about Starscream. There is an email address on that site's contact page; is it the same one you already tried? - Josh Triplett Searching for Starscream somehow managed to miss that page. I'll check it out.
Re: gens License Check - Non-free
Benjamin Cutler wrote: Searching for Starscream somehow managed to miss that page. I'll check it out. Eh, it's the same thing from before. Different addy, but just about the same content. I'm going to look into replacing the m68k core. Probably from UAE, since that's a pretty tested core. :p
Re: gens License Check - Non-free
On Tue, 8 Jun 2004, Josh Triplett wrote: That is commonly done for packages that allow distribution as source only, or do not allow distribution of binaries built from modified source. It does not get around the GPL's requirements. Quoting from http://www.gnu.org/philosophy/pragmatic.html : Consider GNU Objective C. NeXT initially wanted to make this front end proprietary; they proposed to release it as .o files, and let users link them with the rest of GCC, thinking this might be a way around the GPL's requirements. But our lawyer said that this would not evade the requirements, that it was not allowed. And so they made the Objective C front end free software. On the other hand, their lawyer is an interested party. It's like trusting a MPAA lawyer to interpret the DMCA for you. The FSF's position here is well-known, but has some odd implications. For instance, if you write code that requires Windows libraries, it is a derivative work of Windows, and thus Microsoft can at any time prohibit you from distributing it. (Note that in this scenario the OS exception won't help since it would be Microsoft, not the author of any GPL code you use, who would be claiming the copyright violation.)
Re: gens License Check - Non-free
On Tue, Jun 08, 2004 at 11:42:12AM -0700, Ken Arromdee wrote: On Tue, 8 Jun 2004, Josh Triplett wrote: That is commonly done for packages that allow distribution as source only, or do not allow distribution of binaries built from modified source. It does not get around the GPL's requirements. Quoting from http://www.gnu.org/philosophy/pragmatic.html : Consider GNU Objective C. NeXT initially wanted to make this front end proprietary; they proposed to release it as .o files, and let users link them with the rest of GCC, thinking this might be a way around the GPL's requirements. But our lawyer said that this would not evade the requirements, that it was not allowed. And so they made the Objective C front end free software. On the other hand, their lawyer is an interested party. It's like trusting a MPAA lawyer to interpret the DMCA for you. The FSF's position here is well-known, but has some odd implications. For instance, if you write code that requires Windows libraries, it is a derivative work of Windows, and thus Microsoft can at any time prohibit you from distributing it. Bad example. There are two implementations of most of the significant win32 libraries - windows and wine. Anything which works on both is a derivative of neither. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: gens License Check - Non-free
Ken Arromdee wrote: On Tue, 8 Jun 2004, Josh Triplett wrote: That is commonly done for packages that allow distribution as source only, or do not allow distribution of binaries built from modified source. It does not get around the GPL's requirements. Quoting from http://www.gnu.org/philosophy/pragmatic.html : Consider GNU Objective C. NeXT initially wanted to make this front end proprietary; they proposed to release it as .o files, and let users link them with the rest of GCC, thinking this might be a way around the GPL's requirements. But our lawyer said that this would not evade the requirements, that it was not allowed. And so they made the Objective C front end free software. On the other hand, their lawyer is an interested party. It's like trusting a MPAA lawyer to interpret the DMCA for you. Granted; nice analogy. :) The FSF's position here is well-known, but has some odd implications. For instance, if you write code that requires Windows libraries, it is a derivative work of Windows, and thus Microsoft can at any time prohibit you from distributing it. (Note that in this scenario the OS exception won't help since it would be Microsoft, not the author of any GPL code you use, who would be claiming the copyright violation.) That is a reasonable implication. I don't know whether licenses are revocable by default unless stated to be irrevocable, or if they are irrevocable by default unless stated to be revocable (I think the latter is true), but either way, it is quite possible for non-free software to have a revocable license, and for that license to affect derivative works of that software. Basically, non-free software could impose any arbitrary restriction it wants (assuming that contract licenses are valid). However, software which is written using a portable library which works on many different platforms, including Windows, would not be affected by this. Furthermore, the existence of wine and winelib provides a reasonable buffer against claims that a given Windows application is a derived work of Windows libraries, as long as the given application works with wine. Also, note that the Linux kernel includes an explicit exception for works that simply make system calls; without that exception, software that uses any system call specific to Linux would most likely be a derived work of the kernel, and would fall under the GPL. - Josh Triplett
Re: Creative Commons Attribution license element
On Tue, Jun 08, 2004 at 02:35:55PM -0400, Evan Prodromou wrote: AS We've done these to death already, starting in 2003. They're AS non-free. That won't change. Ah. Well, could you respond to my points as to why I think they _are_ free? I disagree with the terms of the summary. You acknowledged at least two reasons why it was non-free. I didn't write the summary. The discussions which resulted in the summary are the significant part, and I dimly recall they had valid points, but did not follow them closely. Beyond that I'm not personally inclined to analyse a license which is clearly non-free for other reasons; it's time-consuming. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: gens License Check - Non-free
On Tue, 8 Jun 2004, Andrew Suffield wrote: The FSF's position here is well-known, but has some odd implications. For instance, if you write code that requires Windows libraries, it is a derivative work of Windows, and thus Microsoft can at any time prohibit you from distributing it. Bad example. There are two implementations of most of the significant win32 libraries - windows and wine. Anything which works on both is a derivative of neither. So before Wine was created, anything which uses a Windows library was a derivative of Windows?
Re: gens License Check - Non-free
Ken Arromdee wrote: On Tue, 8 Jun 2004, Andrew Suffield wrote: The FSF's position here is well-known, but has some odd implications. For instance, if you write code that requires Windows libraries, it is a derivative work of Windows, and thus Microsoft can at any time prohibit you from distributing it. Bad example. There are two implementations of most of the significant win32 libraries - windows and wine. Anything which works on both is a derivative of neither. So before Wine was created, anything which uses a Windows library was a derivative of Windows? Yes. - Josh Triplett
Re: gens License Check - Non-free
@ 08/06/2004 14:48 : wrote Benjamin Cutler : Benjamin Cutler wrote: Searching for Starscream somehow managed to miss that page. I'll check it out. Eh, it's the same thing from before. Different addy, but just about the same content. I'm going to look into replacing the m68k core. Probably from UAE, since that's a pretty tested core. :p *this* checking out is ok. but and the other (easier)? maybe Neill Corlett is willing to GPL or BSD/2cl the code for us... why not ask? -- br,M
Re: Creative Commons Attribution license element
AS == Andrew Suffield [EMAIL PROTECTED] writes: AS Beyond that I'm not personally inclined to analyse a license AS which is clearly non-free for other reasons; it's AS time-consuming. No problem; I'm sure someone else will chime in. Thanks for your help so far. ~ESP -- Evan Prodromou Email: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED]
Re: gens License Check - Non-free
On Tue, Jun 08, 2004 at 12:00:21PM -0700, Josh Triplett wrote: Also, note that the Linux kernel includes an explicit exception for works that simply make system calls; without that exception, software that uses any system call specific to Linux would most likely be a derived work of the kernel, and would fall under the GPL. I still wonder if this exception is legitimate--I don't have any real examples, but with a code base the size of the kernel, I can't imagine that it hasn't imported any GPL code that hasn't granted this permission, or that they really did track down old MIA contributors. (Maybe I have the wrong impression of the kernel people, and they're more thorough with respect to licensing than I think.) -- Glenn Maynard
Re: Creative Commons Attribution license element
On 2004-06-08 17:06:25 +0100 Evan Prodromou [EMAIL PROTECTED] wrote: Second, let me note how poorly timed the analysis is. Creative Commons revised their suite of licenses this year (from 1.0 to 2.0), and this list was asked to provide comment: http://lists.debian.org/debian-legal/2004/01/msg00241.html You seem to get the basics of these problems in reply to that. Were they taken into consideration by CC? It may be poorly timed but at least a debian user helped to make it happen. Please praise Ben Francis and give him due credit for getting your attention with http://lists.ibiblio.org/pipermail/cc-licenses/2004-June/000909.html Equally, let us note that a debian *developer* subscribed to cc-discuss solicited the views of debian-legal, but did not make sure our views were clearly known to them. Then again, we're all volunteers in debian AFAIK, so let's not throw accusations of unprofessional conduct around. [...] As far as I know, the above-mentioned analysis wasn't forwarded to Creative Commons before today. [...] I'm sorry it didn't happen sooner, but I can only do so much at once and I just assumed that you reported it back to them. So, that's my feedback. I'd like to know what can be done to amend the analysis and re-open this license (as well as Attribution 2.0, ShareAlike 1.0, and Attribution-ShareAlike 1.0 and 2.0) for consideration. Convince enough people that the summary is updated. I still think it won't be DFSG-free until the author name purging part is fixed, so is there much point? I need to think about your trademark comments when it's not so hot here. On the Creative Commons side, I'd wonder what opportunity there is to get Debian's very tardy comments and critiques applied to new versions of the CC licenses. The comments are not tardy, it's just that they don't seem to have got to cc-discuss before. I assumed that you would be doing that reporting, in the same way that maintainers asking debian-legal usually report results to the upstream authors if required. Maybe I misjudged it, but no-one's dead yet AFAIK, so no need to grieve. -- MJR/slef My Opinion Only and possibly not of any group I know. http://www.ttllp.co.uk/ for creative copyleft computing Help hack the EuroParl! http://mjr.towers.org.uk/proj/eurovote/
Re: gens License Check - Non-free
Josh Triplett [EMAIL PROTECTED]: So before Wine was created, anything which uses a Windows library was a derivative of Windows? Yes. There are so many theories on this subject that I am perpetually confused, but I don't think that is what is usually claimed in the case of GPL libraries. I think the usual claim is that the program that uses the library plus the library is a derivative of the library (which is obviously true) and also a single work even when the parts are distributed separately (which is at least plausible). In the case of a typical Windows library that's not a problem because: 1. Only Microsoft and its agents are distributing the library. 2. The library is not available from public servers. 3. There is explicit or implicit permission to link the library with arbitrary programs. However, in the case of a a GPL library it is possible to argue that the person distributing the program is encouraging people to fetch the library from a public server and link it with the program, and therefore that person is in effect distributing the GPL library in an unlicensed manner. There are all kinds of hypothetical circumstances that might strengthen or weaken that argument. For example: 1. The argument seems stronger in a case where the program and the library are being distributed by the same person or by people who are in some way working together. 2. The argument seems weaker in a case where the program is being distributed in source form only together with an explanation that the program is for research use only until there is a compatibly licensed substitute for the library. Obviously I have no idea in what circumstances the argument might be accepted by a court in what jurisdictions, but I think that's roughly what the usual argument is, and it doesn't directly imply anything about the situation with a typical Windows library.
Re: Creative Commons Attribution license element
MR == MJ Ray [EMAIL PROTECTED] writes: Me Second, let me note how poorly timed the analysis is. MR It may be poorly timed but at least a debian user helped to MR make it happen. Please praise Ben Francis and give him due MR credit for getting your attention with MR http://lists.ibiblio.org/pipermail/cc-licenses/2004-June/000909.html Ben deserves some praise. Nice job, Ben! MR Equally, let us note that a debian *developer* subscribed to MR cc-discuss solicited the views of debian-legal, but did not MR make sure our views were clearly known to them. Yes, indeed. My grouchiness was unmerited, and I should have been doing a better job as a conduit between the two groups. I'm now subscribed to debian-legal and I'll try to keep the lines of communication open better. I'm sorry to have been harsh for something that was more or less my own responsibility. ~ESP -- Evan Prodromou Email: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED]
license change for POSIX manpages
(Please cc: me on replies) The upstream source for the manpages has received permission from IEEE to include text from the POSIX documentation in Linux manual pages. Debian has not distributed the POSIX man pages because until recently the license prohibited modification. The latest version (1.67, 20 May 2004) now allows modification, so long as any conflicts with the standard are clearly marked as such in the text. Joey Schulze, Debian's manpages maintainer, thinks the need for clear marking may be a problem. I've attached the full text of the new license. The other sentence that caught my eye is This notice shall appear on any product containing this material. Is putting it in /usr/share/doc sufficient? Does this now meet Debian's criteria for distribution in main? Thanks, --Andre The Institute of Electrical and Electronics Engineers (IEEE) and The Open Group, have given us permission to reprint portions of their documentation. In the following statement, the phrase ``this text'' refers to portions of the system documentation. Portions of this text are reprinted and reproduced in electronic form in the linux-manpages package, from IEEE Std 1003.1 (TM), 2003 Edition, Standard for Information Technology -- Portable Operating System Interface (POSIX (R)), The Open Group Base Specifications Issue 6, Copyright (C) 2001-2003 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group. In the event of any discrepancy between these versions and the original IEEE and The Open Group Standard, the original IEEE and The Open Group Standard is the referee document. The original Standard can be obtained online at http://www.opengroup.org/unix/online.html . This notice shall appear on any product containing this material. Redistribution of this material is permitted so long as this notice and the corresponding notices within each POSIX manual page are retained on any distribution, and the nroff source is included. Modifications to the text are permitted so long as any conflicts with the standard are clearly marked as such in the text.
Re: gens License Check - Non-free
On Tue, Jun 08, 2004 at 10:03:38PM +0100, Edmund GRIMLEY EVANS wrote: Josh Triplett [EMAIL PROTECTED]: So before Wine was created, anything which uses a Windows library was a derivative of Windows? Yes. There are so many theories on this subject that I am perpetually confused, but I don't think that is what is usually claimed in the case of GPL libraries. I think the usual claim is that the program that uses the library plus the library is a derivative of the library (which is obviously true) and also a single work even when the parts are distributed separately (which is at least plausible). In the case of a typical Windows library that's not a problem because: 1. Only Microsoft and its agents are distributing the library. 2. The library is not available from public servers. 3. There is explicit or implicit permission to link the library with arbitrary programs. That said, I have no problem conceiving of the notion that MS might change the license to prohibit specific programs from linking to a given library. Probably as part of a security update. So the theory holds, but it *could* be a problem. Fortunately it won't be our problem. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Creative Commons Attribution license element
On 2004-06-08 17:06:25 +0100 Evan Prodromou [EMAIL PROTECTED] wrote: a number of mix-and-match license elements (Attribution, ShareAlike, NonCommercial, NoDerivatives). So any CC license that would require Attribution would also fall under this analysis. Do any SA/NC/ND licences not include attribution? http://www.opensource.org/licenses/attribution.php This is not, of course, canonical for Debian, but it does provide some suggestion that a group following guidelines similar to ours don't see a serious problem with requiring attribution. I don't think OSI follows similar guidelines. Notably, Debian does not require contributors to its process to use non-free software, defaults to no consensus (sometimes annoyingly so) and only produces licence summaries if driven. Even so, I'd be amazed that OSI approved a licence that includes advertising in the licence and requires a program to do a particular act, were I not already convinced that OSI has gone bad. The Initiative Failed a long time ago, it seems. In the words of USPTO: Opensource is Dead. [...] Apache 2.0 also requires attribution (in the NOTICE file). I still think that licence looks like it has be considered case-by-case, as there is scope to abuse it. 3) As for the trademark clause [...] If A grants B the rights outlined in Attribution 1.0, no increase in trademark restrictions by the third-party Creative Commons could revoke those rights. Can you explain this more? How is it compliance with the licence not to obtain prior written consent of Creative Commons before using their trademark in a normally-permitted manner that is not in compliance with Creative Commons' then-current trademark usage guidelines ? -- MJR/slef My Opinion Only and possibly not of any group I know. http://www.ttllp.co.uk/ for creative copyleft computing Help hack the EuroParl! http://mjr.towers.org.uk/proj/eurovote/
Re: license change for POSIX manpages
On Tue, Jun 08, 2004 at 04:32:11PM -0700, Andre Lehovich wrote: The latest version (1.67, 20 May 2004) now allows modification, so long as any conflicts with the standard are clearly marked as such in the text. This seems to be reasonable. It's also right up against the line - a stronger requirement would be a problem. I'm not really comfortable with it, and would be happier if it said something like: If modifications are made which conflict with the standard, then either these modifications must be clearly marked, or references to the standard must be removed, such that the resulting work does not misrepresent the standard. That means I can take the documentation, update it to reflect a later specification, and simply remove all references to POSIX, rather than haul a huge list of changes around. The acid test is that when IEEE dies, I should be able to use their documentation to construct a successor to POSIX. I've attached the full text of the new license. The other sentence that caught my eye is This notice shall appear on any product containing this material. Is putting it in /usr/share/doc sufficient? Yes. I'm undecided on whether that requirement is DFSG-free. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Mozilla Public License is non-free: stipulates court venue ?
Hi all - With the recent discussion about choice of venue, I was wondering about the Mozilla license. Specifically, the Mozilla Public License v. 1.1 [1] seems to contain a choice of venue clause in section 11: | With respect to disputes in which at least one party is a citizen of, or an | entity chartered or registered to do business in the United States of America, | any litigation relating to this License shall be subject to the jurisdiction of | the Federal Courts of the Northern District of California, with venue lying in | Santa Clara County, California, with the losing party responsible for costs, | including without limitation, court costs and reasonable attorneys' fees and | expenses. http://www.mozilla.org/MPL/MPL-1.1.html As discussed recently, choice of venue clauses may be non-free, because they require parties to travel unreasonable distances to avoid summary decisions against them. Does this clause make the MPL non-free? Another question: section 3.4(a) of the MPL seems to require retroactively informing recipients about any third-party legal problems with the software: | If Contributor has knowledge that a license under a third party's intellectual | property rights is required to exercise the rights granted by such Contributor | under Sections 2.1 or 2.2, Contributor must include a text file with the Source | Code distribution titled LEGAL'' which describes the claim and the party | making the claim in sufficient detail that a recipient will know whom to | contact. If Contributor obtains such knowledge after the Modification is made | available as described in Section 3.2, Contributor shall promptly modify the | LEGAL file in all copies Contributor makes available thereafter and shall take | other steps (such as notifying appropriate mailing lists or newsgroups) | reasonably calculated to inform those who received the Covered Code that new | knowledge has been obtained. Debian has found the SGI Free Software License B [2] to be non-free and possible undistributable in part because of a similar, more restrictive clause [3]. Do the same arguments apply to the MPL? Note the SGI Free Software License B also contains a choice of venue clause in Section 13, which was not noted as problematic in bug #211765 [4] : | Any litigation relating to this License shall be subject to the exclusive | jurisdiction of the Federal Courts of the Northern District of California (or, | absent subject matter jurisdiction in such courts, the courts of the State of | California), with venue lying exclusively in Santa Clara County, California, | with the losing party responsible for costs, including without limitation, | court costs and reasonable attorneys fees and expenses. The full text of both licenses is pasted below. Thanks! Jim 1. http://www.mozilla.org/MPL/MPL-1.1.html 2. http://oss.sgi.com/projects/FreeB/ 3. http://lists.debian.org/debian-legal/2003/09/msg00800.html 4. http://lists.debian.org/debian-x/2003/09/msg00410.html -- MOZILLA PUBLIC LICENSE Version 1.1 --- 1. Definitions. 1.0.1. Commercial Use means distribution or otherwise making the Covered Code available to a third party. 1.1. Contributor means each entity that creates or contributes to the creation of Modifications. 1.2. Contributor Version means the combination of the Original Code, prior Modifications used by a Contributor, and the Modifications made by that particular Contributor. 1.3. Covered Code means the Original Code or Modifications or the combination of the Original Code and Modifications, in each case including portions thereof. 1.4. Electronic Distribution Mechanism means a mechanism generally accepted in the software development community for the electronic transfer of data. 1.5. Executable means Covered Code in any form other than Source Code. 1.6. Initial Developer means the individual or entity identified as the Initial Developer in the Source Code notice required by Exhibit A. 1.7. Larger Work means a work which combines Covered Code or portions thereof with code not governed by the terms of this License. 1.8. License means this document. 1.8.1. Licensable means having the right to grant, to the maximum extent possible, whether at the time of the initial grant or subsequently acquired, any and all of the rights conveyed herein. 1.9. Modifications means any addition to or deletion from the substance or structure of either the Original Code or any previous Modifications. When Covered Code is released as a series of files, a Modification is: A. Any addition to or deletion from the contents of a file containing Original Code or previous Modifications. B. Any
Re: Creative Commons Attribution license element
On 2004-06-09 00:12:02 +0100 Evan Prodromou [EMAIL PROTECTED] wrote: MR == MJ Ray [EMAIL PROTECTED] writes: Please don't SuperCite outgoing email. It is difficult to follow. [...] I'm now subscribed to debian-legal and I'll try to keep the lines of communication open better. I don't think you mentioned that you weren't subscribed when asking for comments in January. That may have limited feedback that you saw, especially as your initial posting address bounced. Summary: Oh well, let's fix it now. -- MJR/slef My Opinion Only and possibly not of any group I know. http://www.ttllp.co.uk/ for creative copyleft computing Help hack the EuroParl! http://mjr.towers.org.uk/proj/eurovote/
Re: Creative Commons Attribution license element
posted mailed Evan Prodromou wrote: snip Making our organization's ideas known to Creative Commons could have meant a better suite of licenses for the 2.0 release. Instead, the opportunity was missed. As far as I know, the above-mentioned analysis wasn't forwarded to Creative Commons before today. How disturbing. I think we thought it had been. snip But requiring attribution to the original author does not appear to me to be that kind of burden. In particular, the license makes it clear that you must give the Original Author credit reasonable to the medium or means You are utilizing. A Licensor could not abuse this requirement by making Attribution impractical -- say, by providing a 5-terabyte name or title. Licensees are only required to give Attribution in a reasonable way. Actually, I think most of clause 4b is fine; it's only one little bit of it which is troublesome. I will now analyze it carefully: From clause 4b: If you distribute, publicly display, publicly perform, or publicly digitally perform the Work or any Derivative Works or Collective Works, You must keep intact all copyright notices for the Work So far free. and give the Original Author credit reasonable to the medium or means You are utilizing by conveying the name (or pseudonym if applicable) of the Original Author if supplied; I think this is a reasonable and free requirement. It's trivial and easy, and amounts to nothing more than proper attribution. the title of the Work if supplied; This is a stronger requirement, but I also think this is reasonable and a free requirement. This *does* correspond vaguely to requiring appropriate references to prior work (as is done in scientific papers), unlike some other things we've discusses. Also, it's standard practice in the free software community. to the extent reasonably practicable, the Uniform Resource Identifier, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work; Well, I think this is barely free, though it's a little silly. and in the case of a Derivative Work, a credit identifying the use of the Work in the Derivative Work (e.g., French translation of the Work by Original Author, or Screenplay based on original Work by Original Author). Likewise this is a reasonable and free requirement. Such credit may be implemented in any reasonable manner; Great! In other words, for Debian, we put it in the copyright file along with all the other credits. Or we put it in a CREDITS file or a CONTRIBUTORS file or a NOTICES file. Or next to the copyright notices in the files. Or whatever. Except then there's this next clause provided, however, that in the case of a Derivative Work or Collective Work, at a minimum such credit will appear where any other comparable authorship credit appears and in a manner at least as prominent as such other comparable authorship credit. *This* is the problem clause. It's unclear to most of us exactly what any other comparable authorship credit means. If it means the credit given to any other author who wrote approximately the same amount of the material -- then it might possibly be a free requirement, or it might not (I'm not sure, since I haven't thought about it); but it's ceratinly an ugly requirement. If it means the credit given to any other author of the same work, it certainly isn't. If it means something else, I have no idea. With this ambiguity, the at least as prominent requirement is then a potential interpretation nightmare. Suppose, for a silly and extreme example, you wanted to use a huge hunk of material under this license in a version of ReiserFS, so that the code under this license needed a comparable authorship credit to Reiser's. Would that mean that the credit would have to appear in the FS name, so as to be in the same location and at least as prominent as Reiser's credit? Yeech. Prominent credit requirements are the specific type of credit requirements we've been objecting to. They cause endless trouble in a way that ordinary credit requirements do not. This might be fixable with a clarification, or a lawyer's opinion on what exactly it *means*, rather than a license change. Evan wrote: 2) I agree with this one. The intention appears to be to allow copyright holders to avoid having their name used in advertisement, a la the BSD, but in an opt-out rather than opt-in fashion. However, as stated, it would indeed allow a license holder to prevent _any_ mention of themselves in derivative works. This could severely limit the licensee's freedom. An example would be an annotated version of a work that critiques the writer, or an autobiography that is revised to include critical comments or facts about the writer. It would probably be useful to modify the license to show that the licensor can revoke the Attribution requirements, but not prevent other mention of their name. Right.
Re: Mozilla Public License is non-free: stipulates court venue ?
Jim Marhaus wrote: Hi all - With the recent discussion about choice of venue, I was wondering about the Mozilla license. Specifically, the Mozilla Public License v. 1.1 [1] seems to contain a choice of venue clause in section 11: | With respect to disputes in which at least one party is a citizen of, or | an entity chartered or registered to do business in the United States of | America, any litigation relating to this License shall be subject to the | jurisdiction of the Federal Courts of the Northern District of | California, with venue lying in Santa Clara County, California, with the | losing party responsible for costs, including without limitation, court | costs and reasonable attorneys' fees and expenses. http://www.mozilla.org/MPL/MPL-1.1.html As discussed recently, choice of venue clauses may be non-free, because they require parties to travel unreasonable distances to avoid summary decisions against them. Does this clause make the MPL non-free? I believe so. Doesn't Debian use Mozilla under the GPL/LGPL license option though? (In other words, is anyone using the MPL in a way that matters to Debian?) snip other MPL problems
Re: license change for POSIX manpages
posted mailed Andre Lehovich wrote: (Please cc: me on replies) The upstream source for the manpages has received permission from IEEE to include text from the POSIX documentation in Linux manual pages. Debian has not distributed the POSIX man pages because until recently the license prohibited modification. The latest version (1.67, 20 May 2004) now allows modification, so long as any conflicts with the standard are clearly marked as such in the text. Joey Schulze, Debian's manpages maintainer, thinks the need for clear marking may be a problem. Yeah, it's not actually free. :-( If it said something like So long as no conflicts with the standard are represented, explicitly or implicitly, as conforming to the standard, it could be free. As it is, it seems to quite effectively prohibit (for instance) adapting a printf manpage for use as a manpage for weirdf, a non-POSIX command. I see no sane way to make sure that conflicts with the standard are clearly marked as such in the text for such reuse. Correct me if I'm wrong. I've attached the full text of the new license. The other sentence that caught my eye is This notice shall appear on any product containing this material. Is putting it in /usr/share/doc sufficient? Does this now meet Debian's criteria for distribution in main? No. Thanks, --Andre -- There are none so blind as those who will not see.
Re: Creative Commons Attribution license element
On 2004-06-09 01:56:18 +0100 Nathanael Nerode [EMAIL PROTECTED] wrote: 3) As for the trademark clause, I agree that the trademark requirement is burdensome. This isn't supposed to be an actual part of the license, according to the source code for the web page; [...] I missed that. I'm not in the habit of reading licence page source codes in the normal run of things. Yes, it's not clear, as a cursory glance at copies of the CC licence suggests. I see some Nathanael Nerode pointed that out on cc-discuss in March... are we talking into a black hole, or do CC react to that list? -- MJR/slef My Opinion Only and possibly not of any group I know. http://www.ttllp.co.uk/ for creative copyleft computing Help hack the EuroParl! http://mjr.towers.org.uk/proj/eurovote/
Re: Creative Commons Attribution license element
MJ Ray wrote: On 2004-06-08 17:06:25 +0100 Evan Prodromou [EMAIL PROTECTED] wrote: a number of mix-and-match license elements (Attribution, ShareAlike, NonCommercial, NoDerivatives). So any CC license that would require Attribution would also fall under this analysis. Do any SA/NC/ND licences not include attribution? In the case of the 1.0 licenses, the SA, NC, SA-NC, ND, and NC-ND licenses did not require attribution, although only the first of these would have any chance of being Free. In the 2.0 licenses, CC decided that everyone wanted attribution, so they included it in all their licenses to reduce the number of different combinations. I don't think OSI follows similar guidelines. Notably, Debian does not require contributors to its process to use non-free software, defaults I'm curious, what non-free software is required to contribute to OSI? - Josh Triplett
Re: Creative Commons Attribution license element
Evan Prodroumou wrote: On the Creative Commons side, I'd wonder what opportunity there is to get Debian's very tardy comments and critiques applied to new versions of the CC licenses. Perhaps if they read their own mailing list?... The trademark issue appears to be an issue solely with the web page presentation of the license, which should simply be fixed; the trademark clause is not supposed to be part of the license at all, but the web page does not make that clear. I sent a message regarding this to them some time ago, but it seems to have fallen into a black hole. Perhaps you know someone who could actually get something done on this point?...
Re: Mozilla Public License is non-free: stipulates court venue ?
On Tue, Jun 08, 2004 at 10:30:09PM +, Jim Marhaus wrote: | With respect to disputes in which at least one party is a citizen of, or an | entity chartered or registered to do business in the United States of America, | any litigation relating to this License shall be subject to the jurisdiction of | the Federal Courts of the Northern District of California, with venue lying in | Santa Clara County, California, with the losing party responsible for costs, | including without limitation, court costs and reasonable attorneys' fees and | expenses. Choice of venue aside, I question whether if you sue me and lose, you pay me my costs is free. That might be a good policy for laws (or perhaps not; I'm not very informed of the legal theory behind that), but I'm not sure if it belongs in a free license. | If Contributor has knowledge that a license under a third party's intellectual | property rights is required to exercise the rights granted by such Contributor | under Sections 2.1 or 2.2, Contributor must include a text file with the Source | Code distribution titled LEGAL'' which describes the claim and the party | making the claim in sufficient detail that a recipient will know whom to | contact. If Contributor obtains such knowledge after the Modification is made | available as described in Section 3.2, Contributor shall promptly modify the | LEGAL file in all copies Contributor makes available thereafter and shall take | other steps (such as notifying appropriate mailing lists or newsgroups) | reasonably calculated to inform those who received the Covered Code that new | knowledge has been obtained. This fails the Chinese Dissident test. -- Glenn Maynard
