Licensing questions

Michael Kelly mike at
Tue Aug 19 13:01:08 UTC 2003


Thanks for your insightful response.  It does indeed clear
up my confusion.  As to your last comment about the
value of a board without the source, it is absolutely
our plan to provide full source, but to charge a fee for
this and to keep the drivers (which we will do in house)
proprietary for a period of around 6 months.  After that
we will most likely contribute them to the community.  That
gives us some time to recoup the costs and get a head start
on our competition.  This seem to be a common model.  For
instance I know that Wasabi, who do a lot of NetBSD work,
do it  that way.

Again, thanks for taking the time to help me resolve some
of these issues.


At 12:40 AM 8/19/2003, you wrote:
>On Tue, 2003-08-19 at 03:49, Michael Kelly wrote:
>> Joel,
>> Thanks for the response.  I think understand the idea
>> of the two licenses, but which one governs when?
>None governs none. It's not a matter of "governing" nor "choosing".
>Each file in RTEMS has its own license. Some are BSD-licensed (primarily
>because they are derived from some *BSD code), most are "GPL with
>exceptions" (Esp. original OAR-RTEMS code), very few have other
>All in all, all code in RTEMS is supposed to be freely usable in closed
>source applications.
>>   In
>> the example of a BSP, if I write all the target specific
>> init code and the drivers are they GPL or LGPL or
>> mine?  
>The license you put your code under, rsp.the license the code contains,
>your code is derived from.
>Example: You "wrote a driver for a NIC"
>* If you had ported a BSD NIC driver to RTEMS, this driver will have to
>apply the BSD-driver's license/copyright. In general, a BSD-style
>license allows you to use this code in closed source applications, as
>well it permits integration of your work into the official RTEMS source
>=> BSD-derived work in general is compatible to the RTEMS licensing
>* If you had ported a Linux NIC-driver to RTEMS, this driver applies the
>corresponding Linux-license. In general, this will be a GPL-license,
>which will automatically put your derived code under the GPL. You will
>have to obey the restrictions of the GPL, which basically will put all
>of your product's SW under the GPL, and will require you to ship the
>source code on demand. 
>Such code will not be acceptable for inclusion into the RTEMS source
>tree, because it would put RTEMS as a whole under the GPL and therefore
>would render RTEMS inapplicable for closed source applications.
>=> GPL-derived work in general is not compatible to the RTEMS licensing
>policy. However, such code theoretically could be distributed as
>add-on-packages to the source tree.
>* If your driver is "100% your genuine original work", you can put your
>code under any license you want. If you want too see your code included
>into the official source tree, you'd have to choose a licensing allowing
>closed source usage. For such cases, choosing a BSD or X11 style license
>instead of inventing your own is a convenient solution to avoid
>> At some point it will make a lot of sense to contribute
>> drivers especially since almost all of the boards we 
>> will be porting to are SoC devices with a multitude of
>> on chip peripherals.  That said, we also need to eat 
>> and would like to recoup some of the initial porting 
>> costs in the form of RTEMS kits.  These could range 
>> from a few hundred to a few thousand dollars.  I want
>> to be sure I have the right to do so, and to a slightly 
>> lesser degree, the permission of the larger RTEMS 
>> community to do so.  After say six months, we could 
>> put a BSP into the RTEMS project where they can be 
>> maintained and the pieces parts used on other projects
>> based on the same chips.
>Let me put it this way: Nothing in RTEMS licensing prevents you from
>following the policy you described above ;) [1] However, if you want to
>share the "benefits of open software", you'd better be off sharing your
>code with others.
>[1] To me as a developer, not having access to all the source code used
>by an embedded board is a criterion for not considering such kind of

Michael J. Kelly
VP Engineering/Marketing
Cogent Computer Systems, Inc.
1130 Ten Rod Road
Suite A-201
North Kingstown, RI 02852
tel:401-295-6505 fax:401-295-6507
alternate email: mkelly6505 at

More information about the users mailing list