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
Open Source Governance Policy
Uncategorized Comments Off on Open Source Governance Policy
There was a legal judgment last August which is pretty significant in terms of upholding the rights of open source copyright and license holders.
The Court of Appeals for the Federal Circuit Court, which is considered the most important intellectual property appeals court in the US, upheld a open source copyright license.
In non-technical terms, the Court has held that open source licenses have the right to set conditions on the use of copyrighted work. So, even if an open source license does not collect royalty fees, it is a copyright license and the conditions need to be honored. If you violate the condition, the license disappears, and you are a copyright infringer. In other words, a open source license is just like a commercial license in that if you use the open source, you have to honor the conditions of the license.
Here is the opinion:http://www.cafc.uscourts.gov/opinions/08-1001.pdf.
This is very significant as some previously had the theory that because an open source license did not collect monetary fees, there was no real “contract” and the conditions in the license were not really enforceable.
So there you have it. Many engineers in commercial software companies download open source and incorporate it into their commercial software, without honoring the license obligations. This case, clearly establishes that the license obligations must be honored, or it is a case of copyright infringement which can lead to losing battles in court.
All of this reinforces the basic conclusion, commercial software developers should set a open source governance policy. They should decide which open source licenses have conditions which are acceptable to the organization and can be fulfilled. Any licenses which have conditions which are not acceptable should not be approved.
The organization should also scan for open source in the current source code base, using either manual methods or a professional audit firm like Source Auditor. The organization should remove any open source which is associated with licenses which are not approved and not acceptable to the organization. For many commercial organizations, this is usually open source associated with the GPL license, which accounts for over 50% of the projects in open source repositories like Sourceforge.
Of course, many GPL licensed open source projects have similar project counterparts that are licensed with friendlier licenses like Public Domain, MIT, BSD, CPL, or Apache.
The policy should also be enforced going forward, ie, the organization should review new proposed additions of open source to the commercial code base, and should decide if the proposed addition license is acceptable before approving the addition.