Open Source Licensing

Peter Wayner writes "For most open source software users, there are few things as easy to understand or follow as an open source license. If you share your code and follow a few basic steps, you're in the clear. This simplicity is a bit deceiving because the licenses are really quite complicated if step off the well-beaten path. And if you happen to be accused of something odd like SCO's claim that IBM donated SCO-owned code, well, the normally simple rules turns into a thicket of brambles with three-inch-long thorns. Lawrence Rosen, a hacker turned lawyer, has stepped forward with a deep and important exploration of the law. Curious programmers will enjoy it, but it's indispensable for businesses trying to honor the rules while still closing off some of their code." Open Source Licensing: Software Freedom and Intellectual Property Law author Lawrence Rosen pages 400 publisher Prentice Hall rating 9 reviewer Peter Wayner ISBN 0131487876 summary Major open source licenses are dissected and compared; invaluable anti-FUD for businesses and enlightening for all free software enthusiasts. The tricky part of following the GPL and even the BSD license comes when you want to keep some of the code private. This isn't as nefarious as it sounds. Many people write their own software, keep it secret, yet run it on top of Linux. Others write proprietary web applications and run them with a BSD-protected version of Apache running on top of a GPL-protected version of Linux. If you stay on the right side of the lines, you're still Richard Stallman's best friend. If you link the code together in the wrong way, though, you're toast.

This has been a particular headache for embedded systems manufacturers. If the engineers take advantage of the openness of Linux and make some tweaks to the part that is officially Linux, the company must to distribute their changes too. If they merely create software that works like a regular program, then there's no need to distribute anything. (Notice the ASP in the URL!) I know at least one very sharp businessman who explained to me how he carefully made sure the proprietary code in his system would only be dynamically linked to the GPL-protected code. If he left things statically linked, he would be legally bound to release all of his code and his investors wouldn't allow that.

"You had to work with developers. We had to create a build process that very carefully keeps things separate. If we weren't able to do that, we wouldn't have been acquired," he told me.

Rosen's book is a guide for anyone who's trying to walk that line. It dissects the major (GPL, BSD, Netscape, Apache, etc.) as a lawyer would: this kind of legal writing is always eye opening for me ,because the courts often make decisions differently from programmers. They value abstract issues like damages and pay attention to the often nebulous concept of who "owns" a piece of code. Thanks to the hard work of the lawyers at SCO, the distinctions will continue to be important to everyone experimenting with open source.

There are a surprisingly large number of distinctions, both big and small, between the different licenses. For most of us, the differences don't matter. But it's fascinating to watch a lawyer take them apart and compare and contrast them. The BSD license and the Apache license aren't the same, even though they're close cousins. Who would have known?

This book is a wonderful start on the topic. But by the end, it's clear that it's only just the beginning. There are deep philosophical questions awaiting the movement. The distinction between statically and dynamically linked code was easier to define in the past, long before modern languages like Java and the emergence of the Internet. Are web services specified by a hard-coded WSDL file, an example of dynamic or static linking? Can the DNS service change a static IP address into a dynamic link? Enquiring minds want to know. Rosen's book is a great way to begin the exploration of these topics.

You can purchase Open Source Licensing: Software Freedom and Intellectual Property Law from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

The movement

[MikeMacK]

There are deep philosophical questions awaiting the movement.

I do try and ponder the deep stuff when I sit on the porcelain alter.

Re: Linux changes.

[Alwin Henseler]

...meaning, for GPL-style licences (..)

If it's "GPL-style", it's not the GPL, and exact license terms may be different.

..that if they get a request for the source from those who they distribute to...they have to fork the changes over to that group or person. If not, they don't have to; not just anyone can demand the source -- the recipients have to.

In case of the GPL: I learned just today, that what you wrote, isn't true. Section 2b of the GPL states: "You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License". So basically, if you distribute the program (to buyers of a device with the binary inside) you have to make the source available (to anyone who asks). I'm not sure if "all third parties" means: "anybody" or "any user of the program", but it's clearly not limited to "buyers of that device". Ofcourse, this only applies if you are distributing the program. As long as it's just sitting on your desk, nobody can demand anything from you.

Theoretically, if the same device is leased they would not have to distribute the source also...though I'd like to hear a counter argument.

In my book, "distribution" means: passing copies around. In that context, what's the difference between selling or leasing a device?

Did you take your Free Software licensing quiz today?