views:

236

answers:

5

I am creating a game in C++. Now I am not sure on how I will distribute it yet - though I am pretty sure that I won't be asking money for it. And I am looking into a licensing and I wondered if there is a license that is suited for the undecided like me.

My current releases (which are really really early versions of the game, with far from full functionality) are executable only. However, I am actually thinking that I might release the source on an open source license. For now, I am the only contributor, so that would be no problem as I only need my own permission to move to a less restrictive license. However, when I allow other people to contribute, I would need all their permissions to do so (right?). So I was wondering if there is a license that let's me distribute the game executable only for now, but will let me switch to a less restrictive license if I want. Basically I need a license in which contributors give permission to switch to a less restrictive license up front.

Does anybody know of license (or other construction) that would allow me to do so?

Edit: There are answers stating how I should just do open source and then perhaps change the open source license later on. That's actually not an answer to my question. I am looking for a license that would allow keep the distribution rights to me for now, but also allows me to switch to an open source license later on if I want to do so - even if by that time I am no longer the sole contributor. Please stop telling me that I should just do open source.

A: 

Dual licencing is not uncommon. You could start with something restrictive like GPL (but this requires your source code to be made available) and later include a less restrictive one like MIT, BSD, etc.

Khnle
Alright, I see that isn't uncommon. However, how would that work? I mean, you do need each contributor's permission to make the license more liberal, right? Also, how could it be applied in this situation?
Jasper
+1  A: 

If you're the sole copyright holder you can make the license whatever you want.

In my opinion the FLOSS license you choose generally tells you what the contributions will be licensed under.

As Khnle answered, how are you going to encourage code patches w/o source code?

Broam
A: 

For a small project, just release it. Use WTFPL (http://sam.zoy.org/wtfpl/) and leave it at that. If you get someone wanting to contribute that'll be great. If the project really takes off the WTFPL can be overridden by GPL or BSD or MIT when the time comes.

Freiheit
+1  A: 

As long as you are the copyright holder, you can switch and add licenses all the time. If you don't want to release the source now, just do it without any open-source license yet. Also note, that when you release a version under an opensource license, you can publish newer versions of the program as closed source again, or under a different license (but the older version will stay under the previous license).

Things are of course a bit more complicated if there are more contributors. If you wan't to change/add/remove any license of a source which includes parts which are owned by someone else, you need the permission of that person (the copyright holder of that part) to do that.

Your problem now is, if I have understand correctly, that you are worrying about contributers which might help you before the opensource release. But I think the number of contributers will be quite small as long as you develop under a closed-source license and you will surely know each one personally. So, it should be no problem for you to talk to those persons (probably friends?).

Companies (if you are wondering how they solve such problems) are on the other hand completely different. In a company the employees aren't copyright holders, because they are doing it as part of their employment and so the copyright holder is the employer (which has the ability to decide freely - and without asking - about the licensing).

I hope you have now understood how licenses and copyright work in general. If you are interested in the different opensource licenses too, I would recommend to take a look at the GPL (probably the most popular one along opensource projects), BSD and MIT. The later two licenses are having the advantage that they are less restrictive making commercial usage possible.

tux21b
I know how copyright better than most people, but I think your answer is a good explanation nevertheless (for one thing, I could tell you that as long as I contract someone to make something for me, the copyright will automatically be mine, even though I am not a company). As for your license suggestions, I don't really believe in copyleft, so that would be _LGPL_, BSD and MIT.
Jasper
The fact that I know pretty well about copyright makes me want to have things in order, even if the issue isn't going to be a major one, as there isn't going to be many contributors. It's just a shame if - for example - I decide to release the code 10 years from now (when I stop supporting the software - basically like the software this is a rewrite (in the broad sense of the word) is doing right now) and I would be hindered by copyright issues and unreachable people, only because I let someone write some code today. No, when it comes to copyright, it's best to have things straight.
Jasper
Oh, and one more sidenote about the contracting part of copyright, that's us copyright law we are talking about here - that's not a universal thing. I am from the Netherlands, and if I am not mistaken, contracting is not enough to grant you the copyright here, but I am not entirely sure how it exactly works. Anyway, it isn't that relevant, but I mentioned it anyway, just to show how complex copyright issues can be.
Jasper
+1  A: 

If you don't want to open the source at first, you can copyright the code and keep it under a closed, restrictive license. If others want to contribute, make them agree to something similar to a non-disclosure agreement. Essentially, you will distribute the source code to them under a special license that allows them to modify the source code and make changes but does not give them rights to re-distribute it. Part of that agreement can state that contributors give the project unlimited rights to the use of their contributions, including but not limited to the ability to publish the code under an open-source license. That way, contributors know up-front that you might re-license the code and have no grounds to complain when you do.

Moving code to a less-restrictive license is fairly easy to do. As long as you make sure that the project either owns all the source code or has unlimited/unrestricted rights to use, modify, and re-distribute it, then open-sourcing it at your discretion shouldn't be too much of a problem.

Update: Unfortunately, there aren't a lot of pre-fabricated, NDA-like licenses like this that are freely available. Since they are designed to impart specific legal rights and enforce specific legal restrictions, they are typically drafted by a lawyer and custom-tailored for the particular project/situation.

That being said, you can probably use the available open-source licenses to write your own restrictive license. You would want your license to focus on granting and reserving your rights and not necessarily on restricting the rights of others (at least not in the same detail). For example, take the following clause (a modified version of section 2.1 of the Adaptive Public License):

2.1. COPYRIGHT LICENSE FROM CONTRIBUTORS.

(a) Subject to the terms of this License, the Contributor 
    hereby grants <<Project Owner>> a world-wide, royalty-free,
    non-exclusive copyright license to:

    (i)  reproduce, prepare derivative works of, publicly display, 
         publicly perform, distribute, sublicense, and re-license
         the Contribution; and

    (ii) reproduce, publicly display, publicly perform,
         distribute, sublicense, and re-license any derivative
         works (if any) prepared by <<Project Owner>>;

    in Source Code and Executable form, either with other Modifications,
    on an unmodified basis, or as part of a Larger Work.

You would replace "<<Project Owner>>" with either your name or the name of your project. You would also include another section that stated that recipients of the code are not permitted to share or re-distribute the code, including modified versions of it, in any way, shape, or form except to submit changes back to you. Another section would state that all modified versions of the code must be licensed under the same license, and another section would reserve (for you) the right to change the code's license. A general disclaimer (like the one at the end of the BSD License) is also a handy thing to have. You can use language from existing licenses as a template (sort of like I did above) to generate the different sections of your license.

If you do write your own license and have even the slightest possibility that you may have to enforce it legally or that it may be enforced against you, have a lawyer review it before you use it (IANAL)!

Update2: Another option that you might be able to pursue is to change the way that contributors submit their code. Your source code would carry a license that forbids the contributor from transferring the code, in source or object form, with or without modifications, to any other party for any reason, with the sole exception of submitting patch files back to you. When the contributor submits their work, have them submit only a patch (instead of the modified version of the source) and require the patches themselves to be MIT or WTFPL licensed. That way, you have unrestricted rights to use the patches, including re-licensing them or using them in your project (regardless of your project's license). You won't have to get the original author's permission to re-license your code, since the only part that they have claim to is the patch files. Your only obligation would most likely be to give proper credit to the contributor (as in a "thank you to the following contributors" section in your documentation or website), but you were probably planning on doing that anyway.

bta
Similar to how the GPL forces modified versions to also be GPL-licensed, your development license would force modified versions to be licensed by that same license. Just make sure that your development license indicates that you (or perhaps "the project") have unrestricted rights to the code in terms of use, modification, (re-)distribution, and re-licensing.
bta
@bta, when you say `your development license would force modified versions to be licensed by that same license`, you're not quite right. A license can state its redistribution (of modified versions) rules as it wants. It's true that the GPL forces modified versions to be licensed under GPL, but that's a conscience choice of the GPL known as copyleft. Take for example the LGPL, which has no such restriction and allows redistributions under any license.
Jasper
@bta, The note that I should pay attention to giving me the right to change license without giving that right to others is a good one (I just hoped that such a thing was pre-existing, but it sounds like it is not...)
Jasper
@Jasper- I meant to indicate that your license would force modified versions to use the same license *if you implemented your license using a similar methodology*. See my edit for more.
bta
@bta, that makes a whole lot more sense, indeed. Your edit offers some good insights on modifying an existing license for this purpose. Thanks for the link to the General Adaptive License!
Jasper
@bta, I don't think your exact modifications fit my exact purpose here, but it serves as a good guideline. Personally, I think it actually would be more legally sound to use the term "Project Owner" and define that term somewhere at the beginning of the license (in programming speak: not using constants in the middle of the code). That would detach the license somewhat from this very project and I guess that Project Owner could be defined such that these rights are transferable, which is probably not necessary, but it's never a waste to keep your options open like that
Jasper
@bta, Oh and do note that making the "Project Owner" a transferable thing will in fact only be a legal change, not a practical one, as the same thing can already be achieved by me relicensing the it under the same license with a different "literal" - but as a programmer I think you can see why that is a less preferable way of solving things.
Jasper
Your second update looks really interesting. Personally, I wouldn't truly like to have to work through patches only. It's a bit radical (though probably judicially very sound) but it has some properties somewhat like what I was thinking of with the help of your answers.
Jasper
I was thinking about something along the lines of disallowing any redistribution (of the work or any derived work), except by the "project owner". (sending the project owner modifications wouldn't be any problem, as he's not a third party and thus it's not redistribution) And then from there, giving the right for relicensing the code to any license to the "project owner" as well. Perhaps there should be a clause that makes it explicit that anyone may make modifications (though not distribute modified code).
Jasper
Taking a page from the APL link you gave me, I will create an exhibit B, in which the project owner will be defined - by the latest entry. Then in the license, there will be a clause how the project owner may modify exhibit B by adding a an exact piece of text and filling it in, thus giving ownership to someone else. Additionally, it would do good to have some clauses in case of death (falling back to original contributor, falling back to any contributors together, falling back to an open license). This is going way beyond my single use case, but I like it as a puzzle :P
Jasper