GPL and RTEMS was Re: Does rtems have a portable, sort-of calibrated time-wastingloop?

[Joel Sherrill]

Jerry Needell wrote:
> 
> Joel Sherrill wrote:
> >
> > gregory.menke at gsfc.nasa.gov wrote:
> >
> >>Joel Sherrill writes:
> >> >
> >> >
> >> > "Eugeny S. Mints" wrote:
> >> > >
> >> > > Hi,
> >> > >
> >> > > On Tue, 25 Mar 2003 gregory.menke at gsfc.nasa.gov wrote:
> >> > >
> >> > > >
> >> > > > Perhaps something like Linux's udelay- it doesn't have to be fast, but
> >> > > > should cause the program to spin for the supplied interval.  It should
> >> > > > not itself reschedule, so rtems_wake_after is out- and should be
> >> > > > callable from an isr.
> >> > >
> >> > > Yes, seems it is 'rtems_bsp_delay()' macro. Each bsp should
> >> > > define it in a custom way (because it is very dependent on
> >> > > the clock speed of the target). I'm not sure, wether it is
> >> > > callable from an isr but don't see any restriction for this.
> >> >
> >> > Since this routine is BSP dependent, it could end up not being
> >> > callable from an ISR but that is not the intent.  It is intended
> >> > to be a tight assembly loop or poll a HW counter/timer but should
> >> > be callable from an ISR.  The only issue is killing time
> >> > in the ISR.
> >>
> >>I'm porting the Linux 3com driver and in a couple places it waits on
> >>the hardware- usually a quick test with a fallback to longer and
> >>longer intervals with either eventual success or failure.  I've not
> >>found any of these waits in the rx/tx isr yet- but theres not
> >>telling.  Its pretty hairy code in there..
> >
> >
> > Standard warning about porting Linux code to RTEMS applies here.  It is
> > GPL with no exception so can't be included in the RTEMS source
> > distribution.
> > Please use a BSD driver as your starting point.
> >
> >
> >>Gregm
> >
> 
> Joel - I realize this is a sensitive topic so I'll ask this "off-line".
> You can post it to the list if you want. 

I understand completely and decided to post it since it is a common
and subtle issue.  I have to be ever vigilant on submissions to
avoid license issues.

> Can you summarize, or point me
> to a good reference on the liscencing issues that you are refering to.

I don't have a standard reference but this is one I found on the net
which 
looks pretty good

http://mind.be/library/licenses/

The key is that an RTEMS application and RTEMS are linked together to
form a single executable which means that any GPL code in RTEMS forces
the application code to be GPLed.  This is why RTEMS is careful about
not
merging GPL code without an exception to allow users to link their
program
with it without incurring this obgligation.  RTEMS includes this
exception
to the GPL which makes it permissible to link a proprietary application
with RTEMS:

As a special exception, including RTEMS header files in a file,
instantiating RTEMS generics or templates, or linking other files
with RTEMS objects to produce an executable application, does not
by itself cause the resulting executable application to be covered
by the GNU General Public License. This exception does not
however invalidate any other reasons why the executable file might be
covered by the GNU Public License.



> - Jerry
> 
> --
> _______________________________________________________________________
> Jerry Needell                     | Internet: jerry.needell at unh.edu
> Space Science Center/Morse Hall   | Voice: (603) 862 2732
> University Of New Hampshire       | FAX:   (603) 862 0311
> Durham, NH 03824                  |