Request Review for RTEMS License (Legacy?)

Chuck Swiger chuck at codefab.com
Mon Aug 18 22:26:19 UTC 2008


On Aug 18, 2008, at 1:33 PM, Joel Sherrill wrote:
>> Perhaps you may have wanted to place your code under the LGPL rather
>> than the GPLv2 plus an exception for using the runtime classes and
>> headers...?
>
> RTEMS is an embedded real-time operating system which
> is statically linked with potentially proprietary user code.
> Currently there is no burden placed upon end users when
> shipping their application. The LGPL would require then
> to ship a binary for their proprietary code and a relinking
> kit. This is not acceptable.
>
> Being statically linked causes problems.

The exceptions in GPLv2 clause 3 (or similar in LGPL clause 6):  
"However, as a special exception, the source code distributed need not  
include anything that is normally distributed (in either source or  
binary form) with the major components (compiler, kernel, and so on)  
of the operating system on which the executable runs, unless that  
component itself accompanies the executable."

...would probably apply in your case.

Simply calling system library routines via the publicly published API  
in a GPL'ed glibc or similar does not bring a proprietary program  
under the auspices of the GPL.  However, I would agree that statically  
linking and then distributing a binary which includes GPL'ed software  
would, unless an exception like yours was granted.

>> Anyway, granting additional permissions doesn't change
>> the status of the GPLv2, which is already OSI approved;
>
> Playing devil's advocate here...does that mean one could
> write an exception paragraph which went against the spirit
> of the GPL and still claim the result to be OSI approved?

Granting additional freedoms or permissions would not change an OSI- 
approved license from being approved or at least _approvable_.

> On a more practical note, does this mean your policy does
> not distinguish between the licenses found in these files
> (links to GCC SVN)?
>
> GPL: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/bt-load.c?rev=2.39&content-type=text/x-cvsweb-markup
> GPL+ exception 1: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/libgcc2.c?rev=1.195&content-type=text/x-cvsweb-markup
> GPL + exception 2: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/s-osinte-rtems.adb?rev=1.2&content-type=text/x-cvsweb-markup
>
> If this is the case, I will gladly accept that the RTEMS
> license is covered under the GPLv2 umbrella.

I'd consider or classify those to be GPLv2 + additional permissions,  
and not list them as separate licenses.  If there were more  
significant changes than just the permissive grant, a separate listing  
e.g. for the Affero GPL (http://www.opensource.org/licenses/agpl- 
v3.html) might make sense.

>> or you might consider switching to the GPLv3 which provides more  
>> explicit handling
>> of this in clause 7 about "Additional Terms".
>>
>
> There is a GPLv3 based run-time license circulating around
> in draft form to standardize the licensing for GCC run-time
> files. If there were a GPLv2 variant of this, we would seriously
> consider it because that is what we wanted for 10+ years.
>
> But it is GPLv3 based and I don't see us switching.

OK.  Of course, you or your downstream recipients are allowed to move  
to GPLv3 per the "...either version 2, or (at your option) any later  
version." clause, but as you please....  :-)

Regards,
-- 
-Chuck




More information about the License-review mailing list