5 ms·

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 lear

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.

DannyBee 13y ago
I'm just curious why this was surprising. It seems fairly straightforward. Was the surprising part that someone wanted to put it in hardware?
- silentbicycle 13y ago
  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.
  - DannyBee 13y ago
    "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.
    - silentbicycle 13y ago
      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.
      - DannyBee 13y ago
        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.
Freaky 13y ago
Why not 2-clause BSD?
- papsosouid 13y ago
  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.
  - mhurron 13y ago
    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.
    - shawnz 13y ago
      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.
      - pyre 13y ago
        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.
        dlitz 13y ago
        > 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.
shawnz 13y ago
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-attribution-in-a-binary-only-distribution http://www.quora.com/Does-the-MIT-license-require-attributio...
- silentbicycle 13y ago
  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.
  - deleted 13y ago
    [deleted]
  - shawnz 13y ago
    > 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.

DannyBee 13y ago

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

silentbicycle 13y ago
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.
- DannyBee 13y ago
  "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.
  - silentbicycle 13y ago
    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.
    - DannyBee 13y ago
      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.

Freaky 13y ago

Why not 2-clause BSD?

papsosouid 13y ago
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.
- mhurron 13y ago
  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.
  - shawnz 13y ago
    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.
    - pyre 13y ago
      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.
      - dlitz 13y ago
        > 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.

shawnz 13y ago

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-attribution-in-a-binary-only-distribution http://www.quora.com/Does-the-MIT-license-require-attributio...

silentbicycle 13y ago
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.
- deleted 13y ago
  [deleted]
- shawnz 13y ago
  > 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.