Slashdot Mirror


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.

5 of 193 comments (clear)

  1. Knowing your limits by JohnnyNoSPAM · · Score: 5, Interesting

    Thank you for discussing this book. I will be sure to check it out.

    I think that in the not-too-distant future, this kind of legal knowledge will be a bit of a prerequisite. This is especially true as awareness of the value of open source continues to spread, and more and more companies and people turn to open source as a cost effective tool. Check out "No More Stock" at this page: http://www.businessweek.com/technology/content/sep 2004/tc20040922_8372_tc024.htm With that, we can expect to see more and more proprietary software vendors who are feeling the heat of open source competition to stretch the very limits of any contract or license agreement.

    Knowing the legal limits *as a court would interpret them* will be crucial for open source developers world wide.

  2. Re:How Many Times... by Surazal · · Score: 5, Interesting

    Just because something's properly GPL'd doesn't mean it's sue-proof, and there's a lot more to litigation than just the substantive law at issue.

    Well, it will help protect you by helping you become more sue-proof for licensing reasons than you would be by not reading the book. Of course it may not be as effective in a theoretical loss-of-life situation (in a country where someone can successfully sue for spilling hot coffee on their own lap, anything can happen). But in those types of situations, your choice of license is moot; the actual product is being held responsible for /*insert bad thing happening here*/, not the terms you released it under.

    You're right, though, nothing is a substitute for a good lawyer for some things.

    --
    --- Journals are boring; Go to my web page instead
  3. Another view on OS/GPL by Anonymous Coward · · Score: 4, Interesting

    Seems that OS may have other ramifications!
    From http://www.builderau.com.au/program/work/0,3902465 0,39131082,00.htm
    "solicitor, Nick Abrahams today revealed he was in pre-court negotiations to defend a legal case in which a large IT company was attempting to use provisions of the open source General Public License to force his client to reveal its proprietary code."

    I've submitted this as news (twice) yet it doesn't appear to be getting posted.......

  4. Re:Funny... by wasabii · · Score: 4, Interesting

    You need the book, because you are wrong. You have stumbled onto a point of major issue with teh GPL, which simply isn't 100% answered yet.

    When a peice of code, lets say, libfoo, is under the GPL, that means the structures in memory that libfoo defines, the method signatures, etc, are all peices of libfoo. They are copyrighted works released under the GPL.

    Now, lets say you want to write a peice of software to USE libfoo. To write this software, it's required to import some of libfoo's headers. These headers are copyrighted. When you compile your software, even though it links dynamically at runtime, it still retains this copyrighted memory structure information in the final binary image. You're compiled program has just included GPLd code. In fact, if you simply call methods, you're program could arguably be including copyrighted material.

    This is a major peice of contention... and I would say this IS how the GPL works, even though most people ignore it. WHy would I say that? Because of the LGPL, which was designed SPECIFICALLY to address the issue by putting in writing that it was OKAY to use LGPL libraries in a non-LGPLed program. Because the FSF found the need to create the LGPL, one can only assume that that GPL really does work th is way. Somebody suing you for using their GPL'd code would most likely bring this up in court, and they'd likely win.

    According to a strict interpretation of hte GPL, this is the way it is. It disturbs me greatly that some people have never read the thing, or are willing to ASSUME anything in the face of copyright. That's bogus to me. Don't rewrite the GPL to suit how you wish it was, interpret it as it is and go from there, otherwise you are opening yourself up a can of worms.

  5. been there yesterday: GPL author violated BSD (c) by hubertf · · Score: 4, Interesting
    Even if no money is involved, dealing with legal stuff is annoying. I had the experience a few days ago when someone took code from me that's under a BSD license, removed my name & license and put everything under GPL.

    Read the full story at my web page, http://www.feyrer.de/g4u/g4l.html.


    - Hubert