Proposed Open Source License update

[diafero]

Finally, we have been considering using a Contributor License Agreement to protect against protégés of Daryl McBride, the delusional CEO of SCO who claimed rights to Linux because he believed Linux was a copy of Unix. We are not entirely convinced it is necessary. We would enjoy any comments, pro or con, on CLAs.

Could you please explain how a CLA would have helped the slightest bit in the SCO issue? Like, if every Linux kernel developer would have signed a CLA to the Linux Foundation (which was only founded much later, but you get the point)... it would not have helped at all to defend against SCO's wrong accusations. I honestly do not see the connection.
Count me on the "con" side for CLAs, unless you find a good argument to require them.

[JWPlatt]

I'm not trying to argue for or against it, but I do want to put it up for discussion. If we had done this for the original GPL license, maybe we wouldn't have had to go through this relicensing process. In the words of someone who knows better than me:

Most projects never collect CLAs or copyright assignments from their contributors. Instead, they accept code whenever it seems reasonably clear that the contributor intended it to be incorporated into the project.

Under normal circumstances, this is okay. But every now and then, someone may decide to sue for copyright infringement, alleging that they are the true owner of the code in question and that they never agreed to its being distributed by the project under an open source license. For example, the SCO Group did something like this to the Linux project, see http://en.wikipedia.org/wiki/SCO-Linux_controversies for details. When this happens, the project will have no documentation showing that the contributor formally granted the right to use the code, which could make some legal defenses more difficult.

- Karl Fogel, Producing Open Source Software - page 154 to 155. Producing Open Source Software Website.

One would think that the GPL makes the intention "reasonably clear," but sometimes people have other ideas. So I'm curious about what community developers think. By the way, as is explained in the book, a CLA does not ask for copyright assignment and does not change your rights to use your code, in case anyone wonders about that.

[Hoikas]

I contribute my code under the GNU General Public license.

[Chogon]

It looks like everyone agrees with the wording of the new license. So let get this thing going!

@Paradox: what you setup for getting permissions would almost work, but I would need more information. But I do like the wording...

So, if all the developers involved could send me an email (markd@cyan.com) with the subject: MOULa Open Source re-licensing
With the following body:
"I hereby give permission for my contributions to be relicensed under the modified GPLv3 license posted by Mark DeForest (aka Chogon) at viewtopic.php?f=92&t=642.

Digitally signed by:
[the handle you use to check in code with]
[your real name]
[snail mail address]

=-=-=-=-=-
Thanks eveyone!
Mark

[added] Oh, and IMHO the CLA stuff seems like overkill for this. So let's not worry about that at this point. Thanks!

[Christian Walther]

all the developers involved

Could you post an explicit list of who these developers are? I’m unsure if you mean all developers from whom Cyan has accepted contributions in the past (which, as far as I know, would not include me), or all developers who have existing contributions elsewhere that Cyan might integrate in the future (which would include me).

I’ll assume the latter for now and send the requested e-mail as soon as I can find my PGP keys for signing.

[JWPlatt]

The contributor list is: a'moaca', cjkelly, mystler, dragossh, D'Lanor, Paradox, Branan, Hoikas, and Yootay. Rarified and I have done commits, so we'll send in something too.

This is only necessary for work currently in our CWE and MOULSCRIPT repos. Other forks, such as h'uru, need to collect permissions from their contributors. Those forks are not our responsibility. This is only a resolution to code currently in the repos. Future code will inherit the new licenses as it will appear when we push the license changes.

[JWPlatt]

I still think the content credits should be in their own file, but I suppose that since for now nobody's actually using CWE for anything non-Uru it's just a nitpick.

I just want to let you know I haven't forgotten your comment here. Unlike the license, credits can get revisions at any time without much effort, and any active project should get such revisions occasionally. I agree that there should be a separation of the engine from the game implementation (content) itself. But yes, until Uru is not the only product using CWE, it's academic - except I would also expect that some shards offering their own unqiue content would have to modify the file for themselves to credit their artists.

[Marten]

I still think the content credits should be in their own file, but I suppose that since for now nobody's actually using CWE for anything non-Uru it's just a nitpick.

I just want to let you know I haven't forgotten your comment here. Unlike the license, credits can get revisions at any time without much effort, and any active project should get such revisions occasionally. I agree that there should be a separation of the engine from the game implementation (content) itself. But yes, until Uru is not the only product using CWE, it's academic - except I would also expect that some shards offering their own unqiue content would have to modify the file for themselves to credit their artists.

So, go ahead and take care of it now? It seems there is no-one here who thinks splitting the credits is a bad idea.

OU has put considerable effort into planning for other future scenarios which today are also only academic. You've written a JPEG exception "just in case", you adopted enterprise tools for a relatively small open source project because you hope that someday "we can be ready for something big"... I could go on, but really, the effort to split a file in two seems minuscule compared to other work that's been done with no greater guarantee it will prove to be worth the investment of your time.

I'm not saying this to be mean - I would prefer the future to prove that everything you've done for Uru has been worthwhile. But it'll be awkward if you're not consistent!

[JWPlatt]

Um, well, because the permissions are all in and Chogon may be pushing at this very instant.

It is just so easy that it just didn't need to delay anything by going through another round of checks right now. The change is easy. Asking everyone "Is this okay?" is hard.

[Christian Walther]

I’ve taken a closer look at the “Open source re-licensing” changeset (a4a583e) in CWE, and it looks good.

I notice however that it not only contains the license changes, but also code changes from CWE-ou revisions 3 to 6 (mostly #ifdefs for optional SDKs, specifically: the entirety of r3, 4, 5, and the source code changes, not the project changes, of r6), with the result that the MOULOpenSourceClientPlugin/Plasma20/Sources folder of CWE (as well as everything else outside of Plasma20/MsDevProjects and StaticSDKs/XPlatform/jpeg-8c-rgba) is now identical to the one of CWE-ou.

I guess this is a good thing, but was it the intention? I think it would have been cleaner to split the license changes and the code changes into separate revisions.

In a way it’s proof that Cyan is willing to integrate contributions from CWE-ou (even though in this case it’s only contributions with no effect on the output), but why not be more explicit about that? The way it’s hidden in an unrelated change here makes me suspect it was an oversight.