toybox

About Download Development

Toybox is released under the following "zero clause" BSD license:

Copyright (C) 2006 by Rob Landley <rob@landley.net>

Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted.

THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

The text of the above license is included in the file LICENSE in the source.

Why 0BSD?

As with CC0, unlicense, and wtfpl, the intent is to place the licensed material into the public domain, which after decades of FUD (such as the time OSI's ex-lawyer compared placing code into the public domain to abandoning trash by the side of a highway) is considered somehow unsafe. (But if some random third party takes public domain code and slaps some other license on it, then it's fine.)

To work around this perception, the above license is a standard 2-clause BSD license (the from OpenBSD) minus the half sentence requiring text copied verbatim into derived works. If OpenBSD's 2BSD is ok, then our 0BSD should be ok, despite being equivalent to placing code in the public domain.

Modifying the license in this way avoids the hole android toolbox fell into where 33 copies of BSD license text were concatenated together when copyright dates changed, or the strange solution the busybox developers used to resolve tension between GPLv2's "no additional restrictions" and BSD's "you must include this large hunk of text" by sticking the two licenses at opposite ends of the file and hoping nobody noticed.

This "stuttering" is the common failure mode of public domain adjacent licenses (BSD, Apache, and so on) when used in combination or in long-lived projects. How one would enforce such a multiply concatenated result in court is an open question. (How one would be sure they weren't exposed to liability due to a disagreement over the definition of "supporting" materials is another fun gotcha.) Public domain equivalent licenses avoid this problem entirely: different license text can collapse together because derived works are not tied to a specific wording of a specific license, and does not place bookeeping requirements on the recipient. The permission grant exists upstream, and the internet makes that available to everybody; how or if to propogate that permission grant into other projects using portions of this code is left up to the recipient. Having a LICENSE file in your source tarball is still a very good idea, but the license itself requiring it is subtly problematic, so ours doesn't.