Larry Doolittle wrote:
> That's a long list.  I should spend more time with Google.

Yep ... it's almost temping to spend a few days in Google, print out
all the projects, highlite all the infringements, and send them to
Xilinx legal.

I understand that any trade secret or proprietary interests that Xilinx
then chooses to leave in the public, by not acting with due diligence
to protect, would fall into the public domain (if it hasn't already).
They would still have copyright on all the materials, but fair use
under copyright would allow full access to "interfaces" and just being
able to use, discuss, and program in support of the product without the
very restrictive EULA interference. This would allow public
documentation of the interfaces for all objects viewable from the
intermediate ISE files, in addition to what was already openly
documented in the ISE manuals.

That would certainly greatly open the field for open source development
to augment the Xilinx tool chain.

E.I. duPont deNemours & Co., Inc. v Christopher, 431 F.2d 1012 (5th
Cir. 1970), cert. denied, 400 U.S. 1024 (1971). is the citation
normally used to describe this. The bottom line is that if they do not
take every step to protect their rights in trade secrets, that right
will be denied, and all claimed rights will be forfeited. Thus it would
be fair game for open source development to fully use any and all
information found both in ISE and all the university projects that
contain this information as well, as the foundation in the ISE EULA
would be completely breached.

Larry Doolittle wrote:
> While I despise terms like this in an EULA, they almost make sense
> when discussing the running software itself.  The most egregious
> consequences come from trying to apply them to documentation, as
> Xilinx's license does.

It's not just the documentation, but the intermediate files themselves,
such as the wealth of IP that can be extracted from an XDL file from
an instantiated design of any significant size. Much of that IP becomes
obscured in the bitstream, especially without the source and
intermediate
files to correlate the bitstream to.

Any project that release intermediate files which use a significant
part
of the libraries, and other IP cores, does in fact disclose IP which is
either directly usable in other non-xilinx designs, or is very easily
converted/reverse engineered, rendering the reasons behind the strict
EULA terms moot. Files which contain fully routed designs, with back
annotated timing information disclose a wealth of internal IP about
Xilinx product ... if not nearly all.

The younger generation has played fast and loose with IP now for about
a decade. Many do not take the time to read the EULA's or employment
contracts they sign, or any other legal document for that matter. I've
sat
on both sides of the table over the last 35 years, doing faculty
sponsored
security research (AKA hacking), reverse engineering, and defending my
employer/company after others breaches and claims.  This whole series
of threads has a common theme in that people do not know what the
legal requirements are that they are commited to, and frequently assume
completely contrary to the exact terms they are bound.

We see this in the vast theft of music and other IP on the internet,
and
the huge number of P2P proponents claiming it was legal to ignore
copyright restrictions against illegal "broadcasting" and
"distribution" of
music, videos, movies, and computer programs/data because there was
no profit involved, or that P2P downloading servers are different from
other
forms of pay-per-view content on demand broadcasting services. We see
in retrospect that the high court rules against P2P using the standard
that
if it looks like theft, it is theft.

We see the same theme in handling other industries IP, such as Xilinx
restricted IP. While I took a lot of heat over the JHDLBits disclosure
that
after a year, the project was held up in negotiation with Xilinx for IP
release,
is exactly an example of not negotiating the exact terms of the
licenses and
disclosure at the begining of a project rather than wading thru all the
ramifications
in difficult discussions about just what can and can not be released at
the end.

That it apparently was resolved to everyones satisfaction, which is
great, but
the lesson is to take note that these issues need to be resolved before
your
project gets a C&D letter along with a huge claim for damages from the
release
of another companies IP.

Many years ago the universities got up in arms when AT&T tried to
enforce
the proprietary interests in UNIX that were being violated by teaching
the
source code in class rooms. The issue of educational sites handling NDA
restricted material, particularly in the form of EULA's needs to be
carefully
addressed by our schools.

Here we have a long list of schools treating the IP in Xilinx's ISE
software
with the same degree of care they would a software title like Norton
Utilities.
And we have Xilinx employees advocating the same, dispite the very very
strict EULA terms. We also have the most respected posters in this
forum
doing the same.

I'm just tring to be open, honest and ethical in FpgaC's handling of
this
Xilinx IP - which in order to get equal access as all these other
projects
means confronting the issues and hopefully getting Xilinx to realize
the
cat is way out of the bag, isn't likely to be going back in, so we
should
look at the defacto state of their IP and adjust the licenses to
reflect
actual use -- or do the very nasty thing of sending everyone C&D
letters
and forcing all these schools to treat the Xilinx IP with the degree of
care the EULA requires.

The kill the messenger reality is a bit tough sometimes ...

Larry Doolittle wrote:
> > or just sit down and release the XDL formats and library
> > interfaces, along with the exposed chip architectures and
> > routing that all of the above listed projects have already
> > fully disclosed.
>
> Whoa, where did "library interfaces" come from?  Now you're talking
> software, not just documentation.  Drop that item from your wish
> list.  You'll raise fewer hackles.
>
> The "exposed chip architectures" are very sensitive to Xilinx, but
> I think they would listen to a reasoned argument that information
> of that type can not be put back in the bottle.  Too much of it is
> already out there in the patent literature, for example.

I know it's a huge mouthfull for Xilinx to swallow. But let's face it,
that just publishing the file format for XDL isn't enough. An project
that then publishes an XDL output file which would instantiate a
design, is then releasing the library interfaces and chip geometry
information. Any project that posts a synthesis tool that generates
library calls with placement/routing information would be publishing
the library interfaces and chip geometry/routing details of the device.
While some of this is in the data sheets, most of it is not.

Just documenting the XDL file format would leave nearly all the
university projects listed in violation of the EULA because of the
IP inside the XDL files themselves, and the programs which
generate/manipulate them.

Jan Coombs wrote:
> Antti Lukats wrote:
> > you are right he hasnt told that, he actually told to me that I should get
> > used to people (like he) hiding its identify.

> Handles are good deflectors of casual interest. I found the discussion very
> interesting, and had noticed Johns name and interest before today.

It's actually been interesting to watch the petty bickering over this.

The sad part is that they also told several hundred thousand other
people
that use handles they are not welcome to participate in this forum, as
the
"self appointed owners of the list" will riddicule and do everything to
expose
their true identiies at the slightest difference of opinion. ...
totally sad as long
standing usenet guidelines embrace handles.

Antti Lukats wrote:
> "Ed McGettigan" <ed.mcgettigan@xilinx.com> schrieb im Newsbeitrag 
> news:drbp92$nh99@cliff.xsj.xilinx.com...
> 
>>fpga_toys@yahoo.com wrote:
>>
>>> I've actually told
>>>everyone who I am, and it's not that difficult to figure it out,
>>
>>I can't find any reference to you, so who are you then.
>>
>>Ed
> 
> 
> Ed,
> 
> you are right he hasnt told that, he actually told to me that I should get 
> used to people (like he) hiding its identify.

Earlier today in this thread, 11:50 uk time.

> 
> but if I am not mistaken then his name is: John Bass
> 

Handles are good deflectors of casual interest. I found the discussion very 
interesting, and had noticed Johns name and interest before today.

Jan Coombs

[Pardon me while I partially mix threads, I blame it on an erratic
news server.  So I'm using one article as a surrogate to paste in
comments I retreived via Google.  So while the author attributions
are correct, the text doesn't come from the articles listed in the
header.]

On 2006-01-28, fpga_toys@yahoo.com <fpga_toys@yahoo.com> wrote:
>
> Larry Doolittle wrote:
>> Second concern: can open source software be published that
>> works with XDL?  IANAL (honest), but we have to look at this
>> from a lawyer's perspective.  [chop]
>
> The answer unfortunately is that the EULA NDA restrictions and
> open source are mutually exclusive. The EULA NDA is so resrictive
> that you can not even talk to anyone about your "performance" with
> the experience as benchmarking includes everything from bugs, to
> comparitive results, to non-comparitive objective results.

While I despise terms like this in an EULA, they almost make sense
when discussing the running software itself.  The most egregious
consequences come from trying to apply them to documentation, as
Xilinx's license does.

> Consider the BYU JHDL, [chop] University of Massachusetts VPR, [chop]
> UC Berkeley['s] Post-Placement C-slow Retiming, [chop]  Peter Sutton's
> JPG, [chop] Greek universities [unspecified] DAGGER, [chop] IRIAS
> FPGA array layouts, [chop, plus] research and thesis work [in
> Sweden, VPI, Seul, Pennsylvania State, UCLA, Stanford, all of which
> use XDL].

That's a long list.  I should spend more time with Google.

> Xilinx should either properly protect it's IP,

By pulling its head out of the sand, sending C&D letters to all
of the above projects, and posting a FAQ (oops, "answer record")
saying "No, you can't publish code that speaks XDL because of the
terms of the ISE EULA".

> or just sit down and release the XDL formats and library
> interfaces, along with the exposed chip architectures and
> routing that all of the above listed projects have already
> fully disclosed. 

Whoa, where did "library interfaces" come from?  Now you're talking
software, not just documentation.  Drop that item from your wish
list.  You'll raise fewer hackles.

The "exposed chip architectures" are very sensitive to Xilinx, but
I think they would listen to a reasoned argument that information
of that type can not be put back in the bottle.  Too much of it is
already out there in the patent literature, for example.

>> One way to [resolve the confusion is for] Xilinx to post the
>> XDL documentation on-line.  Why isn't it already in the "Xilinx
>> ISE 8 Software Manuals and Help"?  Or maybe it is, and I'm just
>> too blind to see it?

I searched more fully, it's not there.  And posting the material
(obviously NDA-free, unlike the ambiguous stuff in the ISE download)
would quickly end this discussion.  I have to assume Xilinx would
like that result.

           - Larry

Larry Doolittle wrote:
> [*] No, I don't think the ISE license is, or should be, OSD-compliant.
> The discussion here is whether code that I write, based on the
> documentation given in ISE, can be released under an OSD-compliant
> license, like BSD or GPL.

The question goes far past that. Consider the BYU JHDL has XDL
interfaces in
it. As does the University of Massachusetts VPR for Virtex + JBits
Interface
project built on top of the University of Toronto work. Besides the VPR
work
at UofT, several other projects like EVE have XDL interfaces as well.
As
does the UC Berkeley work for Post-Placement C-slow Retiming.  As does
Peter Sutton's work JPG - A Partial Bitstream Generation Tool  to
Support
Partial Reconfiguration in Virtex FPGAs" at UQ Australia. As does the
DAGGER work done at universities in Greece. The MIT team doing 3-D Fpga
architecture research was using it. The French researchers at IRIAS are
doing FPGA array layouts with it. As is research and thesis work at
Lund Institute of Technology, Sweden in dynamic reconfiguration. As is
research and thesis work at Virginia Polytechnic Institute. As is
research
and thesis work at Seoul National University, Korea. As is research
work
at Pennsylvania State University. As is research and thesis work at
UCLA.
As is research and thesis work at Stanford. ... and the list goes on,
and on.

Many of these projects have released source and documentation which
has XDL formats and xilinx device interfaces embedded.

In searching, we also find that XDL is discussed in class room
lectures, and
is the subject of class exercises.

Many of these projects describe XDL as an open interface, and treat if
freely
as such. That is clearly stated in many places including the Xilinx/BYU
work
for Los Alamos SEU project. Some of these projects include Xilinx
co-authors.

So, clearly the cat is out of the bag, and Xilinx should either
properly protect
it's IP, or just sit down and release the XDL formats and library
interfaces,
along with the exposed chip architectures and routing that all of the
above
listed projects have already fully disclosed.

Larry Doolittle wrote:
> That will generate a legal flap akin to deCSS, and
> unfortunately will cause Xilinx to reconsider its public
> XDL support.

In another thread I pressed Austin for an answer which he said his
reading (as does yours and mine) is that the EULA prohibts open source.

I've updated the FpgaC users manual to include this, and asked Austin
for his input, which he declined ... not a suprise as it gets too close
to
legal, which is where probably where he forwarded my request.

Given the obvious conflict this creates in the Xilinx developers
community
with open source, the company legal department really needs to make a
clear an definative statement that is given to rank and file Xilinx
Staff so
that they may avoid miss-representing the current legal state, and have
the guidance to communicate that clearly to customers.

Another Xilinx employee, Ed McGettigan saying that copyright law
protects
you from the EULA, there clearly is a unified message problem from
Xiinx
that could very unfairly trap open source developers in a legal fight
with
Xilinx.

John

> From jbass Fri Jan 27 14:59:57 2006
> To: austin.lesea@xilinx.com, jbass
> Subject: Need your review and suggestions

Hi Austin,

The following text has been added to the FpgaC user manual, to call
attention to the Licensing restrictions involved. I hope this fairly
and accurately documents the challenges we currently face working
with the Xilinx EULA.

Please feel free to make or suggest any changes that you feel would
better describe the current problems, and better support Xilinx and
your customers. FpgaC would like this to go well for both our project
and Xilinx.

Thanks,
John Bass

-------------------------------------------------------------------

Interfaces to newer FPGA's

The current vendor interfaces are ones we picked up from TMCC, so
that project did the footwork for vendor acceptable interface points.
In the 10 years since, the vendor tool chains have significantly
changed. Xilinx no longer supports XNF as a netlist format, and has
not provided a publicly documented replacement for it which interfaces
to the newest FPGAs.

While we can use EDIF to some extent as a netlist input source, what
we don't have access to is a legal description of all the library
system blocks and macros to instantiate in the EDIF netlist for newer
devices.  Those library interfaces are documented inside ISE and
subject to the ISE End User License Agreement which contains a strict
Non-Disclosure agreement blocking open source use of the library
information. We can blindly use the older known library blocks to the
exent they are mapped to EDIF, but we do not have access to any of the
newer library blocks and macros as implemented for Virtex-II Pro and
Virtex-4 parts.

There is a new XDL interface which is a very attractive interface point
for FpgaC, which Xilinx now would like 3rd parties to use. However, the
documentation for XDL and the device libraries is restricted with an
NDA
which is incompatable with open source licenses. Implementing those
interfaces in open source C code, would in fact publish them to the
world
in violation of NDA restrictions, so they are currently off limits for
FpgaC.

When asking Xilinx staff what public interfaces are currently legal for
FpgaC to use to import netlists into the ISE tool chain, this question:

    "But that aside, the question remains, just what, if any,
     legal interfaces may open source software use to augment
     the ISE tool chain?  The strictest reading of the license
     and NDA is clear ... NONE."

Gets this reply from Austin Lesea of Xilinx:

    "I am not a lawyer.

    "But it seems clear to me, when I read it: the answer is "none."

    "To imply otherwise is clearly misleading, and could be interpreted
as
     intentionally causing harm (to Xilinx, or its partners, or its
customers)."

So, we need to lobby Xilinx to provide a usable open source entry point
into their ISE and ISE WebPack tool chains that does not violate open
source restrictions or the NDA's in the Xilinx Licenses.  Needed is a
publicly documented netlist format, such as XDL, and a set of publicly
documented library interfaces that we can call out to instantiate all
library blocks and macros for each device family, including the device
geometries for LUT's, CLB's, and other on chip objects to faciltate
FpgaC guided placement decisions or externally providing placement and
some routing information to the backend ISE tools for bit stream
generation.

Anyone providing Xilinx specific code for FpgaC needs to explore these
license issues, and make sure that we do not violate either the Xilinx
Intellectual Property (IP) rights, or the open source license(s).
Written
releases, or documented public interfaces, are required, not just for
Xilinx, but all FPGA vendor's IP.

I have been told, but have not personally explored, that we face very
similar problems with Altera. If someone could provide similar details
for their product lines and tool chains it would be greatly
appreciated,
as I do not hold a license for all the required Altera tools.

It has been suggested that some of the smaller FPGA companies are much
more eager to get open source support for the product lines, and we
will
actively support each of those that we can.  If your favorite vendor
doesn't have a support path included in this release, let the FpgaC
project team know, and we will set up a project to get them supported
as soon as possible.