reused, but also how derivatives of the work may be licensed.[1] The GPL thus effectively forbids proprietary or commercial adaptations of GPL-licensed code. The LGPL falls somewhere between, but still effectively permits commercial reuse via linking to an LGPL-licensed library.[2] These three paradigms raise essential questions, such as whether or not attribution should be required, whether derivative works should be required to be licensed under similar terms, and whether commercial reuse of the licensed content ought to be allowed. These questions recur in open-content licensing even outside the software context.[3] The issue is thus not whether to constrain users’ behavior, for all licenses constrain (even if only by maintaining extrinsic constraints imposed by copyright law),[4] but rather which constraints a licensor finds best to effectuate her intent.
The same group of licenses might also be evaluated not for how they affect individual users, but for how they affect the commons. BSD-style licenses are essentially agnostic on the question of growing the commons. Developers may add software to the pool, but anyone else is free to incorporate the licensed content into a proprietary product and need not make their own contributions available for others to reuse.[5] In contrast, the GPL’s reciprocity provision demands that what is borrowed from the commons be returned to the commons: modified versions of GPL-licensed software may be distributed only under the GPL (with source code) for universal copying and
- ↑ See supra notes 58–65 and accompanying text.
- ↑ See Josh Lerner & Jean Tirole, The Scope of Open Source Licensing, 21 J.L. Econ. & Org. 20, 22 (2005) (labeling BSD-style licenses “unrestrictive,” the LGPL “restrictive,” and the GPL “highly restrictive”). Bruce Perens, a software developer and influential advocate in the FOSS community, labels these three licensing paradigms “gift” (BSD), “sharing with rules” (GPL), and “in-between” (LPGL). See Perens, supra note 31. Perens actually cites the Apache License, version 2.0, not the BSD license, as the paradigmatic “gift license.” The Apache License differs from BSD-style licenses in a number of respects that are unimportant for present purposes.
- ↑ See infra Part II.C.
- ↑ See, e.g., Adam Kubelka & Matthew Fawcett, No Free Beer—Practice Tips for Open Source Licensing, 22 Santa Clara Computer & High Tech. L.J. 797, 813 (2006) (“[r]egardless of which type of license is applicable, all licenses contain downstream obligations on distributors.”); Michael J. Madison, Reconstructing the Software License, 35 Loy. U. Chi. L.J. 275, 287 (2003) (characterizing software license as “a soup-to-nuts statement of the scope of legitimate behavior by a user or consumer of that software”); Van Houweling, supra note 31, at 935–39 (noting that software licenses often aim to constrain behaviors that copyright law leaves unregulated).
- ↑ As one of the leading minds behind the GPLv3, supra note 53, explained:
The BSD license says: “Here is a commons. It is not defended by copyright against appropriation. Everything in the commons may be taken and put into proprietary, non-commons production as easily as it may be incorporated in commons production. We encourage people to put material into commons, and we are indifferent as to whether the appropriative use made of commons resources is proprietary, or commons-reinforcing.”
Eben Moglen, Freeing the Mind: Free Software and the Death of Proprietary Culture, 56 Me. L. Rev. 1, 6 (2004).
