Is xilinx source code license ok with rtems?

[Ralf Corsepius]

On Wed, 2007-02-28 at 17:58 +0100, Thomas Doerfler wrote:
> Robert,
> 
> all in all, I agree with Ralf. One nice feature of RTEMS maintenance is,
> that OAR and Ralf can at least _build_ ALL BSPs when they test certain
> modifications. If the virtex BSP relies on external code, this feature
> would break.
Exactly this is the point. It might sound harsh to you, but it's a
simple consequence from a simple practical problem: "What we can't
compile, build, modify and test qualifies as 'dead code'", it will start
to rot and starve pretty soon.

> See further comments below.
> 
> Robert S. Grimes schrieb:
> > Ralf Corsepius wrote:
> >> I.e. I would probably veto against a driver which is using code from
> >> outside of source tree, because this would render this driver
> >> unbuildable and untestable.
> >>   
> > Really?
A actual decision would depend upon many details, such as technical ones
(can we easily switch it off, can the API be stubbed/reused, is the API
any good), legal (Are we allowed to stub the API - Unclear to me: Can
APIs be legally restricted) and maintenance-wise implications (Can we
change the API if it's broken). 

All in all this doesn't look compelling to me.

>   Obviously, if the choice was between two existing and working
> > drivers, Driver A (no external dependencies) or Driver B (depends on
> > external code), clearly the choice is Driver A.  But what about if only
> > Driver B exists?  And, as is the case here, it depends on code that is
> > provided with the hardware?  Would you really want to turn away users of
> > this platform just because there was no RTEMS-only solution?
> 
> I think the current state of the virtex BSP (or the state for the next
> four weeks) will allow it to live outside the RTEMS source tree, e.g. as
> a patch that can be applied to the tree. Maybe it could also get placed
> into the "contrib" tree on the ftp.rtems.com server.

 
> > But isn't there a middle ground here?
I can tell you what I did in the past: Contribute a (functional) BSP
that is as close as possible to the one in use, except that a few parts
which weren't distributable were missing (In my case it had not been
legal restrictions, it was drivers for custom hardware, nobody but us
had).

>   Can't there be a "user
> > contributed" BSP class?
Not yet. It's on my schedule for many years (known as bspkit), but so
far there had not been much visible progress in this direction.

>   Wouldn't that be better than a very small
> > number of publicly-available BSPs?  Wouldn't that encourage more users
> > of RTEMS, a larger community, and ultimately, a better product in the
> > long run?
> 
> The RTEMS community is smallar than, let's say, the Linux community. But
> there your would find the same problems. Any modifications should
> integrate into the existing concepts, be compatible with the license,
> and should not break maintainability.
Exactly. It's an OpenSource project, based on volunteerism and on each
party being involved mutually profiting from benefits of OpenSource
contributions. 

Closed source and legal restrictions don't necessarily fit nicely into
this model.

Ralf