Nothing in this paper is legal advice or a statement of the law. This paper is an exposition of an (untested) argument as to the effect of the BSD license.

Scott will be speaking at the Gaming Miniconf at LCA2007 in Australia on Tuesday at 11:15 if anyone wants to discuss the paper afterwards. The paper is also available in PDF format.

*************************

BSD – The Dark Horse of Open Source

Brendan Scott^*
Open Source Law
www.opensourcelaw.biz
inquiries@opensourcelaw.biz
January 2007

Abstract¹

We observe that there exists a broad misconception that the BSD permits the licensing of BSD code and modifications of BSD code under closed source licenses. In this paper we put forward an argument to the effect that the terms of the BSD require BSD code and modifications to BSD code to be licensed under the terms of the BSD license. We look at some possible consequences and observe that this licensing requirement could have serious impacts on the unwary.

Note/Disclaimer: This discussion is limited to likely effects under Australian law. Some of the arguments made are of a generic nature and might be profitably applied in other common law jurisdictions, such as the UK and the US – but, then again, they might not. Open source licenses have been subject to little judicial scrutiny to date. Nothing in this paper is legal advice or a statement of the law. This paper is an exposition of an (untested) argument as to the effect of the BSD license.

1. Discussion and Assumptions

1.1 It seems that the collective wisdom is that once you acquire BSD code, you can license it to others under any terms you like, including on the terms of a closed source license.² The received wisdom is that the BSD has minimal restrictions on what can be done with the code. In particular, there is the view that its terms do not need to apply to derivative works made from BSD code. Take the view of Microsoft, for example:³

"The BSD license places no substantive restrictions on software developers as to subsequent use in derivative programs and licensing of those programs. The BSD license allows programmers to use, modify and redistribute the source code and binary code of the original software program, with or without modification. Derivative works can be either open source or commercially licensed." [presumably, taken in context, "commercially licensed" means licensed under a license other than the BSD]

1.2 This nature of the BSD is something which can easily be taken on faith. We don't assert that this view is universal (as some of the references in the rider show), but it certainly does appear to be prevalent. We consider that the view evidenced by the references set out in the rider is, more likely than not, incorrect. In this paper we look at a number of scenarios and analyze some consequences of the application of the BSD to software code.

1.3 An assumption made by this paper is that licensees are granted their license by distributors, and not by the original licensor. The mechanics of license propagation is not one specifically addressed by most open source licenses. There seems to be an assumption that when a person gives a copy of (open source) software to a third party, the giver also grants a license over that software to that third party. This method of licensing is assumed in this paper. There is another interpretation of the license mechanism, which is that the original licensee has already granted a license over the software to everyone, and the giver is simply notifying the recipient of the terms of that license. We note that draft 2 of version 3 of the GPL specifically addresses this issue, adopting a hybrid position by which the original licensor grants a license to the recipient automatically at the time of receipt of the code.⁴ Where relevant, comments on the effect of this alternative licensing interpretation (ALI) are made in the article. These are marked “ALI”.

2. What are the terms of the License?

2.1 The text of the BSD is as follows (our numbering – it is this numbering which is used when we refer to “clause x” of the BSD):⁵

1 Copyright (c) , [YEAR], [OWNER]
All rights reserved.

2 Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

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

4 * 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.

5 * Neither the name of the [organization] nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

6 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

2.2 The logical flow for this analysis is to consider distribution of BSD code in source and object form, with and without modification. We consider each of these scenarios separately in the following paragraphs.

3. Redistribution in Source Form without Modification

3.2 This begs the question: what is the legal effect of being required to retain “this list of conditions”. Are they just there for show? Do they have some other effect? In determining this, a court will look to the objective meaning of the clause and, potentially, the objective intention of the party granting the license. In this case, the actual subjective intention of the party granting the license (and what they thought the words meant) is irrelevant.⁷ What the court is looking to determine is what the reasonable person (ie an idealized and dispassionate citizen who is called on to assess the scope of the license) would make of the words.⁸

3.3 Consider first the warranty disclaimer. If there is a requirement to “retain” a copy of the warranty disclaimer in a redistribution, is a court likely to say the warranty disclaimer is intended to be effective or not? For example, could the disclaimer be retained but framed by a redistributor in such a way that the disclaimer had no legal force?⁹ It is likely that the reasonable person would read the license and think that the licensor intended that the warranty disclaimer was to run with the redistribution without qualification.

3.4 On this analysis, the warranty disclaimer travels with the distribution and the distributor has no ability to qualify it. The question then becomes what about the other clauses? What about clause 2 which permits “redistribution and use” of the source code? If, in the case of the warranty disclaimer, the objective intention of the requirement to “retain” or “reproduce” the warranty disclaimer is that the warranty disclaimer is a condition of the distribution, why should the same reasoning not apply to the terms in the “list of conditions”? Moreover, if the warranty disclaimer is operative as a condition, what basis can there be for arguing that the other clauses are not?

3.5 If the other license terms are operative, then the combined effect of clauses 2 and 3 is that redistribution of the source form must occur on the terms of the BSD license. A similar argument leads to the same result in respect of redistribution in object form. There is a certain element of common sense to this conclusion. If the license terms are not operative, any later taker could legally vary the requirement that the warranty disclaimer be included. Moreover, if anyone could license the code under different terms, then any person redistributing the unmodified code¹⁰ could remove the warranty disclaimer and other terms, removing the protections expressly included by the copyright holder.

3.6 It is a corollary of the above that if a copyright holder wants a warranty disclaimer to travel with the code, then they must include a condition to that effect, and that condition must travel with the code to at least the same extent that the disclaimer is intended to. In short: to be effective licenses which include a disclaimer must be infective.

ALI

3.7 Under the ALI the conclusion in this section follows automatically because the ALI assumes that third parties have already been licensed under the BSD and that the inclusion requirement simply puts the recipient on notice of the license terms. Note that the ALI would not permit licensing in this case under a different license as it assumes that the giver is not licensing at all.

4. Reproduction in Source Form With Modification

4.1 We now turn our attention to the case where modifications are made to the source code, and redistribution of the source code with those modifications occurs. Above, we concluded that the BSD license applies to the unmodified source code. Does it also apply to the modifications?

4.2 Clause 3 simply talks about “Redistributions of source code”. A distribution of modified source is a distribution of source code, so clause 3 applies – a copy of these terms must be included with the modified source code. The wording does not support identification of a specific subset of the source code (ie the portion which is unmodified) for the license to apply to. Assuming our analysis above applies, then by including the license terms with the modified source code will make those terms (in particular, the rights to distribute and use in clause 2) apply to the whole of the modified source code as redistributed.

ALI

4.3 The situation under the ALI is probably similar to the argument above about framing the warranty disclaimer. By definition under the ALI no license is granted by the giver over the original code. This raises a question about the “gap” between the original code and the code as modified. This gap can't be licensed by the original licensor since it's not theirs to license. However, the original licensor has mandated specific wording to be included which purports to apply to the code as a whole (ie as modified). The question would become – is it reasonable to read these words as permitting a similar form of framing to that discussed above (in paragraph 3.3/note 9)? In this respect, two clauses (the warranty disclaimer and the clause 5) imply that the terms of the license are intended to address some of the interests of contributors to the software.¹¹ The references to “contributors” in these clauses would be meaningless if the license terms only applied to the original code and when assessing competing interpretations of the license. As these references to contributors appear to be very deliberate, it would be inappropriate to prefer an interpretation in which they have no meaning. As such, it is unlikely that the license would be interpreted as permitting such framing and the ALI is therefore likely to lead to the same result. Under the ALI there may now be two licences, one from the original licensor relating to the original code, and one from the contributor relating to the modifications.

4.4 A counter argument may be that the copyright statement (clause 1) may be wrong in the case of modifications and the BSD does not provide an option for the addition of other copyright notices. This is difficult, but not impossible, to reconcile with the interpretation above – for example, if clause 1 of the BSD is intended to vest copyright in modifications in the original author it will be consistent with the above interpretation (and, incidentally with the ALI). Such an interpretation would, no doubt, cause some alarm and therefore should not be preferred without substantially more analysis. In this context that clause 6 exquisitely draws both the distinction between the “copyright holders” (plural) and contributors and the “copyright owner” (singular) and contributors. However, if not reconciled (either in this way or as a drafting error),¹² it is difficult to see how the BSD can be consistent (under the ALI) except by reading the references to contributors in clauses 5 and 6 as having no meaning.¹³

5. Binary Form of Modifications

5.1 A similar argument to that for source code applies in relation to modified binaries. Arguably therefore, if you have modified the object form of BSD licensed software then when you distribute it your modifications must also be licensed under the terms of the BSD license.

5.2 One might argue that, in the case of binaries, most people don't actually modify the binary form of some software. Rather they modify the source code, and compile new object code from that modified source. That is, the object code is not the original binary “with modifications”. Rather, both of them are derived from a common source.

5.3 In Australia the compilation of source code into object code is itself a reproduction of the source code.¹⁴ In fact, any derivation of object code from source is such a reproduction. As such, if you modify the source code, you need the original copyright holder's permission to compile it and to subsequently distribute it. Where is that permission to be found in the BSD? If the new object code is not the “source or binary [form], with or without modification” then there is no right to distribute that new object code. Either the compilation of the modified source is a binary form which is subject to the BSD, or it will be an infringement to distribute it at all (in the absence of an additional license).

6. Can BSD Code be Licensed Under a Different License/Closed Source License?

6.1 We asserted above the collective wisdom that BSD code can be licensed under other licenses. There does not appear to be any basis for this wisdom in the terms of the license. Further, the terms of the BSD license do not appear to allow more restrictive licensing terms. This is not to say that the BSD terms forbid them. Rather, the BSD's usage and distribution rights are so broad, that additional (parallel) restrictions would appear to be ineffective.¹⁵ There is not even any basis on which modifications to the code can be used to leverage a different license¹⁶ – because, as we have concluded above, (if part of a “redistribution”) those parts which are the original “with or without modification” must be licensed under the BSD terms.

6.2 We should also note here that, in the world of licensing, the appropriate starting point is to assume that what is not permitted is prohibited (at least to the extent that it is prohibited by copyright or other laws). The BSD does not include an express permission to license under different terms, so the ability to license under other terms can only be arrived at by implication. There does not appear to be any basis in the words of the license which supports such an implication.

6.3 One might also argue that the actions of the community can be taken into account when determining the scope of the license. This argument may have force in certain specific circumstances (for example, where a specific licensor has clearly adopted this broader practice and made their adoption known), but is probably lacking substance in the general case. First, it is something of a circular argument – if the license defines what the community is permitted to do, anything outside the license is illegal. How can the illegal actions of members in the community (even en masse) render their own illegal activity legal?¹⁷ Second, how are the “actions of the community” to be established? Third, why should these actions be implied in the general case? For example if I write some software, then walk outside and give it to a passer-by with a copy of the BSD attached, why should that person's license be determined by anything other than the words of the BSD included with the software (as it comprises their entire knowledge of the license and its context)? Moreover, why should the “actions of the community” be binding on me as a licensor when I choose this form of words for my license, especially if I do not reference those actions in the wording of the license?

7. Does the BSD Require Availability of Source Code?

7.1 The BSD license does not have any express provision requiring that source code be distributed along with a binary. You could argue that by distributing a binary version of the software you are granting a license over the corresponding source code (even if the source code or modified source code is not distributed) since clause 2 of the BSD permits use and redistribution of the program in source form. However, if this argument is correct, it would still not lead to the provision of access to the source code.

7.2 So, even if:

(a) modified source code is required, in the event of distribution, to be licensed under the terms of the BSD license; and

(b) the binary form of the modified source must, if distributed, be licensed

neither of these by itself, nor both taken together, ensure that anyone will be entitled to access to the source code for that binary.

7.3 It is here that the BSD's common wisdom has its force. While a license of object code under the BSD license would presumably require that the source code for that binary also be licensed under the BSD license it does not require that access to that source code be provided. We argue below that this may lead to a false sense of security for those developing on top of BSD code.

8. Some Questions

8.1 Assuming that the conclusion of this paper is true, this raises the following questions (which this paper leaves open):

(a) is it legal/effective to modify the attribution clause in the old BSD terms? Arguably, the practice of modifying the license terms to add attributions is inconsistent with the license – later takers would only need to comply with the original attribution clause and would be free to fail to comply with the additional attribution requirements;¹⁸

(b) how can the GPL also apply to software licensed under the BSD?¹⁹ The additional requirements of the GPL would not appear to be enforceable in respect of the BSD code. If they are not enforceable, how can the conditions in the GPL, and in particular the requirements of clause 2 be complied with?

(c) the absence in the BSD of a requirement to make available the source code brings into question whether the BSD ought to have been approved by the Open Source Initiative (OSI) (for failure to comply with clause 2 of the Open Source Definition²⁰ (OSD)). There has been inconclusive discussion in relation to this on the OSI's license-discuss mailing list in 2002,²¹ the upshot of which was that OSD #2 does not impose a requirement on the terms of the license and is, rather, a pragmatic requirement relating to the software itself and the circumstances under which it is distributed in practice.²² This leads to the troubling conclusion that it is possible for software to cease being open source software even if its license terms remain the same;

(d) when a company incorporates BSD code into some software, then (to the extent the binaries are modifications of that BSD code) the company is, by assumption, required to license that software (including their own modifications and the source code for their modifications) under the terms of the BSD. We saw above that this does not mean that the source code must be released at all. However, what of the situation where the source code subsequently becomes available? If that was the case, would there be no copyright infringement for copying and distributing that source code? This is discussed further below;

(e) what is the difference between a “modification” and a “derivative work”? If they are the same, the scope of the BSD's licensing requirement will be very similar to that of the GPL. Note also that the BSD only permits the distribution of modifications, so if there exist derivative works which are not modifications the BSD does not address whether they can be distributed or even created – and in the world of licensing that is the same as a prohibition. Compare the GPL which expressly (but conditionally) permits the creation and distribution of derivative works;

(f) can BSD software be included in compilations and are there circumstances in which a compilation including BSD code is a modification of that code?

9. The BSD Blind Spot

9.1 The troubling aspect about the BSD is not so much the scope of the license, but the common wisdom that its use entails no risks. Assuming the argument above is correct there exists a risk (set out below) to organizations modifying BSD code. This risk is perhaps not likely to eventuate but, if it does, its effects would be substantial.

9.2 If an organization modifies BSD code and releases a modified version then, as we noted above, the modified version will need to be licensed under the terms of the BSD license. Further, we have assumed that that the terms of the BSD license give a recipient a right to copy the source code for that software, even if they only receive the binary. While it will be of great comfort to know that the BSD license does not require the production of the source code, the BSD license permits anyone who already has access to the source code to distribute it. Of itself, this would appear to substantially reduce, if not remove, the confidential character²³ of the source code. While a person may have held that source code previously under an obligation to maintain it confidential, is it not possible that the granting of a BSD license to that person will remove the requirement to keep it confidential?²⁴

9.3 We must therefore pose the question – can an employee (or, more likely, an ex- or soon-to-be-ex employee) who has access to the modified source code disclose that source code to others if they acquire a copy of the released BSD binary (i.e. as released by the organization)? Even without this requirement, if the license of a binary version can affect the confidential nature of the source code for that version, then, depending on the timing, this may affect the ability to apply for patents which relate to the source code version.

9.4 The realization of this risk does require the confluence of a number of different circumstances, not least the enforcement of the original BSD license. It should not be viewed as an automatic consequence of the adoption of BSD code. Nevertheless, the risk of the BSD is that an organization may make a substantial investment in BSD code on the assumption that that investment code will remain protected by non disclosure only to find that they cannot prevent an employee, or third party who gains access to the code, from making that code public under the BSD license. The end result here is very similar to that of other licenses (such as the GPL), with the proviso that organizations adopting the GPL will usually do so with their eyes wide open to the consequences.²⁵ Those adopting the BSD may find themselves not only blindsided, but to devastating effect.

ALI

9.5 This risk would presumably be exacerbated under the ALI as each person is automatically assumed to have received a license – so the risk would not be contingent upon a person receiving a copy of the licensed binary.

10. Conclusion

10.1 If the arguments in this paper are correct then we can draw a number of conclusions:

(a) the BSD appears to require that modifications be distributed only under the terms of the BSD, and that this requirement therefore cascades down to subsequent generations of code;

(b) the license does not appear to permit the relicensing of BSD code under the terms of any other license, at least in so far as any restrictions in other licenses would seem not to be binding;

(c) there may be some scope for arguing that the term “modification” to the code is restricted or limited in some fashion. However, as the license only permits redistribution of “modifications” the BSD does not permit the redistribution of any derivative work which is not a modification;

(d) the BSD does not have a requirement for the distribution of source code. It is not clear whether this means there is a deficiency in the Open Source Definition.

10.2 Use of the BSD is not without consequences. While unlikely, the worst case scenario could be the inability to prevent the disclosure of modifications made to BSD code – in some cases a catastrophic result. Use of the BSD license requires the same careful consideration as the use of any other open source license. The safest option to follow in these circumstances is to assume modifications made to BSD code are themselves subject to that license, and that disclosure of those modifications may not be able to be prevented.

Rider

What Does The Community Think About BSD Relicensing?

Note the new BSD license is thus equivalent to the MIT License, except for the no-endorsement final clause. [Note: on the analysis in this paper they would not be equivalent]

As at 1 March 2006, Open Source Initiative, foreword to new BSD license
http://www.opensource.org/licenses/bsd-license.php

The BSD License allows commercial use, and for the software released under the license to be incorporated into commercial products. Works based on the material may even be released under a proprietary license.

As at 16 February 2006, http://en.wikipedia.org/wiki/BSD_License
(version: 03:25, 8 February 2006 GrinBot m (robot Adding: nl Modifying: hu))

These BSD-style licenses make it clear that you hold copyright and make no warranty, but that is about it.

Barak A. Pearlmutter (and others), DFSG and Software License FAQ (Draft), Revision: 1.84 $ $Date:
2004/11/16
http://people.debian.org/ ~bap/dfsg-faq.html

The BSD License grants permission to do whatever you want, as long as you incorporate the copyright and a disclaimer of liability. This is one of the earliest open source licenses. Under its terms you may do virtually whatever you want. For example, you could adapt BSD-licensed source code to create a proprietary, commercial product.

Pete Loshin, Open Source Software: Free and Open Source License Myths
http://www.b-eye-network.com/ view/2205?jsessionid=5750033371a735f1d2377e8caa05907c

The copyleft concept is not applicable under a BSD license because BSD does not include the requirement that derivative works are subject to the same terms as the initial BSD license.

http:// wiki.flashline.com/wiki/index.php/ Legal%20Issues%20Relating%20to%20Open%20Source%20Licensing

The so-called new BSD license applied to FreeBSD within the last few years is effectively a statement that you can do anything with the program or its source, but you do not have any warranty and none of the authors has any liability (basically, you cannot sue anybody). This new BSD license is intended to encourage product commercialization. Any BSD code can be sold or included in proprietary products without any restrictions on the availability of your code or your future behavior.
and
Developers tend to find the BSD license attractive as it keeps legal issues out of the way and lets them do whatever they want with the code.

Bruce Montague, Why you should use a BSD style license for your Open Source Project, (particularly telling, as this interpretation is critical the arguments in support of the BSD made by this paper)
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/bsdl-gpl/article.html

The "English" version of the license is effectively that you can do anything you want with the code, but if you use BSD code you can't sue anybody - you have no warranty and none of the developers has any liability.

http://63.249.85.132/ fbsd_intro.html

That's it. You can distribute it as either binary, source, or either, even under a different license (provided that the terms of the above are met).

http://www.my-opensource.org/lists/ myoss/1999-06/msg00182.html

The users can do whatever they want with the software, including releasing it as proprietary software, whether modified or not.

Francesco Potortì, Software licenses, Updated: 2005-04-11
http://fly.isti.cnr.it/ sl/licenses.html

For instance, a vendor could take one of the BSD-licensed Unix systems, change it slightly, and rerelease it under a completely closed and proprietary license (ie. no CopyLeft)

FreeSoftware, http://www.usemod.com/cgi-bin/ mb.pl?FreeSoftware

We also include some notes of comments where people have perceived or enunciated the issue and arrived at the same conclusion as in this paper.

I am not at all sure about the legal implications of including BSD sources into proprietary software, as you have to keep the "list of conditions" intact, which would include the permission for redistribution. I've heard conflicting optinions [sic] on this.

-- MartinBaute, Licensing Issues (Last edited on August 26, 2004 8:46 am.)
http://www.mega-tokyo.com/ osfaq2/index.php/LicensingIssues

The BSD gives very broad and extensive permissions to second parties. But one permission it does not give is the right to change the license. (28 Jan 2000)

Certainly someone could take my BSD source, compile it, and distribute it binary only. However, those binaries still have my license on them and the recipients have the right to redistribute them themselves. (31 Jan 2000)

Prescient comments from David Johnson in this discussion in Debian-legal email list, relating to this message from January 2000 (see also contrary views expressed in the thread):
http://lists.debian.org/ debian-legal/2000/01/msg00081.html
http://lists.debian.org/debian-legal/ 2000/01/threads.html#00081 (thread view)