Open Source Governance Policy
Open Source Process 
Comments Off on Open Source Governance Policy
Gartner released an interesting survey last month. Surveying 300 enterprises, they found that 85% use open source within their organization today and the remaining 15% expect to use open source within the next 12 months. That’s the good news.
The bad news? 69% of those same enterprises had no formal open source policy. This opens up huge liabilities.
As the author, Laurie Wurster, say, “Just because something is free, doesn’t mean it has no cost.” “Companies must have a policy for procuring OSS, deciding which applications will be supported by OSS, and identifying the intellectual property risk or supportability risk associated with using OSS. Once a policy is in place, then there must be a governance process to enforce it.”
So there it is. Actually, here it is, a link to the press release about the study from Gartner.
Open source is undeniably here to stay, within the most conservative enterprises. But, all enterprises should adopt policies, about what open source is acceptable and what open source is not.
From Source Auditor’s viewpoint, the policies should outline the following at a minimum:
- The licenses which contain obligations which the enterprise finds acceptable to fulfill
- The license which contain obligations the enterprise does not find acceptable
- The process for reviewing new candidate open source packages the enterprise wishes to adopt, both directly, or embedded inside commercial products
- The process to review existing software products already in use in the enterprise (to decide if that software contains open source and if that open source contains licenses which are acceptable or not)
This, of course implies, the enterprise not only adopts and enforces a policy, but the enterprise creates a review board that can review new and existing software. All existing and new software should be audited, an an inventory created of all embedded open source.
If all of this seems like a lot of effort for something that is “free”, that’s where we refer back to Gartner’s comment. Open Source may be royalty free, but it certainly has costs. The costs are no different, then the costs of insuring that any commercial royalty bearing software that you use, is in compliance with the license that came with it. As recent court cases have shown, the license obligations in open source are legally enforceable, and violating them is the same as copyright infringement.
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.
Open Source and Writing Policies
Open Source Process Comments Off on Open Source and Writing Policies
In a commercial software company, it is common practice for software developers to download free open source and incorporate that source within their own software. Most developers ignore the license obligations that come with the software. They usually think that because the software is royalty free, the license obligations probably don’t matter.
In many cases, though it does matter, at least if the software developer is using the open source software inside the commercial product, and distributing the open source to external customers.
Open Source comes with a variety of licenses. Some like public domain have no restrictions or obligations for the software developer using, distributing, or modifying either the source code or the object code.
Other licenses, though, can have restrictions on distribution or modification of the software, and can impose obligations on attribution and re-distribution of the software.
For approximately 60% of the open source packages, there is also a provision called “copy-left” which can go viral, and contaminate the proprietary commercial software which is not open source. For many commercial software developers, this is considered unacceptable.
Of course, many organizations have negelected these open source obligations, which has recently led to a series of lawsuits. In most of the lawsuits, the courts have ruled that open source license obligations are enforceable, even if no money changed hands. Thus, it is no longer a prudent option for commercial organizations to download and incorporate open source inside their commercial products without attending to the license obligations that come with that open source.
All of this leads to the need for the commercial software developer to create polices about incorporating open source inside the commercial software and to scan for open source using either manual methods or a professional open source audit firm such as Source Auditor.
Essentially, the commercial software organization needs to decide which open source licenses contain obligations and restrictions which are acceptable to that organization, and which licenses are not acceptable. For example, the organization could create an approved license list, for example (Public Domain, BSD, MIT, Apache, SUN Binary License, Common Public License and its derivatives), while considering other license such as GPL or LGPL not approved.
The organization should also audit its current commercial software to understand a census of open source inside. Any open source inside which does not meet the organization’s policy as posing acceptable obligations and restrictions, should be replaced.
This policy should then be enforced going forward, ie, when a software developer downloads open source and considers incorporating it into the commercial software, the policy should specify whether the license that comes with that open source is an approved license for that organization or not. There should be a review board that would review new submissions to decide if new licenses should be added to the approved list.
For more information about Open Source License Obligations and about tools to audit and track open source
Open Source Governance – How can I manage open source downloads that my engineers make so we can maximize productivity but eliminate the risks of open source?
Open Source Process Comments Off on Open Source Governance – How can I manage open source downloads that my engineers make so we can maximize productivity but eliminate the risks of open source?
There are four recommended strategies for managing open source within the engineering environment:
- Establish an open source policy. The policy should identify the license types that are acceptable to the organization (perhaps such as Public Domain, MIT, BSD, and Apache), any considerations for particular modules or source directories that are already approved or disapproved, approval process for including open source and consequences for not following the policy?
- Isolate 3rd party and open source code in the source repository. Establish separate directories, or even separate repositories to hold the 3rd party code. Establish a naming convention that helps identify the package and version.
- Track the open source used. Track the URL downloaded from, the original package, the licenses, and any modifications to the original package.
- Review the check-ins and enforce the policy. For small companies, this can be done manually. For larger operations, commercial tools such as Source Auditor may greatly aid in the review of open source check-ins.