Reproduction permitted for personal use only. For reprints and reprint permission, contact

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


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, 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.

Richard Marcus is a shareholder in the firm of Godfrey & Kahn, S.C., in Milwaukee, where he practices information technology law. He can be reached at (414) 273-3500 or at

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.


Peter responded 9 years ago: #1

Its not

Roger responded 9 years ago: #2

This article wrongly implies that all OSS or free software will "infect" proprietary software if the oss code is mixed in. This is not true in the case of software licenced under a BSD style license. This article mainly focuses on GPL'd code which does place the burden of sharing any changes you make to the source code.

Also if you have OSS software users among your staff this does not mean they are going to be sneaking GPL'd code into your products. While they might object to you banning the use of OSS software on their systems they will not object if you do not want to infringe the OSS license by including it in proprietry software

Charlotte responded 9 years ago: #3

With a world-wide market place that is more and more demanding open standards and access to source code as a means to ensure continued viability, esp in government circles that have an obligation to protect the common welfare, shrinking from OS through fear or ignorance is short-sighted indeed.

At the same time, OS is complex and needs to be managed. Using it willy-nilly can create headaches and problems, just as using Sun or MS licensed products willy-nilly can cause headaches and problems. But by educating themselves to the issues, and then managing them proactively, companies can reap the multitude of benefits from the OS movement, as well as limit the potential negative consequences.

In this context, a little knowledge can create a lot of fear. OS is a complex area that should be well understood by all companies, whether they intend to use it or not. Indeed, you are correct that a company should have a well-thought-out OSS policy. (This is true whether software development is the main product or an in-house service for the company.) But OS policy should include an oversite committee of individuals who know what OS is and the implications of using code from various OS licenses in various projects. Fear arising from the so-called "viral" impact, for instance, is often just a boogeyman built from ignorance. As an example, copyleft provisions usually do not come into play on in-house only projects. For the GPL, copyleft is only invoked for projects distributed outside a company's walls (the interpretation of which is extremely broad). Also, there is the issue of whether the software is a "collective" or a "derivative" project. In the former case, incorporating GPL'd code will not invoke the copyleft provision, whereas it might in the latter case. Even in such instances, there may be ways to handle the concerns. And if not, there is plenty of code distributed under Apache and similar licenses that does not involve a copyleft provision. Further, companies that are deeply involved in GPL'd code may need to critically examine the business model under which they are operating. OS is a prime mover in the market today causing companies to move to a value-add service approach, rather than a strict proprietary licensing approach. It may be a painful shift, but companies that embrace and prepare for it will be better positioned than those that simply wear garlic around their necks to repel the GPL monster.

Rick Marcus responded 9 years ago: #4

Thank you to Roger and Charlotte for your comments, and to Peter for your correction.

To Roger, I agree that the "viral" aspect doesn't apply to licenses like the BSD license. If you reread the article, you will see that the point you refer to was limited to GPL licensed OSS.

To Charlotte, I agree with your philosophy, and almost all of what you said. My intent was precisely to encourage software companies to become aware of the need to address the use of OSS by their development teams and to adopt a policy that is well thought out and permits the use of OSS where it makes sense in their particular circumstance. I especially think it is a mistake for a number of reasons to simply forbid its use. That is one of the main points I tried to make, because I too am concerned about the knee-jerk "garlic around the neck" response, which I have experienced. I think it comes not from anything philosophical, but from the natural human reaction of denial when faced with the possibility that significant change is occurring.

I also agree with your comment about companies rethinking their business models. OSS is increasingly becoming monetized and used by the big players, and software companies that remain oblivious to it are, on an important level, falling behind. But I must add that, judging from what I see, there is still a lot of ignorance out there regarding OSS.

You also make an important point that companies should have a policy regarding the licensing of OSS for internal use. The government is not necessarily unenlightened on the subject. See, e.g., Financial Institution Letter dated October 21, 2004 issued by the Federal Financial Institutions Examinations Council. You can get it from the FDIC's web site.

Ryan Parker responded 8 years ago: #5

It is also important to recognize that the publishers don't need to rely on OTS or OSS software as their only solution. There are many free-lance portals available on the internet which enables the programmers to create special one of scripts for your webpage. The prices are competitive as most of the programmers are actually indians with very low time costs for their work. Its just another option to consider.


Jamarion responded 8 years ago: #6

Placed to bookmark!

buydrugs responded 6 years ago: #7

What makes an Online drug store so different? First is the price. Retail pharmacies have a
lot of overhead just like many other businesses. There is the building, utility bills, employees,
taxes, and many other miscellaneous things that they have to pay each month to stay in
business. Who pays these bills actually? You do of course! How much does that increase
the cost of the medication you need? 20%, 50%, or maybe as high as a 75% markup that
you have to pay.

Korak Mitra responded 6 years ago: #8

For commercial software developers, the important thing is develop a policy as to which open source licenses are acceptable to the organization and which licenses are not. The article focuses on GPL but there are many open source licenses available.

Click here for more information about
Open Source License Obligations

-Add Your Comment


Comment Policy: WTN News accepts comments that are on-topic and do not contain advertisements, profanity or personal attacks. Comments represent the views of the individuals who post them and do not necessarily represent the views of WTN Media or our partners, advertisers, or sources. Comments are moderated and are not immediately posted. Your email address will not be posted.

WTN Media cannot accept liability for the content of comments posted here or verify their accuracy. If you believe this comment section is being abused, contact

WTN InGroup
FusionCIO InGroup
SupraNet Communications

-More Stories

WTN Media Presents