Nov 5

 

A few words about Open Source Security…

When most software developers think about open source software (OSS), they think of reusable, well-tested, widely available, and mostly, free to use software for almost any purpose.  After all, why re-invent the wheel?  While most of this is true, many people are now aware that there are some important risks and obligations that go along with using OSS.

You may have heard about the issues with certain OSS licenses, such as GPL, and the risk to your intellectual property.  This is still a concern, but there is a much larger threat that is now top of mind for most engineers and companies:  The risk of OSS security vulnerabilities.  This is not a new problem, in fact it has been around for many years.  With the recent security breach at Equifax and the resulting loss of huge amounts of highly sensitive data, potentially affecting millions of people, this is a problem that is now being recognized as critical to address by virtually all organizations.

What if you already have a tool that parses your source code and finds vulnerabilities?  That’s a good first step, but scanning the huge amounts of open source you are likely using is unnecessary and inefficient.  Fortunately most vulnerabilities in widely used OSS are already known and are catalogued in the National Vulnerability Database, which contains a list of Common Vulnerabilities and Exposures (CVE).  The CVE describes the vulnerability and also lets you know if it is fixed in a later version of the OSS component.  So all you need is an accurate list of OSS components and versions and you can easily find any known vulnerabilities in the open source you are using.

So what happened with Equifax?  They use the Apache Struts open source package as part of their platform, and Struts has a known vulnerability in an older version.  A newer version of Struts which fixed the problem had been available for months, so Equifax could have easily prevented the breach before it ever occurred if they knew about the risk and had taken action in time.  It was as simple as knowing what OSS they were using and updating a component with a newer version already released.

Auditing your code to find OSS vulnerabilities is not a complete solution to cyber security, but it is a very important part of an overall strategy to protect your products and cloud based services from being hacked, and in turn protect your business and reputation as well.

Jeff Shapiro


May 29

By Gary O’Neall at Source Auditor

Over the past 3 years, I have been contributing to an initiative to standardizing the way open source software information is stored and transmitted between companies.

The SPDX standard is now reasonably stable and implemented in a number of open source and commercial tools making it relatively straightforward to implement.

There are two scenarios you might find yourself in:

  • Supplier – organizations providing software either directly or embedded in devices.  Suppliers are typically requested to provide an inventory of open source (sometimes referred to as a Software Bill of Materials).  SPDX provides a well defined, standard format for providing the information.
  • Consumer – organizations receiving software from other organizations.  Since the consumers must adhere to the license obligations, receiving information from the suppliers in a standardized SPDX format can help quickly identify the licenses and obligations associated with the supplied source.

Adopting SPDX as a Supplier

As a supplier, the first step is to understand the software you are providing.  If you have organizations providing software to you, see if your suppliers can provide information in the SPDX format (see Adopting SPDX as a Consumer below).

Within your development process, begin tracking the required information for the production of an SPDX document.  You can track this information in a tool that supports SPDX (such as the Source Auditor scanning tools).  You can also track this information in a spreadsheet that is formatted for the open source SPDX translator tools (see http://spdx.org/tools/spdx/spreadsheet-template-0).

If you have not already done so, you should scan your software to create an initial baseline.  Be sure to choose a tool that support output in the SPDX format.

If you already have tools and processes to manage your open source tracking, you should consider incorporating SDPX extensions to those tools.  Even if the tools are built in house, there are open source libraries that can help.  The SPDX tools available at http://spdx.org/tools are all built on a common Java library provided by Source Auditor under the Apache 2.0 license which is available at http://git.spdx.org/.  Source Auditor provides consulting services if you would like help adopting SPDX within your existing tools and process.

Adopting SPDX as a Consumer

The first step in adopting SPDX is to obtaining SPDX from your suppliers.  There are two formats which are supported:

  • Tag/Value – a text file based format which is easily readable and preferred by members of the Linux community
  • RDF/XML – a format used by web enabled application which provides a very precise description of the software using a common vocabulary defined by IETF.  Although this format is human readable, you may want to run it through a viewer (such as the open source SPDX View application found at http://spdx.org/tools/spdx/spdx-viewer).

To translate the SPDX into something a bit more manageable, consider using the SPDX Spreadsheet Translator downloadable from http://spdx.org/tools/spdx/rdf-to-spreadsheet.

If you have existing tools, check if these tools already support (or plan to support) SPDX.  If the tools are built in-house, you can use the open source SPDX libraries to implement SPDX.

Future Directions of SPDX

The current SPDX specification is version 1.1.  It provides a good mechanism for describing files and packages along with their associated licenses.

The SPDX organization is very active in listening to the user community and incorporating changes to increase the usefulness and decrease the effort in implementing the standard.

The 2.0 spec is currently being developed and includes several useful extensions:

  • Description of embedded open source packages – although you can describe an embedded package in 1.1 as a “file” with a license, 2.0 will support a hierarchy of SPDX documents
  • Description of the intended use of a file – Some files are intended as tools or optional components.  The 2.0 spec will support a large number of possible file uses to enable the consumer to better determine if a particular file will be distributed.
  • Better verification – Support for some form of digital signatures is being discussed as a mechanism for verify the originator of SPDX documents

More Information

More information for SPDX can be found at http://spdx.org.  Participation is welcome – there are 3 different sub-teams that meet regularly:

You can also contact me at gary@sourceauditor.com.


Feb 5

Can Open Source ERP Succeed?

By Derek Singleton at Software Advice:

Open source has been a great success for infrastructure software such as Linux, Apache and MySQL. Here at Software Advice, we’ve made use of all three. We’ve also made extensive use of open source development libraries like jQuery. For apps, however, we have either rolled our own or deployed commercial Software-as-a-Service (SaaS) offerings.

We’re not alone in that decision. Open-source applications have failed to gain mainstream acceptance. Despite passionate communities and a compelling value proposition, businesses just aren’t buying open-source enterprise applications. The lone exception, from what I can tell, is SugarCRM (more on this below). But why not enterprise resource planning (ERP)? Why hasn’t an open-source ERP player gained critical mass?

With so many ERP implementations getting long in the tooth, many businesses are yearning to break free from vendor lock-in. To a significant extent, open source offers freedom from vendor control. This, after all, was the original value proposition for open source, even though the whole “free” part gets most of the attention. It seems there is an opportunity for a vendor that does things differently. Can open source ERP succeed?

Here I examine the challenges open source faces in the applications market. In conclusion, I turn the question around to my readers: What do you think it will take to make open-source ERP take off?

Enterprise Applications Are Sold, Not Bought

Enterprise applications require sales and marketing to encourage widespread adoption. The traditional strength of open source is in development – thousands of developers contributing code to a greater good. The open-source expectation is that free software will sell itself. Early adopters will embrace the free technology and rave about its capabilities; the majority will follow the buzz. This has proven effective for open-source infrastructure, where the users are curious developers with the inclination and skill set to tinker with new technologies.

Enterprise applications are different. There is an expectation by the buyer that their hand will be held by doting sales professionals throughout the sales cycle. And they need it. Too many line-of-business buyers are groping in the dark during the software selection process. As a result, the best product rarely wins in the enterprise apps market. The best sales and marketing wins. In the case of ERP, open-source players are helplessly outmatched by Big ERP’s sales and marketing muscle. Oracle spends $4.6 billion a year on sales and marketing, while SAP spends $2.8 billion.

Capitalists Make Poor Contributors

Community contributions are central to the open-source model. Traditionally, the largest area of contribution has been developers writing and contributing code. However, contributions are also made in quality assurance, documentation and support. Again, this has worked well for open-source infrastructure where technology is coded for developers, by developers. There is an admirable sense of partnership between these birds of a feather. A developer’s necessity spurs innovation, while altruism and a desire to be recognized drives her to contribute that code to the open-source project.

This model breaks down when business people enter the picture. As capitalists, they are compensated to grow their firm’s profits, not support a community. Business people seek a proprietary competitive advantage. As a result, they are unlikely to share their innovations. In most cases, business people will support the core of an open-source project; however, they will soon seek to monetize differentiated extensions and other value-added enhancements to the project. Based on what I’ve read of the Compiere chronicles, it appears that the competing financial motivations of the sponsor, channel and contributors were behind many of that project’s challenges.

Application Development Requires Domain Expertise

When it comes to open-source infrastructure, contributing developers are coding in their comfort zone – deep in the technology stack. But when they’re asked to code business applications, they move beyond their comfort zone. For application development, developers need detailed product requirements, which are traditionally delivered by a business-savvy product manager. In open source, this pairing is difficult as a result of the point we made above: business people are less likely to contribute.

Again, the Compiere story is informative. Members of both the Compiere project and its subsequent fork, ADempiere, note that community contributions were primarily technical. These include database ports, performance enhancements, and new web client technology. Once again, we see the developers contributing the underpinnings they felt to be critical. Meanwhile, functional enhancements were developed by commercial entities – Compiere, Inc. and its channel partners – but were typically monetized as proprietary code, rather than contributed.

SugarCRM Has Succeeded, but it’s Fake Open

SugarCRM stands out as the one open-source application project that has gained critical mass. In fact, SugarCRM has emerged as a viable alternative to industry leader Salesforce.com. However, SugarCRM’s success has been achieved through a commercial effort that is almost indistinguishable from a traditional proprietary software vendor. The company has raised over $50 million in venture capital, it has a dedicated sales team, and it employs savvy marketing. Finally, it sells Professional and Enterprise editions, which are essentially commercial software.

Is this true open source? The community edition may be free, but it is flimsy in comparison to the commercial editions. From my perspective, SugarCRM is a commercial software product.

Is There a Path to Open-Source Applications Success?

I don’t pretend to have the answers to a problem many capable people have failed to solve, but allow me to suggest some ideas to get the conversation started:

  • Avoid traditional venture capital. I believe that most venture capitalists have lost interest in open-source. That’s fine. These professional investors are seeking growth and profits that are unlikely to be achieved in open source. Their demands will kill the project.
  • Seek out strategic investors. An ideal alternative to venture capital would be a diverse group of corporate investors. They represent “patient money,” and they can contribute domain expertise. Nevertheless, they should not gain control through the investment.
  • Focus on commodity functionality. Commercial entities are most likely to contribute functionality that they consider a commodity or undifferentiated. Critical mass could be gained by concentrating on applications like financial accounting and human resources.
  • Leverage the Cloud. Cloud hosting of open-source solutions (like this instance on Amazon EC2) eliminates much of the technical complexity of open-source solutions. Meanwhile, it can provide a new revenue steam for monetizing the project.

What do you think will be needed to make open-source ERP work?


Aug 1

Over the past 3 years, we have conducted over 100 open source audits.  Almost all of our customers were software developers, who were developing their own software, but had also added in significant open source into their software.

Here are some of the key situations that necessitated an audit:

Company was being acquired – Usually, the acquiring company will audit the seller’s intellectual property. Since the valuation of the company can be driven down by a negative audit result, it is wise to pre-audit your source code, using a professional audit firm.  Any issues can be discovered and rectified before the formal audit by the acquirer.

Company is acquiring another company – The acquirer will inherit any IP issues from the seller.   Almost all of the larger acquirers will use audit software and a professional audit firm to uncover issues prior to the closing.

Company is a large technology provider and incorporates software from a variety of supply chain participants – The lawsuits have tended to focus on the larger companies with bigger pockets, and the courts have ruled that if a company distribute software provided by someone else, and if that software has licensing issues, the distributor is equally liable as the original supplier.  This means that most large technology provider have decided to require audits from their upstream software suppliers.

Company is a software supplier to a larger technology provider. As the technology provider will require an audit, it is often a good idea to do a preliminary audit which will discover and rectify any issues.


Aug 1

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.0license 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.


Jun 1

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.


Dec 14

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.


Nov 16
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)


Nov 6

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”


Nov 3

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.