Licence choice suggestion

[Xender]

Hi.

As for GPLv3 limiting "iOS app store compatibility", I can think of some solutions.

First of all - as long as you have full copy-rights to the entire code base, you can dual-license it.

Dual licensing can be of any form the copyright holder wants:

• GPLv3 and MIT/BSD
• GPLv3 and proprietary license (whether paid or "freeware") for iOS app.
• etc. - Sky is the limit.

So the real issue as I understand it boils down to having full copy-rights for the whole base. Possible solutions for that:

1. Use MIT or BSD license - the downside is that anyone can make their own versions proprietary. I wouldn't really recommend this one.
2. Use GPL but don't accept code contributions from community, at least not for the iOS version - when all the codebase is written by you / your team, then you have the full rights for all of the code base from the start. I consider this not really a solution and against the spirit of Open Source (it'd be still "Free as in Freedom", though, I think...).
3. ("The middle way"): Contributor License Agreements: Use GPL, but accept contributions only from people who agree to sort of dual-license their modifications (at least for the iOS version) - they release it under GPL, but also give you special permission to do whatever you want with the code - including the right to re-license the whole thing under a license compatible with iOS app store.

I think the CLA way could work better than other alternatives I can think of.
It can be a bit controversial, but it's the only way I can think of that would both liberate the code (GPL) and allow you to make iOS store releases without risk of an unhappy contributor making claims to take down the app from the store.

Disclaimer: I am not a lawyer, nor a license expert.

[peppy]

Thanks for the suggestions. We still haven't finalised anything and agree that dual licensing is likely the best way forward.

[skrzyp]

+1 for MIT/BSD, since it makes the best possibilities for contribution in that project, and it's not iOS-aware

[emmiegit]

I too agree that a dual license is the way to go. I think that as much of the codebase as possible should be GPL, and any parts that are used in the iOS version would be licensed under a permissive license like the BSD or MIT licenses. This way you can allow contributions from the community (since you won't need to worry about relicensing) and still keep your software open. Apple themselves uses permissive licenses: they originally distributed the GPL-licensed GCC, and have since created Clang under the permissive UIUC License to use instead.

Regardless, this is an exciting development for the free software community and I hope the transition goes smoothly. I personally am excited at the idea of a fork of osu! focused on Linux compatibility.

[Xender]

@ammongit - Licensing a part of the project as GPL and other part as MIT/BSD can be problematic in itself.

First of all, GPL doesn't seem to be designed to be used that way. As a strong copyleft/"viral" license, it makes the project live it's own life.
Mixing different licenses would require a clear cut of what is under which license. Then you could treat MIT/BSD-licensed part as the original work and the whole project with additional code as GPL-licensed derived work.

Note the you can relicense MIT/BSD-licensed code under GPL, so you can merge MIT/BSD-licensed codebase into GPL project, but not the other way around.
This approach (permissively-licensed base project and GPL-licensed derived project) also makes it more clear for me than trying to apply GPL only to a part of the project.

Then you have to explain this to contributors, should they contribute their changes to the right project under right license.
Basically only agreeing to contribute to MIT/BSD-licensed base project under the same terms would make the result MIT/BSD-licensed.
Contributing to GPL-licensed project makes the derived result GPL-licensed by the very definition of GPL.
And no one forbids you to fork a BSD/MIT-licensed project and relicense your fork under GPL.

Basically, I think that licensing the whole thing as GPL and requiring each and every contributor to state that they "allow Peppy/osu! core developer team to use their contribution also for making iOS version" might be simpler than splitting the codebase into permissively-licensed part project and GPL-licensed "full" project and managing the separation (because if third-party contributions to GPL part will be accepted, sooner or later someone could contribute something that would be useful for iOS version to the GPL project).

Feels like hacking with licensing corner-cases...

[sr229]

I have to rule out but I consider osu! to be on BSD or MIT license but if you don't want open source editing out of it, you'll use Google's Open Source License (I guess) or AOSL

EDIT: you don't need to choose more than one license, or just create a License out of those Licenses (Like Apple did for AOSL but not GPL compatible)

[mz2212]

I've done some thinking on this as well... Is there any particular reason not to use CC-BY or other variants? It should be compatible with the App Store AFAIK (SA might break that, but it's only really important if you want the license to stay the same on derivative works).

If you need the license to stay the same, the Mozilla Public License (MPL) or the Common Development and Distribution License (CDDL) might be a couple more viable options.

[emmiegit]

@mz2212 CC-BY is not a software license. While I suppose it is possible to use it to license code, I think a GPL-like license is the best bet for osu, since we don't want other companies being able to make proprietary forks of the product. I think the MPL and CDDL are fine, but I personally think osu needs strong copyleft protection, and that those two licenses don't do enough in that regard.

The difficulty here is licensing under GPL or something while still making it compatible with the iOS app store. Here's what the FSF has to say about GPL-licensed code on the app store. The TL;DR is GPL2 and 3 are both incompatible with Apple's restrictions.

Given what everybody has said so far, I'm thinking that the best option is to have all contributors give the copyright to peppy, under the condition that it be licensed as free software. As the sole copyright holder, he can relicense parts as necessary under a permissive license for the iOS app, and the rest under GPL3. Perhaps this is where we could use the Mozilla Public License, since the MPL seems to be compatible with the app store.

[sr229]

@ammongit MPL and CDDL seems a good idea but at @peppy needs to create his own license at this point but I may recommend the Apache license but I have no idea if it has copyleft protection.

EDIT: seems LGPL was a good idea too... maybe not.....

[ThunderGemios10]

The correction for the word "Licence" is supposed to be "License"
P.S: I think GPL v3.0 is a good choice.

[peppy]

I'm Australian. Licence is actually correct for me. Live with it please.

[ThunderGemios10]

@peppy Oh, Didn't know! xD Anyways, I think GPL v3.0 is a good choice.

[Artoria2e5]

Since peppy owns the code, he can tell Apple that he is using a proprietary license for the iOS version. (Dual-licensing with a proprietary license XD.) This still stops others from uploading derivatives to App Store though -- they are receiving the code under GPL. (An evil "shared"-source iOS-only public license will help then.)

[Xender]

@Arthur2e5 - He won't own any code contributed by anyone else on the terms of GPL.
To make any contributions possible to be used for iOS version, custom contribution terms are required.
That's the somehow-tricky part, not the dual-licencing itself (which is trivial).

[Artoria2e5]

@Xender Indeed. And unfortunately CLAs sound evil too. How about something like a GPLv3 App Store Exception then? It seems that most of the incompatiblilities are caused by the DRM-related clauses in GPLv3. (I must be drunk -- without all the clauses it's almost GPLv2…)

[Xender]

@Arthur2e5 - For me, CLA-s sound less evil and much more clear than creating custom exceptions to GPL.
This is because granting the rights to dual-license the contributed code for GPL and Appstore-compatible license can be easily facilitated by a simple CLA (I think).
And it's not that CLA-s in general are evil, it all depends on the actual terms in there.

On the other hand, creating exceptions for GPL is basically changing the meaning of GPL itself.
There are some predefined exceptions for GPL - Linking Exception (which looks deprecated to me?), Font Exception etc.
But AFAIK, all of those predefined GPL exceptions are approved by FSF.

I think that creating a custom exception for GPL would require:

1. Stop using the name GPL altogether, because the resulting license is something different.
2. Study all the interactions between the proposed exception clause and all the other conflicting clauses, maybe specify some clause precedence. Okay, IANAL, I don't even know how something like this could/should be done.
   ...And I wonder if the resulting licence would be even GPL-compatible any more?

[jkemperman]

IANAL

This may be an issue when releasing for desktop or other platforms as well. peppy mentioned the following in this blogpost:

Will a part of the client code be censored? As in, connection to bancho and anti-cheat measures?

Yes, some code will be abstracted out of the open source implementation in order to continue to provide a fun and clean online gaming experience. It will be done in a way that will still allow debugging to be done with a client and server, but not the live server.

FSF states the following in their FAQ:

What legal issues come up if I use GPL-incompatible libraries with GPL software?

If you want your program to link against a library not covered by the system library exception, you need to provide permission to do that.

If I understand the GPL correctly, this means that peppy cannot release the client with any proprietary libraries to connect to bancho, unless those libraries are released under a GPL compatible license. Adding an exception to the GPL license could be a solution, but may prevent keeping future parts of osu! proprietary when those are not covered by the added exception.

This doesn't seem to be a problem with the LGPL license. The LGPL would still
require modifications in the open source part of the client to be published, but
allows linking proprietary libraries made by anyone, including peppy.

[emmiegit]

@gluestick I believe your understanding of the GPL and how it applies to linking is correct. I think that licensing osu! under the LGPL provides it with weaker copyleft protection and should be avoided if possible. However, in that blog post peppy said the following:

Will bancho be open source?

No, but bancho will not exist going forward as we are replacing it piece by piece with a better solution. The
better solution is open source.

It seems to me the best choice is to avoid the LGPL and make the entire client open source, and take anything that should be kept secret (e.g. anticheat) to the server.

(The rest of this post is not related to @gluestick's comment, but to the blog post peppy made)

One question I found interesting was the following:

Won’t people just rip osu! off and make clones? Can I make a clone?

The way I see it, if we all do things right there shouldn’t be a need for clones. We will accept features and
fixes into the main branch to cater to the largest majority of the community possible. While we haven’t yet
finalised a licence choice, it will likely NOT be legal to re-release osu! as your own game, but you could
potentially use portions of the code to make your own unique game.

I don't really understand how you can release osu! under a free software license without making it legal to re-release it as your own game. I understand trademarking the word "osu!" and copyrighting the art, but as long as somebody changes those parts, they are free to release their own version. Firefox is a good example, since you cannot release a Firefox fork and call it "Firefox" or use their logo, but if you replace them then you're good to go.

The thing is that I really don't see people making random forks as a big deal. The majority of the userbase will stay with the mainstream osu! source tree. This is where I think having osu! be completely GPL rather than LGPL is most important, since if a fork does add some features that osu! itself doesn't have and people like it, then we can take their improvements into the upstream osu! source since the fork must be GPL as well.

If osu! was LGPL or used some sort of permissive license then a competitor could release proprietary extensions and use the LGPL's linking exception or relicense the whole thing to something not open. As long as all potential forks are GPL, I think this problem is mitigated, since we can always merge in improvements.

[avail]

about the cloned servers: if made, they aren't going to be made due to people not liking the client, they will most probably be populated by banned players and the likw.

[peppy]

These already exist. A licence ain't going to do anything either way for such cases.

Anyways since i haven't posted here, let me bring you up-to-date with the situation: I am likely going to create an osu! licence specifically for the project. This is not to make it any less "free", but to use the licence to state my intentions of making the project open source. More details will come with time, but you can check out my blog post to get an overview of my intentions and the direction things are heading.

As always, nothing is final.

[xxbidiao]

So a quick question (Sorry that it may be very stupid)

Are we having both osu! and osu!stream open sourcing? Since I guess they are individually developed and have a different code base (I may be wrong but I can't find any reference on whether they are on the same one).

Since we are dual-lincencing is it a reasonable idea to apply different licence to these two versions since osu!stream have completely different game play? (a single stage can have different object sets)
If so (even with some code base share between osu! and osu!stream) LGPL should be a feasible idea.

[peppy]

osu!stream is completely separate. haven't made any decisions about that yet.

[xxbidiao]

Since currently osu!stream is proprietary, and we are talking about App Store compatibility, I assume that you are talking about "We don't want to limit osu! from going online on App Store" (Maybe I'm wrong too.) What about an independent code base for osu!stream? Then we won't be bothering on "Osu! main codebase incompatible with App store" issue anymore since we can apply licences like LGPL (which do not prevent osu!stream to use osu! code if certain conditions are met) to osu! and keep osu!stream as a portal to App Store.

I'm assuming that we are not talking about "To block people from forking osu! code to release something on App Store."

[peppy]

we plan on releasing osu! on ios and other platforms going forward. it has nothing to do with osu!stream in this case.

[xxbidiao]

Anyway let's forget osu!stream.

I mean that since App Store has its own ecosystem, it's really not that easy to give iOS players to have the same experience. At least I see many game apps claimed that even between iOS and Android version of the same app, cash-bought items can't be shared. this means even when we want to connect players from iOS platform to those from PC / Android platform we have to present different things to iOS players - In other words we need to do extra work, having a different code base if we do want an exact port at least looking from outside.

Though porting to any platform involves some extent of special customization on code, why not just calling "osu! iOS code base" another name and make it completely different software that "includes main osu! open-source code as a module legally" through some licence that allows reuse of the code without open-sourcing every code piece?

[peppy]

my plan is to use a single code base to target everything (this is the direction we are heading). i've already got osu! compiling and running on iOS using the main code base

[xxbidiao]

That's great. I believe that technology will never be the limit, but releasing it to App Store is a completely different thing :( . Anyway I'll give dual-licencing with LGPL in it a +1. This at least allow it to be included in proprietary software as a library which seems to be a feasible option for osu! in App Store.

[Xender]

Eh, LGPL is not a strong copyleft licence effectively because of the linking exception.
This is a double-edged sword - may make AppStore release easier, but won't protect that much from forks that take but do not give back.

Strong copyleft like in GPL would be better for the case - it will prevent forks that take but do not give back.
So, I feel @peppy is right with making a custom licence that will explicitely adress all the concerns from the beginning.
Making it GPL-compatible could be nice too.

On the other hand, if @peppy wants people to be able to use osu! code base to make their own proprietary games (with original gameplay, i.e. using the rendering engine, not ripping off everything), then copyleft is not desirable at all, a permissive/liberal free software licence (MIT/X11, BSD, zlib etc.) is needed for that.

[jsebean]

Don't bother with the LGPL as that is designed really for "libraries" (as is defined in that license) only and still requires corresponding source for that "library" be available with any distributed binary forms. So in cases where things are not dynamically linked you are not solving the issue of distributing binaries without corresponding source, which in the case of the GPL (or LGPL for that matter), means exact same source code that was used to create that binary. Meaning any cheat engine for example would required to be open source with the same freedoms of the GPL.

Really the LGPL should be stayed away from if it's not a library, it's not really intended to be used with an entire project that intended to be more than just a library, especially how it's worded it.

@gluestick is right regarding the GPL, if the GPL is the only license chosen and @peppy had to follow those terms from future contributions, but if providing an open source client is the goal, but you do not wish for others to make the game proprietary themselves, the best license to go with is still the GPL, it's just all in how you implement it.

So, to allow the proprietary use separately for peppy only while releasing the main client GPL, either:
1.) require all contributors to agree to a CLA to allow relicensing by @peppy with the open source client itself being released GPL.
2.) Require contributors licensed under a permissive but GPL compatible license such as MIT or BSD (not with advertising clause however). Contributor code could be used proprietary by anyone including but not limited to @peppy since those two licenses allow for that, but @peppy could then choose to only release his code GPL when he release the source while incorporating contributor code from BSD/MIT, and then license his proprietary client separately since he owns the rights to his own code and can relicense it as he wishes, with the BSD/MIT license having no issues with that when it comes to contributor code. That way, in effect anybody who wants to redistribute the client as a whole from source would have to follow the GPL as long as @peppy's code is a major part of the client and wasn't replaced, in which case, it would contain no code from peppy at that point, so why would it matter?

This is all separate to any skins and trademarks which are separate elements of the project which don't have to be licensed under any open source license whatsoever (so the osu! name or skins never have to be redistributable).

I personally like #.2, since it doesn't require a CLA since some people find it dirty but in effect fulfils the goal of the GPL for a complete open source client without allowing someone rip off the game without releasing source code as well, while still being able to implement contributions in a proprietary client with the contributors still owning the full rights themselves to license their own code as they wish in addition to MIT/BSD rather than entrusting someone (@peppy in this case) in a CLA.

Whatever you do, just remember that GPL is incompatible with proprietary code in general, so if you decide to accept contributions under the GPL without any separate license for incorporating in a proprietary client you'll end up with having another Craftbukkit on your hands, which nobody wants to see happen, so it's best to get it right the first time :)

(and for those who don't know what that was... Craftbukkit was a GPL licensed API for the proprietary Minecraft server that is (and always was) technically illegal to distribute since Minecraft server is proprietary and Craftbukkit is GPL, which is incompatible with the Minecraft EULA... which is why the md5 fiasco and wolverness thing happened and still isn't really settled and likely never will be)

[peppy]

Thanks to everyone for their feedback.

As per my recent blog post, we still have some work to do before opening up for external submissions. That said, I have come to a conclusion for a license which sits well with me. Look forward to the announcement and open sourcing in the coming months! 🎱