Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Software Books Media GNU is Not Unix Operating Systems Book Reviews BSD

A Compact Guide To F/OSS Licensing 61

Posted by timothy from the for-the-groaning-bookshelf dept.
barryhawkins writes "When sharing with others that I was reviewing an O'Reilly book through their User Group & Professional Association Program, the first question was always the same: 'What book are you reviewing?' After saying the title was Understanding Open Source & Free Software Licensing, responses ranged from 'What's that?' to 'Well, you won't have any trouble sleeping!' One might think that this list of people included relatives and coworkers who were not attuned to the open source community and its issues. On the contrary, the responses came from those within my circle of acquaintances, which includes software developers, system administrators, and even an intellectual property lawyer. Licensing is not exactly the sort of topic where people slide forward in their seats and ask to be told more. Such is the appeal of software licensing; however, the importance of understanding licensing, particularly within the context of open source development, cannot be overstated." Read on for Hawkins' review.
Understanding Open Source & Free Software Licensing
author Andrew M. St. Laurent
pages 208
publisher O'Reilly
rating 8
reviewer Barry Hawkins
ISBN 0596005814
summary A worthwhile introduction to open source licensing

Those familiar with the O'Reilly product offerings have no doubt seen or purchased one or more their Pocket Reference series. These are not comprehensive references, but rather convenient guides for a specific topic to provide the sort of information one is not likely to have committed to memory, particularly as the trend of having cross-disciplined technologists continues. This book could be considered the analog of such pocket guides for open source and free software licensing. Open source licenses and their legal interpretation, though, easily warrant a "pocket reference" that is a full-sized book of nearly 200 pages.

Frankly, reading through a software license and maintaining a reasonable level of comprehension is a rather tough job. The author manages to make the task far more bearable and fruitful at the same time; a difficult balance to strike. The pace of the annotation works well to break up the various licenses (twelve in total) into bite-sized chunks. Chapters 2 and 3, which address the Apache/BSD/MIT family of licenses and the GPL/LGPL/MPL family of licenses respectively, each end with a section titled "Application and Philosophy" that serves as a sort of reward for making it through the license and establishes a touchstone to summarize and provide meaningful context for what has been covered.

The annotations of the different licenses are a great introduction, but the book should not be considered a complete reference for open source licensing issues. The book seems to affirm this at points where the author indicates that particular topics fall outside the book's scope, even to the point of recommending experienced legal counsel for certain issues. It also has a wonderful collection of footnotes and reference to other resources to allow the reader to flesh out topics of interest beyond the focus of this work.

One subtlety of the book that should not be missed is how the history of the open source movement is woven throughout the book to provide the context in which these licenses came into being and were modified to accommodate the vibrant, emerging world of open development models. The book's last two chapters bring that context to the foreground, fully developing the consequence of the licenses in daily development activity. It is far too easy to view these licenses and as mere legal documents that exist in and of themselves; the author reminds us that these licenses are the manifestations of a spirit of selfless contribution and work toward social good made possible by the considerable sacrifice of quite gifted individuals. For those passionate about the open source and free software movements, the section of chapter 7 titled "Models of Open Source and Free Software Development" is a poignant and stirring encapsulation of the first years of the GNU and Linux projects and the work that brought them into being. The cliché rings true; we do indeed "stand on the shoulders of giants."

The number of editorial errors involving misspelled and/or missing words seemed relatively high; this is a trend that seems to have developed in technical books in recent years, to a point that the technical community has come to accept it as some sort of side effect of the rapid pace with which books must be produced in order to keep pace with the rate of change. Given that this is an issue present in other works as well as this one, it should not particularly count as a mark against the work, but rather serve to underscore an issue publishers should consider improving.

Understanding Open Source & Free Software Licensing strikes a balance between completeness of subject matter coverage and manageability of size. Given the amount of attention the average open source user or developer has given to licensing, reading this book would be a considerable improvement. This book is recommended for a couple of audiences. First, it serves as a great foundation for developers either active in or contemplating participation in open source development. Searching most any open source mailing list for the term "license" can usually turn up some of its hottest flame wars. If most developers had this introductory level of understanding about the main open source licenses, hundreds of message threads arguing about licensing could be avoided.

A second audience for this book is the project manager and/or CTO in most corporate IT shops. Most corporate projects are making use of numerous open source libraries and frameworks. This is particularly true with J2EE, but also with .Net as a number of .Net counterparts to popular J2EE resources arise, e.g. NAnt, NUnit, etc. This book can dispel unnecessary apprehension regarding the use of these libraries that often arises from fear, uncertainty, and doubt (FUD) propagated in much of the mainstream technology media. It can also equip managers to make informed decisions about team members' potential contributions to open source projects and the potential legal implications.

You can purchase Understanding Open Source & Free Software Licensing from bn.com. (You might also be interested in Peter Wayner's review of Lawrence Rosen's book on the same topic, Open Source Licensing .) Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

A Compact Guide To F/OSS Licensing More

A Compact Guide To F/OSS Licensing

Comments Filter:

  • Perfectly reasonable reactions (Score:5, Interesting)

    by eln ( 21727 ) on Monday January 31, 2005 @05:50PM (#11534000)
    Most software programmers don't really care to delve too far into the intricacies of various software licenses. Basically, for most people, if they want the software to be free, they use the GPL, and if they want it to be closed, they either sell it to a company or hire a lawyer.

    As for the intellectual property lawyer, well, while he might find his line of work interesting, he is acutely aware that most people find intellectual property law the best cure for insomnia out there. Most intellectual property lawyers (and contract and tax lawyers, for that matter) I know tend to joke about how boring their line of work is.
    • Well I think it's exciting, but I don't claim that anyone normal would.
      • Well, I'm not sure I would call IP or being an IP lawyer "exciting," but its certainly interesting, and really not a bad job at all.

        I guess I equate "exciting" with stuff like motorcycle racing or something, not trying to traverse 103 rejections...

        As to whether I make any claims to normalcy or not, I'll leave that question open!
    • Hmm. PHP, Apache, Postgres, Webmin, Perl, Bind, DHCP, Zope and in a half hearted way sendmail are all BSD licensed.

      Thats almost all of the key software in a typical linux based web hosting environment as well as some of the most popular open sourced software.

      There are obviously more license choices than the GPL.

      Jason.
      • PHP and Apache both have their own licenses, although they are broadly similar to the BSDL. Sendmail was BSD licenced up until version 8.9, subsequent versions have a rather strange license which is not BSDL or GPL compatible, and has some rather strange terms. Not sure about the other projects.

        The most interesting licensing choice I've seen is SQLite, which is public domain - removing even the requirement to maintain attribution in source form that is present in the MIT license.

    • > if they want the software to be free, they use the GPL

      Only because of firebrand preaching from GPL fanatics. There are no other reasons. [slashdot.org]

  • Could someone please send a copy to Sun? (Score:5, Funny)

    by Anonymous Coward on Monday January 31, 2005 @05:51PM (#11534004)
    Thanks in advance.

  • Great book. Great book license. (Score:5, Informative)

    by UnderScan ( 470605 ) <jjp6893.netscape@net> on Monday January 31, 2005 @05:54PM (#11534048)
    The book is licensed as Creative Commons Attribution-NoDerivs and is available as PDF. [oreilly.com]

  • floss? (Score:4, Funny)

    by Anonymous Coward on Monday January 31, 2005 @06:00PM (#11534108)
    My dentist gave me a fairly informative guide on F/OSS as well. It seems that it can reduce the occurance of gingavitis by up to 60%! Can you believe it? I couldn't.
  • The number of editorial errors involving misspelled and/or missing words seemed relatively high; this is a trend that seems to have developed in technical books in recent years, to a point that the technical community has come to accept it as some sort of side effect of the rapid pace with which books must be produced in order to keep pace with the rate of change. Given that this is an issue present in other works as well as this one, it should not particularly count as a mark against the work, but rather s

  • Another good resource (Score:5, Informative)

    by macklin01 ( 760841 ) on Monday January 31, 2005 @06:05PM (#11534165) Homepage
    When I was trying to decide between GPL, LGPL, and others a few weeks ago, I found the following helpful:

    http://www.croftsoft.com/library/tutorials/opensou rce/ [croftsoft.com]

    It gave a nice, concise grid of options with some further explanation. Too bad I didn't know of this book, though. It sounds like just what I needed! -- Paul
    • From the link:
      http://www.croftsoft.com/library/tutorials/openso u rce/ [croftsoft.com]

      AFL - Academic Free License (replaces Apache, BSD, and MIT)

      Mutual Termination for Patent Action. This License shall terminate automatically and You may no longer exercise any of the rights granted to You by this License if You file a lawsuit in any court alleging that any OSI Certified open source software that is licensed under any license containing this "Mutual Termination for Patent Action" clause infringes any patent claims that

    • That is interesting. I was very tempted towards the AFL, but ultimately steered towards the more-familiar LGPL. I forgot to post one more link that I also found useful:

      License Comparison [soberit.hut.fi]

      This one gives a bit more analysis per license (and groups them nicely), but doesn't have such a nice, concise grid as the other link. -- Paul

    • One of the issues I have been trying to understand about the GPL is exactly when you are or are not allowed to link to non-GPL-compliant libraries. IANAL, if you want a legal advice buy it from a licensed attourney, etc.

      If you read the general overviews, it would seem that such linking is always explicitly prohibited. But the license doesn't mention anything of the sort. I have not been able to find the word "link" used in this context at all in the license. Here are a few common options I have thought
      • IANAL, but...

        One of the issues I have been trying to understand about the GPL is exactly when you are or are not allowed to link to non-GPL-compliant libraries. IANAL, if you want a legal advice buy it from a licensed attourney, etc.

        See the penultimate paragraph of clause 3:

        However, as a special exception,

        the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system

        • The incident everyone points to regarding linking and the GPL was Apple's proprietary objective C extensions for the GCC. IANAL, etc....

          The FSF convinced apple that they were not allowed to keep this proprietary, and they released the source. Apple, BTW, was not distributing the GCC. My layman's analysis is as follows:

          there is a huge difference between Apple's approach (that of extending a *specific application* to add functionality) and the approach of NDIS-Wrapper (enabling a broad range of executabl
    • How to choose a free software license. [dina.kvl.dk]

      It takes a somewhat different approach to the issue, with the focus on what you want to accomplish, rather than the technicalities of each license.

  • Editorial Errors (Score:5, Insightful)

    by CyberKnet ( 184349 ) <slashdot&cyberknet,net> on Monday January 31, 2005 @06:10PM (#11534225) Homepage Journal
    The number of editorial errors involving misspelled and/or missing words seemed relatively high;

    While this is a printed book, and I understand the need for well-formed english, I am glad that the reviewer didn't subtract from the books overall score just because of this. Too many people these days spend too much time looking at the presentation of the subject matter instead of looking at the subject matter being presented.

    A second audience for this book is the project manager and/or CTO in most corporate IT shops

    Having read this book, I would have to disagree with this. Project Managers and CTOs would probably not get more than three pages before the book was discarded to the pile of "might have an underling review this."

    The best place (imnsho) for this book is in the hands of a well-versed and well-spoken advocate with friendly access to those CTOs and Project Managers. Other than that, I would agree with the review completely. An outstanding book. Great content, very informative. Two Thumbs up.

    • Re:Editorial Errors (Score:4, Insightful)

      by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Monday January 31, 2005 @06:23PM (#11534397) Homepage Journal
      I would subtract quite a bit. I can't use this book as a source to convince a manager if it's full of spelling errors that even they can catch. Even on the internet, filling your text with errors in spelling, grammar, and diction is the equivalent of giving a speech wearing a beanie and a mustard-stained tie; doing it in print is making yourself out to be a lazy ass. Would you trust a technical writer who can't use a spellchecker? Me neither.
    • Too many people these days spend too much time looking at the presentation of the subject matter instead of looking at the subject matter being presented.

      I would make the point though that if the presentation is not made adequately then it is difficult to convince other people of the validity of the message.

      That said, however, your second point is very well received. I cannot see a market for this book amongst PHBs and CTOs.
    • While this is a printed book, and I understand the need for well-formed english, I am glad that the reviewer didn't subtract from the books overall score just because of this.

      The goal of a good technical book is to clearly communicate. Many of the rules of good grammar, and the need for generally proper spelling, exist to maximize the potential for clear writing. If one wishes to be flowery or playful, fiction provides a fertile medium. This is especially true of extended subordinate clauses.

      The prob

    • Your second point is indeed a good one. I suppose I am coming from the perspective of "how a CTO should be"; I must agree that the average CTO would probably do just as you have said, which I think is a shame and disservice to his organization. Thanks for taking the time to read the review.
  • When sharing with others that I was reviewing an O'Reilly book....the first question was always the same: 'What book are you reviewing?'

    Noooo...REALLY!!?? You thought perhaps they'd ask for your shoe size or perhaps the time of the last bus back home?
  • Black Duck [blackducksoftware.com]

    Black Duck will have read this book and if you mayebe sorta think you might want to read the book, you'd do well to hit their website and see what they do. IF you write commercial or licensed software and you hope to get some real milage out of open source and not be SCO fodder, then a little time invested by somebody in your organization to know the ins and outs of mixing sources that come under various licenses is a prudent investment.

Slashdot Top Deals

Someday somebody has got to decide whether the typewriter is the machine, or the person who operates it.

Close