It is currently Sat Nov 16, 2019 10:43 pm

All times are UTC




Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 50 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
 Post subject:
PostPosted: Thu Apr 15, 2010 1:18 am 
Offline
Obduction Backer

Joined: Mon Jan 15, 2007 6:03 pm
Posts: 96
Tiran's post is very pragmatic. I agree with all of it. That's why this issue is something which must be handled carefully (and not just slapping some license on the code right away). In some ways, while it's exciting, it's a little unfortunate that the code has been released without a license. But in some ways, it's better, legally, not to have any license than having the wrong one.

Cutting off copyright madness

Maybe the first thing Cyan should do (unfortunately) is issue a statement such as "the code released, as of this date, is copyrighted material of Cyan. You must not redistribute it or modify it without express written permission of Cyan." This would be a temporary statement until a license is chosen and applied. That basically means you can read the source, but you can't do anything with it, because as soon as someone modifies it and uploads it somewhere, the copyright becomes much messier. Note that this would not be considered open source (open source implies the right to redistribute and modify code), but hopefully it would just be a temporary measure.

Don't plan to change the license

I would recommend against "just picking a restrictive license, and hey, you can always make a more permissive one later." In theory, that is valid -- Cyan can release the code under the GPL and later release the same code under BSD. In practice (as someone already pointed out), as soon as there is one third-party contribution to GPL code, it is impossible for Cyan to change the license to a more permissive one without either a) removing all contributed code, or b) getting explicit permission from each contributor. This is (partly) the reason why the Linux kernel will never change license from GPLv2 to GPLv3 -- it's impossible to get approval from all the thousands of contributors. Which brings me to...

GPLv3

If you are going to pick GPL (not necessarily wise), please consider using GPLv3. The GPLv3 is a much stronger license, as it has been written with all legal systems worldwide in mind, whereas GPLv2 is US-centric. GPLv3 also allows for "exceptions" to be added, like someone said Cyan could add a PhysX clause or whatnot. The only reason to choose GPLv2 is if you want to incorporate code from GPLv2 sources. Note that you cannot pick GPLv2 and upgrade to GPLv3 later -- see above.

Separate the software license from the contributor agreement

Tiran wrote:
I strongly suggest that Cyan follows the path of other projects and requires every developer to sign a contributor agreement.

That is a great idea. However, I don't think this should be in the license itself. Nothing should stop me from taking the source code and making a fork of it. I shouldn't have to sign a contributor agreement to publish an Uru-based project online. I should only have to sign the agreement if I want to get my code merged back into the main trunk. Therefore, it isn't part of the software license.

The license should be a standard one. There is too much license proliferation in open source. Having companies make up their own licenses is bad for everyone (it discourages code sharing).

All of Tiran's dot points are good ideas for the contributor agreement, but:
Tiran wrote:
* All derived work must use the same license.
* Developers must release their sources when they distribute binaries.

These last two points are different from Tiran's other dot points. The other ones should be part of the contributor agreement. These last two points should be in the software license -- ie., they should apply to all users of the source, not just those who intend to contribute.

They are GPL-like rules. If you are going for a more permissive license, such as BSD, then those last two don't apply at all. (If I am not intending to contribute back to Cyan, I don't need to use the same license, and I don't need to release my source. But if I am intending to contribute, then it goes without saying that I am releasing the source, not binaries.)

Tiran wrote:
* Developers keep their right on their code but also grant Cyan exclusive permission to reuse and relicense the code in commercial versions of MOUL and related products.

Hmm... I'm not sure about this one. All open source licenses, by definition, allow anyone to use the software for commercial gain. Therefore, it would seem counter-productive (and possibly break the terms of the license) if Cyan were given exclusive permission to reuse the software.

It is a good idea to give Cyan permission up-front to relicense the software though. I'm not sure about this one, really.

Tiran wrote:
Some of the rules may sound harsh or too strict to you. But keep in mind that Cyan is a company that NEEDS to earn money to survive. Perhaps some day Cyan is able to make real money with MOUL again. If we don't allow them to use our code for mutual benefit all our work is for nothing. I think most people want two things: make MOUL a success to get more ages and receive credit for our work.
I absolutely agree. We don't want Cyan in a position where they can't make money off of our contributions. But as I said above, I think that's implicit in the open source license.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Apr 15, 2010 12:38 pm 
Offline
Obduction Backer

Joined: Sun Jan 20, 2008 2:14 pm
Posts: 902
Tiran wrote:
<snip>for a commercial product like MOUL.<snip>


Uh... sorry to burst your bubble... but.. MOUL /isn't/ a commerical product anymore... if it is, I want proper support, to pay subscription fees, or to purchase the game, in some way. Bug fixes, new content, etc. The works. We all know that isn't really possible, now is it? MOULagain simply isn't a "commerical product" anymore. It has absolutely zero of the requirements of it being a "commerical product" right now. For one thing, its entirely freeware. Its supported /entirely/ by donations. Sorry, but, that's not "a commerical product".


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Apr 15, 2010 12:51 pm 
Offline

Joined: Tue May 09, 2006 1:04 am
Posts: 4134
Right. MOUL is freeware. People can try and dress it up otherwise, but it's freeware (or donationware, whatever you want to call it). The goal needs to be improving the game, not making money. You cannot make money with the present Uru, anyhow.

_________________
-Whilyam
Cavern Link:My IC Blog


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Apr 15, 2010 2:09 pm 
Offline
Creative Kingdoms

Joined: Tue May 09, 2006 8:06 pm
Posts: 6229
Location: Everywhere, all at once
Wow, those are two very nice posts, Tiran and Eat_My_Shortz. They are great examples of furthering an issue with a respectful, positive approach to each other. And it's an approach that selflessly considers Cyan's own interests, not just ours. Awesome.

_________________
OpenUru.org: An Uru Project Resource Site : Twitter : Make a commitment.
Image


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Apr 15, 2010 2:22 pm 
Offline

Joined: Fri Feb 19, 2010 5:04 pm
Posts: 115
Location: England
Eat_My_Shortz wrote:
Tiran wrote:
* Developers keep their right on their code but also grant Cyan exclusive permission to reuse and relicense the code in commercial versions of MOUL and related products.

Hmm... I'm not sure about this one. All open source licenses, by definition, allow anyone to use the software for commercial gain. Therefore, it would seem counter-productive (and possibly break the terms of the license) if Cyan were given exclusive permission to reuse the software.

Maybe he meant "non-exclusive permission"?

The point of giving Cyan a "get out" clause would be so that any bug-fixes could be folded back into commercial works which share the same code (e.g. MQO). Otherwise, say that someone finds a bug in the Plasma engine and submits a patch. Cyan notice that the bug is also present in the version used in MQO. If the contributor agreement states that contributions are licensed under an open-source licence, they can't just apply the patch to the version used in MQO (unless it's trivial enough to escape the definition of an original work under copyright law). Even having the bug fixed "independently" in MQO by someone who has seen the patch is dubious (hence the use of a "Chinese wall" in reverse-engineering).

Netscape did this (include a clause granting Netscape an unrestricted licence to certain contributions) when the original Netscape Navigator source code was released. IIRC, the clause only applied to changes to existing files, not to completely new files, so it would apply to a bug-fix or minor change but not to a completely new component.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Apr 15, 2010 3:50 pm 
Offline

Joined: Thu Aug 03, 2006 10:55 pm
Posts: 625
All this talk of contributor agreements and relicensing could be avoided if the code was released under BSD or similar, since it's very permissive.

Actually, I don't think a contributor agreement is needed at all, even if Cyan chooses GPL for the code. Plasma simply isn't that advanced of an engine; the real IP asset in MOUL is the art and story. There's nothing to lose from GPLing it, and a lot to gain in the form of source that might have stayed hidden under a more permissive license.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Apr 15, 2010 7:24 pm 
Offline

Joined: Fri Feb 19, 2010 5:04 pm
Posts: 115
Location: England
PaladinOfKaos wrote:
All this talk of contributor agreements and relicensing could be avoided if the code was released under BSD or similar, since it's very permissive.

Permissive enough that modifications can be licensed under whatever terms the developer chooses. Each developer is free to choose an entirely different (and entirely incompatible) licence, so anyone wishing to actually make use of the contributions needs a team of lawyers to figure out which contributions can legally be combined and what the licence is for the resulting executable.

PaladinOfKaos wrote:
Actually, I don't think a contributor agreement is needed at all, even if Cyan chooses GPL for the code.

Whatever licence is chosen, you need a contributor agreement, even if the entirety of the agreement is "my contributions are licensed under the GPL". Some projects operate without explicit agreements on the assumption that any contribution to a project is licensed under the same licence as the existing project. Such assumptions are risky; it's preferable to have each contributor explicitly state how they are licensing their work.

For comparison, the FSF won't accept any contributions to the GNU project unless you either transfer the copyright to the FSF or at least grant them an unrestricted licence to the work (and they may not always accept the latter). This allows them to change the licensing terms at will (e.g. in the event of changes to the law) and to enforce the copyright (in the case where the copyright is transferred to them).


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Apr 15, 2010 8:43 pm 
Offline
Obduction Backer

Joined: Sun Feb 14, 2010 7:53 pm
Posts: 157
IANAL, but I think a pretty good license would work something like this:

If you are not Cyan, then you may use this code as you wish, provided:
(1) you do not use it commercially (i.e., you may not make a profit), and
(2) you relicense any changes/modifications/improvements/derivative works under this same license.

If you are Cyan, then you may treat this license as equivalent to the CC0 license. (That is, you can do anything you want with it.)

_________________
Have Ages, and link to them without bindings. [Words 1:13]
Seltani


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Apr 16, 2010 2:04 am 
Offline
Obduction Backer

Joined: Mon Jan 15, 2007 6:03 pm
Posts: 96
Whilyam wrote:
Right. MOUL is freeware. People can try and dress it up otherwise, but it's freeware (or donationware, whatever you want to call it). The goal needs to be improving the game, not making money. You cannot make money with the present Uru, anyhow.

Yes, but Cyan is still making money off of the Plasma engine elsewhere, such as with MagiQuest Online, and less recently, Cosmic Osmo's Hex Isle. We need to respect that they will use this engine in future for commercial use, and that it would be beneficial for everyone if our changes are folded back into the main engine (nobody wants to maintain two versions of the engine for legal reasons).

OK, so I understand that it's very important that Cyan can continue to use this engine, with our changes, for commercial use. But it's equally important that this thing is licensed in a way that is as permissive as possible for the community.

Pavitra wrote:
IANAL, but I think a pretty good license would work something like this:

If you are not Cyan, then you may use this code as you wish, provided:
(1) you do not use it commercially (i.e., you may not make a profit), and
(2) you relicense any changes/modifications/improvements/derivative works under this same license.

If you are Cyan, then you may treat this license as equivalent to the CC0 license. (That is, you can do anything you want with it.)

This is well-intentioned but there are significant flaws with this approach. First and foremost, it is not an open source license. By definition, an open source license means that anyone can use the source code for commercial purposes. It seems a bit weird that someone else could make money off this code, but that's what you are going into when you make something open source. Open source means the source belongs to everyone, not just that everyone can see it. All open source licenses, from the very restrictive (GPL) to the very permissive (BSD) allow commercial use.

Similarly, an open source license cannot single out a particular group. A license which gives one right to Cyan, and a different right to everybody else, is not open source.

As someone has pointed out, the real assets for Cyan are the non-code assets (the textures, models, trademarks and story IP). So there is still a lot of value in this for Cyan.

Secondly, as I have said before, we do not want to create yet another license. (Firstly because it will have to be drafted by lawyers, secondly because it will make MOUL incompatible with the vast majority of other source code out there, and thirdly because a new license will have to be OSI-approved to be considered open source.)

Note that "being open source" is not just a definitional badge of honour. If the project is not released under an OSI-approved open source license, then hosting sites such as Launchpad and SourceForge will not allow the code to be hosted there.

So as I have said above, Cyan needs to choose a standard open source license. Then there are two usage scenarios -- forks and improvements.

A fork is where someone takes the MOUL code, modifies it, and makes it public, with no intention of ever submitting the changes back to Cyan. Maybe they go off and make an entirely new game based on MOUL (not in the D'ni universe, or Cyan could sue them), with a million crazy modifications to the engine which we simply wouldn't allow in Uru. It might seem greedy, but it's something you can do with open source code if you want to (and if you have a strong license such as GPL, then Pavitra's clause (2) applies -- the fork must be similarly licensed even if it isn't pushed back to the trunk -- therefore the community can borrow code back from the fork without the forker's permission, and everyone wins). For forkers, only the terms of the license apply. They do not play by Cyan's rules, they do what they want within the terms of the license.

An improvement or patch is where someone takes the MOUL code, modifies it, and makes it public, with the intention that the modification is incorporated back into the MOUL trunk, for use on the Cyan servers, etc. This is arguably the more useful for the community, and it's where most of the work will be done. People doing improvements need to follow the terms of the open source, but this is where they also have to play by Cyan's rules. Because in order to get code back into the trunk, you sign an additional agreement. Cyan can ask for anything. Cyan could say "you must sign over copyright of the code to us" (which a lot of open source projects do). Or they could say "you must grant us a perpetual right to relicense this code". It's Cyan's perogative, because if they wanted to, they could simply not accept any changes (and force us to fork it instead). This means that all the code which has been integrated into the core MOUL engine will be licensed under Cyan's terms.

So one possibility is that MOUL itself is GPL-licensed, which means you can fork it and use it commercially, but you cannot modify it without releasing the sources back. However, any code which goes back to Cyan is licensed differently with Cyan's interest, such that it's still GPL'd, but Cyan has some extra rights to it which lets them link to proprietary code (e.g., MagiQuest Online) without making MQO open source as well. This is the distinction I was trying to make earlier between the open source license and the contributor agreement.

Thus: Cyan does not have special rights with respect to the software, but all of the code in the MOUL trunk is (at least) licensed specially to Cyan, and (at most) completely owned by Cyan.

I am not a lawyer, by the way. I've just done a lot of research over the years with open source software licensing.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Apr 16, 2010 2:30 am 
Offline

Joined: Mon Sep 14, 2009 5:47 am
Posts: 35
I like this ki better it just looks more D'ni

Image

yes this came out of that zip file.

_________________
KI# 00643644
Image


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Apr 16, 2010 3:09 am 
Offline
Obduction Backer

Joined: Sun Feb 14, 2010 7:53 pm
Posts: 157
Eat_My_Shortz wrote:
This is well-intentioned but there are significant flaws with this approach. First and foremost, it is not an open source license. By definition, an open source license means that anyone can use the source code for commercial purposes. It seems a bit weird that someone else could make money off this code, but that's what you are going into when you make something open source. Open source means the source belongs to everyone, not just that everyone can see it. All open source licenses, from the very restrictive (GPL) to the very permissive (BSD) allow commercial use.

Similarly, an open source license cannot single out a particular group. A license which gives one right to Cyan, and a different right to everybody else, is not open source.

You respond below to what I'm about to say, but I want to point it out nevertheless: Cyan has no legal obligation to ever release their code at all, much less under a license that meets any particular definition (such as the official one) of "open source". I was working not from what I think open source actually is, but rather from what I thought Cyan was most likely to have in mind when they first said they were going open source.

Eat_My_Shortz wrote:
As someone has pointed out, the real assets for Cyan are the non-code assets (the textures, models, trademarks and story IP). So there is still a lot of value in this for Cyan.

Secondly, as I have said before, we do not want to create yet another license. (Firstly because it will have to be drafted by lawyers, secondly because it will make MOUL incompatible with the vast majority of other source code out there, and thirdly because a new license will have to be OSI-approved to be considered open source.)

That's completely true. I was thinking in terms of allowing the project to still be profitable to Cyan, but with these two points together -- cost of lawyers and profitability of story IP -- the tradeoff probably isn't worth it. Full open source is, surprisingly, financially better for Cyan.

Eat_My_Shortz wrote:
So as I have said above, Cyan needs to choose a standard open source license.

Agreed.

Eat_My_Shortz wrote:
Then there are two usage scenarios -- forks and improvements.
(...)
People doing improvements need to follow the terms of the open source, but this is where they also have to play by Cyan's rules. Because in order to get code back into the trunk, you sign an additional agreement. Cyan can ask for anything. Cyan could say "you must sign over copyright of the code to us" (which a lot of open source projects do). Or they could say "you must grant us a perpetual right to relicense this code".

Enhhh... I suppose it's possible that this works all the time in the real world, but I have this vague fear that we'll get into the situation where I can't ever look at the OpenDrizzle source if I want to ever submit a patch to Uru.

Eat_My_Shortz wrote:
So one possibility is that MOUL itself is GPL-licensed, which means you can fork it and use it commercially, but you cannot modify it without releasing the sources back. However, any code which goes back to Cyan is licensed differently with Cyan's interest, such that it's still GPL'd, but Cyan has some extra rights to it which lets them link to proprietary code (e.g., MagiQuest Online) without making MQO open source as well. This is the distinction I was trying to make earlier between the open source license and the contributor agreement.

Probably better to just do LGPL or something. Maybe. I dunno.

The thing is, what you describe is still forky. There are two sets of code, theoretically using the same license yet in practice licensed differently. One is community-held GPL, and one is Cyan-held GPL. Code flows one way, from the Cyan pool to the community pool, never from the community pool to Cyan's. (Individual members of the community can give things to Cyan, but the community-held codebase as a whole is by default inaccessible to Cyan.)

It is better than what I first suggested. Any forks from Cyan will be intercompatible with each other, so it's two code pools rather than N+1; and code flows one-way rather than zero-way. But I still don't like it. It just... feels suboptimal.

I dunno.

_________________
Have Ages, and link to them without bindings. [Words 1:13]
Seltani


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Apr 16, 2010 5:56 am 
Offline
Obduction Backer

Joined: Mon Jan 15, 2007 6:03 pm
Posts: 96
Great, Pavitra. I think we're on the same page now. I entirely agree with everything you've said.

Pavitra wrote:
Cyan has no legal obligation to ever release their code at all, much less under a license that meets any particular definition (such as the official one) of "open source". I was working not from what I think open source actually is, but rather from what I thought Cyan was most likely to have in mind when they first said they were going open source.

This is very true. But I would hope that Cyan would make this a true open source project, and not a "source visible, under our rules" project (the Microsoft "Shared Source" licenses come to mind). Just the fact that it isn't an OSI license makes it so much more limited what can be done with it (with regards to hosting, code sharing, etc).

Pavitra wrote:
Full open source is, surprisingly, financially better for Cyan.

I agree, except for the "surprisingly" part ;). It's a difficult business model to figure out, but a lot of companies (I dunno, Google?) profit a lot from open source, and pour millions of dollars into open source code because they know the benefits are better for them (from a purely selfish economical sense) as well as everyone else. A common mantra in open source is that proprietary software is about trying to steal the biggest piece of pie, open source is about trying to grow the pie bigger, and keep your percentage of the pie -- either way you get more pie, but with open source, everybody else gets more as well.

In this case, I'd say having a community of excited devs pouring code into your project for free is a pretty exciting thought for Cyan, especially since they are making money out of it (MQO).

Pavitra wrote:
Enhhh... I suppose it's possible that this works all the time in the real world, but I have this vague fear that we'll get into the situation where I can't ever look at the OpenDrizzle source if I want to ever submit a patch to Uru.

Yes... that would suck. What license is OpenDrizzle under? I think the ideal way around this issue isn't making Cyan give up rights to MOUL, but instead having the OpenDrizzle developers sign over some rights to Cyan, in exchange for that project being officially acknowledged by Cyan (and possibly incorporated into the official Uru trunk). I can't speak for Cyan or the Drizzle developers, but I'd expect the Drizzle developers would be very pleased if Cyan finally recognised that tool.

Pavitra wrote:
Probably better to just do LGPL or something. Maybe. I dunno.

That's possibly a good option, yes.

Pavitra wrote:
The thing is, what you describe is still forky. There are two sets of code, theoretically using the same license yet in practice licensed differently. One is community-held GPL, and one is Cyan-held GPL. Code flows one way, from the Cyan pool to the community pool, never from the community pool to Cyan's. (Individual members of the community can give things to Cyan, but the community-held codebase as a whole is by default inaccessible to Cyan.)

I was hoping it wasn't too forky. To put this in context with my original proposal (either on this thread or the other, I forget), I proposed a three-tier model: 1. Individual branches, 2. Community-supported trunk, 3. Cyan-maintained branch (off trunk).

You seem to have interpreted my model as (1) and (2) being non-Cyan-approved code, with all changes merged from (2) into (3) requiring signing. That isn't what I want.

I want the Cyan branch to closely if not exactly mirror the community-supported trunk (just with an extra layer of approval from Cyan. In other words, every change not approved by Cyan should be factored out of the trunk quickly to keep the two branches closely in sync -- one is not a fork of the other). Therefore, under my model, the (2) community trunk would require signing the Cyan agreement as well. Therefore, everything accepted into the mainstream by the community is compatible with (3) Cyan's branch.

This resembles the model of the Free Software Foundation and Python. All code committed to the trunk of Python, for example, requires that developers sign over some rights to the Python Software Foundation, so they have control of the license without having to contact each individual developer, should the licensing have to change.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Apr 16, 2010 4:33 pm 
Offline

Joined: Fri Feb 19, 2010 5:04 pm
Posts: 115
Location: England
Eat_My_Shortz wrote:
Similarly, an open source license cannot single out a particular group. A license which gives one right to Cyan, and a different right to everybody else, is not open source.

This isn't true within the normal definition of "open source". So long as you give sufficient rights to everyone, nothing prevents you from giving even more rights to specific groups.

E.g. the GPLv2 requires that you either provide the source, offer to provide it on demand, or pass on an offer from a third-party to provide it on demand. But the last option is only permitted for non-commercial distribution; if a commercial distributor receives such an offer, they must take on the responsibility for providing source.

The FSF considers the Netscape Public Licence to be a "Free Software licence" in spite of having exactly the requirement being discussed, i.e. that the original developer (Netscape) could use modifications to existing files in proprietary products.

Eat_My_Shortz wrote:
Secondly, as I have said before, we do not want to create yet another license. (Firstly because it will have to be drafted by lawyers, secondly because it will make MOUL incompatible with the vast majority of other source code out there, and thirdly because a new license will have to be OSI-approved to be considered open source.)

Creating another licence is less than ideal, but it's not a deal-breaker. Most open-source licences don't have the compatibility issues of the GPL; you can use BSD- or MIT-licensed code even in proprietary products, LGPL code can be used as a shared library by proprietary products, etc. And we can't use GPL code in MOULa so long as it uses PhysX due to clauses in the PhysX licence which are incompatible with the GPL.

An alternative is to offer the code under a normal open-source licence, but only accept modifications back into the mainline if the author is also willing to licence the modifications to Cyan for commercial use.

Without such a requirement, simply releasing the source code presents legal and reputational risks to Cyan. Once a bug fix starts to circulate, even a completely independent bug fix in the proprietary version of the engine risks a perception of misappropriation of open-source code.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Apr 16, 2010 5:22 pm 
Offline
Obduction Backer

Joined: Sun Feb 14, 2010 7:53 pm
Posts: 157
Eat_My_Shortz wrote:
In this case, I'd say having a community of excited devs pouring code into your project for free is a pretty exciting thought for Cyan, especially since they are making money out of it (MQO).


Can Cyan realistically make money from MQO (directly, in the way they're doing now) if MQO incorporates GPL'd code? This is why I was thinking earlier about special exemptions for Cyan, or later about developers assigning copyright to Cyan.

Eat_My_Shortz wrote:
Pavitra wrote:
Enhhh... I suppose it's possible that this works all the time in the real world, but I have this vague fear that we'll get into the situation where I can't ever look at the OpenDrizzle source if I want to ever submit a patch to Uru.

Yes... that would suck. What license is OpenDrizzle under? I think the ideal way around this issue isn't making Cyan give up rights to MOUL, but instead having the OpenDrizzle developers sign over some rights to Cyan, in exchange for that project being officially acknowledged by Cyan (and possibly incorporated into the official Uru trunk). I can't speak for Cyan or the Drizzle developers, but I'd expect the Drizzle developers would be very pleased if Cyan finally recognised that tool.

OpenDrizzle was just the name of a hypothetical program that might exist in the future. I imagined it as GPL, with copyright not assigned to Cyan (so that if Cyan wants to use it, such as in MQO, they're bound by the GPL). Cyan might be able to persuade the devs of one particular project to give them a special exemption, but there will always be more -- after OpenDrizzle, there's still FreeKI and plOSma...

Eat_My_Shortz wrote:
I proposed a three-tier model: 1. Individual branches, 2. Community-supported trunk, 3. Cyan-maintained branch (off trunk).

You seem to have interpreted my model as (1) and (2) being non-Cyan-approved code, with all changes merged from (2) into (3) requiring signing. That isn't what I want.

I want the Cyan branch to closely if not exactly mirror the community-supported trunk (just with an extra layer of approval from Cyan. In other words, every change not approved by Cyan should be factored out of the trunk quickly to keep the two branches closely in sync -- one is not a fork of the other). Therefore, under my model, the (2) community trunk would require signing the Cyan agreement as well. Therefore, everything accepted into the mainstream by the community is compatible with (3) Cyan's branch.

This resembles the model of the Free Software Foundation and Python. All code committed to the trunk of Python, for example, requires that developers sign over some rights to the Python Software Foundation, so they have control of the license without having to contact each individual developer, should the licensing have to change.

I thought someone (you?) earlier in this thread said that the FSF requires signing contributions over to them. "Resembles the model of the FSF" would then seem to entail "changes merged from (2) to (3) require signing".

The thing is, if changes are never signed over to Cyan, then that puts Cyan in an awkward position wrt MQO; and if changes are sometimes signed over to Cyan, then some developers won't want to do that and the codebase will fork. The remaining option is that changes are always signed over to Cyan, which requires a nonstandard, non-fully-open-source license.

_________________
Have Ages, and link to them without bindings. [Words 1:13]
Seltani


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Apr 16, 2010 5:53 pm 
Offline

Joined: Tue May 09, 2006 1:04 am
Posts: 4134
Eat_My_Shortz wrote:
Whilyam wrote:
Right. MOUL is freeware. People can try and dress it up otherwise, but it's freeware (or donationware, whatever you want to call it). The goal needs to be improving the game, not making money. You cannot make money with the present Uru, anyhow.

Yes, but Cyan is still making money off of the Plasma engine elsewhere, such as with MagiQuest Online, and less recently, Cosmic Osmo's Hex Isle. We need to respect that they will use this engine in future for commercial use, and that it would be beneficial for everyone if our changes are folded back into the main engine (nobody wants to maintain two versions of the engine for legal reasons).

Those are different versions of the Plasma engine and are not covered by this release.

_________________
-Whilyam
Cavern Link:My IC Blog


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 50 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to: