Hacker News Reader

Comment by hvs | Hacker News Reader

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.

View on HN

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.

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.

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.

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

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.

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

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.

Reply on news.ycombinator.com