I assume licensing isn’t the most favorite subject of many of our members. Some probably even fled to NethServer because of the licensing hell by proprietary software companies.
Well, guess what: We have our own licensing hell. And it is called license (in)compatibility.
Let me give you an example to illustrate why I am starting this discussion.
I have been active in an opensource project called Chamilo. Chamilo is an Electronic Learning environment, just like Moodle, that we now have available in the NethForge-testing repository (go test!!)
One of the dependencies of Chamilo is php-xapian. Xapian is an opensource search engine library. you can use it to index and search your content. To use xapian with php, you need to build these yourself. Php-xapian is not available in the official repositories as a binary. Why? Because the license form of xapian and php bite each other: they are not compatible with each other.
There are several sources about open source licenses. The source I often use is FSF (Free Software Foundation) or the website of Richard Stallman: gnu.org
On gnu.org there is a compatibility matrix that sheds some light:
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility
but that only compares several GPL flavors of licenses.
On wikipedia there is a more complete matrix on the most known opensource licenses:
You might ask: What does this have to do with NethServer?. Well, as you know, NethServer is a highly modular distribution. And anyone can create and add modules for NethServer. Most of the time these modules are existing projects and are shipped under a specific license.
And that’s where this topic kicks in: What if the license of the application that you want to add as a NethServer module is not compatible with the NethServer license?
I asked this question to an attorney who specialises in ‘internet law’. He responded with the following answer:
"Dag Rob,
Merci, leuke vraag. Heel in het kort, als een dependency license-incompatible is dan mag je ze niet samen shippen maar moet de eindgebruiker deze zelf downloaden en installeren. Een installatiescript dat dit automatisch doet, is op het randje. Ik kom hier in januari op terug op de blog!"
Groeten Arnoud
Which translates:
Hi Rob,
Thanks, nice question. Short answer, if a dependency is license-incompatible, you can not ship them together, but the end user must download and install the dependency himself. An installscript that is doing this automatically is considered a grey area. I will get back on this in Januari with a blogpost!"
regards,
Arnoud
Now we can do several things about this.
- do not allow incompatible modules (in official repositories, including nethforge)
- put modules like this in privately maintained repositories (like stephdl, or by any other member of the community)
- … any other options?
Key is: what do we, as a community, want to offer and how are we going to respect free licensing forms. Although it might be a pain in the behind, respecting licensing forms is VERY important. It makes what opensource is about. It allows you to use software, distribute software, change software and examine software. For some reason different forms of licensing were created. We, as a community and project have to find some way that we respect those rules and still be able to ship great software modules with NethServer.
As the second part of the answer I received states: USING software that is license incompatible with NethServer is no problem at all! All free licenses have in common that you are free to use it. The problem is with shipping them together.
I would like to come to consensus how to handle this dilemma with NethServer.