4 ms·

Used to work at Siemens. Their open-source policies were onerous from a consumption point-of-view. Every revision of every approved open-source product had to b

by abawany 10y ago

Used to work at Siemens. Their open-source policies were onerous from a consumption point-of-view. Every revision of every approved open-source product had to be reviewed by their open-source legal hawks to ensure that nothing had changed. I don't remember their mandatory training on open source but I especially don't recall any encouragement to publish open source projects and to contribute to them. Great company but it certainly treated open-source with a sentiment that I can only describe as fear.

nickpsecurity 10y ago
That's definitely bad. One of my ideas for Mentor didn't even need open-source, though. The idea was that they enabled export of some intermediate steps in RTL synthesis or optimization so customers could equivalence check them. I don't use their stuff so forgive me if they already do this & I just didn't know. Anyway, the initial, intermediate, and final RTL's could be checked both with testing and formal tools that were open-source. All the magic behind making those steps happen can remain proprietary. Likewise, do some OSS stuff for gate-level testing and material checks to run after Mentor's. Analog stuff done similarly as there's already diverse proprietary and FOSS tools for SPICE, etc. So, they can differentiate on verifiability while still keeping the trade secrets that make them the most money. There is risk that the intermediate steps could let people reverse engineer some of the magic. However, that's low given people can already analyze their binaries when running those steps and academics [like Mentor funds] come up with better ones all the time. The next step in my Mentor-oriented plan was same buyer acquiring eASIC so the verified, hardware designs could be practically thrown into initial production at little cost. Key IP that almost everyone needs they get for free so long as they use eASIC for the HW design for X years or iterations with a fair, royalty agreement. Interested in what people in hardware market think of these schemes?
pjmlp 10y ago
I worked at another one of the similar field and the policies were quite similar.

by abawany 10y ago

nickpsecurity 10y ago

That's definitely bad. One of my ideas for Mentor didn't even need open-source, though. The idea was that they enabled export of some intermediate steps in RTL synthesis or optimization so customers could equivalence check them. I don't use their stuff so forgive me if they already do this & I just didn't know. Anyway, the initial, intermediate, and final RTL's could be checked both with testing and formal tools that were open-source. All the magic behind making those steps happen can remain proprietary. Likewise, do some OSS stuff for gate-level testing and material checks to run after Mentor's. Analog stuff done similarly as there's already diverse proprietary and FOSS tools for SPICE, etc. So, they can differentiate on verifiability while still keeping the trade secrets that make them the most money. There is risk that the intermediate steps could let people reverse engineer some of the magic. However, that's low given people can already analyze their binaries when running those steps and academics [like Mentor funds] come up with better ones all the time. The next step in my Mentor-oriented plan was same buyer acquiring eASIC so the verified, hardware designs could be practically thrown into initial production at little cost. Key IP that almost everyone needs they get for free so long as they use eASIC for the HW design for X years or iterations with a fair, royalty agreement. Interested in what people in hardware market think of these schemes?

pjmlp 10y ago

I worked at another one of the similar field and the policies were quite similar.