This page has been proofread, but needs to be validated.
Harvard Journal on Legislation
[Vol. 47

Because they require crediting the owner but omit other limitations on the copying, modification, or redistribution of the licensed works, BSD-style licenses are often characterized (with tolerable, if imperfect, accuracy) as “attribution-only” licenses.[1] What the BSD-style licenses omit, moreover, is at least as important as what they require. BSD licenses are not reciprocal licenses and have no “copyleft” condition.[2] Nor do they require source code to be distributed with the software.[3] Because derivatives of BSD-licensed works need not be licensed under a BSD-style license (or any other recognized FOSS license) and need not include source code, BSD-derived code may be freely incorporated into proprietary software works distributed in binary-only form.[4]

3. Open-Source Licensing: Constraint and Liberation

The GPL, the LGPL, and BSD-style licenses serve as useful examples from the broader universe of FOSS licenses because of their very different presumptions and effects. They represent points along a continuum which can be viewed from either of two directions.

The licenses might first be characterized according to the constraining force they exert on downstream users of the licensed works. The BSD license is minimally constraining; beyond the obligations to recognize the original author’s copyright and to refrain from implying endorsement or pro- motion, the license places no limitations on a user’s copying, modification, or distribution of the work, including for profit.[5] At the opposite extreme, the GPL is maximally constraining, regulating not only how a work may be

    fourth condition, the so-called “advertising clause,” requiring the crediting of the University of California–Berkeley in advertising materials for any BSD-derived product. This clause was deleted from the standard-form BSD license in 1999, leaving the three conditions stated in the text. See id..

  1. See, e.g., Phillips, supra note 68, at 490; Greg R. Vetter, Commercial Free and Open Source Software: Knowledge Production, Hybrid Appropriability, and Patents, 77 Fordham L. Rev. 2087, 2096, 2097–98 (2009); cf. Zittrain, supra note 9, at 269 (“The BSD license materially differs from a wholly public domain release only in that it requires a particular kind of credit or attribution for the original author on whose work the new program is based.”). For a discussion of the reputational interests of authors of BSD-licensed software projects, see Catherine L. Fisk, Credit Where It’s Due: The Law and Norms of Attribution, 95 Geo. L.J . 49, 90–91 (2006). Labeling BSD-style licenses as “attribution-only” seems to misapprehend the significance of the license’s third clause, which requires nonattribution in situations where crediting the owner’s organization would carry an implication of endorsement. Cf. Jane C. Ginsburg, The Author’s Place in the Future of Copyright, 45 Willamette L. Rev. 381, 391 (2009) (noting reputational interests of FOSS authors in not being associated with later users’ “ill-conceived or badly-executed changes to the underlying program.”).
  2. BSD License, supra note 81; cf. supra notes 64–71 and accompanying text.
  3. See David S. Evans & Anne Layne-Farrar, Software Patents and Open Source: The Battle over Intellectual Property Rights, 9 Va. J.L. & Tech. 10, ¶ 22 (2004).
  4. See James Gibson, Once and Future Copyright, 81 Notre Dame L. Rev. 167, 203 (2005); Fabrizio Marrella & Christopher S. Yoo, Is Open Source Software the New Lex Mercatoria?, 47 Va. J . Int’l L. 807, 823 (2007); Phillips, supra note 68, at 490; Vetter, supra note 85, at 2097–98.
  5. See supra notes 82–85 and accompanying text.