Licensing questions

[Joel Sherrill]

Michael Kelly wrote:

> 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.

I would just warn you that sometimes holding code can
result in making it harder to merge, obsolete, or just plain
out of date.  For example, an update of the TCP/IP stack is
planned.  When that occurs, it is possible that something will
change in the network driver interface.  If we follow the
normal path, any driver in the tree will get updated and
those outside will only see a notice to the list that
something changed.

So I would say if you want to keep the BSPs proper in-house for
some time, OK.  But be careful in submitting any changes outside
that are to shared areas.

But even keeping the only BSP to yourself, there is a potential
for issues to arise.  An example here is that we push to have
more shared code for BSPs so there is a desire to unify the
PCI and IRQ APIs and code.  The x86 and PowerPC have different
PCI APIs.  When unified, there will be changes which would not
be reflected in any externally modified BSP.

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

If you want to talk any details via voice, ping me privately and
I will pass along a phone number.

--joel

> 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
> 


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985