A primer on Open Source licensing, or: How to ride the penguin (without hitting the icebergs)

Presentation by Heather J. Meeker of Greenberg Traurig.

Two broad categories of licenses: Free and open licenses. Viral and non-viral licenses in lawyer speak.

Public domain (copyrights are relinquished) and “proprietary” code. Both open source and closed are proprietary code, so the term “proprietary” as opposed to open source code does not make sense.

BSD license. A very short license. “Redistribution and use in source and binary, with or without modification, are permitted provided that the following conditions are met”.

The disclaimer means “I am giving you this stuff to use, but you are responsible for your own use”.

Lesson no. 1. It is easy to get mixed up in trying to understand with does the text of the GPL really mean. In the open source community text is interpreted broadly or widely. It is important to know how is the text perceived in the industry as well of how a lawyers is interpreting it.

GNU GPL. This particular license gives lawyers a lot of headaches. A very interesting document. More a political statement that is very different from other licenses,

The GNU GPL is viral agreement. If you get GPL covered work and you make derivative code you have to relicense this code under the GPL.

Derivative work is a copyright term. The GPL seeks to defined what is derivative work and what is not derivative work. The problem is that the GPL has multiple definitions of same variables.

The open source community has many opinions about what the GPL says on derivative work, but the lawyers have to know about this.

You need to know the concerns and “feeling” how the Free Software Foundation because they will always be involved in the enforcement of the GPL. You have to comply with the “spirit” of the GPL.

Derivative work can be difficult to pin down. It is not obvoius that a piece of code written from scratch and dynamically linked to GPL code.

Copyleft is really a trade secret scheme not a copy right issue.

Take the example of OEM type software distribution agreement as oppose to the GPL. OEM means that the licensor finds a licensee that has a compatible product and that the licensee gets the right to license the licensor’s code to use with the compatible product.

Distribution in object code as opposed to distribution in source code.

The source code is a trade secret in the typically OEM agreement.

Use of open source does not require you to lay open source code. Provenance of the code: Where did the code that you use really coming from – SCO vs. IBM.

Creating an open source project. Did you develop the software? Have you the copyright to issue the software under a open source license? Who has contributed? Have the contributors assigned the rights to you? The enforcement of an open source license is easier, if you hold the full copyrights.

Are you willing to open the barn door irrevocably.

Using the open source code in your products. GPL compliance. What are the issue of embedding open source code in your products.

Compliance with open not free license are much easier.

Keeping track of inbound licenses. Need to keep track of the open source code that is included in the product. Important to trach changes in open source licenses.

Due diligence. Make an audit on what open source code is in the target’s products. Necessary to compare this to buyers’ need for warranties. Make sure that you have documentation.

As an open source project initiator don’t forget your exit option. You may want to turn your hobby into a business. You may want to contribute code to a business.

Contributors to open source development. Make sure that you are allowed in the employment contract to participate as matter of using time. Make sure that you don’t contribute that you employer has the copyright for or that there are trade secret issues.

Contamination by code owned by others or by trade secret cannot only be handled by professional management of the open source project. Trade secret can be difficult to enforce because the open source project lays open the secret, and the more it is used the more it becomes less a secret. Not so different from (or inherently different) a proprietary code project but the due diligence process can be typically much more cumbersome because of the amount of external contributors to the project.