NEW ORLEANS -- Getting a grip on all the legalities associated with open source and proprietary software licensing...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
is a daunting task. To gain that understanding, says Mark Webbink, general counsel for Red Hat, one first needs to understand the true legal implications of words like patent, copyright, proprietary and open. After that, students of software law can get into more advanced subjects, such as an examination of what happens when developers mingle applications that were created under different licenses.
Webbink led a session at last week's Red Hat Summit in an effort to help Linux users and developers better understand the legalities of the software business. Here, Webbink answers several of the questions that attendees posed during that session:
Can you describe the spectrum of legal protections offered to software makers?
Mark Webbink: At one end, there is code that is totally protected by trade secrets. At the other end, you've got the public domain.
What does the public domain mean exactly?
Webbink: The public domain means that the author of the work has disclaimed the copyright. He has said, 'I do not want the copyright for this work. I disclaim it.' It is out there for the public to use in any manner that the public wants to use it. By the way, putting a piece of software in the public domain is not an easy thing to do. It's not as simple as, 'Go use this anyway you want.'
Where do proprietary licenses come in?
Webbink: Proprietary licenses apply where code is being shared with somebody else. But a typical proprietary license is not going to allow copying of the code beyond what you're allowed to do under Section 117 of the Copyright Act, which is a section of the Act that says you can make one backup copy of the code. [A proprietary license] is not going to allow you to make derivative works. It is not going to allow you (typically under an end user license) to redistribute that work to somebody else. Although, you can in fact sell your license to that work to somebody else, as long as you give up your rights to that code.
What is a non-protective open source license?
Webbink: The classic example of this is the Berkeley Software Distribution License. Other examples would be the MIT license and similar licenses. These licenses are only distinguished from things in the public domain largely by the fact that the copyright holder has not disclaimed their copyright. And, consequently, they can do anything to it they want to. But they have granted all rights, without any restriction, to copy, modify and redistribute the code.
What is a protective open source license?
Webbink: In the middle [of the spectrum] is the protective open source license, such as the GNU General Public License (GPL). Like a non-protective open source license, it does allow you to copy and make a derivative works, and it allows you to redistribute. But it adds a condition to that redistribution. It says that if you're going to redistribute this work, whether in the original form or the modified form, you have to do so under that original license. Consequently, once free, always free. Non-protective open source licenses can be inserted into proprietary applications. GPL code cannot.
Is there any way to take code issued under the General Public License and apply it to your own proprietary software?
Webbink: If you take a piece of GPL code, and embed it in a proprietary application, and distribute that as a single application, then the entire application has to be provided under the GPL. On the other hand, if you take the GPL code, and you ship with that an application that is proprietary, that independent application does not have to be open. In fact, there are a lot of proprietary applications that run on Linux including Oracle, WebSphere and others.
Does this process of bundling open and proprietary applications lead to problems?
Webbink: It's especially difficult when you're dealing with embedded systems, where the vendor is trying to reduce the footprint and tightly integrates [proprietary] applications and the underlying operating system. In some instances, their applications may become subject to the GPL. And it's that association, the fact that something that has been integrated with the GPL, that some folks talk about [the GPL as] being 'viral.'
At Red Hat, we do ship some proprietary applications because we think they'll be useful to our end users. For example, we ship a proprietary Java Virtual Machine. But we put those things on separate discs so there is no question that they are independent programs. It's not that we couldn't put them on the same disc. It's just that we choose to draw fairly distinct physical boundaries around what we do in that regard.