How to Blow $100 Million

David Kuehling dvdkhlng at
Sun Sep 5 05:32:10 EDT 2010

Sorry for another long mail on this non-productive topic.  Short summary
for those who have better things to do with their time: you're (mostly)
right i'm (mostly) wrong, and I agree it's not that bad at all :)

>>>>> "Wolfgang" == Wolfgang Spraul <wolfgang at> writes:

> David,
>> Is that so hard to see?  You only get a license to: - _use_ object
>> code _created_from_THE_SOFTWARE_ to _physically_ implement the design
>> So what you do not get a license for is: - _modify_ object code -
>> use/modify object created using other (synthesis etc) software -
>> _use_ object code in non-_physical_ implementations, i.e. simulators
>> or whatever

> Where do you read that you don't get a license for these things?  

The license has to explicitely lift the restrictions placed by copyright
law.  Ok, I admit that one might read section 2 "modify" to include
"synthesized into netlist/bitstreams/whatever".  Then most of the
mentioned problems are gone.

> You are quoting from paragraph 3, which I believe was written to give
> you the right to manufacture. It says 'use to implement' because the
> entire paragraph is about manufacturing. You want them to add an "or
> modify" behind every "use", no matter what the entire sentence or
> paragraph is about?  

If sections 2 omits object code from the right to distribute (yes, maybe
that's a non-problem), then section 3 only adds a right to distribute
for "these devices" (i.e. hardware), then of course I'm looking for what
parts are not included in the rights to distribution.  I'm not
interested in the right to "modify" because that seems implied in "use".
However the right to distribute modified works is distinct from a right
to distribute "the devices".

> The object code can also be modified object code
> (it says 'or derivative work' - a term introduced in paragraph 2,
> which describes the rights to modification).

I read that as "code created from the Software using a derivative work
(as input)", or "code created from the Software, or a derivative work of
that code".  Reading it again under the context of paragraphs 1 and 3, I
think you might be right and this might allow any tools for physical
implementation.  They upper cased Derivative Work only here and in
section 2 before, maybe this is how they reference the previous section?

> In my understanding, Lattice tries to give you 3 rights, worded in 3
> different paragraphs:

> 1. use 2. modify 3. manufacture

> Each idea is expressed in one paragraph.  The second paragraph is
> about modifications.

Yes, reading it again and putting my paranoia aside, I agree that that
makes sense.

> You write:
>> What I'm still hoping for is to see more open designs that can at
>> least (partially) be compiled&simulated using open-source software

> I cannot see why you think they try to not give you a license for
> modifying their sources and let you compile and run them in
> simulators?  Paragraph 3 is about giving you the right to
> manufacturing.  

They explicitely reference "the Software" in paragraph 3, which is
defined at the start of the license to mean:

  '"Software" means the LatticeMico32 System computer program(s) other
  than the open source programs identified in Section 11 ...'.

That sounded suspicious.

> Paragraphs 1 and 2 are slightly worded towards 'distribution' only
> because (imho) that is by far the more meaningful thing to clarify,
> that you have the right to distribute their stuff. You are saying
> because they only clarify that you have the right to distribute their
> stuff, you don't have the right to run it in a simulator on your own
> computer? Sorry but I think that is really gross.

I won't have come to such conclusions, when the contract were presented
as a normal License, not an "EULA" i.e. without any agreement required
merely for /use/.  But w/ paragraph 1 given a broad right to "use"
anyway, I guess you're right and use is unrestricted, so simulation and
stuff is a non-issue.

> They do not specifically say that you have the right to keep both your
> eyes open when looking at the source codes. 

:) But then again, if copyright law contained a restriction about
opening my eyes, then yes I'd demand them to put a paragraph about that
in their license as well.


> Here's my take: The GPL is a software license. It talks about
> libraries, linking, executables, object code, etc. How this applies to
> 'object code' in an FPGA (typically called 'bitstream'), or even
> manufactured silicon, is not clear to me. 

A problem I sometimes think about, too.  

> If I take some GPL licensed Verilog, and I use it to manufacture a
> chip, in the process I may mix in some proprietary IP. Even the gate
> design can be and is copyrighted by foundries. Am I not allowed to do
> this? If I add proprietary Verilog sources before synthesis, so what?
> Does that mean the resulting IC 'links' a GPL and proprietary part? Is
> it an 'aggregate' as defined in the GPL?

> And while we can all have opinions on this, what do the creators of
> the GPL say? Who will try to enforce some of these things to make them
> real?

> There are things in the Lattice license I don't like either, and I
> agree there might be GPL compatibility issues, maybe more so as long
> as we are still talking about bitstreams (=object code?). I think the
> GPL looses most of its meaning when it comes to manufacturing silicon.
> Personally I dislike the export controls the most, I'm a global
> citizen and don't understand why citizens or residents of Syria, Iran,
> Cuba and what not should be excluded. Reminds me a bit of the early
> SSL days...

I'm not sure whether the GPL is that bad after all.  Most of the
proprietary verilog sources you metion would be covered as "system
libraries" under GPL3 section 1.  And what makes the physical silicon so
much different from a manufactured ROM that contains a GPL executable?

> Today, if we lean back a bit, and think about what Lattice really
> tried to say, I think they did in fact want to open up this technology
> to the point that others could use, modify, and manufacture chips with
> it.  If we are incorporating IC logic from a 3rd party licensed under
> GPL, and they have a problem of being mixed with Lattice sources, they
> should come forward. It would help everybody.  We could clarify the
> meaning of the GPL in bitstream and silicon land, we could approach
> Lattice or the FSF asking for clarifications.

That sounds reasonable.  I somehow feel stupid for my overly paranoid
reading of their license, stealing some time from the more productive
people at Qi hardware :)

But then, maybe it was good after all that some of these points were

> I plan to talk to Lattice at some point anyway, I would like to
> understand why they opened up their sources in this way, whether/how
> they can guarantee that their stuff is patent-unencumbered. Whether
> they have any plans in investing more time into the open part. Whether
> they can remove some things like the export control paragraph, or
> whether they can adjust or clarify some terminology to be more in line
> with the software-centric GPL terminology.

Maybe you could then ask them to have their license approved by OSI?
This might keep people like me from attempting to read and understand
their license.

> For me (well, non-lawyer), the best would be if the license just gets
> shorter, more BSD style. The shorter it is the less room for
> misinterpretations, on both sides. Of course, a lawyer would probably
> feel the other way round, and add a lot more words to make it more
> clear... :-)

What obout the OLL (one-line license) :)

  "Get it, use it, share it, improve it, but don't blame me."


GnuPG public key:
Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the discussion mailing list