Legal Risks of Open Source
Open Source Trends 
Comments Off on Legal Risks of Open Source
Deja vu. The feeling of having been here before.
On December 11, the Free Software Foundation filed a complaint against Cisco Systems, claiming copyright infringement related to several Linksys wireless routers. The foundation alleged that “in the course of distributing various products under the Linksys brand, Cisco has violated the licenses of many programs on which the FSF holds copyrights including GNU GCC, Binutils, Wget, Debuger, Readline, Parted, and the C library.” The foundation also said that, “Cisco has denied its users their right to share and modify the software as a result.”
The FSF has requested an injunction be issued against Cisco and asked that damages and litigation costs be awarded. The suit covers several popular Linksys routers.
Brett Smith, FSF compliance and licensing engineer, wrote in his blog, that the FSF had been working with Cisco since 2003, but despite Cisco’s efforts, “during this entire time, Cisco has never been in compliance with our licenses…”
In a statement, Cisco said: “Cisco is a strong supporter of open source software. Cisco takes its open source obligations seriously and is disappointed that a suit has been filed by the Free Software Foundation related to our work with them in our Linksys division.”
So, the FSF has decided that Cisco wasn’t moving fast enough in insuring they are in compliance with the licenses that came with the open source they are using. I don’t know how this will play out, but it points to the legal dangers of leveraging open source without also making sure that all the license obligations are fulfilled.
It sounds like the FSF is especially concerned about the GPL redistribution obligation, where all modifications to the open source, the original open source, as well as any software that is “based on” the GPL open source must be provided as open source under the GPL license.
For many commercial entities, this particular provision is the one that proves unacceptable, because it risks forcing the commercial entity to make what they consider their intellectual property into freely available open source. For these commercial entities, it behooves them to audit their software, to identify the GPL licensed open source, and to clearly identify their legal risks with relation to that GPL licensed open source.
For example, here are some typical options if the commercial entitiy finds GPL licensed open source inside its commercial software:
1. Completely remove that GPL licensed open source and replace it with proprietary software
2. Completely remove that GPL licensed open source and replace it with other open source that has a more commercially friendly license
3. Completely remove the GPL licensed open source and ask the customer to get that open source themselves. This is not a practical option for consumer focused products, but can sometimes work in the business to business market.
3. Isolate that GPL licensed open source so none of your other proprietary IP is “based on” the GPL licensed open source. This is usually interpreted as, “not linked to”, ie, your proprietary IP should not be linked to the GPL licensed open source. In this option, you still need to redistribute the modifications to the open source and the original open source.
4. If the GPL licensed open source also has a commercial license, obtain the commercial license. This is usually an expensive option but is available in some cases.
At Source Auditor, our audits provide a quick and accurate way to identify the GPL licensed open source present inside your commercial source code, as well as recommended options to remove them if the provisions are deemed unacceptable.
Legal Risks of Open Source – GPL/Linux Loadable Kernel Modules
Uncategorized Comments Off on Legal Risks of Open Source – GPL/Linux Loadable Kernel Modules
Loadable Kernel Modules are user written software which tightly binds with the operating system kernel and runs in the same address space as the kernel. This requires calls to the kernel using specially defined kernel functions.
From the point of view of the commercial software developer that develops the “user” written software, they are binding to the kernel in order to improve the execution speed and reduce the resource consumption of their software. From the point of view of the kernel developer, at least in the case of the Linux kernel, the user written software is extending the function of the kernel, is based on the kernel, and is basically a derivative work of the kernel.
This difference in point of view is leading to a disagreement about open source licenses, which increases the legal risk for commercial developers who develop software that runs on Linux, and which is implemented as Loadable Kernel Modules.
Basically, the Free Software Foundation argues that since the Linux kernel is licensed under GPL, and since the user software that is implemented as a Loadable Kernel Module is based on the Linux kernel, the user code should also be licensed under the GPL and given away as open source. Also, any user code that is statically linked to the Loadable Kernel Module should also be licensed under GPL. The FSF believes this is an especially strong argument because the calls to the Linux kernel that enable Loadable Kernel Modules are labeled as “GPL only,” so the user that implements Loadable Kernel Modules is implicitly agreeing to the GPL licensing requirement.
Many commercial software developers argue that this user written Loadable Kernel Module is not based on Linux or a derivative of Linux, but is separate and independent and they should not be compelled to license it under GPL. They would further argue that their user code runs on several kernels and is not dependent on the Linux kernel in particular.
Regardless of which side of that legal issue you are on, you can see the potential for signficant legal risk with alarming viral implications.
At Source Auditor, we believe it is best to:
- not implement user code as a LKM, if working on top of Linux
- for user code that must be developed as LKMs on top of Linux (this is often required of device drivers), the commercial software developer has to accept the strong possibility that their LKMs will need to be open sourced under GPL.
- for user code that must be developed as LKMs on top of Linux, these should be isolated, ie, not statically linked to your other code. There are “glue code” models that can be used for this.
- your existing source code should be audited for LKM implementations. These are easy to spot as the calls to the Linux kernel are well defined. Here is a wiki article with more detail on LKMs: http://en.wikipedia.org/wiki/Loadable_kernel_module
Top 15 Open Source Licenses (in Source Auditor)
Open Source Trends Comments Off on Top 15 Open Source Licenses (in Source Auditor)
GNU General Public License (GPL) 2.0
GNU Lesser General Public License (LGPL) 2.1
GNU General Public License (GPL) 3.0
Mozilla Public License (MPL) 1.1