Licensing issues

The choice of the three-clause BSD license

Given the goals of technology, and therefore licensing, neutrality, cooperation, non discrimination, software freedom, reusability, ease of access, use and distrbution, self promotion and acceptance, only two traditional FLOSS licenses (or to better say two classes of licenses) are viable: the Lesser General Public License and a BSD-style (or more or less equivalently MIT- or ISC-style) license.

From our point of view the first one ensures that all LGPL-covered code remains free, preventing it from being included into proprietary software and, at the same time, preventing proprietary software being used inside of it to some extent (exceptions are possible, but such things probably involve some kind of agreement beetween the two copyright holders). Furthermore, redistribution of binary-only versions is prohibited.

The second one is more permissive: it allows redistribution of binary-only versions, but also allows reuse in proprietary products with no restriction other than showing the original copyright notice.

As you can see, both are not perfect for our purposes. Myabe the best choice would be to adopt the LGPL adding some kind of exception to allow binary-only redistribution given that the source code is not modified, or use a combination of the two. But this is probably too complex to do.

So we have to choose beetween one of the two and the most appropriate seems to be a BSD-style license.

The concern of inclusion in proprietary software is understandable, but the risk should actually be quite low for the following reasons:

  • the source code for our own version will always be available, so that a concerned user can always choose to use it and the products linking to it;
  • should it ever be used as part of a proprietary operating system with visible performance, support or feature improvements, the "polymorphist" attitude of the framework to adapt to the underlying system should make it possible to make use, or not, of the derived version as well;
  • our focus on portability, cooperation and support should make it unconvenient to do such thing.

Then, there are other possible advantages for FLOSS operating system developers, such as the possibility to include it in their own API if they want to do so, whatever license they use.

Also, source files needed to support some proprietary formats cannot be redistributed, but binary-only versions are fine. A BSD-style license, in this case, was the only possible (reasonable) choice.

Avoiding license clashes

To prevent the possibility of making work together pieces of software whose licenses are not compatible, an internal system to verify the licenses of each component should probably be included somewhere.

This task, however, is postponed to some future release.

Documentation license

All the documents produced by the NASPRO projects will be released under the Creative Commons Attribution 3.0 Unported license (or subsequent versions).