Hacker News Reader

Comment by wrycoder | Hacker News Reader

I was more interested in the Silice project above:

https://github.com/sylefeb/Silice/tree/draft

Me too. I was particularly hopeful that they would explain why they decided to not go with systemC as it seems to solve a similar problem but I couldn't find anything.

https://en.wikipedia.org/wiki/SystemC

Hi, Silice author here. I cannot provide a detailed answer as I am not familiar enough with SystemC. I started Silice as a "quality of life" (in the video game sense) thin layer above Verilog, hoping to obtain something that would be more enjoyable to write with. I'd like this to be true both for getting started with FPGA, but also when describing advanced designs with efficiency concerns in mind (LUT count, max perf, hardware specificity such as DSP blocks, etc.).

In many ways Silice is very simple. Just a thin abstraction layer with helpful syntax helpers (groups, interfaces, pipelines, fsm), automating some checks and performing simple optimizations (e.g. flip-flop pruning). But please see the README for all details.

The spirit in which I am developing Silice is "I hope you'll find it useful" and absolutely not "this will be the definitive HDL". First, I am surely not qualified enough to imagine achieving such a goal, and second I am a big believer in having various tools for various problems and various styles.

So I hope you'll find it useful :) I am taking great care in providing a build system to make it easy to get started both in simulation and real FPGA hardware. This relies on many other great projects: yosys, nextpnr, edalize, openfpgaloader, verilator, icarus, ...

Also, Silice comes with fun examples! https://github.com/sylefeb/Silice/tree/master/projects

Thanks for the pointers! I'll definitely take a look.

It looks interesting enough, but I see that it's AGPL 3.0 licensed. AFAIK, the perceived toxicity of that license makes it impossible for use in a commercial setting?

There's always the option of paying someone who wrote the thing you need to give you a nicer license

I like to learn new stuff by doing personal projects, but since there are so many things to learn, I select those that, one day, might benefit me professionally as well: as a consultant, to help me with perform some task at work more efficiently, etc.

Most new languages that gather some kind of following get their start outside a commercial environment.

If a tool has a license so toxic that many companies (1) simply rule out their installation on company servers or company laptops out of principle, I move on and select something else to learn.

> the thing you need

The license makes it so that I'll never know whether I need it or not.

(1) Google is one of them: https://opensource.google/docs/using/agpl-policy/

I'm delighted to hear that you will be writing a clone of this and will release it as MIT or BSD license due to your strong ethical stance.

This is great news. Both projects will improve now as they can now bounce ideas off each other.

Thanks for sharing! Your brand new account is off to a good start!

Thanks! Its because I have such great examples and mentors!

Hi, Silice author here. I picked the AGPL 3.0 knowing it is on the strict side of the spectrum, but not thinking it would be 'toxic'?

If you have some pointers on this I'd like to learn more. In particular, I'd like Silice to be under a GPL style license (so that everyone benefits from improvements), but also to ensure that what is produced with Silice (designs coming in/out of it) is not 'contaminated' by the license.

There's a related issue in Silice github on this: https://github.com/sylefeb/Silice/issues/106

Hi,

I love your work and the examples. The Doom example is great!

A search for “AGPL toxic” has a fair number of hits, both in favor and against. I honestly have no clue who to believe…

I’ll be using Google here as an example because they openly lists their internal open source policies, but other companies have similar rules: https://opensource.google/docs/thirdparty/licenses/

Google prohibits SW licensed under AGPL not only on their servers, but even on employee laptops.

They fear contamination and forced release of their internal IP, because, compared to regular GPL licenses, the AGPL has some language in it that makes it problematic making those tools available on a network.

This may be an overreaction on their part, but I’m not in a position to argue that case.

The comment on your GitHub issue, that generated Verilog isn’t covered by the license terms, is understandable, but without a real license it’s probably only just that, a comment, and even if it provides legal cover for generated code, it still doesn’t matter because it doesn’t change the blanket ban of AGPL licensed tools.

Google does not have such strong objections against GPL3, which differs from the AGPL3 in just one paragraph.

Thanks for the feedback and pointers, I'll be looking into both issues (AGPL and the question of generated code).

I think 'toxic' in the case of AGPL means that companies who would like to run privately-modified versions of your AGPL software on their servers for end-users to use (remotely) don't want to share their changes.

If your priority is strictly that you want everyone to benefit from improvements that are made, AGPL isn't toxic.

On the other hand, it might limit what improvements are made in the first place, because companies that don't want to share won't adopt the software and make those improvements.

So the dilemma is one of priorities. If you want widespread adoption by companies, you have to license in such a way that companies can keep private modifications, because that's their priority. (Unless they are an open source company, and I would be surprised if those have a problem with AGPL.)

There is a secondary dilemma where companies worry about where the line is between 'private modification' and 'mere aggregation'. It's understandable that companies who think their crown jewels are the network services they provide, would worry that using AGPL software as part of their services might be found to be so closely related to the AGPL software that it's a derivative of it, making the whole thing is subject to AGPL release terms. Especially if engineering gets a bit sloppy about copying and pasting.

Some companies ban GPL software, not just AGPL.

Your assumption that a company’s priority is to not share is a possibility, but it is a worst case one, and one that is IMO less of a concern for a programming language: keeping bug fixes or even new language features to themselves may very well be a net negative. A buggy reference language implementation for external users will turn them off from using it, and make it harder to hire experienced users or benefit from improvements by others.

For such a case, the fear of using AGPL is much more likely one of accidental contamination, such as an employee copying a piece of AGPL licensed code into a completely different, unrelated project.

There's a lot of FUD against AGPL. I suspect that's because companies with deep pockets don't like it -- for reasons that are entirely by design of AGPL and simply s matter of preference.

The only toxicity here is from people who call that "toxic".

For your choice, you need to ask yourself: if your project were to be used as part of a web service by a company which then doesn't share the changes they made to your project, would you be okay with that?

If the answer is "no", then AGPL is the right choice. Otherwise, go with GPL.

In practice, your project doesn't seem the kind of thing where I expect substantial use in a web service. I mean, perhaps there's going to be a Godbolt of HDLs one day? But I guess it's unlikely to come up in a significant way, in which case the whole web service issue just doesn't matter and therefore GPL is the "safer" choice.

Reply on news.ycombinator.com