In previous post I gave number of reasons why open source is a terrific thing specially for public organisations. I also promised to tell some practical considerations about releasing our software as an open source. Here you are. My experience is based on my employer’s Finnish Meteorological Institute’s, releases where I was active. I’m mainly talking about releasing old, previously propriety, software as an open source.
First the boring part: licences. I’m not a lawyer and I may be inaccurate or even wrong in some cases. But specially when handling open source software, every engineer need to think licenses at least a bit.
The first question is of course: What license should I choose? To analyse this more, first one has to decide whether he wants a permissive1 or copyleft licenses2. The most important difference is that in copyleft licences derivative work need to be published with the same license than original work. This makes copyleft licenses quite scary for many organisations.
Another remarkable aspect in licenses is a requirement of providing modifications back. For example GPL3 requires that all modifications has to be provided back to community. This is a nice idea and makes GPL quite popular with many. But it also makes a usage of such projects very hard for many organisations.
Correct choice also depends on a status of the project. If you have unique software with sure status, GPL may be a good choice. If you have to fight for your status and building community is hard, MIT or alike is much better. It’s often good idea to select familiar license for the target community. For java developers Apache4 is a familiar and for some other community MIT5 may be more friendly
To choose the license one has to also ask: What license can I use? Because of the copyleft aspect, usage of for example GPL licensed components requires publisher to either use GPL or remove the component. It’s notable still, that copyleft in GPL does not include system libraries. In practice, if you install your libraries from a common repository and link them dynamically, you probably don’t have to worry about it’s license.
In order to check what license can be used one has to know what licenses have been used in the software. In old and large software project this may be quite tricky. Happily, there are some ready tools available. Black Duck software6provides this software as a service. fossology7 developed mainly by Siemens provides probably the best open source way. Fossology is also available as docker image8 which makes using the software very easy.
Running these softwares is easy. Just upload the source code and read the results. But reading the results is not so easy. In practice, some manual check is always required. In Finland, non-profit organisation Validos9 has been a great resource to interpret the results. For member fee, Validos checks the licenses of used libraries and components and provides results for all members so that one component has to be checked only once.
It’s notable that also libraries and components that are included in the project after publication need to be compatible with selected license. This process has to be light enough so that it’s followed and does not slow down software development. But there are other aspects in selecting used libraries as well. Is library vital? Who’s developing it? What’s their business model? Checking the license is a great point to go through these concerns as well.
So, dealing with licenses is boring. It’s hard. But it’s not so hard. By questioning what license I can use and do i want permissive or copyleft license one can get far. By using ready tools like fossology and using dynamic linking handling licenses is relatively easy.
After going on this boring but necessary part, next I’m going to handle more interesting question like handling source code and other practical issues.