From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16957 invoked by alias); 31 May 2013 08:06:08 -0000 Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org Received: (qmail 16943 invoked by uid 89); 31 May 2013 08:06:08 -0000 X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,SPF_NEUTRAL autolearn=no version=3.3.1 Received: from gateway16.websitewelcome.com (HELO gateway16.websitewelcome.com) (69.56.150.11) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 31 May 2013 08:06:05 +0000 Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 7D8A53551F3C1; Fri, 31 May 2013 03:05:39 -0500 (CDT) Received: from ham01.websitewelcome.com (ham.websitewelcome.com [173.192.111.52]) by gateway16.websitewelcome.com (Postfix) with ESMTP id E37E03551F175 for ; Fri, 31 May 2013 03:05:38 -0500 (CDT) Received: by ham01.websitewelcome.com (Postfix, from userid 666) id E05FB3F6B6720; Fri, 31 May 2013 03:06:12 -0500 (CDT) X-Spam-Flag2999: NO X-Spam-Level2999: X-Spam-Status2999: "No, score=-0.0 required=5.0 tests=BAYES_20 autolearn=unavailable version=3.3.1 Received: from montecarlo.websitewelcome.com (montecarlo.websitewelcome.com [174.120.9.66]) by ham01.websitewelcome.com (Postfix) with ESMTP id 7B8D13F6B4DF7 for ; Fri, 31 May 2013 03:06:03 -0500 (CDT) Received: from [195.189.206.101] (port=40627 helo=[192.168.209.11]) by montecarlo.websitewelcome.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UiKLQ-0000Sy-H4; Fri, 31 May 2013 03:05:52 -0500 Message-ID: <51A859DE.9090108@siva.com.mk> Date: Fri, 31 May 2013 08:06:00 -0000 From: Ilija Kocho User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Dallaway CC: Uwe Kindler , eCos development list Subject: Re: eCos Driver for open source CANopen stack CanFestival References: <519DC3FE.4070001@web.de> <51A8547A.3010907@dallaway.org.uk> In-Reply-To: <51A8547A.3010907@dallaway.org.uk> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-BWhitelist: no X-Source-Sender: ([192.168.209.11]) [195.189.206.101]:40627 X-Source-Auth: ilijak+siva.mk X-Email-Count: 1 X-Source-Cap: c2l2YW1rO2JpYmltYW47bW9udGVjYXJsby53ZWJzaXRld2VsY29tZS5jb20= X-SW-Source: 2013-05/txt/msg00007.txt.bz2 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. >> >> http://www.canfestival.org/ >> http://dev.automforge.net/CanFestival-3/ >> >> This driver is based on the eCos CAN framework of the public eCos >> repositories. >> 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 CanFestival authors. 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. Ilija