Re: GPL and closed source
While I'm even less of a lawyer than most folks here, I disagree. My opinion is that you *can* write a closed source plugin to work with a published interface, and distribute it for a fee, and nobody can stop you from doing that. I also remember having read here that RMS is of the opinion that if the interface only has been implemented in a GPL-program, then my stance is wrong, and you cannot distribute your closed source plugin. So let us consider: It is pretty clear from the text of the GPL that you cannot distribute your closed source plugin *linked into* the GPL-program. But if you distribute the GPL-program and the plugin separately, I don't see any problem with users throwing the two together. I don't think such users would contravene the GPL, since they're doing no developing or distributing of code, just using several programs as they see fit on their own computers. The argument that shows why RMS' opinion on this matter (assuming he was quoted correctly) is wrong and you *can* do this is that you could at any time develop a closed source program that implements the published interface to which your plugin links. If the FSF were to sue you, you'd have to take the stance that you are distributing the plugin first, before writing the closed source replacement/improvement of the core GPL-program. So IMO, the fact that you *could* implement the interface yourself in a closed source program makes it impossible to fault you for selling a closed source plugin to that future program. Problems might arise if the interface itself were proprietary. If yours is a serious commercial venture, you should talk to a lawyer about that possibility. Again, IANAL, I'm just going by my understanding of the GPL and what I consider just and fair. As a final thought, I think the FSF would be crazy to test the GPL in court on this issue, where the claim they're making is much weaker than in other cases of potential license violation (like all the GPL code that was linked to Qt before that was GPL). Peter Henningsen alifegames.com At 07:39 AM 7/12/01 -0700, you wrote: >> Let's say that I've developped a programm under GPL. >> Is it possible to create Closed-source plugins for the GPL programm and sell >> them ? > >If you own the copyright to the larger framework, this can be >done legally. You'll want to make sure that you either >completely own, or have disclaimers or assignment of rights >documents from all developers. If the framework is yours, you >can take all or part of it closed source at will - you own it. > >However, if the framework is not clearly under your copyright, >then you can't do this, since you cannot link closed source to an >open source framework - and pluggable modules are considered to >be linking. > >This is my non-legal opinion, of course. > >Greg > >
Re: Real-World Copyright Assignment
>> . If you submit code to a >> project, you don't do it in expectation of future profits directly from the >> code. Likely unworkable and unenforcable. Currently that is the rule no doubt, but I think we could get open source code written faster and probably better if people could actually expect getting paid for their work. In exchange for giving up his/her copyrights, a contributor to my code who has written 10% of the code (counted by lines of code, assuming that every contributing author writes entire file modules, and small patches are disregarded) would get paid something like 5% of any profits from commercial licenses. Commercial releases would always be ahead of GPL- releases, and commercial releases would contain closed source encryption and authentification code that allows users to play together over a central server in an environment that allows the formation of trust between participants. >Which brings the next thorny issue: suppose a contributor does >not want to assign his/her rights to you (perhaps thinking "what >do I get out of this, or perhaps opposing it on principle). What >then? He's not a contributor if he does not agree to assing the rights. I make that clear at the start. As for forking, since I'm writing game code, that is actually a good thing. It means another game gets written. I would not like to see a proliferation of servers running the same virtual world that I run, but such paid services obviously work much better with closed source code, where it is much harder (both technically and legally) to cheat. And nobody can combine our code with closed source encryption code but ourselves. So while we release code under the GPL, we are the only ones who can offer no-cheat networked use of the code. Peter Henningsen alifegames.com
Re: license-mix, legal consequences?
I will only integrate contributor's code into my codebase if they hand over
copyright to alifegames.com (in exchange for a fair share of any profits
that may derive from commercial licenses to the code in the future), so I
will be able to release my own core code at any time under any license I
wish. What I am wondering about is the code that comes into the project with
other copyrightholders, and under a license different from the GPL, e.g. the
MIT license. The GPL states:
2.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.
My understanding is this: As the copyrightholder to my code, even if I
release it under the GPL, I am not bound by the terms of the GPL, and can
include code under a different license such as the MIT license. However, if
someone else uses my code under the terms of the GPL, and wants to release a
modified version of my code, then according to 2.b) he would have to license
the entire program under the terms of the GPL, *including the parts that he
received under the terms of the MIT license*. I had been thinking that it
would not be legal to simply take MIT licensed code (or Tcl/Tk licensed
code) and without permission of the copyright holder re-release it under the
GPL.
The responses I got on the list seem to indicate that I am wrong, and this
re-release under a different license that imposes more conditions would in
fact be legal. However, no one addressed this point directly and clearly,
and I am still unsure of the legality of that process. Would anyone be
willing to address this directly?
Peter Henningsen
alifegames.com
At 12:45 PM 6/19/01 -0700, Danese Cooper wrote:
>>At Sun, we license OpenOffice.org code under both the LGPL and SISSL.
>>Since only the copyright holder can change licensing terms for a body
>>of code, we collect copyright assignments from contributors (whether
>>they are working under LGPL or SISSL). The point is that we have to
>>work at keeping the codebase "whole" under both licenses.
>>
>>About including code you don't "own" (by copyright) in such a scheme. In
>>NetBeans there were several libraries which we didn't own and didn't have
>>rights to redistribute. We included these as binaries with the author's
>>permission and modified our build system to use the binaries...
>>
>>Danese
>>
>>>on Sun, Jun 17, 2001 at 08:38:55AM -0300, Henningsen ([EMAIL PROTECTED]) wrote:
>>>> I want to release code I write myself under a dual license scheme,
>>>> both GPL and commercial license, the latter for people who want to use
>>>> the code in closed source projects. In my project I would like to
>>>> include code released under the Tcl/Tk license model ("keep copyright
>>>> notices in place, and keep this license text with the code"), and code
>>>> released under the MIT license.
>>>>
>>>> I checked on the FSF's site whether these licenses are compatible with
>>>> the GPL, and didn't find anything. Are they or are they not? And if
>>>> they're not, would that mean that people who want to use my
>>>> GPL-released code could not also use the code modules with
>>>> incompatible licenses unless they got a special permission from me (in
>>>> effect a free commercial license)?
>>>
>>>Peter:
>>>
>>>First, IANAL.
>>>
>>>Dual licensing of your own code doesn't (generally) require
>>>"compatibility" between licenses, defined as the ability for software
>>>under one license to be used under the terms of another.
>>>
>>>This is effectively a logical OR: compatibility requires that,
>>>excepting other arrangements with the copyright holder(s), you can use
>>>alternative or additional licensing terms. This is a small set of
>>>licenses.
>>>
>>>Dual (or multiple) licensing, on the other hand, is a logical AND.
>>>You're saying that any of the specified licenses is sufficient to meet
>>>the legal obligations for software copying, modification, distribution,
>>>or other 17 USC (or Berne, internationally) exclusive rights under
>>>copyright.
>>>
>>>The issue that may then arise is the introduction of third-party code
>>>into your project. So long as this code is introduced under the same
>>>dual/multi license terms, there are no compatibility issues raised.
>>>However, if code is contributed under only one, or some other subset, of
>>
license-mix, legal consequences?
I want to release code I write myself under a dual license scheme, both GPL
and commercial license, the latter for people who want to use the code in
closed source projects. In my project I would like to include code released
under the Tcl/Tk license model ("keep copyright notices in place, and keep
this license text with the code"), and code released under the MIT license.
I checked on the FSF's site whether these licenses are compatible with the
GPL, and didn't find anything. Are they or are they not? And if they're not,
would that mean that people who want to use my GPL-released code could not
also use the code modules with incompatible licenses unless they got a
special permission from me (in effect a free commercial license)?
Peter Henningsen
alifegames.com
Request for Comments
I think I have found a cool way to make money with open source, but I don't
expect to become rich with it. I'd be well pleased if it would generate a
normal income. I think what is needed is not a new license, but a way to
organize the use of dual license schemes. So this is somewhat off-topic for
this list, and I apologize for that. However, if you are willing to take the
time, I am very willing to listen to your inputs. This document is intended
to promote a vibrant Linux Game Programming community, and it is a first
draft that *will* be changed. (If this is too long, just read sections 2.1,
3.1 and 5., or even just the last two paragraphs, which refer to earlier
discussions on this list.)
Linux Game Programming (LGP) Compact
(c) Peter Henningsen 2001 - You are free to write similar agreements for
your own project, using the same language if desired.
Preamble:
The LGP Compact (LGP-C) is intended as a way to organize a group of
developers and artists so they can develop a successful series of games and
make money in an open source environment. The LGP-C provides for code
releases both under the GPL and commercially. Its intention is to organize a
group of developers and artists so that the group can effectively negotiate,
take counsel, make decisions, propagate itself, organize cooperation, and
share income fairly. This compact is not a legal document that is
enforceable in court, but constitutes the guidelines we resolve to follow.
These guidelines can be amended by consensus any time.
LGP Compact:
The participants in the compact organize themselves into a social organism
("group") with the purpose of producing and releasing a series of games
codenamed "DungeonHack". Group members can have one of the following
functions, which will be explained in detail:
1. Maintainer
2. Coder
3. Artist/Author
1.1 The maintainer(s) are responsible for the following product-related tasks:
a) define a task list, and keep tabs on progress
b) discuss with newcomers to the project what task they should do
c) support newcomers on their chosen task until they're up to speed
d) integrate contributions into a main code branch with regular releases
e) contribute code, art, and/or documentation to the project
e) do everything else that needs to be done and for which there is no
volunteer, such as
maintaining a website, doing publicity, etc.
1.2 The maintainer(s) represent the coders, authors and artists in all
negotiations, and make decisions on their behalf after taking counsel with
them. In particular, the maintainer(s) are responsible for
a) deciding who gets a license and who does not
b) determining the price of commercial licenses
c) making agreements with new contributors, particularly artists and
authors, about the percentage weight their contribution will have in the
overall project - e.g. they could make an agreement with a graphic artist
that professionally animated 3D-figures of the protagonists count for 30% of
the project (meaning the artist will get 30% of all contributor income).
1.3 The maintainer(s) are the people who are actually maintaining the
project, and have done so in the past. Who is a maintainer and who is not
should be amicably agreed upon by the contributors to the project. In case
there is no agreement, the following rules apply:
a) There are 1 or more maintainers. At the start of the project the active
and only maintainer is [EMAIL PROTECTED]
b) If there are two maintainers, they are called the active maintainer (who
is actually doing most of the tasks under 1.1) and the backup maintainer
(who used to do them earlier). The backup maintainer(s) give support to the
acting maintainer, and help with difficult problems.
c) If there is a person in the group who consistently does more of the tasks
in 1.1 than the active maintainer, the active maintainer steps down and
hands the post over to that person. If he does not, the group members can
force him to step down if a majority (counted by percentage contributions to
the project) votes for him to do so.
d) When an active maintainer steps down, he becomes backup maintainer.
Several people can share the job of backup maintainer.
e) The maintainers should earnestly try to come to consensus decisions when
performing the tasks in 1.2, but if they cannot, their votes are counted
with the following weights: Every maintainer has a percentage of the votes
that is equal to his percentage contribution as a coder/artist/author,
except that if there are several backup maintainers, then their percentage
is divided by their number.
2.1 The coders are the people who have written code for the project. They
assign their copyright in the code to alifegames.com in exchange for their
share of the income generated by the project. Coders agree that the
DungeonHack code should be released both under the GPL and under commercial
licenses, with new code often only available commercially. It is understood
by all that commercial relea
Re: Open Source *Game* Programming License
>What I would argue is that someone (presumably a company, but it could >be anyone) might provide the source code for a game program, together >with a usable but less than awesome "reference" world file with a >published format (so that if anyone else wants to develop open world >files they may), then advertise and sell (yes, _sell_ :)) >professionally-developed world files. That is indeed the best way to make money at open source games that anyone has been able to point out so far, and it will mostly compensate artists. A way for programmers to get paid would improve this model, but hey, it's a good start. And in my suggested LGP license (which is not really a new license, but a dual licensing scheme, and which has garnered no response from this list so far) programmers (copyright holders) would also get compensated if and when a commercial license is sold. For instance, if a commercial publisher wanted to pick up an LGP-licensed game, and pay for super-cool worlds with expensive graphics, and without GPL'ing his code enhancements, *then* the programmers would get paid. Maybe a far shot, but better than nothing. Peter Henningsen alifegames.com
Open Source *Game* Programming License
other licenses drag on and on about this, but I fail to see the point. Any other problems with this text that you can see? I do not understand this as a new license, but as a document that makes it easier to organize collaboration between copyright holders and maintainer to allow for commercial and free releases. Maybe be the more interesting document would be the contract between copyright holders and maintainer, but since I'm the only copyright holder as of now, I haven't bothered with that. And don't bother looking at DungeonMaker, which is inconsequential... I'm really doing this license thing for my next big project. Peter Henningsen alifegames.com
Re: Open Source *Game* Programming?
>> IANAL but I think the general reaction would be that the >> graphics are part of the overall work and said game company >> would then be obliged to also give away the graphics, >> which you would then have access to. > >Doom and Quake have been released as GPL. Graphics and data files have not. >By this reasoning, anyone except the creators of Doom or Quake could not >distribute those programs at all, since the graphics are necessary to use >the program and they are not open source. It is my understanding that graphics that comes with a game does not have to be given away with GPL'd code. In fact, one of the most promising ideas of open source game developers on generating revenue is to release the game with some graphics (like the first levels), and then charge for more and better graphics. In that model only the graphic artists get paid, which makes sense because the open source game community is desperately short of good graphic artists. Peter Henningsen alifegames.com P.S.: And thanks to everybody who posted a reply to my question. I'm pondering the dis/advantages of the Aladdin license, and of dual licensing with the GPL. Realistically Microsoft probably wouldn't want to release any games under the GPL, and if they did, that would be worth it;-)
Open Source *Game* Programming?
I would like some advice on what to do in my situation. I am developing artificial intelligence modules for computer games, and model games to demonstrate and test them. I would like to do that in an open source environment, and would like my code to be used widely in other open source games. However, the only chance I have of ever seeing my creations in a first class game is if they are picked up by a commercial publisher who then will have to pay about a million dollars largely for graphics to get the game up to AAA standards. If I publish under the GPL (as I have done) or any of the other open source licenses I have seen and understood, a publisher could simply take my work, add modifications to my code (to which I would have access, since they would have to be open source also), add his copyrighted graphics (to which I would >>not<< get access to use in my own versions of the game, because graphics that goes with code is not covered in open source licenses), and then he could sell it without giving me either royalties or proper artistic credit (credit in the source files and the Readme file is worthless in a game). I don't think this would be fair, and therefore I will not release my work under a license that makes this possible. The type of license I am looking for is one that is basically like the GPL for non-commercial users, but that requires commercial users of my software to acquire a license from me (which implies that I will be paid and get artistic credit). Or else, a license that would force any graphics bundled with my code to become freely available, and that would ensure that I get proper artistic credit. So my questions are simple: Is there any open source certified license that meets these criteria? If not, is it possible to write one? Does anyone in the OSI have an interest in addressing these specific problems faced by most open source *game* developers? And a more philosophical question: If it is against the spirit of open source to require commercial users to buy a license, why is that? I think it is perverse to require me to offer my work as a donation to Microsoft and other game publishers just so I can use SourceForge. Remember, the modifications a publisher might make to my code are worth nothing. The graphics is what is valuable. Peter Henningsen alifegames.com
