IFOSS L. Rev. Vol 2 Issue 1: Licence Profile: BSD by Andrew Sinclair

The BSD software licence is one of the most popular open source software licences, with simple permissive licence terms. This article is a short overview of the licence, examining its elements and their interpretation.

This item is part of the Articles section of IFOSS L. Rev. For more information, please consult the relevant section policies statement. This article has been independently peer-reviewed.

The BSD licence is the flagship representation of the "non-copyleft" open source licensing model. Its terms are unquestionably simple when compared to many other open source licences, yet the BSD licence carries great significance. When measuring popularity by frequency of use, the BSD licence consistently ranks at the top of the list after the GPL family of licences.1 This makes the BSD licence the most common non-copyleft licence, and in holding this status, the BSD licence is often the first example cited when comparing copyleft and non-copyleft licensing models.

When viewed as the primary representation of a major open source licensing model, the BSD licence's language is marvellously simple, and perhaps this is because the simplicity of the model demands a simple embodiment. There are similar licences, like the MIT licence and the historical permission notice, which also use very few words to represent the non-copyleft model. The BSD licence's few words, however, require some interpretation to fully cover the rights and obligations that open source communities have come to associate with it.

The BSD licence has a three-part structure. It sets forth a basic copyright notice, has a short licence grant, and has a warranty disclaimer and limitation of liability clause.

The BSD licence's copyright notice follows the style of a traditional proprietary copyright notice. It sets out the author's name and the date of the work consistent with the US Copyright Act.2 When the United States joined the Berne Convention in 1988, it revised its Copyright Act to eliminate the notice requirement.3 However, copyright notices are still extremely common, and they serve still serve the practical purpose of identifying the copyright owner to recipients of the work. The copyright notice in the BSD licence also makes sense given the timing of the BSD licence's first use. The original version of the BSD licence was first used in 1980 in connection with the Berkeley Software Distribution. As this was well before the new US law removing the notice requirement became effective, the notice would have been required for enforceability under US law.4

The second part of the BSD licence's copyright notice is the familiar "all rights reserved" notice, which seems to contrast the broad set of rights granted by the rest of the licence. Surely, not all rights are reserved, as the author is granting many rights in the same instrument as the notice (the BSD licence), but it is an interesting relic of the more reserved closed source licensing model where such a notice would likely be followed by much more narrow licence grant. None of the other common open sources licences include or suggest including "all rights reserved" in the copyright notice or anywhere in the licence.5

The heart of the BSD licence is its one-sentence licence grant and short list of conditions: "Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met . . ."6 The only right explicitly granted is the right to distribute, but there is a strong suggestion that a right to modify or prepare derivative works is also present. The "source and binary forms" language suggests that the source code version may be available, which would have little practical use if the recipient does not also have a right to modify it. Furthermore, "with or without modification", while not explicitly granting the licensee a right to modify, has no other plausible interpretation; the right to distribute "with or without modification" presumes that someone has the right to modify. If this referred to the licensor's right to modify, there would be no need to express this right; whether software version is modified by the licensor prior to licensing would have no effect on granting a licensee a right to distribute.

It is clear that the licensee has a right to distribute the work, and it would be hard to argue that the licensee does not also have a right to modify. However, one of the most significant rights under copyright law is entirely missing from this grant: the right to reproduce the work. Some right of reproduction could be read into the right to modify, as the type of work the licence covers is computer code, and it is impractical to suggest that the licensee may modify and distribute a computer software work but may not reproduce that software. The expressly granted right to use could bolster this position; with respect to software, use often requires some form of reproduction. A second and perhaps stronger solution to the omission of the right to reproduce the work is to look beyond the strict legal interpretation and consider the intent of the licensor. The fact that the licence includes the superfluous "all rights reserved" is not helpful in construing the licence to grant a right that is not explicitly granted, but the open source community has treated the BSD licence as permitting a right to copy.7 With decades of use assuming this right, this convention cannot be ignored.

“* Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

The first condition is relatively simple, and it is stated very simply in the licence. It is also a condition that is extremely easy to satisfy, as failure to retain a notice would require the act of removal. However, the second condition may be one that is frequently overlooked. When a licensee compiles the source code into binary form and distributes that binary, the second condition would require the licensee to add a copy of the licence to the binary's accompanying documentation or other other materials. This isn't entirely consistent with the common view that the BSD licence only requires "credit" or "attribution". Attribution is required in the form of the copyright notice portion of the licence, but merely attributing the work to a particular author would not satisfy the condition. It should still be relatively easy to comply with this condition. In the context of distributing BSD licensed software as open source, the inclusion of the source code version would likely satisfy the requirement. If the licensee complied with the first condition by not removing any notices or licence information, and if adequate notices were already present in such source code version, the source code version would constitute "other materials" distributed with the binary version which includes notices adequate to satisfy the second condition. Complying with the second clause in a proprietary context requires more care. The licensee who redistributes the binary must add a copy of the licence to documentation or other materials.

The third condition is a prohibition on using certain names to promote a product, but this does not seem to alter the rights of the licensee. In most jurisdictions, trademark law already prohibits the kind of unlicensed endorsement addressed by this condition. However, the condition is not meaningless; while it may be that a contributor or copyright owner would have a trademark infringement claim against a licensee who uses its name without permission, the condition ties such unauthorized use to the copyright licence. The licensor therefore has an additional remedy (a copyright claim) available should a licensee promote a product using the licensor's name without permission. The third condition may also serve the practical purpose of reminding licensees that they should not use the licensor's name for promotional purposes. Many readers of the BSD licence will not be lawyers versed in local trademark law, so the third condition's setting out the promotional restriction in plain English is helpful to licensees who may not otherwise be aware of this prohibition.

The final part of the BSD licence is its one-sentence disclaimer of warranties and one-sentence exclusion of liability. As software licensed under the BSD licence is done so without charge or royalty, it is appropriate that licensees do not receive commercial guarantees. Furthermore, the potentially ongoing distribution stream enabled by licences like the BSD licence would make warranties and liability terms difficult to implement. The BSD licence takes the distribution and re-licensing model into account in both the warranty disclaimer and the liability exclusion by applying these to all upstream copyright holders and contributors.

The original version of the BSD licence included an additional condition: “All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the <organization>.”9 In addition to the problem of the potential inconsistency between this condition and the condition prohibiting promotion or endorsement, Richard Stallman cited this condition as practically problematic.10 If developers started adding code to the work, the list of required advertising notices would continue to grow until it became unmanageable.11 The Free Software Foundation has also cited the advertising condition as triggering a conflict with the GPL.12 In 1999, the University of California removed this condition of the BSD licence, and the version with the advertising restriction is not an approved licence by the Open Source Initiative.13

While the BSD licence and similar highly permissive licences are generally thought to be compatible with copyleft licences like the GPL, the legal effect of combining code under the BSD licence with code under a copyleft licence is not always clear.14 The BSD licence does not include an express right to sublicense, so if the BSD licence is compatible because the code it governs is “re-licensed” under the copyleft licence, the licensee must rely on the licensor's intent and community interpretation to read this sublicense right into the BSD licence's terms. However, the typical open source model is a direct grant from the copyright owner to the licensee, not a sublicence.15 If, instead of a sublicence, the BSD licensed code is combined with the copyleft code but continues to be licensed under the BSD licence, this would seem to conflict with the terms of the copyleft licence, which will typically require that derivative works are licensed under the copyleft licence. Resolving this apparent conflict in the legal context would require analysis of the applicable copyleft licence and application of the particular facts and circumstances. However, it is once again helpful to consider the community interpretation of the BSD licence and copyleft licences, which generally considers the BSD licence to be compatible with copyleft licences.16

The BSD licence is significant due to its popularity and the simple non-copyleft licensing model it represents. In a few ways, the BSD licence lacks clarity as a legal document, as it does not include some express licence grants that are otherwise reserved under copyright law. However, the BSD licence's long history of use and shared community interpretation help to resolve the apparent conflict between a strict textual interpretation and the licence's practical use. The BSD licence's language also includes some clues as to rights that are assumed, which further support the view that it is indeed a very permissive licence. BSD licence compliance is relatively straightforward, but a licensee who has a an over-simplistic understanding of the BSD licence may find it too easy to overlook the requirement to add notices to documents when distributing BSD licensed software in binary form. Overall, the BSD licence is a simple licence, but not quite as simple as a one-sentence “do whatever you want, but include the licence terms” summary would reveal.

Licence and Attribution

This paper was published in the International Free and Open Source Software Law Review, Volume 2, Issue 2 (June 2010). It originally appeared online at http://www.ifosslr.org.

This article should be cited as follows:

Sinclair, Andrew (2010) 'Licence Profile: BSD', IFOSS L. Rev., 2(1), pp 1 – 6
DOI: 10.5033/ifosslr.v2i1.28

This article is licensed under a Creative Commons UK (England and Wales) 2.0 licence, no derivative works, attribution, CC-BY-ND.

As a special exception, the author expressly permits faithful translations of the entire document into any language, provided that the resulting translation (which may include an attribution to the translator) is shared alike. This paragraph is part of the paper, and must be included when copying or translating the paper.

1See http://sourceforge.net/softwaremap/? (showing the number projects hosted on SourceForge.net using various licences, with BSD in the third position after GPL and LGPL); See http://www.blackducksoftware.com/oss/licenses#top20 (showing the frequency of licences appearing in Black Duck Software, Inc.'s database of open source software, with BSD in the fourth position after GPL, LGPL, and the Perl Artistic licence)

3Berne Convention Implementation Act of 1988, Pub. L. No. 100-568, 102 Stat. 2853, enacted October 31, 1988

4Deek, Fadi P. & McHugh, James A. 2008 Open Source: Technology and Policy. New York: Cambridge University Press, p. 337

7Meeker, Heather J. 2008 The Open Source Alternative: Understanding Risks and Leveraging Opportunities. Hoboken(NJ): John Wiley & Sons, Inc. p. 28 (Noting that "these rights are universally understood to be granted under this license."), DiBona, Chris, Ockman, Sam & Stone, Mark eds. 1999 Open sources: Voices from the Open Source Revolution. Sebastopol(CA): O'Reilly & Associates, Inc. p. 164 (Brian Behlendorf writes of BSD-style licences: “[By] and large it can be summed up as, ' Here's the code, do what you like with it, we don't care, just give us credit if you try and sell it.'”)

11St. Laurent, Andrew M. 2004 Understanding Open Source & Free Software Licensing. Sebastopol(CA): O'Reilly Media, Inc. p16 (noting that the requirement to including references to numerous preceding works can become a burden)

15Meeker, Heather J. 2008 The Open Source Alternative: Understanding Risks and Leveraging Opportunities. Hoboken(NJ): John Wiley & Sons, Inc. p. 29, see http://www.gnu.org/licenses/gpl.html (GPLv3 says, “Sublicensing is not allowed; section 10 makes it unnecessary.”)