4

So I've done lots of open-source work. I have released many projects, most of which have fallen under GPL, LGPL, or BSD licensing.

Now I have a new project (an implementation library), and I can't find a license that meets my needs (although I believe one may exist, hence this question).

This is the list of things I'm looking for in the license.

  1. Appropriate credit given for ALL usage or derivative works.
  2. No warranty expressed or implied.
  3. The library may be freely used in ANY other open-source/free-software product (regardless of license, GPL, BSD, EPL, etc).
  4. The library may be used in closed-source/commercial products ONLY WITH WRITTEN PERMISSION.

GPL - Useless to me, obviously, as it completely precludes any and all closed-source use, violating requirement (4).

BSD/LGPL/MIT - Won't work, because they wouldn't require closed-source developers to get my permission, violating requirement (4). If it wasn't for that, BSD (FreeBSD in particular) would look like a good choice here.

EPL/MPL - Won't work either, as the code couldn't be combined with GPL-code, therefore violating requirement (3). Also I'm pretty sure they allow commercial works without asking permission, so they don't meet (4) either.

Dual-licensing is an option, but in that case, what combination would hold to all four requirements?

Basically, I want BSD minus the commercial use, plus an option to use in commercial/closed-source as long as the developer has my written permission.

EDIT: At the moment, thinking something like multiple-licensing under GPL/LGPL plus something else for commercial?

Improve this question
3
  • Due to 4, you probably wont be able to do that under a single license, and should consider dual licensing.
    – leeeb
    Commented Feb 20, 2011 at 23:58
  • In that case, what license combination would meet all the requirements?
    – Spartan-117A
    Commented Feb 21, 2011 at 0:00
  • 1
    "GPL precludes any and all closed-source use" No it doesn't. You can release your code to the public as GPL and then license it commercially to companies that don't want to publish their modifications. You're the copyright holder; you can do what you want.
    – endolith
    Commented Jan 15, 2013 at 21:47

3 Answers 3

Reset to default
5

The requirements you give are contradictory: BSD-licensed software can be used in closed-source software without any special permission; if you want your code to be usable in BSD-licensed projects, you will need to allow that too.

Improve this answer
5
  • Basically, I want BSD minus the commercial use, plus an option to use in commercial as long as they have my permission.
    – Spartan-117A
    Commented Feb 21, 2011 at 0:01
  • 2
    That doesn't make sense -- something that forbids commercial use will not be allowed in a BSD-licensed project.
    – Jeremiah Willcock
    Commented Feb 21, 2011 at 0:02
  • 2
    The point beeing that BSD minus something won't be BSD compatible anymore and therefore in contradiction with point 3.
    – Lawnmower
    Commented Feb 21, 2011 at 0:03
  • If I offered a dual-license under the LGPL, as a library it could be used with BSD code, could it not?
    – Spartan-117A
    Commented Feb 21, 2011 at 0:14
  • 3
    LGPL allows commercial use. Even if you dual with another license, a company could simply refer to the LGPL license and use your software without your permission. Basically dual licensing can only increase the freedom of use, not reduce it. Dual license means that users can choose which license they like to use.
    – Lawnmower
    Commented Feb 21, 2011 at 0:35
5

Be aware that #4 means that you'll have almost 0 closed source users. Unless it can be used without ANY hurdles, it won't end up in any commercial/closed source products. Pretty much ever.

The requirement for written permission means that someone, somewhere needs to track that permission was asked for, verify that it was obtained, and then keep that information on file somewhere such that it can be accessed later if the project/organization is sued. In a corporate environment this job will fall to the legal department, and in any normal company, they are pretty busy. So no one's going to bother - they'll work around your component instead.

Basically, the written permission thing stands as a roadblock to adoption in closed source projects/organizations, and it's almost never going to be worth the time needed to get over that roadblock. Especially since the only reason they'll be able to think of that you want to give written permission is that you intend to extract some kind of payment from them. Whether that's your intent or not is irrelevant - that's how it's going to seem, and they are simply going to go elsewhere for what they need.

If you don't want to release it for everyone to use, just make it GPL or some other license that makes it clear that it's for open-source use only. Don't try for half-measures, they will just get in the way.

Improve this answer
3

Your best bet is to dual license under the GPL (for non-web-based software) or AGPL (for web-based software) and a closed-source license of your choice (which you would grant as you wish with written permission).

More details:

Requirements 1 and 2 (attribution and disclaimer of warranty) are provided by virtually any license.

Requirement 3 (compatible with ALL open source licenses) is going to be tricky, because not all open source licenses are compatible with each other. GNU keeps an extensive list of open source licenses, with notes on their compatibility. You ought to be able to pick one of the GPL-compatible licenses listed there and be fairly confident that it will work with most open source licenses.

Requirement 4 (commercial / closed source only with permission) is problematic. The Open Source Definition prohibits discriminating against fields of endeavor (e.g., commercial use), so a single license that meets this requirement would arguably not be open source. Even the GPL doesn't prohibit commercial use ("commercial" and "closed source" aren't synonymous), so if you use the GPL, you'd need to be prepared for the possibility of companies using your code in internal closed-source applications and bundled with publicly released closed-source applications.

Improve this answer
1
  • 2
    +1, dual license gets close, but yeah requirements 3 and 4 are just impossible to reconcile. You can't be allowed in BSD/MIT projects and also prohibit commercial use.
    – Havoc P
    Commented Feb 23, 2011 at 5:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.