Open Source Compliance Trend

June 1st, 2009

There have been a number of lawsuits over the past 2 years, and it is starting to look like a trend!  Both the out of court settlements and the court determined settlements have favored the plaintiffs, ie, the advocates of open source.  The courts have ruled that the license obligations are enforceable.  Further, it appears that both the original commercial software developer and the company that buys and distributes the commercial software are equally liable, if the open source inside the commercial software comes with license obligations that are not fulfilled.

Most of the settlements have driven the appointment of an open source compliance officer.  This is someone who is empowered in the corporation to insure that the open source license obligations are, in fact, met.  This is something Gartner has recommended for some time, and it looks like the trend to create this type of post is gathering steam.

So it is becoming official, companies using open source inside their commercial software should appoint an open source compliance officer to help create the open source policies and then enforce them.

Details of the last 9 court cases is below:

-Verizon, the telecommunications giant, was sued by the Free Software Foundation.  The suit alleged that Verizon was distributing Busybox in its FIOS wireless routers (which were made by Actiontec Electronics).  Busybox is licensed under GPL, and Verizon was accused of not honoring the GPL obligations and not making the Busybox source code available to its customers.  The suit was settled with Actiontec Electronics agreeing to 1) appoint an Open Source compliance officer 2) publishing the BusyBox source code on their website 3) informing all of their customers including Verizon of the obligations posed by the GPL license.  Of course, Actiontec Electronics is also paying an undisclosed sum to the Free Software Foundation, similar to the last 3 lawsuits brought by the Free Software Foundation.

-Diebold, maker of voting machines, was sued by Artifex, copyright owner of the Ghostscript open source package.  Artifex has accused Diebold of incorporating Ghostscript into its commercial voting machines without honoring the terms of the GPL.

-Skype, maker of the phone conferencing software, was sued by GPL-Violations.org in a German court.  The court found that Skype was guilty of not upholding the terms of the GPL.  Skype was distributing a third party VoIP phone from SMC Networks (the WSKP100) which used a version of Linux.  Skype was found to not providing an adequate mechanism for the user to get an alternative copy of Linux.  While the infraction is relatively minor, this ruling upheld the general principle that the provisions of the license are enforceable, and in this case, enforceable in Europe.

-D-Link, maker of various routers, was sued by GPL-Violations.org in a German court.  The complaint was that D-Link was selling and distributing the DSM-G600 product which incorporated GPL licensed software and yet D-Link was not meetings its GPL license obligations.  The German court found that “D-Link is not entitled to dismiss GPL’s legality on the one hand, while at the same time enjoying the use of code licensed under it.”  D-Link has signed a cease and desist agreement, published firmware on its site, and informed customers.  In addition, the court found D-Link liable for the expenses incurred by GPL-Violations.org.

-Fortinet, a small maker of firewalls, was sued by GPL-Violations.org in a German court for distributing Linux without following the terms of the GPL.  The court ruled against Fortinet, and Fortinet agreed to publish the GPL licensed code on its website and to let customers know.

-Monsoon Media, was sued by the Free Software Foundation.  The suit alleged that Monsoon was distributing Busybox, which is licensed under GPL, inside its products, while not honoring the terms of the GPL.  Monsoon settled this out of court by agreeing to pay the Free Software Foundation an undisclosed sum, while also publishing the GPL licensed code and letting its customers know.

-Xterasys Corporation, was sued by the Free Software Foundation.  The suit alleged that Xterasys Corporation was distributing Busybox, which is licensed under GPL, inside its products, while not honoring the terms of the GPL.  Xterasys settled this out of court by agreeing to pay the Free Software Foundation an undisclosed sum, while also publishing the GPL licensed code and letting its customers know.  Xterasys also agreed to create a post of Open Source Compliance Officer.

-High Gain Antennas, was sued by the Free Software Foundation.  The suit alleged that High Gain Antennas was distributing Busybox, which is licensed under GPL, inside its products, while not honoring the terms of the GPL.  High Gain Antennas settled this out of court by agreeing to pay the Free Software Foundation an undisclosed sum, while also publishing the GPL licensed code and letting its customers know.  High Gain Antennas also agreed to create a post of Open Source Compliance Officer.

-Cisco, maker of the Linksys family of routers, was sued by the Free Software Foundation for copyright infringement.  Per the suit, Cisco has incorporated several GPL and LGPL licensed components including the GNU GCC and the GNU User Stack, both essential components of Linux, and Cisco has repeatedly failed to fulfill the GPL obligations which include disclosing that their products include GPL licensed code and offering to make that code freely available to customers.  This suit was settled out of court, with Cisco agreeing to the usual conditions, ie, paying an undisclosed sum to the plaintiff and agreeing to honor the terms of the license while appointing an open source compliance officer.

Tags: , ,
Posted in Open Source Trends | No Comments »

LGPL and the obligation to replace the library

March 2nd, 2009

When most people think about the LGPL 2.1 license, they focus on the requirement to redistribute any changes they make to the library and the ability to safely use the LGPL 2.1 licensed library within commercial products as long as the library is clearly separated from the proprietary code.

What is sometimes overlooked is the obligation to allow the replacement of the LGPL 2.1 library. Section 6 of the LGPL 2.1 license describes the obligations if you distribute a commercial product containing an LGPL 2.1 library. This has several implications on the commercial license and the packaging of the product. Depending on your software and hardware architecture this may be an easy obligation to meet or a difficult one.

In the case of Java, the class files of an LGPL 2.1 library can be dynamically linked when the application starts, making it easy to replace the LGPL 2.1 library. As long as the user knows where the library is located and the Java code is not packaged in an “obfuscated” manner, the library can be easily replaced. The user must be allowed to debug and make work any such changes and this may require changes to your commercial license if it has a “no reverse engineering clause”.

Things get a bit trickier if you’re using an LGPL 2.1 package in software embedded in a device. Since the license requires that a mechanism must be provided to allow the library to be replaced, you will likely need to provide some mechanism for replacing the firmware on the device with a version of the firmware containing a replaced LGPL 2.1 library.

Perhaps the most challenging situation is when the LGPL 2.1 libraries are used in security sensitive code. There are over 100 encryption software packages on Source Forge offered under LGPL 2.1 or LGPL 3.0. If such software can be replaced, how do you ensure security of the software? Complying with this license obligation will now require the user to be rather careful and sophisticated to not accidently open up a security hole when replacing such sensitive libraries. While many users may be able to maintain or even enhance the security of the product with this capability, opening it up to all users could create a security problem. If your software is used to protect other software or media you may have obligations to maintain a level of security not practical with the requirements of this obligation.

In all cases, the supportability of the software must be considered. If the user replaces a library, what does that mean to the support you provide to your customers? This will likely have impact on your support terms and support processes.

Net, the LGPL 2.1 obligation to allow the user to replace the library is sometimes a challenging obligation to meet. This is another item to consider in setting the policy for the open source licenses that your organization will allow inside your commercially licensed software.

Tags: ,
Posted in Open Source Process | No Comments »

Legal Risks of Open Source

December 14th, 2008

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.

Tags: , , , ,
Posted in Open Source Trends | 1 Comment »

Open Source Governance Policy

December 10th, 2008

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.

Tags: , ,
Posted in Open Source Process | No Comments »

Legal Risks of Open Source – GPL/Linux Loadable Kernel Modules

November 22nd, 2008

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

Tags: , , ,
Posted in Uncategorized | No Comments »

Top 15 Open Source Licenses (in Source Auditor)

November 16th, 2008
This is a list of the top 15 open source licenses as seen in Source Auditor. Each link leads to the license text for that license.  This is useful in generating your policy as to which open source licenses are acceptable to your organization, and which open source licenses are not.  We will periodically update this list and add more licenses.

GNU General Public License (GPL) 2.0

GNU Lesser General Public License (LGPL) 2.1

Artistic License (Perl)

BSD License 2.0

GNU General Public License (GPL) 3.0

Apache License 2.0

MIT License

Mozilla Public License (MPL) 1.1

Common Public License (CPL)

zlib/libpng License

Eclipse Public License (EPL)

Python Software Foundation License

Apache License 1.1

PHP License Version 3.0

Open Software License (OSL)

Tags: , , , , , , ,
Posted in Open Source Trends | No Comments »

Open Source Governance Policy

November 13th, 2008

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.

Tags: , , ,
Posted in Uncategorized | No Comments »

Open Source and Writing Policies

November 9th, 2008

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

Firms Struggle With Open Source

Tags: , ,
Posted in Open Source Process | No Comments »

What are the typical license obligations that come with open source?

November 7th, 2008

Since there are several hundred thousand free, widely used, and well maintained open source packages on the internet, it makes perfect sense to leverage open source whenever possible.  If you are a commercial software developer that depends on selling your own software in the marketplace, however, it is important to understand the legal obligations and the legal restrictions that come with your open source license.

With most Open Source licenses, obligations and restrictions in the license only apply if you distribute the open source, i.e., you incorporate the open source inside the source or binaries that you ship to your customers.  If you use the open source software only as a tool during the development process, the obligations posed by the open source typically do not apply.

With most Open Source licenses, the typical obligations center on attribution and re-distribution.

Attribution refers to giving credit to the authors and contributors of the open source software, i.e., the commercial software provider that incorporates open source inside, might need to properly give credit to the creators of the open source.   The requirements can include none or some of the following:  do not remove copyrights in the source code; provide credit in the end user documentation; do not use the open source authors names to endorse the commercial product without permission; clearly mark if you make any modifications to the open source; if there is a redistribution requirement, clearly show in the documentation how to get the redistribution; in any advertising you do for the commercial product, make sure you acknowledge the open source component provider.

Re-distribution refers to making the open source and related components freely available, i.e., free of charge and available to the public.  This is typically under the same license as the original open source.  This can include the original open source, any modifications you make, and most importantly, any software “based on” the open source code.  “Based on” is interpreted differently depending on the license.  Some licenses are viral in nature, and by some interpretations essentially force you to make all of your own commercial software that is linked to the open source software to also be given away free.  These licenses are also called “copy-left” licenses, and pose the greatest threat to a commercial software company’s business model.

Restrictions depend on the license, but common restrictions include: do not make any modifications to the open source; do not distribute this open source software without adding value of your own with additional software; do not remove copyrights in the open source; do not initiate patent litigation against any of the contributors to the open source on the grounds that something in the open source violates one of your patent claims.  Violating these restrictions can cause the license to be terminated.

While there are several hundred unique licenses, the following discusses some of the common types:

The least restrictive licenses are public domain licenses, which are essentially no licenses at all.  Source code provide in the Public Domain are free to use without restriction i.e., you can use the source code without any attribution or re-distribution and you can make modifications and derivative works; and you can distribute any or all of the open source software as you see fit.

These are followed by MIT style licenses, so named, because these licenses follow a template created by MIT.  In these licenses, the rights are similar to public domain and the only obligation is attribution.  For MIT style licenses, this requirement is often satisfied by leaving the original copyrights that came with the open source software in place and also providing credit to the open source authors in the end user documentation.

The next common style is BSD style licenses, originally created by the University of Berkeley, with both an original and a “modified” version of the license available.  These licenses are similar to MIT style, with the additional attribution requirement that the commercial software provider cannot use the names of the open source provider as a product endorsement without explicit permission.  The original BSD license also required that in any advertising done for the commercial product, there was an acknowledgement of the open source provider; however, the modified BSD license is far more common.

The next common license style is from Apache, which is a large well organized cooperative of open source contributors, with an extensive library of open source software.  The Apache 1.1 licenses requirements are very similar to the BSD modified license requirements.  The Apache 2.0 license adds that any modifications to the open source code must be clearly marked with a change log.  The Apache 2.0 license adds an important restriction, the patent non-assert clause, which essentially states that if you initiate patent litigation against any of the authors or contributors who helped create this open source, you can no longer use the open source.

The next common set of licenses is the Common Public License and its derivatives such as Eclipse Public License, IBM Public License, Mozilla Public License, etc.  These licenses all have similar obligations to the MIT license, but they also have additional obligations in attribution and re-distribution.  The CPL license requires that the commercial software developer has to make the original CPL licensed open source code as well as any changes to that source code made by the commercial developer, available for free.  In addition, the commercial software developer has to state in the end user documentation how the user can obtain this open source code along with the changes.  Finally, the source code changes made by the commercial developer should be clearly marked.   It is important to understand, that nothing in the CPL or its derivatives compels the commercial software developer to give away for free its own code that is packaged in separate modules from the open source software.

The final common set of licenses are the LGPL v2.1 and the GPL 2.0 licenses, which together make up about 70% of all of the open source code inside sourceforge.net, a well known open source repository.

The GPL 2.0 license has all the same attribution and re-distribution requirements as the CPL license above.  However, the GPL also require any works based on those packages to be offered (re-distributed) under the same “free to the public” terms.  Most commercial software companies consider this an unacceptable license for commercial software, because it does drive a change to their basic business model.

The LGPL v2.1 license carries a similar obligation to the GPL 2.0 license but has a more restrictive definition of where the re-distribution obligation applies, which makes it friendlier to commercial companies then the GPL license.  For example, any commercial software which is dynamically linked to the LGPL licensed package does not require re-distribution.  However, the LGPL license also carries other obligations such as requiring the distributor of any package which includes the LGPL libraries to allow the end user to replace those libraries.  This may conflict with some of the terms of the commercial software package.

There are also several dozen unique licenses for individual open source packages.  While they can generally be classified as similar to one of the common licenses described above, they often have some unique requirement or feature that needs to be taken into account.

To summarize, open source licenses center on attribution and re-distribution, although they can have other requirements as well.   Understanding these license obligations, and abiding by them, is the true cost of free open source, and it is important to understand and manage these license obligations to avoid legal issues and to safely leverage open source.

When Source Auditor conducts an open source audit, we help our customers identify and understand the technical aspects of their license obligations arising from downloaded open source.  When open source packages are identified with terms unacceptable to you, we also suggest alternative implementations to replace those packages.

Tags: , , ,
Posted in Uncategorized | No Comments »

Does IT need a “Open Source Compliance Officer?”

November 6th, 2008

This is an interesting thought in an article in Information Week, citing the recent lawsuits that have been won by open source advocates.  The article notes that Xterasys settled a  lawsuit with the Software Freedom Law Center, where they admitted not following the provisions of the General Public License after downloading and incorporating Busy Box open source within their own product.  The kicker is that Xterasys agreed to create the post of Open Source Compliance Officer to insure they would not violate the provisions of open source license obligations in the future.

For a software developer, tracking the use of open source is something they should be doing, just as tracking the use of proprietary software is something they should be doing.  Providing that the software developer has a policy on open source licenses (they know the licenses which their organization would accept) the task of tracking what open source is used within the organization is relatively simple.   If desired, Source Auditor provides the means to audit the code and set a baseline inventory, which can then be easily maintained.

IT’s Newest Title: “Open Source Compliance Officer”

Tags: ,
Posted in Open Source Trends | No Comments »

Can the unfulfilled legal obligations of open source inside my source code really lead to lawsuits?

November 3rd, 2008

There have been a series of lawsuits related to unfulfilled legal obligations from open source licenses over the years. Verizon, for example, was sued by the Software Freedom Law Center on behalf of Busybox, which is a GPL licensed package. The claim was that one of Verizon’s subcontractors used a GPL licensed package in Verizon’s wireless routers, without fulfilling the re-distribution obligations of GPL. This claim was settled when Verizon’s subcontractor agreed to provide its source code free to the public.

Similarly, in recent years there have been similar successful claims against Cisco, Monsoon Multimedia, and Xterasys (see articles in the links section below). In the Cisco/Linksys case, Cisco chose to re-engineer their routers to avoid GPL based re-distribution obligations. Xterasys was settled when Xterasys agreed to pay an undisclosed sum and to meet their GPL re-distribution obligations. The Monsoon Multimedia case is still in litigation.

Lawsuit Charges Open Source License Violation
Open Source Advocates Slap Verizon with GPL Lawsuit
Open Source Developers Settle GPL Lawsuit

Tags: , , ,
Posted in Open Source Trends | No Comments »

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?

October 28th, 2008

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.

Tags: , ,
Posted in Open Source Process | No Comments »