I've done some open source projects, and I plan to do more in the future. So far, I've released all my code under GPL, but I've read a few articles which claim GPL is too restrictive for any code to be used in corporate environment. This, supposedly, reduces contributions.

Here's what I wanted to accomplish:

For full applications:

no commercial use with the exception of selling support for the application (i.e. the app cannot be sold, but everything around it can)

For libraries (components, plugins, ...):

can be included into commercial projects without modifications

any modification the the library/component must be open sourced (contributed back) - the rest of the project, commercial or not, is not affected

For applications, GPL still seems the logical choice. For libraries, my primitive understanding of licences makes me think that LGPL is a good match, but, I'm not sure. I've looked at MIT licence, and that seems too permissive.

Most of the time, I want people to use my code anywhere they want to, as long as any improvements are contributed back.

This brings me to my question(s): is LGPL a logical choice for open source libraries, components, plugins etc? Is there a better alternative? Is GPL a good choice for my applications or is there something better?

Update:

For those who are interested in my final decision, I've decided to release my libraries under multi-license scheme, MPL, LGPL and GPL. This enables virtually everyone to use my code with no obligations, unless they modify it under MPL, in which case it would have to be contributed back.

This means the code can be used by both FSF and proprietary software, but "bad" commercial exploitation is prevented (or so I'd like to think).

Do you mean no commercial use or no commercial distribution /reselling?
–
MIAOct 16 '10 at 15:40

Probably distribution/reselling. I wouldn't mind if people used my stuff commercially, but I guess that would depend on the project. Although I don't see a way to use anything I've written so far for commercial purposes..
–
dr Hannibal LecterOct 16 '10 at 16:01

4

It's important to note that (contrary to some of the answers) the Creative Commons FAQ explicitly states CC licences should not be used for software. (The CC0 Public Domain Dedicationis approved for use with software but wouldn't be suitable for the purposes stated in the original question.) Instead CC recommends choosing a licence approved by the Free Software Foundation or the Open Source Initiative.
–
Peter BriggsDec 5 '11 at 17:20

1

My guess is, unless you've come up with something truely and genuinely unique and useful, the chance of "bad commercialization" is so small as to be not worth the time spent to try to prevent it.
–
Bryan OakleyDec 6 '11 at 13:59

If what you care about is making sure your code stays free, getting improvements back, and being sure anyone can use it, then MPL is the right license for you. It's free to use in any product, including commercial software, without weird, arcane linking restrictions like the LGPL imposes. It requires that anyone who uses your code and modifies it release the changes under MPL, but it doesn't touch or restrict any of the rest of the code in the project.

I'm not familiar with MPL at all, but it sounds very interesting. So far, I've only released PHP code so linking restrictions shouldn't be a problem, but I do plan on releasing some Mono code as well, MPL might prove very useful.
–
dr Hannibal LecterOct 16 '10 at 14:23

If you want to prevent commercial use of your software, GPL won't cut it. GPL tends to be avoided by commercial enterprises in products they sell because of the requirement to redistribute the modified source, but they're free to use GPL software internally. That's not to say businesses aren't set up to sell GPL software, or build hardware around GPL software (LinkSys, for example), but most businesses would prefer not to share their product with competitors.

I don't know if the Creative Commons Attribution Non-Commercial No Derivatives license is what you want (the only restriction you mentioned is commercial use), but if not, you might need to have a license prepared for you by an attorney that contains the language granting rights you wish license holders to have.

Also, once you begin to include such restrictions as non-commercial use and non-modifiability, you may no longer meet the criteria for an open source license as defined by the Open Source Initiative. Their site also lists other approved OSS licenses. Perhaps there's one already that matches your goals.

And adequately defining your goals will be key before selecting the rights and limitations you place on users of your software. Is popularity more important than modifiability or distribution or usage or…? Think of your objectives in releasing the code to begin with, and in what spirit you do that or the terms under which you grant access may have the opposite effect.

@Huperniketes No, they don't. A business using software (eg a database browser) is exactly the same as a person using that software. Theres no difference, as long as the project isn't incorporated into the business's final product.
–
alternativeOct 16 '10 at 16:38

3

@mathepic, you are incorrect. A business is a commercial concern - existing for profit. Any activity it engages in is commercial. And setting up a webserver running Apache to host user manuals is commercial use of Apache. The operative word, in the legal sense, is use, not distribution, not sale or resale.
–
HuperniketesOct 16 '10 at 16:47

no commercial use with the exception of selling support for the application (i.e. the app cannot be sold, but everything around it can)

Beware that the GPL doesn’t forbid selling the application, and forbidding this would indeed render your license non-free, as observed by Huperniketes. The only thing the GPL ensures is that the company selling the software would also have to provide the code base for free. But they don’t have to provide the software package as-is for free. That’s quite a big difference, since the source code of a software is not a readily usable product.

Whether you can actually apply for MPL or only GPL depends on one critical difference:

The "rights hereunder" include the right granted to recipients to link
MPL "Covered Code" with private non-MPL code to form a "Larger Work"
(MPL 3.7 Larger Works). GPL does not give recipients any such right.
Therefore, the recipient cannot change the licensing terms to apply
the GPL instead of MPL.

What this means for you is that if you are using any component which itself is GPL'ed, you (probably) cannot release code (which is using this) under MPL; MPL will wrongly attempt to allow redistribute GPL'ed code under MPL which is improper. This is fine, if your dependencies are in the order of MIT or Apache license.

In general, if you are not doing any better by choosing MPL over GPL alone unless you are already using MPL stuff. GPL will also ensures that contributions will be made published back as well.

There is only critical change MPL provides is the protection against the unknowingly induced patent infringements. As the license puts it:

It is not OK for someone to create a Modification for which he or she
has a patent, make the Modification available free of charge as
required under the License, and then come back and try to charge
everyone for the patent rights.

If you wrote all your code (that is, if you own your code) you can also dual license it: publish your code in e.g. GPLv3 and offer to sell it (with another license) to those wanting to use it less restrictively.

(this is in particular relevant for a library, because a GPL-ed library can only be used on GPL software).

Be careful about external contributions or patches that you incorporate into your code (since you don't own them).