Licensing questions

Tue Aug 19 01:49:42 UTC 2003

Joel,

Thanks for the response.  I think understand the idea
of the two licenses, but which one governs when?  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?  

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.  I just don't think I can afford
to do that right away.  Besides, if I want to contract you,
I'll need the revenue from the BSP's at first until the 
board volumes catch up.

All of this can change of course, if we work a deal with
a chip vendor as we did with Cirrus (that's the board
that's supported now).  That is very likely to happen
once for every few boards we design.  In those cases
we can get the chip vendor to pony up some dough
as they know the value of an open source RTOS (though
they often think it begins with an L, but we'll learn em proper!).

BTW, the plan is to port RTEMS to the following board
CPU combinations in more or less this order:

1. CSB337 - Atmel AT91RM9200 (ARM920T) - 10/100 built in.
2. CSB336 - Motorola MC9328MXL (ARM920T) Dragonball MXL
    SMC LAN91C113 10/100
3. CSB360 - Motorola Coldfire MCF5272 - 10/100 built-in
4. CSB325 - Intel PXA255 - SMC LAN91C113 10/100

Michael

P.S.  I would be happy to continue this off line if it's more 
appropriate.

At 09:29 PM 8/18/2003, Joel Sherrill wrote:
>Michael Kelly wrote:
>
>>Hello all,
>>
>>As a new, potential provider of RTEMS BSP's,
>>I am a bit confused about the licensing.  I have
>>read the GPL and LGPL licenses, but some
>>questions remain:
>>
>>1. Do I have to provide the source to a BSP,
>>including drivers?  If so, how and when should
>>this occur?  I have concerns about liability for
>>early untested (or only partially tested) code.
>> 
>
>No.  Most of RTEMS is under the GPL with an exception that lets
>you link with it without imposing the GPL on your code.  The rest
>of RTEMS (such as the network stack) is under a BSD license.
>
>Both RTEMS and newlib (the C library) stick to source that
>is free and imposes no restrictions on your application.
>
>With that said, if your BSP is for a useful commercial board,
>then it is desirable to get it merged when stable.  But if it is
>for a proprietary board, the odds are that it does no one
>else any good to have it.  If the BSP is based upon a
>CPU with on-CPU peripherals, the core of the BSP is
>generally useful.  Or some of the drivers may be useful
>if they are generic (e.g. UART, NIC, etc.) , but we
>don't want to maintain a BSP for a board which no one
>else can get.
>
>My assumption is that any BSP you would be thinking of would
>be in the generally useful category because RTEMS already
>includes a BSP for a Cogent ARM board.
>
>>2. Are network drivers different than the other
>>drivers since they are part of the BSD stack?
>> 
>They follow a different structure and we encourage people to get
>them from the *BSD world but that's about it.  If they are from the
>BSD world, then they can be merged into RTEMS and others
>can freely use them in their system.
>
>As a project, we do not impose pure-GPL code on users as
>part of the base RTEMS tarball.  If you want to include code under the GPL
>or any other license in your application or BSP, then it is up to you to ensure
>that you and all subsequent users adhere to that license.
>
>Does that make sense?
>
>>3. I want to include a BSP with each of my Single Board Computers, but do not want to
>>support customers unless they are paying for
>>the support.  What are the accepted practices
>>for charging a customer when you provide them
>>with the RTEMS code and/or support?
>> 
>You don't have to charge them anything.  Of course, that would
>limit the amount of help and support you could give them. 
>With free software, you pay for the support, consulting, training,
>customization, etc. you require.  In this case, you might give it to
>them and encourage them to pay for answering questions or
>writing drivers for extra peripherals.  You could also send them to
>OAR for training and core RTEMS support.
>
>Long term, it might make sense to charge a modest fee and acquire
>a "partial" OAR support engineer.  That's an arrangement where
>a certain percentage of an RTEMS person's time is dedicated to
>your needs and those of Cogent board users. 
>It all depends on your business model and what makes sense as a
>partnership.  If you want to make money on hardware volume, give
>RTEMS and BSPs away and build in enough to cover the
>dedicated RTEMS engineer.
>
>As we have always said, give RTEMS away in serial boxes.  We don't
>care.  Just contribute to the project and if you need help, please use
>our services.  RTEMS does require time and resources.  Those cost
>money.  We have to eat and pay the bills too.
>
>--joel
>
>>Thanks,
>>Michael
>>
>>
>>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
>>
>> 
>
>

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