I'm just going to address the second part of your question about licences. Incidentally, I will say that this having been moved to Meta has provided an incentive for me to answer, since it's appropriate here to give personal views and opinions, whereas on Main it's not.
Probably by far the best known licence for open source work is the GNU GPL, and the fact that it's so well-known undoubtedly contributes to its continuing popularity. However, I consider this unfortunate in some ways, because of its (quite deliberate) almost total incompatibility with any other licence and expansive definitions of "linking" and "combined works".
For example, if one program produces any output (e.g., a file on disk) that another program reads and processes in an automated way, these programs are considered linked for the purposes of the GPL. Obviously, this is highly divergent from the ordinary concept of linking in software engineering (which is precisely the LGPL's reason for being, in that it reflects the typical meaning rather than this broader sense). Furthermore, if these two programs are distributed together in a non-incidental way (which by itself results in them constituting a "combined work"), if either one of them is licensed under the GPL, then the combined work must be also.
The net effect of these factors is to render the GPL highly inconvenient to use for any project that incorporates, even indirectly, commercial/closed-source ("proprietary") code; this certainly applies to Mathematica, for which the interpreter, runtime environment, and standard library all form part of a closed-source commercial product that is implicitly required by all Mathematica-language code. In my opinion, the fact that WRI asserts that the language itself is proprietary also calls into question whether the GPL can be applicable to any Mathematica project due to its absolute exclusivity toward other licences. The LGPL doesn't really help us here except if we limit ourselves to distributing LibraryLink programs (in source form only, as the LibraryLink headers aren't GPL-compatible). Mathematica does incorporate some libraries licensed under the LGPL--for example, GMP--but this is of little consequence to us as users seeking to distribute our own code. The legal issues are overall so problematic that personally I would be willing to contribute code to any GPL or LGPL-licensed Mathematica project only in the narrowest of circumstances.
So, having argued that we shouldn't use the GPL or LGPL if we wish to avoid making things unduly difficult for ourselves and other contributors to our projects, what options are still open to us? For this I think the OSSCC's licence list is a very useful resource. Their suggestions are:
- If you want a licence with strong copyleft provisions, choose the CDDL
- If you want a permissive licence, use the Apache License 2.0
Of these, I would personally prefer the latter, but I think the choice between copyleft and permissive is mainly guided by one's own political views, so legitimate disagreement is possible.
One caveat: the Apache License is long, and this level of legal detail might put some potential contributors (or even users) off. The main difference between the Apache License and the much shorter MIT License or New (2-clause) BSD License is that the former requires contributors to grant a licence to any patent rights they may have in their contributions, so as to avoid patent trolling. Where this is not an issue--for example, in code you've written yourself and just want to distribute to the community--I would probably prefer to use one of the shorter permissive licences as a matter of convenience.
Edit
Sjoerd asks:
What about SE's license?
In my opinion, while generally appropriate for the site, this is also highly problematic as far as software packages are concerned. The Creative Commons Attribution-ShareAlike 3.0 licence is a copyleft licence intended for literary and artistic works, not computer code, and as a result makes the assumptions that:
- Licensed works have a single Original Author, and that if adaptations are made then it is practical to credit or not credit each of the contributors in relation to their contributions according to their wishes. For software with multiple contributors who each build on each other's contributions, it can become impossible after a number of revisions have been made to determine who is the legitimate Original Author for each aspect of the project (however "aspect" should be defined). This is in fact the central problem of the original (3-clause) BSD License, which prompted the creation of the New BSD License by removing the "endorsement" clause.
- The qualitative nature of a licensed work is not substantially changed by any adaptations. For example, while it would certainly violate the spirit of the licence, it's somewhat unclear whether it would be technically admissible to take a work licensed under CC-by-SA 3.0 and "adapt" it as part of a machine-locked,
Encode
d commercial package, provided that the latter (now rather meaninglessly) adopted the same licence. As copyleft is of little value for software without availability guarantees for the source code, the appropriateness of this licence is called into question.
- The licensed work is purely artistic, not the embodiment of an invention, and therefore patents cannot apply to it. This leaves open the possibility of patent trolling.
Other miscellaneous problems in attempting to interpret the CC-by-SA 3.0 licence in the context of computer code also arise from the fact that the licence is clearly not intended for this purpose. Therefore, my suggestion would be not to use it for software packages, and if you want to use code presented on this site in a package, to contact the author and ask whether they'll grant you a licence under alternative terms more suitable for the purpose. (I added a notice to my profile specifying my licensing terms; perhaps it would be helpful if others did the same.)