I have several open source projects and now I really got to a question of choosing a license. They all are somewhat licensed, but in a noob way.

I don't think I'll find something meeting all of the criteria, but maybe I can find something extensible (unlike CC, for example), so I can separately state my conditions.

I want to license both source code and non source code materials.

What I want:

  1. Allow private use without most of the restrictions. If somebody is using/forking for themselves (or a small closed group, if you can legally formulate that), then I'm OK if they don't state the changes/don't publish the source code/use it in proprietary product. Most likely they would use it like that anyway, but it's better to allow them.
  2. Allow commercial use, but with a default share-with-me clause. Yea, I can state that the project is for non-commercial use only and that I can relicense it on personal conditions, but I want to make it somewhat easier. Make money on it if you can & give me 5% or, if you don't like that, spend some time & contact me.
  3. Get notifications about other projects using mine (out of curiosity, self-importance and because it would be a good point in stuff like portfolio). If somebody is using my project (or a meaningful part of it, if you can legally formulate that) in another public project, then I want them to notify me about that (like post/email/PM).
  4. Allow relicensing for commercial use. I don't think I want somebody to take my project and close the code for themselves, but if they are sharing with me at the same time, then why not. Keeping of these conditions on a derivative project is optional.

Of course I also want my credits all over derivative projects, but that's a usual condition.

Probably all of these conditions are more of requests then requirements to a license, but that's how I'd like it.


My 2 cents is that you are after too many conflicting requirements at once. Compulsory share-back-with-me and notify-me type of licenses would likely not be what I call free, libre or open source licenses.

Based on your parameters, I would pick some kind of well known copyleft or limited copyleft license such as as the LGPL, GPL or AGPL: this would not meet all your requirements though. Yet a limited copyleft license would probably strike the best balance where you want to allow all usage including proprietary usage and want to grant some freedom to your code.

You can ask for reuse notification, but I would shy away from demanding it.

  • Currently I'm using MPL, but probably not in a right way as I was applying my conditions on top of it. If won't find anything better I'll probably go the opposite way & drop points 1 & 3 & prohibit points 2 & 4. Jul 23 '16 at 7:42
  • MPL is a fine limited copyleft license. And with the MPL 2.0 you offer the choices of the secondary L/GPL licenses too which opens up more choices to your user. IMHO, stay away from applying anything extra on top of existing licenses such as the MPL: this will likely either create a conflict or just make your project plain weird and something harder to grasp license-wise and hence a deterrent to use and reuse. Jul 23 '16 at 7:51
  • 4
    "I'll probably go the opposite way & drop points 1 & 3 & prohibit points 2 & 4" ---> Then this would no longer what wee call a free, libre or open source license but a plain proprietary license. No FLOSS license prohibit commercial use. We cannot help you further here with proprietary choices.... Jul 23 '16 at 7:51
  • 1
    For instance if this you on Github and this is your license here github.com/ZeroUnderscoreOu/SteamLinkFilterBypasser/blob/master/… then you have effectively created a "frankenlicense", e.g. frankenstein license. Your terms are conflicting with the MPL. This kind of things means either the license is not enforcable or you are effectively granting no serious rights at all. Jul 23 '16 at 7:57
  • 1
    The CC-NC licenses are NOT FLOSS licenses in the sense they does not meet neither open source definition nor the Debian FSG, nor the FSF definitions. These are proprietary license, not free, not open source. Jul 23 '16 at 8:26

I might recommend Perl's Artistic License. Section 4 will be of particular interest to you.

(4) You may Distribute your Modified Version as Source (either gratis or for a Distributor Fee, and with or without a Compiled form of the Modified Version) provided that you clearly document how it differs from the Standard Version, including, but not limited to, documenting any non-standard features, executables, or modules, and provided that you do at least ONE of the following:

  • (a) make the Modified Version available to the Copyright Holder of the Standard Version, under the Original License, so that the Copyright Holder may include your modifications in the Standard Version.

  • (b) ensure that installation of your Modified Version does not prevent the user installing or running the Standard Version. In addition, the Modified Version must bear a name that is different from the name of the Standard Version.

  • (c) allow anyone who receives a copy of the Modified Version to make the Source form of the Modified Version available to others under

  • (i) the Original License or

  • (ii) a license that permits the licensee to freely copy, modify and redistribute the Modified Version using the same licensing terms that apply to the copy that the licensee received, and requires that the Source form of the Modified Version, and of any works derived from it, be made freely available in that license fees are prohibited but Distributor Fees are allowed.

I think this satisfies your criteria. Either the user must give their modifications to you, give proper attribution, or make their code FLOSS as well.

However, if you are building a library, you should probably take note of Section 8:

(8) You are permitted to link Modified and Standard Versions with other works, to embed the Package in a larger work of your own, or to build stand-alone binary or bytecode versions of applications that include the Package, and Distribute the result without restriction, provided the result does not expose a direct interface to the Package.

So people can freely embed a modified version of your library in proprietary works, but if all they are doing is distributing a modified version of the library, then section 4 applies. From the Perl Foundation's notes:

You're totally free to embed Perl inside your software in a way that doesn't allow users to access Perl. On the other hand, if you embed it and users can nevertheless do things like running Perl scripts, then you really are distributing Perl and need make sure that your distribution fits one of the use cases in (1)-(7).

  • Thanks for the suggestion. I finally got to reading Perl's license and, quite strangely, for me it reads different: 4. You may distribute the programs of this Package in object code or executable form, provided that you do at least ONE of the following: a) distribute a Standard Version of the executables and library files, together with instructions (in the manual page or equivalent) on where to get the Standard Version. <...>. Aug 13 '16 at 23:40
  • @ZeroUnderscoreOu My fault; I linked version 1.0. I'll update the answer.
    – EMBLEM
    Aug 14 '16 at 1:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.