28 Sep Open source software — Managing the legal risks
It’s a common practice for programmers to find readily available source code on the Internet that can be downloaded and incorporated into the software they are developing. Using open source software (OSS) in this manner can be very efficient. Unfortunately, there are many misconceptions about OSS, and the legal ramifications that can arise are not so simple.
It’s important to know that OSS is not “free” software in the usual sense of the word. OSS provides certain elements of freedom, most typically the freedom to use it in any application, to modify it and to redistribute it. But with those freedoms often come legal baggage that can produce unexpected results.
Inclusion of OSS in a software company’s products can affect more than simply the product that contains the code. It can ultimately impact major transactions. For example, the due diligence process for the sale of a company often includes an analysis of whether a company’s proprietary software products contain OSS code. Finding OSS code at a late stage in the game can not only cause many headaches, it can even scuttle the deal.
Software licenses
Software is subject to copyright protection, which is a bundle of specific legal rights that the owner of the copyright has, and that no one else may exercise without permission. When a copyright owner grants permission to someone else to exercise one or more of these rights, the legal term for that permission is a “license.”
A software license is a contract. It can impose affirmative obligations on the customer, as well as restrict what the customer may do with the software. When companies or programmers download and use OSS, they are accepting the license terms that come with it. Otherwise, under the copyright law, they would have no right to use the OSS code at all.
The eolution of OSS
Normally, software vendors consider their software products to be proprietary. They treat the source code as the crown jewels of their business. A new perspective emerged in the 1980s, when Richard Stallman founded the Free Software Foundation and published a manifesto that expressed his anti-copyright ideology (which he called “copyleft”). He began to develop the high-level elements of a Unix-compatible operating system that would be “open” for all users.
In the meantime, Linus Torvalds began creating an operating system kernel that ultimately was combined with Stallman’s work and became known as Linux. While Linux is the original and most famous example of OSS, there are many other OSS products available today including well-known programs such as Apache and Mozilla.
OSS lcenses
Stallman was also a pioneer in software licensing. To implement his copyleft ideology, Stallman developed his own unique license agreement: the general public license. This is the most widely used OSS license form today, but a number of other open source licenses are also in use. You can learn more about them at www.opensource.org. It is necessary to study each one carefully before using or agreeing to it, as they vary widely.
The key aspect of the general public license is that it does not permit a software developer to incorporate OSS code into a proprietary product. With this license, if OSS code is incorporated into a company’s software product, the company must provide the same “freedom” to anyone who receives a copy of the software that the OSS vendor gave the company under the general public license. In effect, the general public license causes the OSS code to “infect” the software into which it is incorporated and turns the otherwise proprietary software product into open source software. If it is distributed, the proprietary software must include the same license terms as the general public license, specifically including the requirement that its source code be made available to all users.
Enforcement
The Free Software Foundation established by Stallman is alive and well. It monitors violations of the general public license, and if it catches a software developer who has incorporated OSS code under the general public license in its own proprietary software product, the Free Software Foundation will take action. You can read about its compliance program on its web site, at www.fsf.com., in the “compliance lab” section.
There are many other factors, legal and otherwise, not covered here that should be considered when deciding whether to use OSS in software development.
A software developer should seriously consider establishing a company policy for the use of OSS by its development teams, tailored to its specific circumstances.
When properly used, OSS has many positive attributes and can be an effective tool. However, if a company’s programming staff includes adherents to Stallman’s ideology, they may object to a policy that outlaws the use of OSS, which can result in a decrease in morale, or even the development of a company culture that promotes the underground violation of company policy. The worst outcome is for company managers to think that their proprietary software products don’t have any OSS code, only to learn the truth during the due diligence phase of a major transaction.
The opinions expressed herein or statements made in the above column are solely those of the author, and do not necessarily reflect the views of Wisconsin Technology Network, LLC. (WTN). WTN, LLC accepts no legal liability or responsibility for any claims made or opinions expressed herein.