decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.


Contact PJ

Click here to email PJ. You won't find me on Facebook Donate Paypal


User Functions

Username:

Password:

Don't have an account yet? Sign up as a New User

No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law
Sunday, January 14 2007 @ 02:34 PM EST

Brendan Scott has been studying the BSD license, particularly in the context of Australian law, and he has come up with some startling questions. Is the BSD license as permissive as we've thought? The paper is principally for lawyers to consider, but it's certainly of interest to everyone, and note his disclaimer:
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



Abstract1

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.2 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:3

"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.4 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):5

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.1 Consider the situation where code licensed under the BSD license is redistributed6 in source code form and without any modification. Normally, the reproduction of the source code of software involved in such a redistribution would be an infringement of copyright. Therefore in order to distribute the code legally, the distribution would need to be permitted by a license. Clause 2 clearly permits a person to redistribute that code providing that they comply with clause 3. Clause 3 requires the retention of “the above copyright notice” and “this list of conditions”.

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.7 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.8

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?9 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 code10 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.11 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),12 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.13

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.14 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.15 There is not even any basis on which modifications to the code can be used to leverage a different license16 – 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?17 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;18

(b) how can the GPL also apply to software licensed under the BSD?19 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 Definition20 (OSD)). There has been inconclusive discussion in relation to this on the OSI's license-discuss mailing list in 2002,21 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.22 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 character23 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?24

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.25 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?

There is an inherent problem with attempting to ascribe views to a large group of people, only the minority of which have been interviewed or reviewed. As such, technically, this paper asserts without proof that the
BSD relicensing view is widely shared. Posing any number of references may only be evidence of a specific subset of the community which holds the view, rather than the community as a whole. However, in support of this paper's assertion, we include a collection of quotations from documents which purport to be reference documents on the meaning of specific open source licenses or on open source licensing. Except as stated otherwise each of these pages were accessed on 17 February 2006, and the most recent version of the document which could be located has been used.

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)


*Brendan is the principal of Open Source Law, an ICT legal practice with a special focus on open source and customer copyright. Brendan has over 12 years of experience in ICT related legal issues. He is a director and founding member of of Open Source Industry Australia Limited and is on the steering committee of the Australian Service for Knowledge of Open Source Software, a national focal point for advice, management, governance, storage and dissemination of Open Source Software (OSS) for research and higher education.

1 Orthography in this paper is US English. The term “BSD” is used variously (and a little inconsistently) to mean “Berkeley Software Distribution”, “Berkeley Software Distribution License” and “Berkeley Software Distribution Licensed”.

2 See discussion and references in the rider.

3 http://www.microsoft.com/resources/sharedsource/ Articles/LicensingOverview.mspx#EDAA as at 9 March 2005.

4 See clause 10 “Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License...

5 Text taken from: http://www.opensource.org/licenses/bsd-license.php.

6 Surprisingly, “distribute” seems to have an appropriate meaning in US English, but not in UK English. Compare the meanings given in The American Heritage Dictionary of the English Language: Fourth Edition 2000 and The Fifth Edition of the Shorter Oxford English Dictionary (or the Australian Oxford Dictionary). Presumably “re”distribution is used in the license rather than the more natural “distribution” on the assumption that your acquisition was an initial distribution – or the drafter didn't turn their mind to it.

7 If they express that subjective intention prior to the granting of the license it will vary the license – in accordance with an objective interpretation of the manner in which they express their subjective intention.

8 It is not clear whether it is the idealized addressee of the license or the dispassionate third party observer whose view is considered.

9 Consider (eg): “One of the conditions on our redistribution is a requirement to include the following. However, it is included only as an example of some fine legal draftsmanship and has no effect on your rights as a recipient of the corresponding code:..

10 Note that the discussion in this section is only in respect of the unmodified code.

11 Clause 5 is ambiguous in that “its contributors” may mean the contributors of “[ORGANIZATION]”. The better reading is probably that it refers to contributors to the software, especially given that clause 6 includes references to contributors and the “copyright holder”. The “obnoxious advertising clause” which was removed from a previous draft of the BSD refers to “the University of California, Berkeley, and its contributors” and is of little assistance.

12 The contributors references can also be argued to be errors, but with less force given the manner in which they have been included.

13 Or that contributors means contributors of “[ORGANIZATION]” – which, while unnatural, is plausible for clause 5, but less so for clause 6. Query though whether it is meaningful, especially in the general case (eg licensor is an individual).

14 Section 21(5) of the Copyright Act 1968 (Cth).

15 For example, additional terms “In order to use this you must first whistle dixie.” are unlikely to be effective, because if the software is licensed under the BSD then the recipient has a license to use the software without such whistling.

16 For example, by packaging BSD code with third party code into a single product.

17 You could argue waiver in specific instances, but would need to bootstrap that somehow to a generic waiver in all instances.

18 This does not address the issue of multiple versions of the old BSD terms being applied to independently created works, each with a different author attribution requirement.

19 Subject to the comment in paragraph (f), the GPL might apply to a compilation which includes BSD code, the compilation being a separate work for the purposes of copyright law.

20 http://www.opensource.org/docs/definition.php

21 See, for example (from 2002):
http://thread.gmane.org/gmane.comp.licenses.open-source.general/397 and http://thread.gmane.org/gmane.comp.licenses.open-source.general/372

22 The term “license” does not appear in OSD #2. This interpretation is subject to its own problems – how, for example, can a program “allow access” to the source code? Either this is a requirement that the program itself actually displays its own source code, or the reference to “program” should really be a reference to the license. This clause of the OSD is problematic.

23 This is one of the key elements of trade secret protection under Australian law.

24 This issue is complex and will depend greatly upon both the circumstances giving rise to the confidentiality (eg implication, agreement or deed) and the jurisdiction in which the issue will be decided. Nevertheless, we can see no reason why, in theory, this outcome is not possible.

25 As a result of the widespread publicity of those consequences.


  


BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law | 391 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections Here
Authored by: feldegast on Sunday, January 14 2007 @ 02:52 PM EST
So they can be fixed

---
IANAL
My posts are ©2004-2007 and released under the Creative Commons License
Attribution-Noncommercial 2.0
P.J. has permission for commercial use.

[ Reply to This | # ]

3.2 should say "raises the question"
Authored by: Anonymous on Sunday, January 14 2007 @ 02:53 PM EST
Little pet peeve of mine...

Begging the question, in the context of an argument, is assuming the truth of
the proposition that is in dispute; it is a kind of circular reasoning and a
logical fallacy.

Raising the question is making salient in the conversation an interrogatory
sentential construction.

So in the current context, which is 3.2, "this" (and "this"
is ambiguous here and should be replaced with a definite description) raises the
question you pose - a question that should end with a question mark, not a
period.

Try this:

3.2 Clause 3 of the BSD license raises the question: what is the legal effect of
being required to retain “this list of conditions”?

[ Reply to This | # ]

BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law
Authored by: Anonymous on Sunday, January 14 2007 @ 03:26 PM EST

The B in BSD is Berkeley, as in University of California, Berkeley. The motivation for the license is that as the taxpayers already paid for the development, it would not be appropriate to limit how any taxpayer could enjoy the fruits of intellectual study. A lesser consideration is that since it was built by faculty and students in order to teach and learn concepts, BSD code may necessarily require further engineering to produce real world products. For an entity, outside of academia, developing code, the GPL makes more sense, because they are paying for their own r&d.

[ Reply to This | # ]

Off topic thread here
Authored by: tiger99 on Sunday, January 14 2007 @ 03:38 PM EST
As no-one seems to have started one yet.

Please remember those clickable links, where possible!

[ Reply to This | # ]

BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law
Authored by: Anonymous on Sunday, January 14 2007 @ 03:48 PM EST
Yeah, that theory's come up before a couple of times, in discussions of the
various free software licenses (don't have a reference to hand, sorry). The
general conclusion is that while it *might* be true, the BSD license does not
contain any clauses that restrict or command the actions of a person who might
redistribute the software. That means they can't really be sued or in any way
required to provide the modified source - if they give it to you, fine, but if
they don't, then you can only obtain that source through dubious means. Any such
method would likely be illegal in and of itself, without regard to the license.

Consider: assume Microsoft had a piece of software, distributed in binary form.
If one of Microsoft's developers of the software were to redistribute the source
without permission, then while this may not be a breach of copyright law, it is
almost certainly a breach of their employment contract and most likely of trade
secret law too. Thusly Microsoft can pursue legal remedies without having to
resort to copyright law.

So not much has really changed - the entity doing the modification still has
abilities to place restrictions on what happens to those modifications, even if
their ability to use copyright law for this purpose is suspect.

(The implications of this for restrictive-license source distribution, like
Microsoft's "shared source" program, is an unknown - and it's
Microsoft's problem to worry about, so nobody really cares)

The really important implication of this theory is the question of whether or
not you can combine the BSD license with a restrictive EULA that places special
extra conditions on the recipient. That is widely regarded as an unknown - with
no case law on the subject, it's far too difficult even for a lawyer to guess
accurately. As a point of general principle, free software developers usually
dismiss this issue by noting that they really don't care about it, and anybody
who wants to use a restrictive EULA is just going to have to deal with the
matter themselves.

Note that the practice of making special restrictions in a shrink-wrap EULA is
also widely considered by many lawyers to be legally suspect in the first place
- it's based on the notion that a forced, non-negotiated contract is somehow
binding merely because the recipient had the option of not using the software at
all. So nothing's really changed there either - restrictive EULAs have always
been questionable and this is just one more reason to add to the pile.

The basic point is - these things *may* be true (it's generally agreed that we
won't know unless and until the theory is tested in court), but they don't
really have major implications even if they are. Certainly they don't have any
apparent implications that the free software community is likely to care about -
this is a problem for corporations, who can get their own overpaid legal
department to fret over it.

[ Reply to This | # ]

Slightly biased?
Authored by: tiger99 on Sunday, January 14 2007 @ 03:49 PM EST
I am wondering if the author is merely showing a pro-GPL bias by identifying flaws in the BSD licence that have no real significance?

Having said that, I personally prefer the GPL, precisely because it does not allow anyone to take the work of others and make it into a commercial product, while contributing nothing back to the original author, or the community, as BSD was thought to allow.

He could be saying that the BSD might not allow that either, but I think he is just saying that the BSD licence is not clear legally, and may be risky to use. The so-called risks associated with the GPL are well known and understood, therefore they are not risks at all.

All very confusing to a non-lawyer.

I suspect that this will quietly go away, and this time it may well be that M$ and the FOSS community are actually in agreement. Just think what it would mean to M$ if their use of BSD code was found to be illegal! But it would be fun.....

[ Reply to This | # ]

OzPLB
Authored by: Anonymous on Sunday, January 14 2007 @ 04:31 PM EST

FWIW, the National Information and Communications Technology Australia (NICTA) is promoting something called Au stralian Public Licence B Version 1-1 (OZPLB) as a BSD replacement license. They're using it for stuff like Iguan a, a "base OS" for imbedded systems.

Clearly, somebody in the Australian government has been persuated that BSD-like "corporate friendly" licenses, which allow corporations to take public code and make it proprietary, is better than GPL-like "free market friendly" licenses, which maximize software market transparency and competition on code quality -- not marketing -- by ensuring that the codebase is available to every customer.

Karl O. Pinc <kop meme com>

[ Reply to This | # ]

This glosses over the actual use case and seems to be confused
Authored by: Anonymous on Sunday, January 14 2007 @ 05:56 PM EST
Yes, unmodified BSD-licensed code must be distributed under the BSD license as
he notes.

The normal use case is a large work which contains many modules, with the BSD
code as a single module. The BSD code remains under the BSD license and all its
requirements; it cannot be relicensed and is not relicensed. However, the
*other components* may be under any license. This means that to use or
distribute the work as a *whole*, you need to satisfy *both* the BSD license and
the other, perhaps proprietary, licenses. Unlike the case of the GPL, *this is
possible*.

The case of a heavily modified hunk of BSD-licensed code is similar. This is
the case of a *derived work*, which is subject to two copyrights: the copyright
of the person making the derived work, and the copyright of the person who made
the original on which it was based. The original copyright is licensed solely
under the BSD license, and cannot be relicensed. The derived work's copyright
may be licensed under any license, including proprietary ones. Both licenses
must be satisfied simultaneously, but again this is possible.

This is my non-lawyer's understanding, but I have done a fair amount of research
on this stuff, and this seems to be a consensus view among everyone who has done
any investigation into copyright law as it affects derivative works and
compilation works.

To summarize:
* BSD-licensed code *cannot be relicensed*.
* But it *can be* included in a work with a different license.

This means your proprietary program *must* legally include all those BSD license
statements, warranty disclaimers, and copyright notices; they apply to the
"BSD portion" of the program. I'm not sure what would happen if the
"BSD portion" was deemed to be inseparable from the rest, but that's
usually not the case, as far as I can tell.

[ Reply to This | # ]

Doesn't authors intent count for anything?
Authored by: Anonymous on Sunday, January 14 2007 @ 06:08 PM EST
People choose the BSD license because they want people to be able to use their
source code in both closed and open products.

If they didn't want them to be use their source code in these ways, they would
choose a different license.

And so, while it maybe possible to come up with some hypertechnical
reinterpretation of the BSD license which conflicts with that intent, doesn't
the authors' intent govern?

And aside from that, who is going to enforce a hypertechnical reinterpretation
of the BSD license, except the copyright holders - nobody but the copyright
holders has standing?

And aside from that, even should a BSD license copyright holder, retroactively
hypertechnically reinterpret the license in this, don't all the same sorts of
arguments that apply to SCO's reinterpretation of AT&T contracts apply: it
didn't mean that at the time, the reinterpretation leads to an absurd result,
the reinterpretation leads to copyright misuse, estoppel, waiver, etc.

Quatermass
IANAL IMHO etc.

[ Reply to This | # ]

Grrr
Authored by: Arker on Sunday, January 14 2007 @ 06:12 PM EST
"3.2 This begs the question: "

No it doesn't!

And this guy is a lawyer, so obviously he didn't flunk out of school in grade
two, so he has absolutely no excuse for such an egregious error. I very nearly
stopped reading right there. In fact I did stop. But eventually I came back and
finished the thing, out of respect of PJs opinion that this was important enough
to post.

At any rate, I don't think his thesis is controversial or novel. In fact, he
appears to me to be missing the point. I don't believe, and I wasn't aware
anyone of note believed, that the BSD license allows one to *change* the
license. BSD code can be used in, for instance, GPL code - there is a little,
AFAIK, in the Linux kernel, but it's still under the BSD license. It just
happens to be the requirements of the BSD license and the requirements of the
GPL license can both be satisfied simultaneously. That is, the BSD code is under
the BSD license, the GPL code is under the GPL license, and the work as a whole
must therefore be treated as if it were GPL licensed in order to satisfy the
conditions of both licenses. You can still pull out whatever BSD bits there are
and republish them under the BSD license, but if you use any of the GPL parts
you must treat the combination as if it were GPLd.

And MicroSoft can get away with leveraging BSD code for its proprietary products
because the BSD license doesn't contain any requirement to make the code
available with the binaries. They don't, technically speaking, change the
license of that code - they simply don't publish the code, and the BSD license
doesn't require them to. Am I wrong?

[ Reply to This | # ]

  • Grrr - Authored by: Anonymous on Sunday, January 14 2007 @ 07:05 PM EST
  • Grrr - Authored by: grouch on Sunday, January 14 2007 @ 07:57 PM EST
    • Grrr - Authored by: Arker on Sunday, January 14 2007 @ 08:06 PM EST
      • Grrr - Authored by: PJ on Sunday, January 14 2007 @ 11:54 PM EST
    • Grrr - Authored by: Anonymous on Monday, January 15 2007 @ 12:42 PM EST
  • Grrr - Authored by: Anonymous on Monday, January 15 2007 @ 01:20 PM EST
License on modifications
Authored by: russellmcormond on Sunday, January 14 2007 @ 06:13 PM EST
I disagree with with suggestion that modifications, or other derived works. should be presumed to be in the same license. When I make a change you end up with different works which are licensed:
  1. The original, unmodified version -- which the originating copyright holder has offered a BSD license for. I can not *change* this, and if I distribute a modified version I am not in any way *changing* the license of the original.
  2. My modifications, which I am the copyright holder for. I can use whatever license I want for my modifications. This is one of the things that may be discussed in the SCO-vs-IBM case, assuming it makes it to trial and SCO doesn't die too quickly.
  3. The combination of the original and my modifications. In order to distribute the whole the license I use and the license of the original need to be compatible with each other. They don't have to be identical, just compatible, such that the terms of one do not conflict with the other.

While it may be possible to create a license which is incompatible with the terms of the BSD license, I can't think of one offhand that doesn't involve me somehow stripping the moral rights of the original copyright holder.

Russell McOrmond
http://flora.ca/
Policy coordinator for CLUE: Canada's Association for Free/Libre and Open Source Software.

---
Russell McOrmond, FLOSS Consultant

[ Reply to This | # ]

BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law
Authored by: david_koontz on Sunday, January 14 2007 @ 06:54 PM EST

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?

IANAL, but the issue of open source licenses is part of my job responsiblities. Looking through Scotts paper, it appears that all issues derive from the definition of "derivative work". Its probably safe in general to use the U.S. definition:

Derivative Works

A “derivative work,” that is, a work that is based on (or derived from) one or more already existing works, is copyrightable if it includes what the copyright law calls an “original work of authorship.” Derivative works, also known as “new versions,” include such works as translations, musical arrangements, dramatizations, fictionalizations, art reproductions, and condensations. Any work in which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship is a derivative work or new version.

A typical example of a derivative work received for registration in the Copyright Office is one that is primarily a new work but incorporates some previously published material. This previously published material makes the work a derivative work under the copyright law.

To be copyrightable, a derivative work must be different enough from the original to be regarded as a “new work” or must contain a substantial amount of new material. Making minor changes or additions of little substance to a preexisting work will not qualify the work as a new version for copyright purposes. The new material must be original and copyrightable in itself. Titles, short phrases, and format, for example, are not copyrightable.

So, small changes aren't a derivative work, and the original BSD license applies. Larger changes are a derivative work and the portion that is under the original BSD license is still covered by the same license, which gives permission for modification.

The derivative work author must abide by the license requirements for distribution, these aren't particularly onerous, keeping the copyright notice in source code, reproducing the copyright notice and list of conditions in any supporting materials when distributed in binary form (attribution).

The derivative work author has the right to control distribution of the authors original works portion of the derivative work. If the author specifies licensing terms for distribution that are not incompatible with the original license, he has not violated the license terms.

As far as the implication as to whether or not the soon to be ex-employee could re-distribute the source code would depend on whether or not the modified work qualified as a derivative work, as the author of the derivative work controls distribution of the portions that are copyrightable by the author of the derivative work. If the soon to be ex-employee had a safe determination that a modified work didn't qualify as a derivative work based on changes involving only elements not coverable by copyright, they could spill the beans on an embrace and extend scheme.

[ Reply to This | # ]

BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law
Authored by: rsmith on Sunday, January 14 2007 @ 07:26 PM EST
Use of the BSD is not without consequences.

That is true for any license, isn't it? You kicking in an open door.

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.

If preventing disclosures of source code is paramount, why you base your product on open source code at all?

Use of the BSD license requires the same careful consideration as the use of any other open source license.

Well, duh! That's another open door kicked in.

---
Intellectual Property is an oxymoron.

[ Reply to This | # ]

I don't believe the BSD license even attempts to be viral
Authored by: pem on Sunday, January 14 2007 @ 07:57 PM EST
As others have pointed out, BSD-licensed material cannot be RElicensed, but can be AGGREGATED with other software under different licenses quite easily. It's just like IBM's JFS. No matter what SCO's Unix license says, they don't have any control over IBM's software which can be linked to it.

So this question in the paper is troublesome (in that it might have the potential to encourage some employee to do something stupid):

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.

Since you can only patent things which have not been publically disclosed (or within one year of initial disclosure in the US), it is prudent to worry about disclosure by employees, which is why most companies have (usually one-sided and onerous) employee IP agreements. Anybody who thinks one of these employee agreements might be circumventable because some proprietary program contains some BSD-licensed code is thinking fairly creatively, but perhaps from the starting point of a GPL mindset.

Unlike the GPL (which is arguably viral, and which is arguably claimed by Stallman, et al. to be even more viral than might be supported by law, the BSD license doesn't try to be viral. It doesn't say you cannot link with incompatibly licensed code; it doesn't try to impose its own definition of derived work; and it doesn't even have any obligation to distribute matching source with a binary.

Try this simple thought experiment. Assume you link some BSD-licensed code with a proprietary library you have a copy of. Have you caused the proprietary library to be under the BSD license now? If you distribute the binary, can your customers now redistribute the entire binary with impunity?

As another poster noted above, Microsoft and other companies routinely use BSD code. See, for example, these Windows XP release notes, which state that "Portions of this product are based in part on the work of Greg Roelofs. Because Microsoft has included the Greg Roelofs software in this product, Microsoft is required to include the following text that accompanied such software: Copyright 1998-1999 Greg Roelofs. All rights reserved." (with the rest of the BSD license text following).

Assume for a moment that a distributor of pirated copies of Windows is trying to make the argument in court that, since Microsoft didn't specify exactly which portions of Windows was composed of the Roelofs code, the distributor can simply assume that all of Windows is fair game, because at least some of it consists of BSD-licensed code. Realistically, how far will that argument get the defendant?

Likewise, if your employer has some internal proprietary code linked with BSD code, and your employee agreement says to keep it confidential, you would be a fool if you disclosed the proprietary code and relied on the strength of the BSD license to protect you.

[ Reply to This | # ]

Decompilation?
Authored by: Anonymous on Sunday, January 14 2007 @ 08:43 PM EST
If the binary is just a source translation, surely so is a decompilation?

So is it therefore valid to be able to decompile/reverse engineer binaries
generated from BSD licensed sources, and treat that source as BSD licensed?

!Z

[ Reply to This | # ]

Tricky formatting - he tricked himself
Authored by: Anonymous on Sunday, January 14 2007 @ 08:51 PM EST
Here is how he formatted the BSD license in his article:

1. Copyright (c) ,
All rights reserved.

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

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



Here is how the BSD license typically appears in source files (from Wikipedia page on BSD).

* Copyright (c) <year>, <copyright holder>
* All rights reserved.
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* * 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.
* * 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.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS 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 REGENTS 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.


I will ignore the trivial differences in what the author calls section 6.

Notice the author also omits the end of section 2.

I think the author has fooled himself as a result of his reformatting, as well as seeming to assume the entireity of one work must be under a single license.

I will deal with this entireity issue first, as it is pervasive through his article, although it really compounds the other error, which is where I think things first went off the rails. A good example is in 4.3 and 4.4 he talks about the "gap" modifications as if there is a problem with them because they aren't covered by the original BSD license). I think there is no problem, when author A releases under the BSD license, he has granted author B the right to make modifications/derivatives, and has no copyright interest in the modifications, and therefore to the extent the original software is A, it remains under A's BSD license, and the modifications and additions, are under B's license. That is simply a reflection of a routine procedure in software licensing (both open and closed). There are many packages where you get source code or libraries, can use them subject to conditions, but your own home-grown code remains yours.

Going back to formatting: Look at section 3.2 to 3.4 in the author's argument. He interprets the warranty disclaimer (what he calls section 6), as being one of the conditions required for source or binary distribution. Because he also assumes everything in one software package must be under one license, he seems to assume the intermediate entity must duplicate the warranty disclaimer.

Example:

A licenses under BSD license to B.

B is now giving software to C, let's say with A's code embedded.

The author seems to assume that B must somehow replicate the warranty disclaimer to party C (section 3.2 to 3.4 of his argument). It's not clear whether he thinks (i) that B must do that in its own capacity, or (ii) do it on behalf of A. Sorry, but I don't think that can be right.

- If he thinks (i), it can't be right, because B can't modify A's BSD license and notice to read "B" instead of "A" in section 6.

- If he thinks (ii), that can't be right, because B can't enter into an agreement on behalf of A. Where's that power granted?

In other words, if you go down his route you get a license which permits you to distribute in source or binary form, but which is impossible to comply with.

So where's he gone wrong?

As I said: The author seems to assume that B must somehow replicate the warranty disclaimer to party C (section 3.2 to 3.4 of his argument)

Why is he assuming that?

Because he has reformat the BSD license so that the warranty disclaimer (section 6) is one of the conditions for redistribution.

The warranty disclaimer isn't one of the conditions for redistribution. It is simply a statement that the redistributor is required to duplicate in their redistribution.

Quatermass
IANAL IMHO etc.

[ Reply to This | # ]

pls repost without the language
Authored by: PJ on Monday, January 15 2007 @ 04:30 AM EST
Pls. can you read our comments policy? Thanks.

[ Reply to This | # ]

What the BSD license DOESN'T say
Authored by: Anonymous on Monday, January 15 2007 @ 05:05 AM EST

It says you can release modified versions as source code under the same license.

It says you can release modified versions as object code under the same license.

It doesn't say you can release modified versions as object code under a different license. Which, by the way, is what Microsoft has done in the past. Since copyright law prohibits every kind of copying that is not explicitly permitted by the license, why do so many people assume that modified object code can be released under a different license? The wording of the license is clear. Nowhere does it permit this. So copyright law prohibits it.

[ Reply to This | # ]

What use is this?
Authored by: Ian Al on Monday, January 15 2007 @ 06:00 AM EST
No, really!

The author noted that, under Australian law, if you modify the source code, you
need the original copyright holder's permission to compile it and to
subsequently distribute it. He asks "where is that permission to be found
in the BSD?".

The BSD does not limit how you use source code or binary code. One of the use's
available under the licence is to compile the source code.

One of the uses available is to disassemble and decompile the object code.

Can Microsoft aggregate BSD code into a larger work under their horrible EULA?
Yes they can. The EULA is not permitted to reduce your rights to the BSD
original or modified parts and Microsoft must make it clear to what part of
their aggregate the BSD licence applies, or not use it at all. That gives you
the rights licenced under the BSD.

So, under the BSD licence you can get a copy of the original source code and
compile it for the target machine also arranging for the intermediate file to be
created of the assembler code. Now, disassemble Microsoft's modified BSD
licenced code. Compare the assembler code for each and you will find out what
Microsoft have changed. You can, now, modify the original source code to
generate Microsoft's object code.

Now, seeing what a pig's breakfast most Microsoft code seems to be, I have to
question your sanity for doing that, but not your legal right.

Moving quickly on, before you become physically sick, let's suppose an
innovative software company has modified a BSD licenced work. The work is on
their development server in both source and binary form with the BSD licence
associated.

Can an employee take copies of either and use them outside of the company in any
way? I don't think so. The employee has a licence so to do, but doesn't have the
legal right. If the employer does anything to restrict copying (including
non-disclosure agreements and armed guards) then the work is a trade secret. The
employee cannot even tell someone else that the BSD work, modified or
unmodified, is a part of the employer's business.

And, if you think about it, that is also true about GPL code that is not
redistributed. Once distributed, both become free, but BSD does not
automatically become open.

---
Regards
Ian Al

[ Reply to This | # ]

Collected responses
Authored by: Brendan Scott on Monday, January 15 2007 @ 07:09 AM EST
Some responses to some comments:

First: if you can see something wrong with my analysis, please let me know.
Thank you for the comments to date.

Second: Some people are saying it's irrelevant because it's patently wrong,
others are saying it's irrelevant because it's rehashing what everyone knows to
be true.

Third: If you have an established relationship with X, the copyright owner of
program y and X has made clear to you how the licence terms for program y are to
be interpreted, that will trump the words of y - at least if their to your
advantage and in the absence of a contract - "I know the invitation says
black tie, but your massage sandals look just fine, come in anyway"
(arguably it will trump the terms even if the interpretation is to your
detriment - "I know the invitation said massage sandals or better, but
black tie is gauche, go away"). This paper is looking at the general case
where person gives software to another under the BSD and no other relationship
or communication between them can be assumed.


Fourth: some of the formatting and text of the quoted licenses were omitted
during transcription. They have been corrected (although the original uses
angle, not square brackets).


Fifth: the confidentiality question is something which needs more analysis. I
suspect the argument will have more legs in AU than in the US given differences
in trade secret law. In addition, confidentiality is an exercise of a court's
equitable jurisdiction so there is more scope for a court to punish blameworthy
conduct. At its highest it applies only to modifications to the BSD code. But
if you're an employer be aware there could be an issue.

Sixth: Derivative works - not something I can comment on, other than to note
that the BSD doesn't use the term - and to say that (as a US law layperson) I
would be surprised if derivative work and modification were read to be
equivalent.


Overview of paper
The structure of the argument can be mapped out like this:
I take some BSD licensed code a. Copyright in a is held by a third party. I
make substantial modifications to it, producing c (call b the changes to a which
give c). Everyone agrees that c is a with modifications.

If I want to redistribute c then, since it is "a with modifications"
must I include the BSD? If so, given that I know the BSD is a software license,
what is the effect of that inclusion? Can I include it so that it has no effect
on what use a third party can make of c? It is certainly arguable that it is
only a requirement to include a notice which has no legal effect. By looking at
the warranty disclaimer I felt that this is not an interpretation likely to be
preferred because if it was it would permit people to remove the (words
requiring the inclusion of the, and therefore also the,) warranty disclaimer.

Alternative Approach
Another way of approaching the question is to consider if I put the BSD notice
on c and gave it to a third party T - without anything else - would T have a
right to use c? If so, on what terms? I think it is more likely than not that
a court would say T has a license to use c on the terms of the BSD. I think it
is unlikely (eg) that the license would be interpreted as restricted to a, with
b unlicensed.


Counter Arguments
There are counter arguments (especially those based on the inherent ambiguity of
the license - see notes 11, 12 and 13 and related text) but I don't find them
(ie those raised in notes 11-13/associated text) convincing. Some comments
have suggested that the requirement to include the BSD relate only to the
"a" component of modified code. I don't think the terms of the BSD
support that (see paragraph 4.2). I can choose not to distribute b, since it's
my code, but if I want to distribute c then I need to attach the BSD and the
rest is history.

The nub of it all is what is the consequence of including "this list of
conditions".

[ Reply to This | # ]

Referrents of terms in the retained clauses
Authored by: iabervon on Monday, January 15 2007 @ 01:56 PM EST
I think the critical issue is what the terms in license terms retained in
redistribution refer to. To start where he starts, I think that a reasonable
person would expect, from reading the license, that Microsoft could offer a
warranty for software they distribute which they received under the BSD license;
the obvious interpretation is that "The copyright holders and
contributors" are the ones Microsoft got the code from, and if Microsoft
retains the original copyright notice and puts their copyright notice (if any,
for substantial changes) elsewhere, they aren't included in this disclaimer.
(Not to say that they can't have their own disclaimer elsewhere.)

Following the interpretation with this additional piece, it seems clear that the
redistribution terms apply to the source that Microsoft received, not to the
source when Microsoft finished with it, or to the binary Microsoft built from
it. So, while the redistribution terms remain in effect, they only apply to
redistribution of the original code. So this only affects the implausible
situation where somebody wants to grant BSD-type rights exclusively to
Microsoft. Maybe they license it to the general public under the GPL, but give
Microsoft a deal which lets Microsoft alone take it proprietary; that wouldn't
work, because anyone who got it from Microsoft would get the license, and (if
they somehow figured out what was going on) could use the license they got via
Microsoft with the source code they got under the GPL.

[ Reply to This | # ]

Man, I hate lawyers :(
Authored by: roman on Monday, January 15 2007 @ 03:54 PM EST
Here are the parts of the license that are important to me and my understanding of it as a developer:

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - this means to me that I can redistribute source and binary of this software if I satisfy the conditions provided below.

* Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - this means to me that the text of the BSD license and the copyright notices on this piece of software must be present in the source when I redistribute the source. To me this only means that I cannot strip this text from the text of the source.

* 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. - this means to me that the text of the BSD license and the copyright notices on this piece of software must be present in the documentation that comes with the program. To me this only means that I cannot strip remove this text from the text of the documentation when I distribute this program in binary.

* Neither the name of the nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. - this only means that I cannot take the name of the organization mentioned in the text of the license that comes with this program, nor can I take the names of persons from the same text and use these names for purposes other than distributing this program further (either modified or unmodified,) without specific prior written permission.

--

This is ALL. There is nothing else for me, as a developer (or for you as a user or anyone else) that this license means. It is not intended to be a GPL. When I want to use GPL, I use GPL, when I want to use BSD, I use BSD. They serve different purpose, they are not the same and they do not mean the same thing.

The lawyers make it possible in court to turn one thing into something else by manipulating the human language.

What I would like to do, is to see the laws written in something like PROLOG with a list of conditions, so when someone wants to know whether something can be done legally for this law, it would be sufficient to just throw a question sentence into this program, which would then give an unambiguous YES or NO response.

In the case of BSD, this machine would givea NO to the question: is BSD a viral license, like the GPL?

[ Reply to This | # ]

Is the distinction between "binary" and "source" legally meaningful?
Authored by: PTrenholme on Monday, January 15 2007 @ 04:05 PM EST

For most people, I suppose, a "binary" distribution would be one made to be read by a specific computer system in a format specified for that system. And a "source" distribution would be one of the instructions used (or which could be used) to produce a "binary" distribution.

But the distinction that the "source" be "human readable" is not very supportable. There are (an extremely small) number of people who can "read" (and understand) a binary data steam of what many would call a "binary" distribution. Or, of course, if we drop the "understand" almost anyone could "read" the binary representation.

The observation that the "source" is in at "higher level of abstraction" is not too meaningful either. Some "source" is nothing more than a list of machine instructions (assembly code), and a one-to-one "translation" of the "binary" distribution to an "assembly language listing" is fairly easy.

So what is the legal meaning of the mention of "source" and "binary" in, for example, the BSD license?

Or, more germane to GrokLaw, in SCOG's contention that Novell is only entitled to money collected for "binary" licenses?

---
IANAL, just a retired statistician

[ Reply to This | # ]

BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law
Authored by: Jonathan Bryce on Monday, January 15 2007 @ 06:07 PM EST
I think the answer is in the licence.

Where do you get permission to distribute the program?

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

there then follows a list of conditions.

You have to comply with them, but any other licence that allows you to comply
with those conditions is surely OK.

[ Reply to This | # ]

BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law
Authored by: MattZN on Monday, January 15 2007 @ 07:25 PM EST
I'm sorry, it is just absurd. I tried to read the paper, I really did. I
couldn't follow the argument at all. It just makes no sense. I'm sorry, but it
doesn't.

I've been programming for a very long time and most of my work uses the BSD
license. Everyone who uses the BSD license, and especially those of us who have
used it for decades, knows exactly what it is meant to do because it says what
it is meant to do in plain language. Because hundreds of companies use BSD code
in precisely the way the license allows them to, and sell their proprietary
derived works without disclosing source code because they don't have to, and
have been doing so for over 25 years.

No lawyerese is ever going to change the meaning of the license with that much
use history. We aren't talking about just Microsoft here. We are talking about
thousands of programmers like me who would easily qualify as expert witnesses
all telling the judge the same thing. We are talking about hundreds of
companies (not just microsoft) that use BSD-derived code in proprietary products
every day and have been using them for decades.

This is a nice fantasy I suppose, but that is all it is. I consider it
reckless, actually. Not F.U.D., but definitely reckless. In particular I think
the author should not try to hide behind his legalese and consider the matter
from a more realistic perspective, such as what would likely happen if someone
actually filed a lawsuit on the matter.

-Matt Dillon

[ Reply to This | # ]

Be wary of this analysis
Authored by: Anonymous on Tuesday, January 16 2007 @ 12:25 AM EST
This was the guy who spearheaded an effort to threaten to sue Australian-based
IT Companies "on behalf of Linus" for using the word "Linux"
in their website text in harmless sentences such as "Here at Foobar
Consulting, we can write software for Linux". (For the record, we received
one)

His motiviation here is undoubtedly to increase the number of lawyers involved
in the software development process.

[ Reply to This | # ]

BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law
Authored by: jig on Tuesday, January 16 2007 @ 04:54 AM EST
objectively, i don't see how the BSD license can be construed to do anything
OTHER than to require attribution of authorship of any part of the code provided
to the entity redistributing it in either binary or source form. well, that an
requiring that the disclaimer as to those authors is included in the
distribution as well.

reading it directly indicates this, reading the various interpretations
indicates this also. to guess that an australian court would interpret it in
some other way based only on australian contract law is probably not a useful
endeavor. there might be gotchas, but in general i don't believe that an
australien court would pull something out of thin air rather than look at
evidence of how it's been used in the past (and it's been used, extensively, as
i've described above).

i think the failing i'm sensing in the reading of the license is that the author
is trying to overload the definitions of the license by playing both the part of
a user and a contributor at the same time, and then messing up, temporally, how
things progress to redistribution. the license requires two set of things, one
set if you use the code, and another (encompassing superset) if you use the
license to (re)distribute your work. i can "use" the code but not use
the license to redistribute it, or at least not the full license (i always have
to attribute past authors and reproduce their disclaimer). it can get a little
complex, but it should be a pretty linear analysis. modifications OR derivitive
works don't automatically acquire the burden of the BSD license, at least not
the full license, and not in total.

[ Reply to This | # ]

Comments on Intention and Licensing under a closed licence
Authored by: Brendan Scott on Tuesday, January 16 2007 @ 06:26 AM EST
Intention of licensors

The intention of licensors will not be relevant unless it is communicated. So
if I say A but intend B, the only thing I can hold a licensee to is A. Further,
it is the licensor's intention which is relevant. If I use your license terms,
I can't see any reason (in general) why your interpretation of those terms
should be binding on me/my licensees. In some circumstances they will be (eg if
I specifically reference them or my conduct implies my adoption of your
interpretation) but in the general case - no.


Prohibiting Closed Licenses
The important point here is not whether a person is able to apply another
license, but what would the effect of that license be if the recipient already
has the benefit of the BSD? Any restrictions in a closed license will be
irrelevant as the BSD already permits "redistribution and use". This
affects GPL compatibility as well, although the answer to that may be that the
work as a whole is subject to the GPL.

[ Reply to This | # ]

The defining Thought Experiment
Authored by: Brendan Scott on Tuesday, January 16 2007 @ 06:46 AM EST
I think the defining thought experiment in this is the scenario I outlined in a
post above (and with which, unfortunately, no one seems to have engaged). Let
me restate it:

Assume
1. a is BSD licensed code.
2. Copyright in a is held by a third party.
3. I make substantial modifications to it, producing c (call b the changes to a
which give c).
4. Every reasonable person agrees that c is a with modifications.

Experiment (Part 1):
I put c (and nothing else) on a CD ROM and walk outside and hand the CD ROM to a
stranger.

First question - am I required to retain the BSD license terms when I give the
CD ROM to that person? [My answer - yes]

Experiment (Part 2)
Assume
5. I have retained the BSD licence terms on the CD ROM.
6. There are no other license terms on the CD ROM and I say nothing else to the
stranger.

Second question - does that stranger have a license to use c? [My answer - I
think so, under the BSD, but they may not know it until they read the CD ROM.]


How would you answer these questions?

[ Reply to This | # ]

BSD license is all about attribution
Authored by: Anonymous on Tuesday, January 16 2007 @ 07:01 AM EST
I did not read the paper to the end. I think the author has some fundamental
misconceptions there.

1. The BSD license talks about distribution with or without modifications.
2. It does NOT talk about anything that specifies licensing of modified works.
F.e. GPL clearly states how modified works should be licensed.
3. If you include the writen text of the license in the source or binary where
the original code is used, you have met the requirements of the license. If the
resulting binary has an MS like EULA does not matter.

CONCLUSION: You have to give credit for the original code to the original
author. Source/Binary/Modified/Unmodified DOES NOT MATTER. One exception is that
you strip the copyright etc. from the distributed work, then you have no right
to use the code and you are breaking the license conditions.

COMMENT: Any OSS license has a virulent nature to preserve the rights of the
original author (attribution of authorship). So it has to carry over to all the
modified works. Either by verbatim inclusion of the copyright (BSD) or
restriction to the same license (GPL) as their requirement.

[ Reply to This | # ]

PJ: just a thought
Authored by: rsmith on Tuesday, January 16 2007 @ 07:14 AM EST
Have you thought to ask the creators of the license what their intent was?

---
Intellectual Property is an oxymoron.

[ Reply to This | # ]

The practical effect of this interpretation for existing projects is likely to be minimal
Authored by: Brendan Scott on Wednesday, January 17 2007 @ 04:14 PM EST
This paper is about discussing the effect of specific words considered in the
abstract - as I hope is clear from the paper's discussion. A number of comments
have asked about the effect of intent and common use. My responses on this
point have been that it can affect the license, but then I've wandered off into
a discussion of the words in the abstract or in the absence of context - which
is the focus of the paper. On reflection this is not an appropriate response
for me as it fails to give proper emphasis to some of the most practical
implications for people in this forum - so let me make some comments about the
practical effects of this argument on existing projects.

If you have an existing project under the BSD then the interpretation in this
paper will probably have no practical effect on you. There are two main reasons
for this. The first is that established projects are upfront in stating what
you can and can't do with the code. If the project has stated that its code can
be used or distributed in a certain way, it would be very difficult to argue
against this (in addition such statements would undermine some of the
assumptions in the paper). The second is that this interpretation is of no
value if the license is not enforced in this way and BSD participants are very
unlikely to do so.

I'm sorry I did not make this clear earlier while the thread was more active.

[ Reply to This | # ]

BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law
Authored by: Anonymous on Thursday, January 18 2007 @ 03:04 AM EST
You make a fundamental mistake in your analysis.

In the BSD license, the word "use" refers to, approximately,
"incorporation of the code, or some portion thereof, within another
work". This is not only the intent, but the only reasonable
interpretation.[1]

Therefore, the license *expressly permits* incorporation of the work, or a
portion thereof, within another work (the "containing work"). That
work, whether classified as a derivative work of the BSD-licensed code or not,
may be subjected to additional copyrights. These additional copyrights may not
permit redistribution of the containing work.


1) The license was written assuming U.S. law. Under U.S. law, copyright cannot
restrict what one does with a legitimate copy of a work, other than make copies
of it. Other definitions of "use" generally referring to things like
actually executing the code, which are simply not covered under copyright law in
the U.S. at all.

- mycroft

[ Reply to This | # ]

BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law
Authored by: Anonymous on Thursday, January 18 2007 @ 03:08 AM EST
Pursuant to my previous comment, I want to make this point very clear.

You cannot simply reinterpret a license under the laws of a different
jurisdiction. International copyright law simply does not work that way. You
must take into consideration what the license means in the jurisdiction in which
it was written. It seems to me that you have completely failed to do that.

[ Reply to This | # ]

BSD - The Dark Horse of Open Source, by Brendan Scott, OS Law
Authored by: Carlos Mundi on Thursday, January 18 2007 @ 01:11 PM EST
Is it just me, or is this one of the most exquisitely poorly written documents on the subject of software licensing? Australian and American variants of formal English are not so different as to disqualify me as an educated reader.

I am not a lawyer, but I have been involved with both commercial and FOSS software licensing for about a decade. My experience tells me that the refuge of 'legalese' is not the chief difficulty with this document. This is at best a first draft of an analysis, and I have to wonder what Mr. Scott's intent was in releasing it in draft form.

I do not dispute the validity of some of the questions raised by this document. Indeed, the FOSS community would do well to bring more qualified legal scrutiny to the underpinnings of our IP culture, including a full account of venues and jurisdictions. I do, however, wonder if the offered analysis of these questions might have at least a small measure of FUD as an objective.

[ Reply to This | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )