Cover your assThere is one huge reason to have a license for your code: cover your ass.
Designing, and implementing software is so complex no one can guaranty that it will work. So -as in any "serious" software license- you should state that you decline any liability if someone is stupid enough to think there will be no bugs.
Some idiots think that a license is necessary to assert your moral rights (you did the code). No. Code either is automatically covered by international conventions, conventions that grants you automatically full ownership at divulgation (prior act), or it belongs to the company you work for.
A good license is strictly defensive against morons. It must at least explicitly states:
- the code is yours and you should be credited for it, because ignorant people (IP pro included) forget about the international conventions (Bern/Genève);
- that you are not liable if an idiot uses your code for a nuclear power plant control resulting in a meltdown 'cause you never stipulated your code was "100%" correct (I know, it is in the nature of software, but people are really stupid);
- that you -not protecting the code against copy- does not mean people can claim ownership of it and cock block anyone from using/sharing/studying it later (espcially YOU).
Idiocy and incompetence are the most important threats in risk assessments...
If your code is shitty or you are clueless about QA: publish under GPLv3 (and later)
QA is the art of improving your code with the feedback of your users. If you are not ready to support the hidden cost of software maintenance (bug fixing, evolution, packaging, documentation, interacting with API providers): you are doomed.
Good code without QA rot.
Bad code even with QA will never evolve in good code.
If you ignore this user will know the obvious. You are bad at software development, you will be bashed by the best, adulated by the worst. Choose carefully if you prefer to be mediocre amongst the bests or best amongst the idiots.
Poor / bad software eventually may have a good reputation (PHP, gnome, GCC, automake/conf, openoffice, some linux distributions). And you may -like them- publish free software. Then my advice is, please, publish in GPLv3+.
These licenses are bad by design and hopefully they will trap you in an ecosystem where you won't pollute (too much) the effort of serious developers to improve the software/OS...
It may take decades for most to realize GPLvx+ license and some "good software" are intrinsically flawed. But I am sure the understanding will gradually come. For now GPLv+ licenses are polluting the ecosystem (cost), but they are a wonderful tool to discriminate the developers with a poor understanding of what coding really is (usefulness).
Efficient license because a one man army should focus
License, QA, documentation, community management, testing, sharing, packaging, architecture ... every software requires a lot of different skills. A software is often the result of the effort of only one person.
Free software is often crafted on free time. You want to minimize the impact of the "parameters" that are out of the code.
All the aforementioned skills are "hidden variables" that will constrict your code and divert precious energy from the fun part. The less constraining a variable is, the better it is.
With GPL you are expected, logically, to handle all the contributions you are de facto triggering (else what's the point of GPL?). Like bad code from clueless companies.
Do you really have time to waste on mentoring the noobs submitting poor code/issues into becoming seasoned developers?
You should focus on making great softwares, not teaching zealots in the truth of coding: the license does not make miracles. Publishing free software code does not grant super powers or skills as a coder.
If you are in the "ethic aspect", then a good license should not disappoint you and should not make you waste your energy in vain deception.
The deception of GPL: it cannot be enforcedOn what grounds a judge will base its reasoning and the amount of money gained from license violation? The money you lost.
No judges or developers understood that the asset is not the code but the reputation of the coders. The reason why nessusd stopped being GPL only is because GPL sux! (Btw the reputation is not assessable \o/)
Nessusd (a CVB scanner) was plagiarized and embedded in security appliances from the exact same companies giving a bad name to nessusd as a "free software thus unsecure amateur code".
Every time Renaud Déraison went for trial, he lost money; he had to spend money preparing the case, but was not granted to win. And when the judge would estimate he won, the prejudice for a free software were close to null. Thus, he was loosing time (time=money) while compelled by the license to help his "competitors" that were using his own code to prove their point of him being an amateur.
We live in an era of marketing were so called geeks are in fact marketers. Marketers packaging already existing software and selling fantasm. Steve Jobs, Big Data community, security based companies... It is a shame, but a license will not change that. Don't put too much hope in the power of license. Else you will get demotivated.
The factorial headache of license combinationsEvery so called open source license may be varying in certain degrees in their conditions of use based on :
- the condition of use (is it a web app hosted? Is it embedded? will it be used as a standalone library?);
- your potential use (CC NC ...). (Non commercial license are NOT opensource or free software. they are plain proprietary licenses marketed as free by indigent enthusiasts and marketers disguised as lawyers (yes, I think of Lawrence Lessig));
- the context in which you release it (commercial company, personal project);
- multiple licensing;
- the licensing of the IP (patents) needed to make the code;
A FLOSS license compatibility matrix today would need even with a faulty approach a 100x100 matrix. If we had the validity domain sub items, add 10 items per license (1000 x 1000 items to scan).
If you choose: apache, GPL, MIT, or any other "5 aspirins" licenses (rated on the number of aspirins you need before plainly understanding them), you introduce uncertainty in the ability you give your software for integration.
A good one man army is a control freak. Release the useless constraints to focus on what can be achieved.
Choose licenses that you understand that are clever and have achievable claims if you need to enforce them.
Useless conclusionAs a word of conclusion I will tell you what a good license is. It is a text that you should understand and you should decide on your actual rationale. If you think GPL is the good one: please, I beg you, do not change your mind.
You should be strongly opinionated, because you are investing in your future. You will rely on it, you should like it, be ready to go to court in case of litigation. You should have a license that matches the energy you wish to divert from coding in a purpose of efficiency. No middle ground exists, and it should be your call, not RMS', ESR', CC's or whoever, or even mine. So RTFL and choose wisely.
I can tell you what licenses I like. Not on a legal point of view but on an affective point. Here are my prefered one:
WTFPL: rock'n roll & concision;
BSD 2 clauses: elegance and concision;
PSL, PAL : because I don't like choosing if I use Perl or python. I use the "default" one, that is easier to integrate in the ecosystem I code in;
PAL: because it is has artistic in the name, and it makes me feel creative;
License Art Libre: okay, I really don't like the fact it is a GPL like for data. But I like the idea of non coders becoming active stakeholders and thinking about the convergence of Free (Original) Content that can integrate in Free Softwares.