Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Linux of the hardware world

Why a permissive licence then? Doesn't that make it too easy for 3rd parties to take your design and slap on some vendor lock-in (e.g. via "secure boot")? Neither does it protect against EEE.



The GPL family of licenses are complex legal instruments which really don't apply in a sensible way to chip designs. LGPL has previously been used in the OpenRISC community, but the 'library' boundary isn't really clear when it comes to hardware. I think there's definitely space for a hardware copyleft license that clearly defines the boundary (e.g. an IP block), but it doesn't exist currently. Strong copyleft like GPL just isn't going to work for ASICs without carefully chosen exceptions, given the need to work with proprietary process design kits. I think projects like LLVM and FreeBSD show that a copyleft license isn't a pre-requisite for building a strong community of contributors, including from industry.

This piece from Andrew Katz is a good read http://www.ifosslr.org/ifosslr/article/view/69/131 or else the (length and inconclusive) discussion about GPLed HDL designs at last year's ORCONF https://www.youtube.com/watch?v=JgRBDuZQsFg https://www.youtube.com/watch?v=UOZkiOtmHEQ

Secure boot is a useful feature, but definitely one that can be abused to limit a user's freedom. I think a copyright license is far too blunt an instrument here - instead certification schemes (e.g. FSF's Respect Your Freedom) make more sense.


> The GPL family of licenses are complex legal instruments which really don't apply in a sensible way to chip designs.

GPLv3 was designed with chip designs in mind, and the FSF has an article about it[1]. I'm not a lawyer (though I do cosplay as one on the internet), but I would assume that the FSF's intentions would've resulted in a license that was applicable to chip designs.

> Secure boot is a useful feature, but definitely one that can be abused to limit a user's freedom.

GPLv3 doesn't stop secure boot from being implemented, it just stops it from being used to take away users' freedom ("Restricted Boot" like Windows 8 ARM laptops that don't allow you to install anything other than Windows).

> I think projects like LLVM and FreeBSD show that a copyleft license isn't a pre-requisite for building a strong community of contributors, including from industry.

I don't think people are worried about community formation. The main concern is that someone forks RISC-V to create a proprietary chip design and then fools users into thinking that it's a free hardware design. Or they steal the market share that RISC-V would've had.

[1]: https://www.gnu.org/philosophy/free-hardware-designs.en.html


That article mentions FPGAs, but doesn't discuss any of the issues with taping out an ASIC design. Specifically, the use of a proprietary and highly commercially sensitive process design kit, and the likely need for other IP to make a realistic chip (e.g. PLLs). I'm not at all against copyleft, but for lowRISC we felt that traversing uncharted territory in licensing would just be too ambitious. Additionally, one of the key components our design is derived from (Rocket) was already under a permissive BSD license.

I understand how GPLv3 and secure boot works with software, I was unclear as to how those clauses might apply to a hardware design. I fully agree that 'restricted boot' is a terrible situation for consumers.


I'd like to highlight the fact that copyleft licensing also creates license incompatibility issues that prevent its use in many open source projects, and the same would apply to open hardware projects in the future. There are those (particularly certain systems-oriented luminaries) who have taken to referring to copyleft licenses as "anti-collaboration" licenses for this reason, and while I try to avoid adopting such snarky terms for my own use, it's worth noting the strength of opinion and specific problems relating to copyleft licenses.

As for me personally . . . I'm an open source developer and advocate with a history of writing very pro-open-source articles for a (somewhat?) major online tech publication, and I am one of quite a few people I know who refuse to throw any significant code into the legal compatibility black hole of copyleft licensed projects. I would, therefore, be considerably less likely to show interest in RISC-V if it was copyleft.

I've also noted that in recent years new copyleft projects (except in particular niche areas where people apparently haven't heard of non-copyleft open source licenses) tend to suffer problems with rate of popular uptake. I'd hate to see that happen to such an obviously excellence-aimed open hardware project as RISC-V.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: