Tracy R Reed wrote:
This question doesn't make sense if it isn't about "accidental"
inclusions. If a GPL library happens to be the cornerstone of the code
then you have already made a conscious decision to keep it all in hour
forever or to release the code when you distribute it outside.
House. I knew what you meant. ;)
The distinction is as follows:
In software, the final artifact is the code. The code is the product;
the product is the code.
In VLSI, the final artifact is a chip or, if you prefer the final
digital artifact, a stream of mask data. The code is used to create the
final artifact, but is *not* the final artifact.
You don't know, a priori, what you are going to do with that artifact.
Will the foundry make a change? Will you subcontract to someone to make
a change and regenerate? Will you subcontract to someone to move that
chip to a new technology? Any of these actions result in a need to
transfer all tools used to generate the final artifact to someone
external to the company.
As such, the only solution is to avoid all GPL code.
For the BSD license to have made such a big difference are we to assume
that many companies are making changes to SPICE2 and distributing SPICE2
binaries outside of the company without releasing the source? What does
this have to do with the SPICE2 user base coalescing into a whole?
Sounds more like incompatible forking.
Absolutely. However, we again have a distinction between the code being
the end artifact and something else being the end artifact. In SPICE2,
the end artifact is an analysis, not code.
SPICE2 was a general circuit simulator. It works very nicely for
general circuits and fails spectacularly for some types of reasonably
common circuits.
I could take the SPICE2 code, and create a simulator that worked well
for one of those troublesome circuits. My input was a SPICE2 input
deck. My output was a SPICE2 analysis deck. However, my simulator
worked for a slightly different class of problems and I could sell it.
This started a network effect. The more people used the SPICE2 input
and output formats, the more they became a standard. Eventually even
IBM internal simulators had to support SPICE2 formats because they were
so pervasive. The format had enough internal "hooks" that you couldn't
move too far from the original code in implementation.
With SPICE3, Berkeley tried to grab some of the money by changing the
license. Result? SPICE3 never had any real uptake. All the commercial
companies went back to SPICE2 whenever they wanted to use code. This
was bad because SPICE3 had quite a lot of good algorithm and device
physics work put into it. However, it all languished. The SPICE3 input
deck format never really caught on. The output formats never really
caught on. Instead, a commercial version, HSPICE, became the new
standard because it was close to SPICE2 (the variables and knowledge
from SPICE2 were mostly useful for HSPICE) but gradually drifted away
from compatibility since SPICE3 takeup was not strong enough to pin it
down as a standard.
Some people have tried to change the SPICE3 license, but the standard
bureaucratic problems arise. Nobody wants to be the one to sign off on
a license change that somebody else might make money off of.
In addition, SPICE is an unusual case. It is a piece of code which has
existed and been useful for more than 30 years. There aren't many other
pieces of code which have that problem.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
