|
+ Home | +Libraries | +People | +FAQ | +More | +
License text
+Introduction
+History
+Rationale
+FAQ
+Acknowledgements
The Boost Software License specifies the terms and +conditions of use for the Boost libraries covered by the license.
+ +Some Boost libraries have their own licenses. The hope is that eventually all +Boost libraries will be covered by the Boost Software License.
+ +As Boost grew, it became unmanageable for each Boost file to have +its own license. Users complained that each license needed to be reviewed, and that +reviews were difficult or impossible if Boost libraries contained many different licenses. +Boost moderators and maintainers spent excessive time dealing with license +issues. Boost developers often copied existing licenses without actually knowing +if the license wording met legal needs.
+To clarify these licensing issues, the Boost moderators asked for help from +the Berkman Center for Internet & Society +at Harvard Law School, Cambridge, Massachusetts, USA. It was requested that a +single Boost license be developed that met the traditional requirements that Boost licenses, particularly:
+Additionally, other common open source licenses were studied to see what +additional issues were being treated, and additions representing good legal +practice were also requested. The result is the Boost +Software License.
+ +The following rationale was provided by Devin Smith, the +lawyer who wrote the Boost Software License. It has been edited slightly for +brevity. Editorial additions are shown in square brackets.
+ +If one of Boost's goals is to ease use and adoption of the various +libraries made available by Boost, it does make sense to try to +standardize the licenses under which the libraries are made available to +users. (I make some recommendations about a possible short-form license +below.)
+[Standardizing the license will not] necessarily address the issue of satisfying +corporate licensees. Each corporation will have its own concerns, based +on their own experiences with software licensing and distribution and, +if they're careful, will want to carefully review each license, even if +they've been told that they're all standard. I would expect that, +unless we're remarkably brilliant (or lucky) in drafting the standard +Boost license, the standard license won't satisfy the legal departments +of all corporations. I imagine that some will, for instance, absolutely +insist that licensors provide a warranty of title and provide +indemnification for third-party intellectual property infringement +claims. Others may want functional warranties. (If I were advising the +corporations, I would point out that they're not paying anything for the +code and getting such warranties from individual programmers, who +probably do not have deep pockets, is not that valuable anyway, but +other lawyers may disagree.)
+But this can be addressed, not by trying to craft the perfect standard +license, but by informing the corporations that they can, if they don't like the +standard license, approach the authors to negotiate a different, perhaps even +paid, license.
+One other benefit of adopting a standard license is to help ensure that +the license accomplishes, from a legal perspective, what the authors +intend. For instance, many of the [original] licenses for the libraries available +on boost.org do not disclaim the warranty of title, meaning that the +authors could, arguably, be sued by a user if the code infringes the +rights of a third party and the user is sued by that third party. I +think the authors probably want to disclaim this kind of liability.
+Without in anyway detracting from the draft license that's been +circulated [to Boost moderators], I'd like to propose an alternative "short-form" license that +Boost could have the library authors adopt. David [Abrahams] has expressed a +desire to keep things as simple as possible, and to try to move away +from past practice as little as possible, and this is my attempt at a +draft.
+This license, which is very similar to the BSD license and the MIT +license, should satisfy the Open Source Initiative's Open Source +Definition: (i) the license permits free redistribution, (ii) the +distributed code includes source code, (iii) the license permits the +creation of derivative works, (iv) the license does not discriminate +against persons or groups, (v) the license does not discriminate against +fields of endeavor, (vi) the rights apply to all to whom the program is +redistributed, (vii) the license is not specific to a product, and (viii) the +license is technologically neutral (i.e., it does not [require] an explicit gesture of +assent in order to establish a contract between licensor and licensee).
+This license grants all rights under the owner's copyrights (as well as an +implied patent license), disclaims all liability for use of the code (including +intellectual property infringement liability), and requires that all subsequent +copies of the code [except machine-executable object code], including partial copies and derivative works, include the +license.
+ +Why the phrase "machine-executable object code generated by a source +language processor"?
+ +To distinguish cases where we do not require reproduction of the copyrights +and license, such as object libraries, shared libraries, and final program +executables, from cases where reproduction is still required, such as +distribution of self-extracting archives of source code or precompiled header +files. More detailed wording was rejected as not being legally necessary, and +reducing readability.
+ +Why is the "disclaimer" paragraph of the license entirely in uppercase?
+ +Capitalization of these particular provisions is a US legal mandate for +consumer protection. (Diane Cabell)
+ +Does the copyright and license cover interfaces too?
+ +The conceptual interface to a library isn't covered. The particular +representation expressed in the header is covered, as is the documentation, +examples, test programs, and all the other material that goes with the library. +A different implementation is free to use the same logical interface, however. +Interface issues have been fought out in court several times; ask a lawyer for +details.
+ +Why doesn't the license prohibit the copyright holder from patenting the +covered software?
+ +No one who distributes their code under the terms of this license could turn +around and sue a user for patent infringement. (Devin Smith)
+ +Boost's lawyers were well aware of patent provisions in licenses like the GPL +and CPL, and would have included such provisions in the Boost license if they +were believed to be legally useful.
+ +Since license wording may change over time, why don't source files +identify the version number of the license which applies?
+ +A copy of the current license always accompanies distributions of libraries, +and that is legally sufficient. Note that Boost cannot retroactively change the +terms applicable to a licensee who has received code under the terms of an older +version of a license agreement.
+ +Dave Abrahams led the Boost effort to develop better licensing. The legal +team was led by +Diane Cabell, +Director, Clinical Programs, Berkman +Center for Internet & Society, Harvard Law School. + +Devin Smith, attorney, +Nixon Peabody LLP, wrote the Boost License. Eva Chen, Harvard Law School, +contributed analysis of Boost issues and drafts of various legal documents. +Boost members reviewed drafts of the license. Beman Dawes wrote this web page.
+© Copyright Beman Dawes 2003.
+See accompanying license for terms and conditions +of use.
+Revised +18 August, 2003
+ + + + \ No newline at end of file