by Philip H. Albert, newsfactor.com
Decisions, decisions, decisions. Do I want cable or satellite TV? Should I dump the SUV for a hybrid? East or West Coast? Like most major decisions, making the move to open-source software -- or not -- can cause a lot of genuine hand-wringing.
Despite all the innuendo and bias regarding the pros and cons associated with such a decision, the legal analysis of using open-source software is the same as the legal analysis for using proprietary software. The devil is in the details; and those details provide risk and opportunities. The trick is to make sure you are set up to maximize the opportunities and minimize the risks.
It is well established that if you have access to code authored by another and you incorporate some or all of it into your own code, that incorporation is a "derivative work." The original author (or the owner of that author's copyrights) can prevent dissemination of your code unless you have a license to that original code.
That can really put a damper on sales, especially if the borrowed code propagates throughout many projects.
New Risks
The increasing use of open-source code in commercial settings introduces new risks related to practical matters rather than to licensing. In a typical, well-run business, there are business-development folks, purchasing officers, engineers, programmers, lawyers and contract negotiators.
Business development tells contracting what software it needs to "in-license" and how the company plans to use it. The contract negotiators then get a suitable license and coordinate with the purchasing officers. Only when all of those steps are completed does the vendor ship the code base to the technical team. As a result, there is no access to the in-licensed code until licenses consistent with the organization's business plans are in place.
With open-source software, the same process should happen, albeit with a gravitas appropriate for the significance of the code being brought in. Thus, if millions of dollars of investment are to be made in product development, marketing, packaging and promotion, the full process must be used even if the purchasing step can be skipped.
Another risk that is sometimes present with open source is that of provenance. You might have a license to a code base from one party, but if there are other claimants to the code, you also might need licenses from others. That means you must know where all of the code came from, a requirement that is not always more difficult to fulfill with open-source code than with proprietary software.
Even if there are other claimants to copyright in the code -- especially in cases where open-source code is licensed and used in closed-source projects -- those claimants might never know that their code is being incorporated into the closed source. With open-source licensing that requires that the source code be distributed in any future distributions, the code base will be more available to claimants and could raise the chances of claims being asserted.
None of these risks are specific to open source and they should not matter when a company is careful about licensing. If you licensed code properly from all interested parties, the manner of acquiring the code base and its availability for review should not lead to copyright claims against you.
Recognizing the Opportunities
So, if properly used, there is no real increased legal risk of using open-source software versus proprietary software. There are, however, many opportunities that are unique to open-source code. Some of these advantages -- such as the ability to leverage the development efforts of a large community of programmers that you don't have to pay -- are well known. Other benefits are less obvious unless you happen to be a lawyer.
Litigation is messy. Sophisticated users of legal services know this, so they generally try and avoid litigation even if their opponent is a disagreeable character. If a dispute can be settled with finality at a cost considerably less than litigation, there will be saber rattling, but a deal will happen. On the other hand, if one side wants something that will cause a shut-down of the other side's business operations, litigation is almost inevitable.
For example, when someone asserts a patent claim against Research In Motion -- the company that makes the BlackBerry PDA -- and asks the court to shut down the company, RIM is stuck. It has to litigate.
Designing Around the Problem
A dispute over the use of open-source code is less likely to get to litigation because it is a lot easier to design around the problem -- except for the SCO v. IBM situation, which is an anomaly all around. If a company finds that it might have used copyrightable material in a way that was not permitted by the license under which it used the material, it can design around the problem -- rather than litigate the issue -- by removing the offending code and creating replacement code from scratch.
Because the source code is available, it is more likely that the company will be able to understand the operation of the code and how to create a replacement. Duplicating the functionality of software is not covered by copyrights, although the line between permissible copying of functions and ideas and impermissible copying of expression is not always clear.
This ability to design around licenses has interesting second-order effects on the parties to a dispute. If an aggrieved copyright holder knows that a user of the code can easily strip it out and move on, the copyright holder is going to be more willing to make a deal that allows the copier to keep using the code under terms that might be acceptable to the copier.
Permission Granted
In the domain of intellectual property, the maxim "it is easier to obtain forgiveness than it is to obtain permission" doesn't apply. Being forgiven for unlicensed use of intellectual property is almost always more expensive than buying permission in the first place.
Given a choice, you should always negotiate for permission before using someone else's intellectual property. Nonetheless, there are situations in which it is not clear until well into a project that permission was needed in the first place. To minimize the impact of such developments, developers facing a choice among various flavors of open-source code should opt for the one most likely to grant forgiveness.
For example, if you are developing a new printer series and want to provide Linux drivers, there are likely many existing open-source projects to form a base for your offering. Suppose you have a choice of open-source code downloaded from a large printer manufacturer (your eventual competitor) or from a small software house. If it later turns out that you needed more permissions than were granted in the license, which company is going to be easier to deal with?
The large printer manufacturer might opt for litigation to wear you down until you quit the business, just as Polaroid did with Kodak in the instant-photography business. By contrast, the smaller developer might grant the necessary permissions in exchange for exposure and other noncash benefits.
Like most major decisions, the choice to use open-source software offers both great opportunities and serious risks. Done correctly, the risk is no greater than with any other in-licensing of copyrightable material. And the opportunities are greater.
Life is about choices. At some point, we need to decide if we are ready to grab the brass ring the next time it comes around.
Philip H. Albert is a patent attorney and partner with the San Francisco office of the intellectual property law firm Townsend and Townsend and Crew LLP.
Copyright 2005 NewsFactor Network, Inc.
NOTE: For more telecom/internet/networking/computer news from the daily media, check out our feature 'Telecom Digest Extra' each day at
For more information go to: