On 31/01/2015 8:32 am, Peter Dufault wrote:
The wording is very bizarre:
"Except as otherwise provided in a valid license issued to you by Xilinx, and to the maximum
extent permitted by applicable law: (1) THESE MATERIALS ARE MADE AVAILABLE "AS IS" AND
WITH ALL FAULTS, AND XILINX HEREBY DISCLAIMS ALL WARRANTIES AND CONDITIONS, EXPRESS, IMPLIED, OR
STATUTORY..."
If there is no other valid license the source is made available "AS IS". But what does "made
available" mean? How can it be used? They then go on to restrict their liability, making it plain it
is expected that the code will be used without the "other valid license". To further add to that
expectation they specifically mention situations where it can't be used under any circumstances.
I wouldn't want to hazard a guess as to what this mess legally means. This is a
"I'll have my cake and eat it too, please" copyright. I'm sure an aggressive
lawyer would have a field day with it.
Yes, the code should be avoided if there isn't another "valid license" somewhere that
clarifies things. Has part of the RTEMS discussion with Xilinx specifically asking for an
appropriate "valid license" and providing a suggested one? That's the tack I'd take.
Here is the long version.
In my view the key issue is the confidential statement and the fact you
have to have downloaded an SDK to obtain the code and the SDK is covered
by a EUL you must agree too.
My understanding is Xilinx and their lawyers are concerned about their
code being used on devices that are not make by Xilinx which is an
understandable position to take given the investment they have made.
Code placed into RTEMS is free for people to take a use and the RTEMS
project cannot determine if the code is only being used on Xilinx
devices therefore we are never sure we comply.
My personal view is the code we are wishing to leverage and use has low
IP value and is often just register definitions or device set up
described in publicly available documentation. The benefits to projects
like ours is the ability to bring up a new device quickly with vendor
tested code. Limiting the access to this code raises the cost of entry
for new devices and in this specific case it is hurting the Microblaze.
We cannot use the Linux version of the code because it is GPL.
The Microblaze and Zynq are a little more complex due to the
programmable logic side of things. A complex projects using these
devices will need to integrate with the programmable logic tools from
Xilinx, eg Vivado. The flow on effect here is these tools are designed
to match up with the Xilinx SDK. If we cannot use or access this code we
run the risk of breaking when the tools are upgraded. Xilinx have in the
past had a loose coupling between the hardware tools and the SDK and
have been able to move and change things as they needed too. Xilinx
understand they need to find a way to define a clear and solid interface
between the hardware tools and the SDK. My hope is the RTEMS project can
work with Xilinx in this area and be a part of this work.
There is real demand for RTEMS on these Xilinx devices which is really
good news so we need to keep moving and this means we need to develop
clean code for now.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
