3 ms·

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

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.

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.