Licensing questions

[Michael Kelly]

Ralf,

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.

Regards,
Michael

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
>licenses.
>
>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
>tree.
>=> BSD-derived work in general is compatible to the RTEMS licensing
>policy.
>
>* 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
>confusion.
>
>> 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.
>
>Ralf
>
>[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
>product.

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
www.cogcomp.com
alternate email: mkelly6505 at hotmail.com