Why a BSD License Might be Wrong for your Embedded Open-Source Project | Hacker News Reader

Why a BSD License Might be Wrong for your Embedded Open-Source Project

spin.atomicobject.com

36 pointssilentbicycle39 comments

Do you know, or necessarily care, who supplied the brakes in your car?

Yes?

That's probably not the best example since many people actually change the breaks in their car, whereas I believe the point of the OP was that this is a library that is compiled into the final product.

That said, I don't think this is evidence that the BSD license is "broken" in some way. It simply requires that the user of your code cite that they used it. (I believe Microsoft failed to do this for a few years for their sockets code). Just like when you quote another text, you need to cite your source; the BSD license requires the same. If that's not your intention, don't use it, but don't blame the license.

Nobody said the BSD license is "broken", nor did they blame the license for anything. He simply pointed out that the license is not appropriate for what many people actually want, and pointed to licenses that are appropriate for those goals. If you want a totally free license where people can do anything, but you still hold copyright, then you want ISC/MIT/zlib, not BSD. Many people do not realize this.

I did not realize this and I am happy that I know now.

Author here. I don't think the BSD license is broken, just that the legal implications of that clause were surprising to me, and I thought I'd share what I learned.

I'm still likely to use the BSD license in other contexts, but will probably default to MIT/ISC/zlib specifically for embedded libraries.

I'm just curious why this was surprising. It seems fairly straightforward. Was the surprising part that someone wanted to put it in hardware?

It is straightforward if you read the license closely with hardware in mind, but I've been releasing stuff under the BSD license for much longer than I've been doing embedded development. I thought I knew what the BSD license meant, but my understanding of it hadn't considered the implications for hardware distribution, and I imagine that's true for most people.

As interest grows in open-source hardware and embedded development, it's something worth drawing attention to. Not every vendor will mention the license, some will just shrug and move on.

"I thought I knew what the BSD license meant, but my understanding of it hadn't considered the implications for hardware distribution, and I imagine that's true for most people."

Right, and no offense, but your solution was then to just solve this specific problem rather than ask about what other legal implications you were missing.

For example, ISC specifically only mentions "this software". If you were to ISC license everything, but also include say, IC layouts, they arguably would not be covered.

Worse, IC layouts ("mask works") are, in the US, a completely separate set of rights that are arguably not covered at all by the "use, copy, modify, and distribute" part of ISC (and have the software issue).

Basically, there are a large set of issues with current licenses and open hardware, and you identified one, and then immediately switched to some other license without considering the other implications as well. It may well turn out for your particular project there are no other interesting implications, but as you say "Details like these are easy to gloss over, but they can have a major impact on whether open-source projects can actually be used by others."

With no offense meant (really), I don't think what you've demonstrated is a good example of handling that well.

My focus on licenses so far only really concerns making it easier for vendors like the OEM to use my library. When I open-source hardware layouts, I now know I need to investigate license details for hardware-specific language. (I don't have any control over the hardware in this case.) I don't mean to imply that I've fully solved the issue yet, just to draw attention to it being even more complicated than expected.

I've also noticed that, while the ISC doesn't specifically address binary distribution the way the BSD license does, the zlib license specifically notes that its copyright conditions apply to source distributions, so it seems like an even better choice in this specific case.

My point in general was that it seems you are still just attacking this one issue at a time, instead of realizing "oh, maybe there is a lot of other things I don't know", and asking for semi-professional help from someone.

By doing this, you make the problem worse, not better.

I'm not suggesting you hire a lawyer, there are actually plenty of places with qualified people often willing to help you figure out what issues you will hit.

Why not 2-clause BSD?

Because the second clause is the problem, not the third. The third clause in 3 clause BSD is:

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

Remove the offending clause and have a two clause BSD license with clauses 1 and 3.

It's a license not an array, you can cut from the middle.

The problem is that "2-clause BSD" is already a generally accepted term for referring to the BSD license with clause 3 removed. Such a license is effectively equivalent to the MIT and ISC licenses, though.

You have a "2 clause BSD" licence. What you call the resultant license is irrelevant. What matters is the text of the license. Heck, you could call it a "modified 3-clause BSD license, please see LICENSE" if that's what you want.

> You have a "2 clause BSD" licence.

Come on, is saving face that important to you? "2-clause BSD" already has a well-accepted meaning. You might as well have said that GPL refers to "Gary's Perfect License"; After all, it's a GPL.

I only commented because of the attitude that removing the second clause from the 3-clause BSD license was not an option because we already have a 2-clause BSD license.

Fair enough. This thread started with "Why not 2-clause BSD", and I understood your comment as defending the use of "2-clause BSD" in a non-standard way.

But nobody suggested it wasn't an option. That is the point.

Two clause BSD is the name of a license. A different license would not be two clause BSD, even if it has two clauses.

If I'm not mistaken, the MIT, ISC, zlib, AND GPL licenses all have the same clause which caused you to reject the BSD license. Has the OEM in question accepted the new license?

EDIT: Sorry, it appears the zlib license differs in that the clause only applies to source distributions and not binary distributions.

EDIT2: I can't find a legally rigorous citation, but here's a Quora discussion which seems to agree with me: http://www.quora.com/Does-the-MIT-license-require-attributio...

The MIT, ISC, and zlib do not seem to, and the OEM is happy with the ISC. I didn't check the GPL, because its overall design conflicts with my intent.

Here's the ISC license, in its entirety:

    Permission to use, copy, modify, and/or distribute this software for any
    purpose with or without fee is hereby granted, provided that the above
    copyright notice and this permission notice appear in all copies.
 
    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.

I don't think the "appear in all copies" applies to binary distribution, or at least there's more room for interpretation because it is far less explicit. IANAL, but if it did, there would likely be a LOT of violations - people typically don't embed the license as a string in compiled libraries. (That would probably be a disincentive for using the GPL, which is several times larger than my compiled library!)

Edit: The zlib license explicitly says "source distribution", and does not apply to binary distributions. Good to know.

> people typically don't embed the license as a string in compiled libraries

Tradition dictates you include the license as a separate file in the binary's directory, or in the case of a consumer hardware product, on the last page of the product's manual.

> I don't think the "appear in all copies" applies to binary distribution.

That's a strange interpretation. Why do you think that?

> IANAL, but if it did, there would likely be a LOT of violations

There are a lot of violations. Many copyright holders don't pursue them, but without an enforceable license, you're relying on upstream copyright holders' ignorance or their goodwill.

If you look at the iPhone for example, there is a menu where Apple lists EVERY single last license that applies for any software they ship.

Settings > General > About > Legal > Legal Notices

Where necessary reproducing the licenses isn't that difficult, either in documentation or within some part of the program. If your customers are purchasing something from you as an OEM you should notify them that they need to put certain statements in their documentation.

Blizzard legal team when writing the credits for Starcraft 2 clearly interpreted the MIT license in such a way that the whole notice needed to be included with each binary copy. The license show up several times, as well as bsd (2,3, and 4 I belive), lgpl and others.

This is not that uncommon. e.g. many Broadcom SoCs uses various code from opensource projects - Broadcom doesn't sell to end users though.

They publish a (small) document to their customers detailing what they have to do as they retail the end product using this particular chip. Which licenses they have to reproduce in documentation and which links to place there pointing to the original source code where that's required.

If that's a burden you do not want to place on the customers - indeed, you need to be careful about the selected license.

I don't see why this is a problem. The manufacturer of the hardware is the only person bound by the license since they're the only people copying, the only people who need to have the software licensed to them. They're bound to give a copy of that notice to anyone who buys their stuff, but nobody downstream has to care, they're protected by the Doctrine of First Sale[1]. Unless the author lives in a country where that doesn't apply.

[1]https://en.wikipedia.org/wiki/First-sale_doctrine

I probably cannot discuss the specifics of the vendor, but I don't know if First Sale applies in their country. I'm not a lawyer, and their lawyers brought it up as a potential issue, so I'm inclined to take it at face value.

Why not just put stuff into the public domain?

The "public domain" designation has its own problems, nicely summarized on Google Code (https://code.google.com/p/support/wiki/FAQ#Can_I_host_code_t...).

In particular, Dr. Richard Hipp (SQLite's main author) has talked about problems that came up from releasing it into the public domain. He eventually created a second license specifically for companies in places that didn't legally recognize the public domain, and wanted to make sure they were protected from liability.

Licensing is complicated.

Thanks for the link.

CC0 addresses these problems with "public domain"; its intent is the most permissive license that's legally possible (plus, in jurisdictions where it is possible, actually placing the work in the public domain). Unlike the other Creative Commons licenses, it it suitable for source code.

( http://wiki.creativecommons.org/CC0_FAQ , https://creativecommons.org/choose/zero/ )

I hate paperwork, but I suppose that providing a document with all the copyright notices along with the car, can't be that bad.

It was never my intention that people who use my open-source library complicate their supply chain by pushing additional work onto their customers.

The paperwork wouldn't necessarily just mean slapping a post-it™ note on the product, it could involve paying for lawyers, translators, and so on.

As someone who manages commercial software development projects (also for embedded devices) I can tell you that it is a royal pain to manage the copyright notices. It is a list that has to be created, maintained, updated and has to make its way into the final product or its documentation. You also have to manage copyright notices from software shipped by your partners.

While you do this, your programmers will just drop in another library ("But I've checked the license, it's fine, it's BSD!") without telling you. And that library will have dependencies.

Overall, if you want to do this right, it's a major pain, for very little actual gain (who reads these copyright notices anyway?).

If you have any other recommendations for making this process smoother, please let me know. I want people in your situation to be able to use my libraries without these irritations. (Author of the post.)

The only thing that comes to mind is a unified standard for copyright statements. If I could be sure that there is a file called COPYRIGHT.statement in every source repo, containing a single line of text that I should include in the documentation, it would be a huge step forward.

Unfortunately, this would require agreeing on a standard and having people follow it, so I'm not keeping my hopes up.

Don't you already have rules related to common licenses like MIT, BSD, LGPL or GPL? Also wouldn't putting all the notices in a common directory and concatenating them at the end be enough? For example the webkitgtk-1.10.2 package (from Fedora 18) has the following files:

- Source.JavaScriptCore.COPYING.LIB

- Source.JavaScriptCore.icu.LICENSE

- Source.JavaScriptCore.THANKS

- Source.WebCore.icu.LICENSE

- Source.WebCore.LICENSE-APPLE

- Source.WebCore.LICENSE-LGPL-2

- Source.WebCore.LICENSE-LGPL-2.1

- Source.WebKit.LICENSE

No doubt a bit of a pain, but clearly it's manageable and something the industry has come to grips with, because it seems like every random device I own has some menu somewhere that gives you a lonnnnnnng list of FOSS copyrights...

Reply on news.ycombinator.com