The Open Source trials: hanging in the legal balance of copyright and copyleft

[Open source has been in the limelight for the last few years, but its legal implications have been in the dark. Research Partner Ã…se Stiller sheds some light into the legal precedents of open source, from Cisco to Skype]

For those meddling in open source software affairs, compliance with licenses is a very hot topic. In the last 2 years we have witnessed the licensing FUD (Fear, Uncertainty & Doubt) giving way to legal clarity with more and more relevant cases proving the acceptance of open source licenses by legal systems around  the world.

The secrets of Copyright
Open source software licenses are based on copyright law. The notion of copyright has a long history; some hundred years ago copying was hard to come by and a threat only to a few.  In contrast, in today’s digital world copyright is much more important as communications move around the world not in 80 days but in 8 seconds; and copying is as easy as pressing a button.

The story of international copyright starts with the Bern Convention in 1880, while the most prominent copyright law is probably the US Copyright Act from 1978. The Bern Convention was initiated by the French Author Victor Hugo in order to protect the rights of European writers against the illegal copying of books which was taking place on the other side of the Atlantic at that time.

In copyright law, the original creator has the exclusive right to reproduce a work by default, subject to certain conditions; firstly the work must reach a threshold of originality, and secondly if the work is created under commission, the person with the chequebook often becomes the copyright holder. The Fair Use doctrine also sets aside some good reasons to copy a work – for example for commenting, news reporting or research – without infringing on copyright.

Only the owner of a copyright can license or sell the right to copy the work to others, under terms and conditions of their choice. Violating these terms and conditions is in principle infringing on the copyright.

Copyright is also sticky. It will survive the creator by some 50-100 years depending on the application law at a country level. Once the copyright expires, the work enters the public domain and is no longer protected by copyright laws. Whilst open source software is by definition publicly available, this does not mean that it is freely available in the public domain as it is still under a license, be that a copyleft or copyright license.

Copyleft vs Copyright
Copyleft – one of the main innovations of open source licensing – is a word play on copyright. Copyright law is used by an author to prohibit others from reproducing, adapting, or distributing copies of the author’s work. In contrast, Copyleft allows an author to give out copies of a work with permission to reproduce, adapt or distribute, but requires any resulting copies or adaptations to also be bound by the same license agreement.

Copyleft is in reality enforced by copyright. which has been clearly demonstrated by a number of interesting legal disputes, e.g. in the New York District court case of BusyBox v. Westinghouse in July 2010 and by the US Court of Appeals for the Federal Circuit.in Aug 2008 in the Artistic License case of Jacobsen v. Katzer (more on this below).

Likewise the German and French courts have provided some good examples that they do accept copyleft licenses as valid and binding for anyone who chooses to make use of the work.

Open Source and Legal precedents
In researching the legal precedents for Open Source licenses we find that most open source license disputes are with regard to the GNU GPL v2, which was written in 1991 by the Free Software Foundation. It took more 10 years before the license was actually tried by any legal system, but since then there has been a number of highly relevant cases of open source license infringement, brought to court in Europe and in USA.

By the end of 2010 a long list of court cases have surfaced which test the validity and legality of open source licensing – the table provides a (partial) list:

Case against Year Place License about Ruling Importance
MySQL Progress Software 2002 District Court  Massachusetts GPLv2 Trademarks Settled 2002 GPL accepted by court
Harald  Welte Dlink 2001 Frankfurt AM GPLv2 GPL Binding? ruled to Welte using code = accepting GLP
Fortinet UK Ltd 2005 Munich GPLv2 compliance ruled to Welte Early test of GPL
Gigabyte Technology Co. Ltd, TomTom 2004 GPLv2 compliance Settled
Iliad 2007 Munich GPLv2 compliance ruled to Welte FSF France
First case outside of Germany
Sitecom 2004 District Court of Munich, GPLv2 compliance ruled to Welte Fist case in Eur
Skype 2008 District Court of Munich GPLv2 Compliance/source code access ruled to Welte GPL must be followed strictly
SCO AutoZone, Daimler Chrysler, IBM, RedHatIncl. countersuits 2003-2004 District Courts in  Utah, Delaware, Nevada,  Circuit Court Oakland GPLv2 IP infringements Trade secrets contact breach Settled, dismissed and referred to Novell case Ownership over UNIX code in Linux
Novell 2004 US Court of Appeal ruled to Novel 2010
SUSE Linux 2003 ICC International Court of Arbitration ruled to SuSe
AFPA Edu4 2009 Paris Court of Appeal GPLv2 compliance ruled to AFPA Downstream rights
BusyBox Astak Inc, BellMicroproducts, Best Buy, Comtrend, Dobbs-Stanford, Extreme Networks, GCI Technologies, High-Gain Antennas, Humax USA, JVC U, Monsoon, Phoebe Micro, Robert Bosch, Samsung Electronics US, Super Micro Computer, Verizon, Versa Technology, Western Digital Technologies, Xtrasys, ZyXEL Communications. 2007-2009 NY District Court GPLv2 compliance Settled/undisclosed still open (?) Monsoon was the first case for  GPL in US
Westinghouse Digital Electronics, LLC 2010 ruled to BusyBox Damages awarded
FSF Cisco 2008 NY District Court GPLv2, LGPL 2 and 2.1 compliance Settled Compliance officer
Jacobsen Katzer 2008 Federal US The Artistic License compliance ruled to Jacobsen Open source licenses are for real

The most typical violation of GNU GPL arises when consumer electronics vendors, or distributors of embedded devices using Linux (which is licensed under the GNU GPL v2.1), fail to supply the source code, copyright notice or to attach a copy of the license – all of which are required by the GPL license. It´s difficult to identify if this is caused by lack of knowledge, poor version control process, or disregard for compliance due to the perceived high cost for compliance procedures, paired with a low risk for detection.

Interestingly, in many cases, it’s not the copyright holder who sues, but a representative like Mr. Harald Welte in Germany or the Software Freedom Law center in USA.

The GPLviolations.org project, set-up in 2004 by Mr. Welte in Germany, is one such enforcer of the Open Source adherence. GPLviolations.org has brought more than 100 cases to court (including D-Link, Skype, TomTom, Motorola and Acer), all of which were successfully settled out of court. Additionally the GPLviolations and Harold Welte have won several victories in Europe over large companies such as Sitecom and Fortinet.

In the Sitecom case (2004) Welte identified his own source code in the binaries for Sitecom´s Network routers, which Welte had licensed under the GNU GPL v2.0 but Sitecom had not made the source code available or referenced the GNU GPL v2.0, both of which are a requirements of the License.  The District Court of Munich granted Welte an injunction against Sitecom Deutschland GmbH whereby Sitecom was prohibited to distribute the products, until they were compliant with the GPL terms. Sitecom appealed but lost and posted the terms for GPL on their Web FAQ for the router.

LikewiseFortinet Ltd UK was banned from distributing their Firewall and Antivirus products by the Munich district court in 2005, until they were in compliance with GPL. GPL-violations.org had found evidence that Fortinet used Linux kernel and other GPL licensed software in its FortiOS product. The Munich court granted a temporary injunction against the company for selling the products, and Fortinet was forced to make their OS available free. Fortinet had been warned by the GPLviolations.org about the violation but attempts to reach an out-of-court settlement failed.

The case of Skype
Similarly, Skype Technologies SA (a Luxemburg company) was accused of violating GPL in 2008 in the course of selling a Linux-based VoIP phone, through the Skype website. Harald Welte took Skype to a Munich court for failing to provide the source code and the license together with the phone. Skype claimed that a URL to where both license and code could be downloaded was provided in the documentation – however the German court found this insufficient under GPL v2. The license states that offering source code for downloading, is only applicable if and when the binaries are downloadable from the same place, which was not the case here. Skype Technologies eventually settled out of court.

D-Link
The2006 case of Welte vs D-Link GermanyGmbH, started much like any other open source legal dispute; D-Link failed to provide the source code for Linux Kernel modifications that were used in a network storage device, and failed to provide a copy of the GPL license. D-Link rectified this error but refused to cover the disbursements for Mr. Welte for the trial, claiming that the GPL license was not  binding for the company. The case then became more interesting as the focus thereby shifted from the usual GPL compliance to become a test of the binding mechanism for the license: Was using the software to be considered equivalent to accepting the terms in the license? The Frankfurt-am-Main’s District Court clarified that D-Link was indeed bound by the terms in GPL v2, solely by enjoying the benefits of the free software and therefore also must cover the lawsuit costs for the plaintiff, Mr. Welte.

Free Software Foundation; on the tail of license infringements
Free Software Foundation (FSF) is another non-for-profit organization that monitors GPL compliance. The FSF was founded in 1985 by Richard Stallman to promote free software, and has since set up regional entities in Europe (2001), India (2003) and Latin America (2005).

The organization is dedicated to promoting users’ rights to the four freedoms of Open Source: To Use, Study, Modify, and Redistribute software. The FSF sponsors the GNU project and maintains the GPL licenses as well as the Free Software Definition.

FSF’s is known to enforce GPL compliance through closed-door discussions rather than lawsuits, with the aim being compliance rather than monetary damages.

Aiding the FSF is the Software Freedom Law Center (SFLC), a US-based law firm founded in 2005 providing free legal services, to nonprofit open source developers. The SFLC has also published a guide on how to comply with GPL and advice on how to act if caught violating GPL.

Cisco – a case for the Supply chain manager
Assisted by The Software Freedom Law Center, the FSF initiated a case against Cisco for copyright violation under GPL and LGPL in 2008. Like many others, the case was settled out of court in 2009 resulting in a donation to the FSF, a pledge of commitment to the GPL and the appointment of a compliance director reporting to the FSF.

Cisco never disputed GPL as such but “bought themselves a lawsuit” through the acquisition of Linksys in 2003. Shortly after the acquisition, complaints started showing up on the Linux Kernel Mailing List and Slashdot on how Linksys was not providing source code for GPL licensed software used in the router firmware (Linksys had bought the chipset from Broadcom who in its turn had outsourced the driver development). FSF took action on behalf of several copyright holders against Linksys/Cisco and other companies using the same 802.11g router chipset from Broadcom, where the issue had originated.

BusyBox –  when no one is too big
Among the more interesting cases for general acceptance of Open Source licenses are the BusyBox cases which involved major corporations, including Verizon, Samsung and Westinghouse.

BusyBox is a set of common Unix/Linux utilities, all packaged in a small executable and typically used in embedded systems. The software is licensed under GNU GPL v2.

The BusyBox legal saga started with 4 different cases of copyright infringements, as a result of the distributors failing to provide source code. The first action was against Monsoon Multimedia which became the first GPL copyright lawsuit in US history. The case was settled in October 2007 with Monsoon agreeing to appoint an open-source compliance officer besides publishing the source code. There was also a monetary part of the settlement but the amount was never disclosed.

The Monsoon case was followed by High-Gain Antennas and Xterasys in 2007 and Verizon in 2008. Picking up speed and size, since 2009 14 new companies (including BestBuy, Samsung, Westinghouse, JVC) were sued by SFSC for violating the GPL license of BusyBox software.

Much like Monsson, Verizon settled in 2008 while it appears that four more defendants (Samsung, Comtrend, Dobbs-Stanford, and GCI Technologies) have also settled with the plaintiffs. The only exception was Westinghouse where a District Court in NY ruled in favor of BusyBox in August 2010. The infringement was considered willful and the damages were tripled by the judge.

MySQL, a near-test for open source derivatives
One of the reasons for uncertainty around Open source licenses and especially the GPL v2 is the often-discussed question about how to define derivative work, and how to link software to GPL-code without having to license that software under GPL too, a requirement of the GPL. This is often described as the ‘viral’ nature of the GPL and remains a core concern for many companies is the linking of proprietary software libraries to GPL licensed code.  It is generally accepted that if the linking is static then the proprietary code must also be included under the GPL license whereas if the linking is dynamic the linked software is not necessarily a derivative of the GPL and as such not bound to the GPL redistribution terms.

Now given that the definition of a derivative work in GPL v2 is unclear, this issue remains a concern, albeit slightly clarified in GPL v3.  For an analysis on the differences between GPL v2 and GPL v3, VisionMobile has published a free paper: The GPLv2 vs. GPLv3: The Two Seminal Licenses, Their Roots, Consequences and Repercussions.

In the context of derivative work and legal precedents, it is also worth discussing the case of NuSphere in 2002.  NuSphere produced a database add-on component (called Gemini) to the MySQL engine. As NuSphere’s Gemini component was statically linked with MySQL’s GPL-licensed database, MySQL sued NuSphere for non-compliance with the license terms. The judge however refused to allow the arguments in the case to expand beyond a mere trademark dispute and urged for an out-of-court settlement between the parties, leaving the definition of derivative work still in the dark and unclarified. 

The Jacobsen case and the Artistic license
The now-famous Jacobsen vs Katzer case revolves around a Java software interface for model railroads, made available under the Artistic License (an approved Open Source license) by the developer Mr. Robert Jacobsen. The software was used by Mr Katzer´s company, in a competing solution, but they failed to provide information about the origin of the software – in violation of the licensing terms. The case was first tried in a US District court and the ruling then was that the license was to be regarded as a contract – not a license.

However the case was appealed in 2008 to the US federal court, when the judgment was reversed in favor of the Artistic License and Mr Jacobsen, thereby providing a legal precedent for Open Source licenses as valid and legally binding.

The SCO Group opera isn’t over yet
This is a story about copyright of Linux code, featuring celebrities such as IBM, Novel, RedHat and SGI. In 2003, the SCO Group based in Utah, claimed that Linux infringed their copyright and trade secrets, and subsequently demanded that Linux users needed a license from them, for parts of the Linux code.

The SCO Group sued a number of companies for donating UNIX code to Linux. The software donations included code that SCO claimed ownership of and thus the accused companies had violated SCO´s copyright. SCO also argued that GPL would not be enforceable in this case because it was preempted by the copyright law, protecting SCOs rights. (see detailed story on Groklaw).

The SCO soap opera of legal precedents has no less than five acts: SCO v. IBM, Red Hat v. SCO, SCO v. Novell, SCO v. DaimlerChrysler and SCO v. AutoZone. It includes ingredients like lawsuits, countersuits, appeals and bankruptcy protection. In 2007 a US federal court ruled Novel to be the owner of UNIX, invalidating the claims from SCO but there is a new appeal from SCO, and a Novel has filed a petition for certiorari* with the US Supreme Court. Meanwhile the final episode in this saga is yet to come.

Edu4 and downstream rights
In 2009 Paris Court of Appeals set a French legal precedent in favour of GPL, in a typical case of binaries but no source. In this case the lawsuit was not filed by the copyright owner, but by the end-user, which makes it all the more noteworthy.

The story goes all the way back to 2000, when Edu4 had distributed a GPL licensed VNC remote access software, for PCs, to a French education organization (AFPA),but refused to provide the source code for its modified version of the program when AFPA, assisted by the French FSF, requested that.

Open source licensing gaining legal maturity
The number of law suits, rulings and discussions above indicate that Open Source licenses are indeed enforceable under Copyright law, and that the enforcers will not hesitate to take large corporations to court for violations. Giving software away for no monetary charge does not invalidate copyright, and damages will be awarded for infringements even though the price for the code was zero.

There is no longer a need to question the legality of Open source licenses.There are enough legal precedents demonstrating that Open source licenses are valid legal documents and binding for anyone who uses the code.

Knowing that the Open Source licenses are in fact tested, tried and fully accepted by the legal system may deal with the U (uncertainty) and the D (doubt) in FUD, but for the remaining F (fear) the best remedy is information. The only good way to mitigate the risk of infringements is to ensure that everybody involved in the development process, has a good understanding of the obligations and restrictions of Open Source licenses, and that the an organisation’s Open Source policy is appropriate – assuming of course that there is one.  Many engineers already know a lot about Open Source software and the licensing models, but do their managers know?

Keeping track of Open Source software that maybe included in the next software release is crucial for any company, and the best way to start is of course with a thorough review of existing codebase, establishing a solid process and of course a comprehensive training program for developers to CxOs.

There is obviously much to discuss besides the narrow focus of this article on court cases. Do you have more examples and experiences to share on open source licensing?

– Ase

* The U.S. Supreme Court uses the Latin term Certiorari for appeals.

[Ã…se is a Research Partner at VisionMobile specializing in software sourcing, policies and training. Ã…se co-delivers VisionMobile’s Open Source Chessboard, a full-day training course on the economics and competitive landscape of mobile open source, covering business models, licenses & patents, governance models, control points, community cultures, plus 10+ case studies on the who’s who of open source.]

Open Source in the mobile supply chain: Introducing community KPIs

[Managing an open source project is not just about choosing your contributors.. Ã…se Stiller, breaks down the complexities of OSS software in the supply chain and introduces a new set of KPIs for evaluating communities.]

CommunitiesAs a software vendor or handset manufacturer, your sourcing process starts with choosing your suppliers. More and more often this choice involves use of Open Source Software (OSS):
– Handset manufacturers are building mobile phones with more ready-made building blocks – and more ready-made blocks are built with OSS.
– More and more important components are coming under an Open Source license. Not just operating systems and application environments (see Android, WebKit, Qt, S60/Symbian, ..) but also low level drivers and critical enabling software.

This is good news for all of those who believe in Open Source as a way to cut costs, improve quality and get away from supplier monopolies and black-box software. With OSS, mobile software companies and handset manufacturers can focus on the real thing; to make money, and not how to squeeze the most out of every license and supplier agreement.

Why open source challenges conventional software wisdom
Open Source in the supply chain introduces some interesting challenges; like
how a software vendor can keep ahead of competition when the repositories are public, and
– how can they stay in control of the product roadmap, when all the usual control mechanisms lose their charm overnight.

There are a number of aspects in which companies will need to change processes and policies to adapt to this new Open Source world, i.e.
– Sourcing process and inbound licensing
– Product planning and product control
– Project management and production control
– Product outbound licensing to customers, partners and open source communities and IP control.

Each of these is a topic for an article by itself, but here I will focus on the first topic; how to manage open source as part of the software sourcing process.

Unfortunately the usual complexity in software sourcing will not go away with Open Source, but the challenges will come in a slightly different flavour.

With OSS there will be no more… … but instead we must…
Tedious negotiations over details in the contract Put in substantial amount of time to figure out how the license terms will work with the specific component, product and market.
Nightly panic attacks over liability clauses Sweat over the risk that we lose the rights to use and distribute
Travel to suppliers in faraway places to ask nosy questions about finances and quality efforts Spend hours on understanding the impact of Governance models of Open Source projects

OSS or not, when sourcing we still have the same needs for a future proof-solution, technical requirements compliance, legal bullet-proofing and sound financials. But let’s walk through these one step at a time.

Sourcing with Open Source
The starting point for software sourcing is the identification of the requirements, followed by the Build Or Buy decision (B/B). The following diagram shows how the sourcing previous works with proprietary software (left) and OSS software (right).

sourcing-processpng2

The first action is to capture software requirements; this is no different for OSS than for proprietary software.

Then instead of the usual RFI & RFQ (Requests for Information and for Quotation) the technical investigation of the OSS is managed in-house, and the Total Cost of Ownership is a result of internal budgeting, not the bottom line in a tender.

The licensing of OSS is generally much easier, as all the terms and conditions are known from the start – and that’s a refreshing change! I must admit though that some licenses are tougher than others to analyze, such as GPL. It takes a good technical insight to fully understand the risks.

Another thing to take into account is obligations that will be inherited downstream. The license must be agreeable to all links in the value chain.

Key performance indicators for Open Source projects
Now to the most radical change; the supplier assessment and control.

Forget about traditional Key Performance Indicators as assessment tools, they won´t work. We can however attempt to identify a new set of KPIs for Open Source communities; KPIs that are measurable and offer a standardized way to evaluate the governance model. For this we must ask the right questions about the community and convert these answers into quantifiable values.

First let’s identify what is important to know about a community serving as a supplier, and why. How can we assess the community’s ability to deliver according both now and in the future?

The first two community KPIs we need to evaluate are the visibility of plans and the visibility of code.

We then need to evaluate who much influence can we exert of the OSS project development plans (as we won’t have any supplier contracts and control mechanisms). We therefore need to evaluate a third indicator; the influence over the decision process.

KPIs

Influence as a KPI is multi-dimensional and therefore we need to break it down into measurable components: (the below are a first attempt, feel free to add and suggest better names).

Decision accessibility: What does it take to get into the deciding team?
Changeability: Can we post a change request?
Openness: Can we contribute a new feature?
Priority: What is our importance to the community?

The questions above are only a subset of a more substantial list of questions that we use, but I won´t bore you with the details here.

The last resort – and one of the true benefits with Open Source from a sourcing perspective is the option to fork. This too must be evaluated and the forkability depends on factors like the modularity and documentation.

When we try to measure the forkability what we are really trying to measure is the cost of the development needed for the branch now and in the future, as well as the cost to backport changes from the tip of the tree into our branch.

In proprietary software sourcing this option corresponds to bespoke customization of the product, and the issues are basically the same. With Open Source there is a chance you will have followers that will share the burden, but worst case you are on your own.

Managing the change
OSS software sourcing is a new type of strategic alliance and it takes new ways to evaluate and manage in the supply chain. We are facing a mini revolution and the traditional control mechanisms are becoming obsolete.

In this article I have dealt solely with the impact to the inbound licensing process. Naturally many other working processes are affected and up for re-evaluation in the light of this way to cooperate cross company borders.

Embracing Open Source brings a need for change and change needs to be managed. I´m sure we will see some interesting organizational theories and models dealing with these issues but unfortunately we cannot wait; we must start the change process now not to lose assets, employees or customers.

Looking forward to hearing your opinions and experience on this topic.

Ã…se Stiller

[So, what’s your open source strategy ? VisionMobile’s workshop on Mobile Open Source is an on-site crash course offering a 360° analysis of economics, licensing, governance models, communities, mobile Linux, standards and 10s of case studies and real-world insights.]

The perils of managing 3rd party software: do's and don'ts

[All consumer electronics, mobile and software companies have to in-source third party software – but the perils and complexities of managing that software are several, as the software moves through your organisation and out to the customer. Guest blogger Ã…se Stiller distills years of experience in software licensing in simple guidelines for managing 3rd party software]

Hydra.png
Sourcing 3rd party software to be integrated in consumer electronics like mobile handsets is a complex affair. There are multiple challenges and threats, in a way similar to the multi-headed Lernaean Hydra, the mythical beast that Hercules fought in Greek mythology. But finding a Hercules to manage your mobile software issues is easier said than done – so is managing the challenges of complying with license terms that you have signed with third parties, as the software itself navigates through your organization.

The particular challenge I would like to draw your attention to in this article is the risk for unauthorized distribution or reuse of the third software.

It is easy to see the need to assess a potential supplier, but it is equally important to turn around and take good look at your own company’s ability to safely manage the responsibility, End-To-End

Whether you are developing a 2D game or a complete application framework putting together software products is not always as “Lego-like” an activity as we like to draw in block diagrams to management. In many cases bringing in 3rd party source code is the only viable alternative, but you must be sure that everyone dealing with the code knows what they are doing.- and you can´t very well ask all engineers to study the contract. Pardon my French but it’s often hard to ask engineers to “RTFM” or to be precise “RTFC” (C for contract).

It´s is hard enough to get the right code, at the right price, in the right shape delivered at the right time but you must also get it with the right terms to fit well into your own development process, not to have to burden developers with unnecessary restrictions and contract details. Sourcing of software is and must be a team activity. Only a true Hercules can deal with all the Hydra-heads single handed.

Staying above the line of software commoditisation
Developing an application, game, application framework or any piece of software for mobile phones means adding unique and sexy features to a whole lot of commodity, and checking that nobody else gets there first. What was cutting edge technology two years ago is now all taken for granted – users don’t want to pay for Bluetooth or FM radio these days and 5 mega pixel cameras is slowly becoming the norm. The value line of software is increasing up the stack with each month going by.

For software companies, as new technology ceases to be a marketing differentiator and turns into standardized commodities, it becomes appropriate to share the costs for maintenance and further enhancements with competitors and partners in the same business. The easiest way to find this economy of scales is of course through sourcing software from Independent Software Vendors (ISVs) or by using software which comes under an open source license (e.g. Eclipse IDE and WebKit browser core).

Another good reason to source software is of course to get access to specific technology that you cannot, or cannot afford, to develop in-house. Some things are simply best done by experts, like preparing Japanese puffer fish and developing e.g. telephony modules for mobile phones.

In mobile phones as well as all other complex consumer electronics you will find a lot of common functionality developed and maintained by external ISVs. The type of components vary from highly visible functions like Web-browsers to completely anonymous drivers, and only very few suppliers will get their logo in a prominent place. A mobile phone would have to be the size of a car to allow for “NN-inside” stickers for all externally developed software components.

There may be many links in the chain between the original developer of a software component and end-user. A lot of the sourced components themselves come with software developed by others than the supplier, like e.g. open source parsers and specific security solutions, and the further away from the original owner of the IP the harder to keep track.
A good practice is to make sure that such components are declared well in advance before you sign an agreement to source software, specifically if there are inherited restrictions or obligations pushed on to you and your customers. Make sure that the sourced software doesn´t come with an undetected Hydra-head embedded in the license. If there is Open Source with obligations to disclose code to end-users this will affect you or your customer, or your customer’s customer.

The perilous journey of software through an organisation
Regardless of the reason for sourcing 3rd party software it is important to truly understand how the sourced component will be used in the internal development process, and how the component will be integrated with existing product. For example, there may be a need to distribute code to sub-contractors or pilot users, customers, additional development sites etc, during the development process . Your license must meet these needs and allow for that – or you must plan for an alternative way to work.

software-lifecycle-confusing.png

Deviations from standard development process may add to the overall cost for the sourced component, and must be taken into the cost/benefit analysis. Naturally you must not panic but maintain a healthy balance between the added cost to eliminate a risk and the weighted cost for an actual breach.

If the sourced component is self contained and easy to replace your worries are less, even with a un-permissive license. However with a less modular and more realistic dependency you need to be more cautious about handling the code.

A good way to reach an understanding of all your needs for re-distribution of a sourced component is by identifying the End-To-End journey for the software through your company. You will then be able to anticipate what distribution rights must be catered for in the contract, and to prepare for a change in the process if you cannot win these rights in the license.

Another benefit of such practice is that you will gain a better understanding of how the third party product is to be integrated with you product. You can describe the level of integration and understand how that will impact your negotiation, or choice of license for Open Source software.

The natural place for an end-to-end flowchart and for the description of the integration is in a Risk Analysis for the sourced component.
Such Risk analysis should also include the standard commercial risks, market risks, legal risks etc – but that is a different subject.

Plan for the software’s journey
There is no single solution to how to safely manage third party code through your development process; any solution must be case specific. Naturally it depends on the size of your organization and of how many will have access to the code, but it also depends on the level of integration with the rest of the product.

software-lifecycle-clear.png

Based on the End-To-End flowchart and the license for the software, you can provide a plan for the management of the third party code; you can identify an owner of the code in all stages of development, and if necessary specify a hand over process between development units, and eventually the hand over to your customers. You can define specific rules for the code and provide solutions before the issue becomes a problem.

As an extra bonus you may also find and be able to eliminate conflicts between licenses – e.g. an Open Source license forcing disclosure of code and another license prohibiting such disclosure. Another Hydra-head down.

Information is King
A development process is only as waterproof for the in-sourced 3rd party software as the team members who are involved in this process. By identifying the different units that will be involved with the third party component, you will be able to locate who needs to be informed about the rights and obligations that come with the component.
Knowledge about the restrictions for the component must be available for all those who actually access the code, all the time.

A good way to achieve this is to keep a simple database where you register the third party IP included in the product, and specify rules for how the code may be spread and used. Access to the information in the database must be granted to all those who come in contact with the code and therefore you may not want to add the contract as such to the database. Do not confuse this with a contracts database; that serves a different purpose.

Information in this database must be easy to find, easy to understand and interpret and it shall clearly explain what you must and must not do with the code. E.g. if you can only distribute to subcontractors or development sites that have been approved in the contract, these subcontractors and sites shall be listed in the database and if you can only distribute binaries to customers that must also be easy to detect for anyone who might need to release code to customers.

It is, of course, crucial that the information in the database is always correct and updated. Therefore someone must be identified as the owner for the information. The owner of the contract is my first choice since that is the person with the most to gain on this; the one who will be hit by the Hydra if something goes wrong or have a smooth and easy day at the office when all the questions are answered by the database.

Do’s and Don’t of software sourcing.
When you accept the responsibility and liability that comes with signing a software license for source code – Open Source or closed Source, you must not let price and liability totally overshadow the rights to use and distribute. Do your homework and get a good understanding of the intended use of the code, before agreeing the license terms. Analyze the risk and avoid problems further down the road by planning the management of the software End-To-End and publish the restrictions for the code where it is easy to find and to update.

Get the team to help define the contractual needs for the sourced software. My experience is that insufficient or unclear license rights too often blocks engineers from doing their job. If you can get the engineering teams to help you prepare the sourcing better by providing relevant input to how your company will use the sourced component, you stand a far better chance getting the contract right from start, and it will save you from panic changes to both contracts and project plans.

Educate all on a need to know basis. My experience also tells me that engineers in general don’t love contracts, or rules restricting their creativity, but they do need to know the “Dos and Don´ts” with the third party code they handle. Just putting rules in a database is probably not sufficient; a verbal run-through of the rules is a good support for the information in the database, and an excellent way to test if the database works for its intended audience. You will probably also learn if the rules set up for the third party IP is too restrictive or too complicated.

Talk to all stakeholders. Sourcing of software is teamwork involving every department in your company – save possibly for janitors. It takes a team to find and fight all the heads of the Hydra. In other words; to provide all the input for the risk analysis leading you to a good license agreement and a safe passage for the software through your development process, you need help from all the stakeholders. Open Source is no different from any other third party software in this respect.

– Ã…se Stiller

[Ã…se has lived through the pains of licensing software both from the selling and the buying side of the cooperation as part of UIQ and Teleca, and has survived to tell the tale and educate the rest of the industry.]