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

Re:Funny...

[techno-vampire]

When lawyers read that, they'll run right out to buy the book because they'll reason that as lawyers, they do need to read it. Good marketing, and the landsharks can afford it.

Re:The movement

[hunterx11]

Brak's mother said that the world would be a better place if we'd all just spend a little more time on the toilet.

I'm confused

[eidechse]

...businesses trying to honor the rules...

These words don't make any sense together.

Re:Funny...

[Mithrandir]

The GNU Readline library is also under the GPL. At least somewhat technically, so is glibc that comes with GCC. However, there is a special exception that has been added to GCC that allows you to use (make calls to) glibc as part of a non-GPL app.

Watch the "L" in "LGPL"

[fizbin]

If you modify or statically use this code that someone else wrote, and distribute it in a compiled form, then you have to distribute the changes that you made and the code that statically uses it in source form under the GPL. If you don't like those terms, then you don't have license to redistribute it in compiled form. The person who originally wrote it only gives you license to use it in this manner.

An interesting license provision - but that's not a translation of the GPL. Specifically, the idea that you can escape the "you must relicense this as GPL" clause merely by dynamic linking is simply not true if you're talking about the GPL. If you're talking about the LGPL, then yes. (though watch the "don't forbid reverse-engineering" clause) Dynamic linking still gets you covered by the GPL - see the long discussion of why CLISP is GPL in the CLISP distribution.

This makes me wonder strongly about the situation discussed in the review - dynamic linking vs. static linking wouldn't affect source disclosure requirements in any way; even if you statically link to an LGPL library, the only requirement then is that you provide the .o files to a user who wants to relink the thing.

If after reading this book, the reviewer came away with an impression of the implications of the GPL and LGPL that are radically at odds with what Richard Stallman has said after consulting with the FSF's lawyers, then I wonder about the book too.