OK, so Which bsd and which driver?

[Joel Sherrill]

gregory.menke at gsfc.nasa.gov wrote:
> 
> Ralf Corsepius writes:
>  > Am Mit, 2003-03-26 um 18.16 schrieb gregory.menke at gsfc.nasa.gov:
>  > > Joking aside, Joel, please don't take this the wrong way- but this
>  > > kind of thing is EXTREMELY frustrating.  I really wish these licensing
>  > > issues were made more plain.
>  > You are mixing up things, here:
>  > Basically, RTEMS comes with no restrictions on licensing.
>  >
>  > Linux is GPL'ed.
>  >
>  > => Nothing prevents _you_ from using Linux-code with RTEMS if obeying
>  > the restrictions of the GPL.
>  >
>  > It's only that GPL'ed code can not be merged back into the "official
>  > RTEMS sources" because this would imply having to put RTEMS under the
>  > GPL.
> 
> Of course- thats my point.  I <want> to put my work back into RTEMS,
> without imposing any sort of constraints on RTEMS.  I am quite aware
> of the license issue- and am only annoyed because the incompatiblity
> is not made public in any obvious way ahead of time.

Very good point.  Where would you have looked to find this information?

This is definitely a problem that comes up from time to time and if
a writeup somewhere will solve it, then it is an easy fix.

>  >  A recursive grep for GPL in the rtems
>  > > source tree didn't turn up any general warnings about inclusion of GPL
>  > > code in RTEMS- only a couple ancient boilerplate references here and
>  > > there.  Instead of wasting 2 days, I could have easily wasted a couple
>  > > weeks getting the Linux 3com driver ported, working and efficient- and
>  > > then have to throw it out due to the AFAICT essentially undocumented
>  > > no-GPL requirement.
>  > As said above, it is not RTEMS which imposes restrictions on you, it is
>  > Linux which does.
> 
> Correct.  And it would be nice if RTEMS contained a warning about this
> issue.  Linux supports a huge variety of hardware these days and there
> is and will be pressure to take advantage of that.  I realize it is
> not strictly REQUIRED of RTEMS to make such warnings- however doing so
> would be a polite act towards individuals contributing their labor to
> the RTEMS community.

If you owned the software in question, you could submit it with the
exception to RTEMS BUT usually (as in this case) the RTEMS porter
is not the original author and cannot tinker with the original license.

>  >
>  > > Sure, I could use it in-house, which I probably
>  > > would, but thats not helping the RTEMS community any.
>  >
>  > Well, the idea of setting up a GPL'ed RTEMS and a non-GPL'ed one has
>  > been discussed several times before, but AFAICT hasn't made it, so far
>  > ....
> 
> I'm not advocating such a thing.  I don't get religious about software
> licenses as such- the GPL and the bsd model serve somewhat different
> constituencies, they both have advantages and I personally support
> them both, morally and financially.  However, my grumpiness is due to
> the fact that I would not be able to contribute a GPL derived driver
> back into RTEMS- and that policy is not clearly stated ahead of time.

It is a pain.  But I believe it is necessary to ensure RTEMS does not
impose any license burdens on applications.

> So, I'm dumping the work I did and will work off one or another bsd's
> driver, which I'll run to ground at some point.  I'm looking at
> freebsd's if_xl.c at the moment, which looks like it supports a
> variety of 3com devices.

FreeBSD, NetBSD and OpenBSD have been used by various people to
grab drivers from at different times.

> Gregm