Alternatives to Creative Commons
Hi all, on the risk of touching a delicate subject, I'm looking for a license to put on some artistic content. In particular, the OpenTTD [1] game currently requires the use of non-free content to work. There is a project started to create free content, so the game as a whole can be made completely free. This content will mostly consist of images and audio. Since the GPL license of the game itself does not seem so suitable, we are looking into alternatives. So far, the most likely candidate is a Create Commons by-SA 3.0 license. From reading back archives, I've found that: a) CC-by 3.0 and CC-by-SA 3.0 are accepted as DFSG-free (at least by ftp-masters) [2] b) The anti-TPM clause in these two licenses is a cause of confusion, and is reason for people to think that they are not free and/or not DFSG-free. Note that I'm not looking for opinions on the above. To prevent further useless discussion, don't reply unless I'm stating something incorrect above. Now, since I am personally not so happy with the anti-TPM clause and would rather avoid the CC license due to the confusion mentioned at b), can anyone recommend any alternatives for a CC-by-SA license, that is (also) DFSG-free? Gr. Matthijs (Please CC me on replies, I'm not on the list) [1]: http://www.openttd.org [2]: http://lists.debian.org/debian-legal/2007/09/msg00126.html signature.asc Description: Digital signature
Re: Alternatives to Creative Commons
Matthijs Kooijman [EMAIL PROTECTED] wrote: Hi all, on the risk of touching a delicate subject, I'm looking for a license to put on some artistic content. In particular, the OpenTTD [1] game currently requires the use of non-free content to work. There is a project started to create free content, so the game as a whole can be made completely free. This content will mostly consist of images and audio. Since the GPL license of the game itself does not seem so suitable, we are looking into alternatives. Dual license your work under GPL and whatever you like. Then there are no DFSG-freedom issues, and you can fix whatever problems you think exist in the GPL. It also simplifies things if we can treat the whole game+data as being under a single license. Cheers, Walter Landry [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: use of Python bindings to GPL library from within non-GPL Python toolkit
Hi Guys, I am sorry that I am following up on this dead thread I started long ago [1], and which Francesco was kind to follow up to. Now I've got another project to package and got the same issue, and I am not clear if I have the right understanding of GPL-compatibility. AFAIK it means that you can use GPL-compatible licensed project within GPL-ed project, and not vise-versa! Am I correct? And actually if I am reading it right, wikipedia says the same: Many of the most common free software licenses, such as the original MIT/X license, the BSD license (in its current 3-clause form), and the LGPL, are GPL-compatible. That is, their code can be combined with a program under the GPL without conflict (the new combination would have the GPL applied to the whole). so -- combination has to be GPLed! If I am not right -- then Francesco is right and I can easily use GPLed project (and don't even ask for LGPL) from anything which is 'GPL-compatible'. If I am right -- then I guess we might have quite a few packages in debian already which would need a closer look. And what could be a possible work-around? double-licensing? search for exceptions from GPLed project authors (release it under LGPL for use in a specific project etc) Thanks in advance! [1] http://lists.debian.org/debian-legal/2008/04/msg5.html On Wed, 02 Apr 2008, Yaroslav Halchenko wrote: Dear Legal People, I am one of the developers of PyMVPA toolbox [1], which we currently distribute under MIT License. It is written in Python and is actually a framework either to create scripts for the analysis or just perform analysis interactively within python (ipython) shell environment. Recently we decided to make use of shogun library inside of PyMVPA, which has python bindings available. Shogun is distributed under GPL (not LGPL). IIRC Python itself, since it is simply a programming language, is not limited in licensing terms to what libraries are allowed to be used (not shipped) within Python, thus it is ok to use shogun within Python. But do we have to double-license PyMVPA for people to be legally able to use shogun functionality within PyMVPA? or since we don't explicitly link to shogun, neither bundle it together we are ok? We don't want to switch to GPL completely since we don't want to limit MIT-compatible licensed software to absorb/use our (non-GPLed) code. If we do have to release it under GPL as well, would it be ok to distribute entire PyMVPA in a single package and just mention that some parts of PyMVPA (which make use of GPL) cannot be distributed/used under MIT license and are distributed solely under GPL? Thank you in advance for clarifications [1] http://pkg-exppsy.alioth.debian.org/pymvpa/ -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] signature.asc Description: Digital signature
Re: Alternatives to Creative Commons
Hi Walter, Dual license your work under GPL and whatever you like. Then there are no DFSG-freedom issues, and you can fix whatever problems you think exist in the GPL. It also simplifies things if we can treat the whole game+data as being under a single license. This seems to say that you don't think there are any problems with GPL for game data. Since Don also said the same thing in another reply, I will look at GPL a bit closer. So far, I've only relied on other people that concluded that the GPL was unsuitable, so I will ask them for motivation and look closer at the GPL text myself. Thanks for the swift replies! I'll post again if I have further questions. Gr. Matthijs signature.asc Description: Digital signature
Re: Alternatives to Creative Commons
There is absolutely no issue licensing game data under the (L/A)GPL. In fact, this is required for at least the GPLv3 in that the license applies to the whole of the work, and all it's parts, regardless of how they are packaged. Thus if the game code or any dependencies (ie, the engine) are licensed under the GPL, the data must be licensed under a GPL compatible license (which the CC licenses are not). After numerous conversations with copyright lawyers on the specific subject of games, the entire game is one copyrighted work.
Re: Alternatives to Creative Commons
2008/9/17 Arc Riley [EMAIL PROTECTED]: There is absolutely no issue licensing game data under the (L/A)GPL. In fact, this is required for at least the GPLv3 in that the license applies to the whole of the work, and all it's parts, regardless of how they are packaged. Thus if the game code or any dependencies (ie, the engine) are licensed under the GPL, the data must be licensed under a GPL compatible license (which the CC licenses are not). After numerous conversations with copyright lawyers on the specific subject of games, the entire game is one copyrighted work. This might be really relevant for us, the Games Team, as there seem to be quite a lot of games that have a different license for the engine and the game data, and the combination of GPL and CC-by-sa seems to be getting more and more popular. According to what you're saying, if we consider the entire game as one copyrighted work, that might make some games simply not distributable. On the other hand, for some games (and theoretically for most of them), the same game engine can be used with different data, and some times vice-versa. If this is the case, the situation might be similar to a media player and media data, or to a word processor and the document. The game engine can be seen as the program, and the game data as the document it applies too. We've had this discussion on how to consider the relationship between games and game data for some time, and in fact it might have relevant consequences such as the game being in contrib or main for some games depending on how we consider it and, if GPL is to be understood as that, might make some games impossible to distribute. It might probably depend on every case, and whether different sets of data really exist, or at least could be created. I'm really interested on the different point of view that might exist about this matter. I'm CC'ing the message to the Games Team, as the thread might be important for us. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Alternatives to Creative Commons
On Wed, Sep 17, 2008 at 3:21 PM, Miriam Ruiz [EMAIL PROTECTED] wrote: This might be really relevant for us, the Games Team, as there seem to be quite a lot of games that have a different license for the engine and the game data, and the combination of GPL and CC-by-sa seems to be getting more and more popular. And that is fine, so long as the game data is /also/ available under the GPL. Note that it is not just games that have this problem, nor is this a problem specific to content vs code. Many projects have incompatible licenses applied to different components or dependencies. Copyright holders often just need to be made aware of this legally makes the work undistributable as it cannot be distributed while in compliance with both licenses. On the other hand, for some games (and theoretically for most of them), the same game engine can be used with different data, and some times vice-versa. If this is the case, the situation might be similar to a media player and media data, or to a word processor and the document. The case where the same game content can be used in a different engine+code verbatim is exceedingly rare. As I understand the situation, what makes the game one copyrighted work is that the content is not generic, application-agnostic software as an image in the GIMP or a text document in a word processor. While the technical process that these are loaded may be very similar, this is an issue of legal judgement, not technical process. That the code and content is both software and is utilized as a single work is what makes them one work. One could likely argue that if the game content were in a standard format and displayed/interacted with much like a web browser displays HTML/CSS/Javascript that the content would be considered a separate copyrightable work. An example of this may be ScrummVM. I'm not aware of any modern system like this, however. Note that the conflict that's arisen with incompatible licensing is due to poor education on the GPL. Many people are under the false impression that the GPL only applies to executable code or that there is some problem with licensing content under the GPL. In truth, those looking for their work to be under the strong copyleft effect of the GPL are best not separating their work's copyright artificially as it may open a loophole for 3rd parties to release proprietary replacement game content.
Re: Alternatives to Creative Commons
On Wed, 2008-09-17 at 21:21 +0200, Miriam Ruiz wrote: 2008/9/17 Arc Riley [EMAIL PROTECTED]: There is absolutely no issue licensing game data under the (L/A)GPL. In fact, this is required for at least the GPLv3 in that the license applies to the whole of the work, and all it's parts, regardless of how they are packaged. Thus if the game code or any dependencies (ie, the engine) are licensed under the GPL, the data must be licensed under a GPL compatible license (which the CC licenses are not). After numerous conversations with copyright lawyers on the specific subject of games, the entire game is one copyrighted work. This might be really relevant for us, the Games Team, as there seem to be quite a lot of games that have a different license for the engine and the game data, and the combination of GPL and CC-by-sa seems to be getting more and more popular. According to what you're saying, if we consider the entire game as one copyrighted work, that might make some games simply not distributable. I'm pretty sure at Linux.conf.au this year in the games miniconf, someone from CC Australia was recomending the use of CC (-SA i think) for game data, and said it didnt conflict with the GPL. Unfortunately i dont think that part of the day was recorded :( Heres the miniconf link, incase you want to check. http://miniconf.mel8ourne.org/wiki/index.php?title=Gaming kk -- Karl Goetz [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Alternatives to Creative Commons
On Wed, Sep 17, 2008 at 7:56 PM, Karl Goetz [EMAIL PROTECTED] wrote: I'm pretty sure at Linux.conf.au this year in the games miniconf, someone from CC Australia was recomending the use of CC (-SA i think) for game data, and said it didnt conflict with the GPL. I too have heard people from CC claim that CC licensed work was GPL-compatible. This disagrees with the FSF's position: http://www.fsf.org/licensing/licenses/ IANAL, but I believe in the FSF's legal accuracy in this given that I've heard (possibly innocent) lies about the GPL spoken by CC people, such as the perpetuation of the linking clause myth and in great detail how the GPL doesn't cover non-instruction software such as icons and fonts. Again, it's always possible to dual license the content. The (A)GPLv3 is stronger copyleft than the CC-BY-3.0 and CC-BY-SA-3.0 licenses, and more specifically addresses software matters (refering to any information stored on a computer, not just instruction code), so if a work is already being made available either under the CC-BY-3.0 or CC-BY-SA-3.0 there are no additional permissions granted by also offering it under the (A)GPLv3 while clearing up any questions about the legal distributability of their software.
Frontier Artistic License
Hi folks, While working on liquidwar for the games team I came across some code that appears to be under the Frontier Artistic License. It seems that there are packages using it. Here is a copy of the text: - The Frontier Artistic License Version 1.0 Derived from the Artistic License at OpenSource.org. Submitted to OpenSource.org for Open Source Initiative certification. Preamble The intent of this document is to state the conditions under which a Package may be copied, such that the Copyright Holder maintains some semblance of artistic control over the development of the package, while giving the users of the package the right to use and distribute the Package in a more-or-less customary fashion, plus the right to make reasonable modifications. Definitions Package refers to the script, suite, file, or collection of scripts, suites, and/or files distributed by the Copyright Holder, and to derivatives of that Package created through textual modification. Standard Version refers to such a Package if it has not been modified, or has been modified in accordance with the wishes of the Copyright Holder. Copyright Holder is whoever is named in the copyright statement or statements for the package. You is you, if you're thinking about copying or distributing this Package. Reasonable copying fee is whatever you can justify on the basis of media cost, duplication charges, time of people involved, and so on. (You will not be required to justify it to the Copyright Holder, but only to the computing community at large as a market that must bear the fee.) Freely Available means that no fee is charged for the item itself, though there may be fees involved in handling the item. It also means that recipients of the item may redistribute it under the same conditions they received it. Terms 1. You may make and give away verbatim copies of the source form of the Standard Version of this Package without restriction, provided that you duplicate all of the original copyright notices and associated disclaimers. 2. You may apply bug fixes, portability fixes, and other modifications derived from the Public Domain or from the Copyright Holder. A Package modified in such a way shall still be considered the Standard Version. 3. You may otherwise modify your copy of this Package in any way, provided that you insert a prominent notice in each changed script, suite, or file stating how and when you changed that script, suite, or file, and provided that you do at least ONE of the following: a) Use the modified Package only within your corporation or organization, or retain the modified Package solely for personal use. b) Place your modifications in the Public Domain or otherwise make them Freely Available, such as by posting said modifications to Usenet or an equivalent medium, or placing the modifications on a major archive site such as ftp.uu.net, or by allowing the Copyright Holder to include your modifications in the Standard Version of the Package. c) Rename any non-standard executables so the names do not conflict with standard executables, which must also be provided, and provide a separate manual page (or equivalent) for each non-standard executable that clearly documents how it differs from the Standard Version. d) Make other distribution arrangements with the Copyright Holder. 4. You may distribute the programs of this Package in object code or executable form, provided that you do at least ONE of the following: a) Distribute a Standard Version of the executables and library files, together with instructions (in the manual page or equivalent) on where to get the Standard Version. b) Accompany the distribution with the machine-readable source of the Package with your modifications. c) Accompany any non-standard executables with their corresponding Standard Version executables, give the non-standard executables non-standard names, and clearly document the differences in manual pages (or equivalent), together with instructions on where to get the Standard Version. d) Make other distribution arrangements with the Copyright Holder. 5. You may charge a reasonable copying fee for any distribution of this Package. You may charge any fee you choose for support of this Package. You may not charge a fee for this Package itself. However, you may distribute this Package in aggregate with other (possibly commercial) programs as part of a larger (possibly commercial) software distribution provided that you do not advertise this Package as a product of your own. 6. The scripts and library files supplied as input to or produced as output from the programs of this Package do not automatically fall under the copyright of this Package, but belong to whomever generated them, and may be sold commercially, and may be aggregated with this Package. 7. Scripts, suites,
