Xilinx Legal

My wife was a paralegal in the past couple of years till she realized she really didn't like working with Lawyers... Anyway, one of her daily tasks was to print out email that had come for each of the lawyers in the office. They apparently couldn't figure out how to read email on their computer, they needed someone to give them a hardcopy of it - that being the case, I don't know how you'll get lawyers to use usenet ;-)

So, to summerize the legal problem as I understand it so far:

1) Xilinx people (presumably AEs) have said that you can use XDL (including parsing it) so long as you don't violate the EULA - and then they say that using XDL to target Xilinx parts will not violate the EULA. 2) Others (fpga-toys) say NO, you can't even parse XDL without violating the EULA because to do so requires you to know the format of XDL which is not published anywhere and is only available by running the xdl command and looking at the resulting file (and since the xdl program is covered by the EULA it's output is also covered). So you can't freely distribute a program that parses XDL. You could parse it with your own program, but you wouldn't be able to legally distribute the parser to others because they might not be under the EULA.

(there are other claims made by fpga-toys related to the exclusive nature of XDL use not being compatible with open source licenses like GPL - but for now let's stick with the first two issues and get back to this one later)

It seems that I recall somewhere in one of these threads that someone from Xilinx mentioned an appnote about XDL. If one existed, that described the format of XDL wouldn't that constitute a public documentation of XDL which is not covered by EULA? However, I could not find such an appnote on the Xilinx site when I searched for it. If such an appnote exists, where is it?

If the appnote doesn't exist, would it be possible for Xilinx to create one? It would need to describe the XDL format and then be published on the Xilinx site. It seems to me that this would go a long ways towards resolving the legal ambiguity of creating open source tools around XDL. Since the XDL format itself looks quite simple, I would imagine that a document like this wouldn't need to be very long. I would also bet that the software group within Xilinx already has documention that would work.

How about it Xilinx folks? Can you get permission from your lawyers to publish an XDL spec on your website? If you can, that would probably resolve the issue. If your lawyers say no, then I suspect it wouldn't help for me (or any other outside entity) to ask and I would also be hesitant to create any open source XDL tools because of the potential legal issues. It's an easy question for you to ask your lawyers and the answer would tell us a lot.

Phil

On a sunny day (Mon, 30 Jan 2006 12:56:47 -0800) it happened Austin Lesea wrote in :

OK, in that sense I can live with it. I hope that we, as non lawyers, will not be creating a problem where it is not, or not supposed to be. Since I have no intention of using the bitstreams webpack generates for anything else then Xilinx devices, I think I am in the clear :-) Regards Jan

Yeah, nobody's looking to do that because, like you say, it wouldn't make sense.

Austin,

Please see my other post made just a few minutes prior to this one:

Basically I asked someone at Xilinx to ask your legal dept if you can publish an appnote that shows the format of XDL on your website. If you can do that, then I think we're fine. If not, then it won't help for outside entities (such as myself) to ask your legal dept if it's OK if I develop open source tools that parse and manipulate XDL. If your lawyers tell you No then that would give us an indication of whether or not we need to spend anymore energy pursuing this route. If your lawyers give you the green light, then I think we're fine.

To reiterate: The only way we can build an XDL parser at this point is to look at the output of the xdl program. If we were to build an XDL parser and then release it freely it looks like we violate the EULA. We're not asking for XDL to be put under an open source license (at least I'm not); we're asking that the XDL format be made available somewhere on your website such that the format itself is available outside of the EULA. Then, if I'm understanding the legal arguments made by fpga-toys correctly, we _could_ create an XDL parser and release it freely (the XDL parser under open source) without violating the EULA.

Phil

Yes, I've been thinking exactly the same thing. I don't see where requiring Xilinx-only usage is all that big of a deal, AND practically speaking you don't give up much at all since most retargetting should probalby be done at some higher level anyway.

Really, I think all we need at this point is for someone at Xilinx to get permission to put an XDL file format spec on their website somewhere as an appnote. If that can be done, then I think we're good to go.

Phil

If the XDL file format is available on the Xilinx site they wouldn't need to RE our tool. At that point if some 3rd party creates an XDL->[Altera|Atmel|...] tool, then it's the 3rd party's problem, not ours.

But again, practically speaking I really don't think that it's the best place for doing design retargetting.

Phil

don't

The loss is not practical, so much as philsophical. There is a critical distinction between "Open Source" software and "Free" software.

"GPL + Xilinx only" could be open source, but it is definitely not Free.

Some developers may not care, for others it could be a show-stopper.

John

Still, it's essentially impossible to do this and have the tool be open source. If the code is open source it can be published in a book; that book can be purchased as a physical object and under the first sale doctrine used as reference material to guide any effort someone wants - including trying to make chips that compete with Xilinx.

Yes, that would simplify things.

Another option is that some of the applications (reconfigureble computing for example) might not need the whole thing to be able to show results promising enough to warrant consideration of expanded releases in the future. If I understood the complaint with high level interfaces for that application, it's that the authors of these experimental tools want to produce very low level, repetitive structures, but modern synthesis tools take their carefully crafted output and munge it by in essence trying to figure out what the silly human wanted so that they can optomize it with trade secrets - which in this unique case is counterproductive.

What if just enough of the format of XDL or something similar were released to expose a low level "programming" interface that's sort of a gigantic version of a very primitive FPGA architecture, either without most of the modern improvements other than size, or without anything but the most basic ways of using whatever advanced functional blocks are included in the release?

It seems if something like that could be released, and people demonstrated something interesting with it that hinted at chip sales, maybe cases could be made for releasing other information.

To do RubyHDL ... IE ... produce netlists, you also need the objects publicly defined that you need to build a netlist describing connections with.

Also, the EULA doesn't offer distribution rights to others bound by it. That will take a separate agreement with Xilinx legal where you take on some personal liability for your RubyHDL's distribution and use.

Sure ... I think we have more than hashed this to death :(

It's probably better at this point to lobby it as a business decision with sales/marketing and real customers.

I think that the issue of what's open source and what's propriety in Xilinx tools is not very well defined. Three licenses pop up at the start, The Xilinx "shall not" and 2 GPL "you can as you please" Xilinx don't distinguish what license covers what programs/libraries etc. Something GNU (and any lawyer) will say you must make clear.

I would also suggest that why even bother with XDL in the first place.. sure its great for Xilinx... but make a common object language. This can be compiled into either Xilinx XDL.. which can use the Xilinx Tool chain to build an FPGA.. or into Altera to let Quartus do its thing. or any other FPGA Vender. The main thing is what's in your source. No Xilinx Libraries, no Altera, no nothing except GPL. In fact.. that's what Mentor and others do already by using EDF files. Then there aren't any legal issues ? Right ? XDL is then only used for Xilinx's :-)

Simon

Austin Lesea schrieb:

LOL, ROTFL.

Xilinx owns the bitstream? And Microsoft owns my PhD thesis because I typed it in Word? Wait, I created a PDF with Acrobat, so the PDF is owned by Adobe. But it was created from a file owned by Microsoft, so now Microsoft needs to sue Adobe.

Sorry Austin, that is complete nonsense. Xilinx can not own a file that contains IP both from me an third parties. A shared ownership might be possible but I really doubt that.

There was a case about two years back were a computer game manufacturer claimed that it owned level files created by an editor delivered with a game. They lost the case.

Please have you legal department read up the first sale principle and have them think again whether they can restrict what a private customer does with the output of the tools. And after they checked that for the US, have them recheck for scandinavian countries.

Kolja Sulimma

BTW: If I typed my HDL in the ISE editor, can I still publish it under GPL (according to your legal department)

The viral clause must still apply to the reverse engineered tool; it has to define reverse engineering as a form of "use".

- Brian

Ed McGettigan schrieb:

There is no mentioning of the EULA. Apparently there is a special law in the US to protect semiconductor masks and the court treated the bitstream as a mask work. The EULA can still be completely invalid.

I just skimmed the law, and I still do not see how Altera could possibly have won. It says

"the ?owner? of a mask work is the person who created the mask work" If I start bitgen, I am generating the mask work and not altera. I use a tool to do it, yes, but surely I am still the creator?

But even if Altera was the owner, it goes on: "the protection provided for a mask work under this chapter shall commence on the date on which the mask work is registered under section

908, or the date on which the mask work is first commercially exploited anywhere in the world" Surely Altera did not register my bitstream and did not exploit it comercially before I sent it to Clear Logic?

Then the law goes on, and explicitely allows to reverse engineer the mask (bitstream) to create your own bitstreams with the information obtained:

§906 (a) 1 and 2: "it is not an infringement [...] for [...] a person who performs the analysis or evaluation described in paragraph (1) to incorporate the results of such conduct in an original mask work which is made to be distributed."

I conclude that §906 (a) of the Semiconductor Chip Protection Act of

1994 permits to reverse engineer bitstream information to create open source tools. But hey, IANAL.

Kolja Sulimma

That seems to be the most logical basis for a claim. Compare for example, this partial passage from RedHat's default licensing of the Cygwin compatability layer:

"The Cygwin API library found in the winsup subdirectory of the source code is also covered by the GNU GPL (with exceptions; see below). By default, all executables link against this library (and in the process include GPL'd Cygwin glue code). This means that unless you modify the tools so that compiled executables do not make use of the Cygwin library, your compiled programs will also have to be free software distributed under the GPL with source code available to all."

This seems to say that if you compile in a way that includes bits of their library, RedHat has an ownership interest in your binary. The only difference is that they exercise that interest by extending the GPL to the result, whereas Xilinx exercises its interest by extending its restrictions on keeping the technology proprietary and only running it on Xilinx silicon. RedHat is also willing to sell you a license to use the parts of the Cygwin stuff which they own under non-GPL terms, and Xilinx may be willing to license a bit stream to you slightly differently if you can make a convincing argument to why it would be in their interest to do so.

That would be shared ownership, which is possible. But to claim that, Xilinx must argue that the bitstream contains material that is protected by copyright. Is is not enough that it was created with a tool that is protected by copyright. (Using a compiler/text editor vs. linking to a library/using a letter template)

Some bitstreams might contain Xilinx library elements but clearly not all bitstreams do.

Kolja Sulimma

BTW: The ISE toolflow uses TCL at some points. If the use of a tool alone would impose the license of the tool on the result all bitstreams would be GPL. So Xilinx needs to explain why the EULA of ISE does affect the bitstream while the license of TCL does not.

Does the license of TCL make claims about the output of TCL-using tools? My guess is it doesn't. So that's a difference right there - it doesn't really give us any clues about the potential validity of making such a claim.

Hey Guys, let's back off and let the open source advocates inside Xilinx to have time to work out how they want to be the good guys.

They clearly recieve a lot of value from free open source that they use internally and put into their product. The backlash could clearly be creating XGPL licenses, which allow use for all but those companies that refuse to be equally open with their EULA's. That would a a lively debate, but we see it already with the number of free software licenses which specifically prohibt commercial use because of these abuses, and the mindset that if someone is going to profit from their work, they want part of the pie in the form of royalties or license fees.

The reality is that all the information open source needs is out of their control anyway, it would just take a legal battle to secure it, that maybe even FSF would fund. I've already documented that fact.

So, let's just give Xilinx a chance to think about this more carefully, and have a chance to volunteer to be good open source citizens.

The previous link that I cited only discussed a narrow issue that was raised to an appellate court. Try this one instead which has notes on the on the Software License Agreement. Altera was not claiming that they "owned" the bitstream only that use of the bitstream was restricted to Altera only devices by the license of the software that created it.

Ed

[disclaimer: I'm a GCC developer and former Cygwin developer]

One key difference between Cygwin and Xilinx, is that apps built with Cygwin also *include* part of cygwin (almost verbatim) in the resulting binary. Do bitstreams built by Xilinx tools *include* portions of the Xilinx tools in the resulting bitstream? Can Xilinx point to a bitstream and say "these 1000 bits are copied from our library" ?

A better comparison is comparing Xilinx to GCC. The GCC license explicitly states that binaries built *with* GCC are not affected in any way by GCC's license.

Note that binaries built *from* GCC (derived works) are a different story. GCC's runtime libraries have a specific clause that covers linking; if you build with GCC, linking doesn't incur the GPL. If you build with something else, linking does incur the GPL.