A Call for an Honest and Sustainable OpenSource License
blog.erlang.de
blog.erlang.de
All that does it make it difficult to interoperate with other packages, and Make it difficult to build my project, because I need to worry about 15 types of overlap.
It's 5AM and I haven't slept yet but here's the 3 second version of how licenses work-
GPL- You post your code. If I release changes, I need to post my code too.
aGPL- Same as GPL, but applies to web services.
LGPL- You post your code. If I change YOUR CODE, I need to release THOSE changes, but not my whole app.
MPL- Like the LGPL, but incompatible. Adds a line saying that people who use your code need to license the Patents, not just the code. The FSF says this is implied in the LGPL, but MPL makes it explicit.
BSD/MIT - Feel free to use the code. You don't have to contribute back.
Apache- Like BSD, but contributors must agree to license any patents.
WTFPL- Do whatever the fuck you want.
Just pick the one you like. It sounds like you want LGPL or MPL. LGPL is the more often used of the two.
Even Firefox (The M in MPL stands for Mozilla...) now offers it's code under the LGPL in addition to the MPL, so there's little incentive to put new code under MPL-only.
It WILL Strictly limit usage of your code, to the point that open sourcing it won't make much of a difference. You won't get the goodwill, you won't get the patches, it's just a bad idea. It makes it difficult for everyone else, and doesn't help you.
If you want something that forces people to contribute back, I'd suggest a dual-license, like you point out MySQL does with GPL/Proprietary. That way if they go GPL, they'll contribute back code, if they go Proprietary, they'll give you money. Either way, you win.
You already outlined your business model: "make money by helping other companies making money with our software; comprising training, enhancing our software, writing custom data apps, etc."
Nothing of that requires any licensing. You demonstrate that you can write good code, keep it up to date, invent some new things. You will have written a very useful toolkit, and no one knows it better than you. Do you really fear that someone trusts other people more to build on it? Do you really fear that you will be out of work, when you have demonstrated these skills for all the world to see?
But I see a deeper problem: why should he "open source" it then (in contrast to just providing the source)? The problem is: how does he handle contributions? They would all have to waive their commercial rights on the software _to the author_. I see this as fundamentally non-open. It may be honest, but not open-source.
And, moreover: * What rights do I own in the parts that I receive royalties for? You say, I still own the rights. But you also say that I am restricted from creating profit with the software I contribute to. Why would I do that? Also, most of the code I contribute will most likely not be usable outside of the project. * What do you do if the holder of a piece of code goes missing? (Not an uncommon problem, but it gets harder if money is involved) * What happens if my piece of code is removed from the software, do the royalties fade? * What happens if the body caring for all such things goes defunct? (Not unlikely, considering its a company) * How do you foster a group of people that actually wants to take part in such a scheme?
Also, my point was that its is fundamentally non-"open". You can have any weird kind of profit scheme with source disclosure, but that doesn't make it open source.
As I said before: i see you don't want to make the jump of letting go of the (perceived) money, which I am fine with. But please don't use the word 'open' for that.