This is the mail archive of the
mailing list for the eCos project.
Re: eCos Driver for open source CANopen stack CanFestival
- From: Ilija Kocho <ilijak at siva dot com dot mk>
- To: John Dallaway <john at dallaway dot org dot uk>
- Cc: Uwe Kindler <uwe_kindler at web dot de>, eCos development list <ecos-devel at sourceware dot org>
- Date: Fri, 31 May 2013 10:05:50 +0200
- Subject: Re: eCos Driver for open source CANopen stack CanFestival
- References: <519DC3FE dot 4070001 at web dot de> <51A8547A dot 3010907 at dallaway dot org dot uk>
On 31.05.2013 09:42, John Dallaway wrote:
> Hi Uwe
> On 23/05/13 08:23, Uwe Kindler wrote:
>> we are currently in the process of creating an eCos driver for the open
>> source CANopen stack CanFestival.
>> This driver is based on the eCos CAN framework of the public eCos
>> We thought about integrating CanFestival as an eCos package like lwIP or
>> uSTL but we are not shure if the license of the CanFestival stack
>> (LGPLv2) is suitable for this plan. What is your opinion? Or should we
>> contact the CanFestival maintainers and ask if they would accept an
>> additional license (the eCos license).
> A port pf CanFestival to eCos would be great, but the eCos maintainers
> would prefer to avoid LGPL in the eCos repository.
> I took a brief look at the CanFestival sources. Copyright appears to be
> held by three individuals at present. Perhaps you could ask them if they
> would accept an additional license. The eCos license would be ideal, but
> we can also accept BSD-licensed code from "certain trusted sources". If
> an additional license is not possible, please get back to us and we can
> think again.
LGPL and eCos Licence are practically same regarding modification of
contributed source and derivative works, but there's an essential
difference with regard to proprietary code.
Having in mind sameness of LGPL and eCos licences regarding the
contributed source, I hope that eCos licence will be accepted by
Regarding proprietary code, in most cases embedded system application,
LGPL requires availability of object code that, I'm afraid, would not
be acceptable for most of producers of embedded systems. I wouldn't put
LGPL code in eCos repository, there are other options such as eCos modules.