[riot-devel] Feedback from emworld and future plans (partnerships AND licensing)

[Jan Wagner]

Hi devs,
 
you have read that many of you are currently at embedded world meeting with
representatives and "unbrella" corps.
I did not understand the future plans for the RIOT-OS yet. Its not even clear to
me why and for what in details
RIOT needs business support. I mean we all have freedom incl the final freedom
to fork etc and therefore
the plans of RIOT are imortant for me but not essential. Maybe someone can
answer me the follwing list of
questions:
 
- RIOT is an OS that is mostly powered by the community with alot  of students
of european universities(?)
-If RIOT is an open source Project why would it require "legal services" and
"promise promition", matchmaking??
- Why is RIOT searching for partnerships is it only about money? - and for what
is that money exatly needed?
- Why are Business Partnerships needed? - the business gets a free OS and saves
tons of development months,
with GPL that "can" give someone back - or simply hide the GPL code - even if
they do not hide it its more a
moral problem because if you get sued - "by who?", and how mutch will it cost?
(even in the times of
gpl-violations.org almost nothing happend) (sorry but thats exatly what happend
with this "applicance like
systems" starting +15y ago.
 
I asked this questions to "understand the big picture" - and it can be quite
different to my idea :
 
A strong, minimal and open IOT OS - that does NOT need promotion or partnerships
- yeah be a partner its called
GPL join the code. I want "people" and "corps" to join simply for selfish
reasons - to get a better OS that
I am currently working with and supporting code too. A selflish but fair win-win
of plain simple gpl.
 
Q: I dont want to start a "a deep philosophical" discussion - But what EXACLTY
is RIOT searching for? - any I am not
talking about these beatifull business buzzwords. How mutch money is needed and
for what "sections" (I just dont
see it - dont need exact numbers).

Q: Do we need promotion at all?

Q: I am straight spitter: I have heard that RIOT will have a "full time
worker/developer" hired - or was
already hired - Where does the money for the salery of this person comes from?


Greets Jan
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] LGPL compliance testing

[Ludwig Ortmann]

PS: can you send a link to your PR? I couldn't find it.

Cheers, Ludwig

Am 26. Februar 2015 07:23:52 MEZ, schrieb Ludwig Ortmann 
:
>Hi Murat,
>
>Under what license are the generated files?
>And also, how do you think your port is related to the discussion in
>this thread?
>
>I can try to talk about this topic with a cypress representative today.
>We are currently at the "embedded world" and they are too. They seemed
>interested in RIOT in an initial chat.
>BTW: As far as I understood it, their software can create object files
>with library code for the psoc. Therefore I guess it should be possible
>to link the generated psoc library with RIOT in our make system as
>well.
>
>So, whatever it looks like today, please don't close your pull request
>yet.
>
>Cheers, Ludwig
>
>Am 25. Februar 2015 21:46:45 MEZ, schrieb Murat CAKMAK
>:
>>Hi All,
>>
>> 
>>
>>I was (still) busy to read mails about LGPL compliance so sorry for
>>slience.
>>
>>
>>As you know, I have initially ported RIOT to PsoC 5LP processor by
>>creating
>>a PsoC Creator IDE Projects. 
>>
>> 
>>
>>In my case:
>>
>>1.   This port not using the default RIOT build environment and
>>PsoC
>>Creator IDE hides linking and other details. 
>>
>>2.   PsoC Creator IDE also creates automatically some source
>codes.
>>I
>>have created an empty project with a small HW design under
>>dist/PsoCCreator
>>directory. But when you build project in PsoC Creator IDE, It is going
>>to
>>create a lot of files; system initialization, APIs for HW blocks which
>>created for RIOT etc. I was not planning to commit those files to GIT
>>repository because they are already created automatically by IDE. 
>>
>>3.   Auto-generated files may be changed (e.g bug fixing) by the
>>version
>>of PSOC Creator IDE. So, md5 sums may be different for different
>>versions of
>>PsoC Creator IDE.  
>>
>> 
>>
>>On the other hand, I can also implemented required files instead of
>>auto-generated PsoC Creator files, and use RIOT build system. But HEX
>>files
>>of PsoC processors also includes HW desing code (verilog) addition to
>>firmware output(elf, hex etc.). I dont know how PsoC Creator IDE
>merges
>>Firmware code and HW design code into a single HEX file and I am not
>>sure
>>about PSOC Creator team share this information with me. 
>>
>>It is the hard way and also I dont prefer to use this way. Because, in
>>this
>>way, we can not use advantages(ARM Core + Programmable Digital&Analog
>>Blocks) of PsoC processors which only available by PsoC Creator IDE. 
>>
>> 
>>
>>So, What is the latest decision? 
>>
>>Should I withdraw my "pull request" for PsoC 5LP port? 
>>
>> 
>>
>>Regards. 
>>
>> 
>>
>>Murat. 
>>
>> 
>>
>> 
>>
>>-Original Message-
>>From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Matthias
>>Waehlisch
>>Sent: Saturday, February 21, 2015 5:09 PM
>>To: RIOT OS kernel developers
>>Subject: Re: [riot-devel] LGPL compliance testing
>>
>> 
>>
>>Hi Kaspar,
>>
>> 
>>
>>On Fri, 20 Feb 2015, Kaspar Schleiser wrote:
>>
>> 
>>
>>> Let me correct myself.
>>
>>> 
>>
>>> There are no technical reasons against using LGPLed RIOT to develop 
>>
>>> proprietary applications.
>>
>>> 
>>
>>  it depends on how you define "technical reasons". Yes, it is not
>>impossible to create separate object files. But you maybe don't want
>to
>>do
>>this for technical optimization (see for example
>>>.pdf>
>>http://www.htsoft.com/news/070309_Whitepaper-OmniscientCodeGeneration_FINAL.
>>pdf).
>>
>> 
>>
>>> Using a "weird compiler" that cannot output the required object
>files
>>
>>
>>> because it is closed source and proprietary is purely political.
>That
>>
>>
>>> compiler could be changed trivially *if it would be open source* or 
>>
>>> the vendor was inclined to do so. This doesn't count as technical 
>>
>>> reason.
>>
>>> 
>>
>>  I agree with Oleg's comment on this.
>>
>> 
>>
>> And btw, if a compiler can "be changed trivially" depends on details
>I
>>suppose.
>>
>> 
>>
>>> >For me the sentence "RIOT allows LGPL + proprietary source code
>
>>
>>> > at the same level of comfort compared to Linux" sounds like a
>cheap
>>
>>
>>> > marketing slogan making clear that the persons are not aware of
>the
>>
>>
>>> > IoT diversity.
>>
>>> Saying otherwise makes clear that the persons are not aware of the 
>>
>>> troubles embedded linux companies go through when developing 
>>
>>> proprietary devices using (L)GPLed linux + libraries.
>>
>>> 
>>
>>  Both systems address different types of devices.
>>
>> 
>>
>>> >From a professional point of view, I would not base strategic 
>>
>>> > decisions on the discussed PR/idea.
>>
>>> What profession would that be?
>>
>>> 
>>
>>  Having an almost complete picture of the landscape.
>>
>> 
>>
>> 
>>
>>Cheers
>>
>>  matthias
>>
>> 
>>
>>--
>>
>>Matthias Waehlisch
>>
>>.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . 
>Takustr.
>>9,
>>D-14195 Berlin, Germany ..  

Re: [riot-devel] LGPL compliance testing

[Ludwig Ortmann]

Hi Murat,

Under what license are the generated files?
And also, how do you think your port is related to the discussion in this 
thread?

I can try to talk about this topic with a cypress representative today. We are 
currently at the "embedded world" and they are too. They seemed interested in 
RIOT in an initial chat.
BTW: As far as I understood it, their software can create object files with 
library code for the psoc. Therefore I guess it should be possible to link the 
generated psoc library with RIOT in our make system as well.

So, whatever it looks like today, please don't close your pull request yet.

Cheers, Ludwig

Am 25. Februar 2015 21:46:45 MEZ, schrieb Murat CAKMAK :
>Hi All,
>
> 
>
>I was (still) busy to read mails about LGPL compliance so sorry for
>slience.
>
>
>As you know, I have initially ported RIOT to PsoC 5LP processor by
>creating
>a PsoC Creator IDE Projects. 
>
> 
>
>In my case:
>
>1.   This port not using the default RIOT build environment and
>PsoC
>Creator IDE hides linking and other details. 
>
>2.   PsoC Creator IDE also creates automatically some source codes.
>I
>have created an empty project with a small HW design under
>dist/PsoCCreator
>directory. But when you build project in PsoC Creator IDE, It is going
>to
>create a lot of files; system initialization, APIs for HW blocks which
>created for RIOT etc. I was not planning to commit those files to GIT
>repository because they are already created automatically by IDE. 
>
>3.   Auto-generated files may be changed (e.g bug fixing) by the
>version
>of PSOC Creator IDE. So, md5 sums may be different for different
>versions of
>PsoC Creator IDE.  
>
> 
>
>On the other hand, I can also implemented required files instead of
>auto-generated PsoC Creator files, and use RIOT build system. But HEX
>files
>of PsoC processors also includes HW desing code (verilog) addition to
>firmware output(elf, hex etc.). I dont know how PsoC Creator IDE merges
>Firmware code and HW design code into a single HEX file and I am not
>sure
>about PSOC Creator team share this information with me. 
>
>It is the hard way and also I dont prefer to use this way. Because, in
>this
>way, we can not use advantages(ARM Core + Programmable Digital&Analog
>Blocks) of PsoC processors which only available by PsoC Creator IDE. 
>
> 
>
>So, What is the latest decision? 
>
>Should I withdraw my "pull request" for PsoC 5LP port? 
>
> 
>
>Regards. 
>
> 
>
>Murat. 
>
> 
>
> 
>
>-Original Message-
>From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Matthias
>Waehlisch
>Sent: Saturday, February 21, 2015 5:09 PM
>To: RIOT OS kernel developers
>Subject: Re: [riot-devel] LGPL compliance testing
>
> 
>
>Hi Kaspar,
>
> 
>
>On Fri, 20 Feb 2015, Kaspar Schleiser wrote:
>
> 
>
>> Let me correct myself.
>
>> 
>
>> There are no technical reasons against using LGPLed RIOT to develop 
>
>> proprietary applications.
>
>> 
>
>  it depends on how you define "technical reasons". Yes, it is not
>impossible to create separate object files. But you maybe don't want to
>do
>this for technical optimization (see for example
>.pdf>
>http://www.htsoft.com/news/070309_Whitepaper-OmniscientCodeGeneration_FINAL.
>pdf).
>
> 
>
>> Using a "weird compiler" that cannot output the required object files
>
>
>> because it is closed source and proprietary is purely political. That
>
>
>> compiler could be changed trivially *if it would be open source* or 
>
>> the vendor was inclined to do so. This doesn't count as technical 
>
>> reason.
>
>> 
>
>  I agree with Oleg's comment on this.
>
> 
>
> And btw, if a compiler can "be changed trivially" depends on details I
>suppose.
>
> 
>
>> >For me the sentence "RIOT allows LGPL + proprietary source code 
>
>> > at the same level of comfort compared to Linux" sounds like a cheap
>
>
>> > marketing slogan making clear that the persons are not aware of the
>
>
>> > IoT diversity.
>
>> Saying otherwise makes clear that the persons are not aware of the 
>
>> troubles embedded linux companies go through when developing 
>
>> proprietary devices using (L)GPLed linux + libraries.
>
>> 
>
>  Both systems address different types of devices.
>
> 
>
>> >From a professional point of view, I would not base strategic 
>
>> > decisions on the discussed PR/idea.
>
>> What profession would that be?
>
>> 
>
>  Having an almost complete picture of the landscape.
>
> 
>
> 
>
>Cheers
>
>  matthias
>
> 
>
>--
>
>Matthias Waehlisch
>
>.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST .  Takustr.
>9,
>D-14195 Berlin, Germany ..  
>mailto:waehli...@ieee.org ..  
>http://www.inf.fu-berlin.de/~waehl
>
>:. Also:  
>http://inet.cpt.haw-hamburg.de ..
> http://www.link-lab.net
>___
>
>devel mailing list
>
> 

Re: [riot-devel] LGPL compliance testing

[Murat CAKMAK]

Hi All,

 

I was (still) busy to read mails about LGPL compliance so sorry for slience.


As you know, I have initially ported RIOT to PsoC 5LP processor by creating
a PsoC Creator IDE Projects. 

 

In my case:

1.   This port not using the default RIOT build environment and PsoC
Creator IDE hides linking and other details. 

2.   PsoC Creator IDE also creates automatically some source codes. I
have created an empty project with a small HW design under dist/PsoCCreator
directory. But when you build project in PsoC Creator IDE, It is going to
create a lot of files; system initialization, APIs for HW blocks which
created for RIOT etc. I was not planning to commit those files to GIT
repository because they are already created automatically by IDE. 

3.   Auto-generated files may be changed (e.g bug fixing) by the version
of PSOC Creator IDE. So, md5 sums may be different for different versions of
PsoC Creator IDE.  

 

On the other hand, I can also implemented required files instead of
auto-generated PsoC Creator files, and use RIOT build system. But HEX files
of PsoC processors also includes HW desing code (verilog) addition to
firmware output(elf, hex etc.). I dont know how PsoC Creator IDE merges
Firmware code and HW design code into a single HEX file and I am not sure
about PSOC Creator team share this information with me. 

It is the hard way and also I dont prefer to use this way. Because, in this
way, we can not use advantages(ARM Core + Programmable Digital&Analog
Blocks) of PsoC processors which only available by PsoC Creator IDE. 

 

So, What is the latest decision? 

Should I withdraw my "pull request" for PsoC 5LP port? 

 

Regards. 

 

Murat. 

 

 

-Original Message-
From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Matthias
Waehlisch
Sent: Saturday, February 21, 2015 5:09 PM
To: RIOT OS kernel developers
Subject: Re: [riot-devel] LGPL compliance testing

 

Hi Kaspar,

 

On Fri, 20 Feb 2015, Kaspar Schleiser wrote:

 

> Let me correct myself.

> 

> There are no technical reasons against using LGPLed RIOT to develop 

> proprietary applications.

> 

  it depends on how you define "technical reasons". Yes, it is not
impossible to create separate object files. But you maybe don't want to do
this for technical optimization (see for example

http://www.htsoft.com/news/070309_Whitepaper-OmniscientCodeGeneration_FINAL.
pdf).

 

> Using a "weird compiler" that cannot output the required object files 

> because it is closed source and proprietary is purely political. That 

> compiler could be changed trivially *if it would be open source* or 

> the vendor was inclined to do so. This doesn't count as technical 

> reason.

> 

  I agree with Oleg's comment on this.

 

  And btw, if a compiler can "be changed trivially" depends on details I
suppose.

 

> >For me the sentence "RIOT allows LGPL + proprietary source code 

> > at the same level of comfort compared to Linux" sounds like a cheap 

> > marketing slogan making clear that the persons are not aware of the 

> > IoT diversity.

> Saying otherwise makes clear that the persons are not aware of the 

> troubles embedded linux companies go through when developing 

> proprietary devices using (L)GPLed linux + libraries.

> 

  Both systems address different types of devices.

 

> >From a professional point of view, I would not base strategic 

> > decisions on the discussed PR/idea.

> What profession would that be?

> 

  Having an almost complete picture of the landscape.

 

 

Cheers

  matthias

 

--

Matthias Waehlisch

.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST .  Takustr. 9,
D-14195 Berlin, Germany ..  
mailto:waehli...@ieee.org ..  
http://www.inf.fu-berlin.de/~waehl

:. Also:   http://inet.cpt.haw-hamburg.de ..
 http://www.link-lab.net
___

devel mailing list

  devel@riot-os.org

 
http://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Switch to BSD?

[Ludwig Ortmann]

Hi,

I'm opposed to the eclipse public license because of its (L)GPL incompatibility 
and therefore to joining the Eclipse foundation.

Cheers, Ludwig

Am 25. Februar 2015 11:39:08 MEZ, schrieb Emmanuel Baccelli 
:
>Hi everyone,
>
>GPL with linking exception seems relevant in this discussion --
>especially
>since eCOS, which is also a well-known embedded OS, uses this license.
>
>As a side note, but highly related: at Embedded World yesterday, we met
>with the Eclipse Foundation [1] guys.
>RIOT is now officially invited to become an Eclipse project.
>
>There are a number of advantages to be under the Eclipse umbrella: they
>provide legal services, and the IoT part of this umbrella [2] is
>actively
>helping communities such as RIOT to grow organically: in particular
>they
>promise promotion, and matchmaking with other FOSS communities and
>relevant
>industrial partners.
>
>There are however strings attached: Eclipse has good reputation as far
>as I
>can tell, but nevertheless some of our independence is lost if we join,
>and
>we have to use the Eclipse Public License [3].
>
>In any case, the Eclipse Foundation guys were stressing that CLAs [4]
>are
>crucial, whatever we do, whether we join Eclipse Foundation or not.
>
>Best,
>
>Emmanuel
>
>
>[1] https://eclipse.org/org/foundation/
>[2] http://iot.eclipse.org
>[3] https://eclipse.org/legal/eplfaq.php#CPLEPL
>[4] http://en.wikipedia.org/wiki/Contributor_License_Agreement
>
>
>On Wed, Feb 25, 2015 at 2:28 AM, Adam Hunt  wrote:
>
>> I'd be willing to bet that GNU Classpath is one of the oldest
>projects
>> licensed under the GPL with a linking exception.
>>
>> Classpath is distributed under the terms of the GNU General Public
>License
>>> with the following clarification and special exception.
>>>
>>
>>
>> Linking this library statically or dynamically with other modules is
>>> making a combined work based on this library. Thus, the terms and
>>> conditions of the GNU General Public License cover the whole
>combination.
>>> ​​
>>>
>>
>>
>>
>> As a special exception, the copyright holders of this library give
>you
>>> permission to link this library with independent modules to produce
>an
>>> executable, regardless of the license terms of these independent
>modules,
>>> and to copy and distribute the resulting executable under terms of
>your
>>> choice, provided that you also meet, for each linked independent
>module,
>>> the terms and conditions of the license of that module. An
>independent
>>> module is a module which is not derived from or based on this
>library. If
>>> you modify this library, you may extend this exception to your
>version of
>>> the library, but you are not obliged to do so. If you do not wish to
>do so,
>>> delete this exception statement from your version.
>>> ​[1 ]​
>>>
>>
>> ​--adam​
>>
>>
>> ​[1] https://www.gnu.org/software/classpath/license.html​
>>
>>
>> On Tue Feb 24 2015 at 5:08:12 PM Oleg Hahm 
>wrote:
>>
>>> Hi Matthias!
>>>
>>> >   but the name (or license branding). We had this discussion
>before.
>>> > Rather unknown licenses need to be explained. Using eCos license
>is
>>> > similar to use a RIOT license.
>>>
>>> Yes, I agree, but at least it's listed (approved?) by FSF. Another
>option
>>> (see
>>> citation from the OSI list from my previous mail) we could just
>state GPL
>>> as a
>>> license and point to the exception for commercial users. I think the
>text
>>> on
>>> the eCos page is pretty comprehensible.
>>>
>>> The Wikipedia is even claiming that the perception "that without
>applying
>>> the
>>> linking exception, code linked with GPL code may only be done using
>a
>>> GPL-compatible license" is "unsupported by any legal precedent or
>>> citation".
>>>
>>> >   I'm just wondering if eCos is the first license with the
>introduced
>>> > exception -- I will not research on this ;).
>>>
>>> I don't think so, but it's the only listed license from FSF that
>>> specifies the
>>> linking exception.
>>>
>>> >   I never said it's impossible. In this type of discussion you
>will
>>> > always find counterexamples. I just wanted to point out that I see
>it as
>>> > an advantage to use an OSI approved license.
>>>
>>> I agree, but if the choice is between a FSF approved license (as I
>>> understand
>>> eCos License is) that matches our needs and a less matching OSI
>approved
>>> license, I'm willing to bite this bullet.
>>>
>>> > > At least eCos, ERIKA and ChibiOS are very similar to RIOT from a
>>> > > software architecture point of view (OS for embedded hardware).
>>> > >
>>> >   No comment ;).
>>>
>>> For clarification: I was referring to the fact that these systems
>have a
>>> similar use case as RIOT, not that there concept or feature set is
>>> similar to
>>> RIOT.
>>>
>>> > > Long story short: I see your concerns, but for me GPL + Linking
>>> > > Exception is a common license model that works well for many
>>> > > well-known and mature projects. Personally, I would think t

Re: [riot-devel] Switch to BSD?

[Jan Wagner]

argh - license madness - lets add some complexity fe. tri-licensed like jruby :)
https://github.com/jruby/jruby/blob/master/COPYING
 
let riot stay as independet and open as possible please - thats my only concern.
i see the websites of iot-ubuntu, iot-"mbed'a likes, iot-eclipse,
and for my personal view its looks like some "business strategy" that has less
and less todo with technical or "co-development" reasons.
 
Jan

> Emmanuel Baccelli  hat am 25. Februar 2015 um
> 11:39 geschrieben:
> 
>  Hi everyone,
> 
>  GPL with linking exception seems relevant in this discussion -- especially
> since eCOS, which is also a well-known embedded OS, uses this license.
>   
>  As a side note, but highly related: at Embedded World yesterday, we met with
> the Eclipse Foundation [1] guys.
>  RIOT is now officially invited to become an Eclipse project.
>   
>  There are a number of advantages to be under the Eclipse umbrella: they
> provide legal services, and the IoT part of this umbrella [2] is actively
> helping communities such as RIOT to grow organically: in particular they
> promise promotion, and matchmaking with other FOSS communities and relevant
> industrial partners.
>   
>  There are however strings attached: Eclipse has good reputation as far as I
> can tell, but nevertheless some of our independence is lost if we join, and we
> have to use the Eclipse Public License [3].
>   
>  In any case, the Eclipse Foundation guys were stressing that CLAs [4] are
> crucial, whatever we do, whether we join Eclipse Foundation or not.
>   
>  Best,
>   
>  Emmanuel
>   
>   
>  [1] https://eclipse.org/org/foundation/
>  [2] http://iot.eclipse.org
>  [3] https://eclipse.org/legal/eplfaq.php#CPLEPL
>  [4] http://en.wikipedia.org/wiki/Contributor_License_Agreement
>   
> 
>  On Wed, Feb 25, 2015 at 2:28 AM, Adam Hunt   > wrote:
>> >I'd be willing to bet that GNU Classpath is one of the oldest
>> > projects licensed under the GPL with a linking exception.
> > 
> >  > > > Classpath is distributed under the terms of the GNU General
> >  > > > Public License with the following clarification and special
> >  > > > exception.
> > >> >  > > >> >  > > > Linking this library statically or
> > >> >  > > >> >  > > > dynamically with other modules is
> > >> >  > > >> >  > > > making a combined work based on this
> > >> >  > > >> >  > > > library. Thus, the terms and
> > >> >  > > >> >  > > > conditions of the GNU General Public
> > >> >  > > >> >  > > > License cover the whole combination.
> > >> >  > > >> >  > > > As a special exception, the copyright
> > >> >  > > >> >  > > > holders of this library give you
> > >> >  > > >> >  > > > permission to link this library with
> > >> >  > > >> >  > > > independent modules to produce an
> > >> >  > > >> >  > > > executable, regardless of the license
> > >> >  > > >> >  > > > terms of these independent modules,
> > >> >  > > >> >  > > > and to copy and distribute the
> > >> >  > > >> >  > > > resulting executable under terms of
> > >> >  > > >> >  > > > your choice, provided that you also
> > >> >  > > >> >  > > > meet, for each linked independent
> > >> >  > > >> >  > > > module, the terms and conditions of
> > >> >  > > >> >  > > > the license of that module. An
> > >> >  > > >> >  > > > independent module is a module which
> > >> >  > > >> >  > > > is not derived from or based on this
> > >> >  > > >> >  > > > library. If you modify this library,
> > >> >  > > >> >  > > > you may extend this exception to your
> > >> >  > > >> >  > > > version of the library, but you are
> > >> >  > > >> >  > > > not obliged to do so. If you do not
> > >> >  > > >> >  > > > wish to do so, delete this exception
> > >> >  > > >> >  > > > statement from your version.
> > >  [ 1  ]
> > >> > 
> >--adam
> > 
> >[1] https://www.gnu.org/software/classpath/license.html
> > 
> >On Tue Feb 24 2015 at 5:08:12 PM Oleg Hahm < oliver.h...@inria.fr
> >  > wrote:
> >  > > >  Hi Matthias!
> > > 
> > >  > but the name (or license branding). We had this discussion before.
> > >  > Rather unknown licenses need to be explained. Using eCos license is
> > >  > similar to use a RIOT license.
> > > 
> > >  Yes, I agree, but at least it's listed (approved?) by FSF. Another
> > > option (see
> > >  citation from the OSI list from my previous mail) we could just state
> > > GPL as a
> > >  license and point to the exception for commercial 

Re: [riot-devel] Switch to BSD?

[Emmanuel Baccelli]

Hi everyone,

GPL with linking exception seems relevant in this discussion -- especially
since eCOS, which is also a well-known embedded OS, uses this license.

As a side note, but highly related: at Embedded World yesterday, we met
with the Eclipse Foundation [1] guys.
RIOT is now officially invited to become an Eclipse project.

There are a number of advantages to be under the Eclipse umbrella: they
provide legal services, and the IoT part of this umbrella [2] is actively
helping communities such as RIOT to grow organically: in particular they
promise promotion, and matchmaking with other FOSS communities and relevant
industrial partners.

There are however strings attached: Eclipse has good reputation as far as I
can tell, but nevertheless some of our independence is lost if we join, and
we have to use the Eclipse Public License [3].

In any case, the Eclipse Foundation guys were stressing that CLAs [4] are
crucial, whatever we do, whether we join Eclipse Foundation or not.

Best,

Emmanuel


[1] https://eclipse.org/org/foundation/
[2] http://iot.eclipse.org
[3] https://eclipse.org/legal/eplfaq.php#CPLEPL
[4] http://en.wikipedia.org/wiki/Contributor_License_Agreement


On Wed, Feb 25, 2015 at 2:28 AM, Adam Hunt  wrote:

> I'd be willing to bet that GNU Classpath is one of the oldest projects
> licensed under the GPL with a linking exception.
>
> Classpath is distributed under the terms of the GNU General Public License
>> with the following clarification and special exception.
>>
>
>
> Linking this library statically or dynamically with other modules is
>> making a combined work based on this library. Thus, the terms and
>> conditions of the GNU General Public License cover the whole combination.
>> ​​
>>
>
>
>
> As a special exception, the copyright holders of this library give you
>> permission to link this library with independent modules to produce an
>> executable, regardless of the license terms of these independent modules,
>> and to copy and distribute the resulting executable under terms of your
>> choice, provided that you also meet, for each linked independent module,
>> the terms and conditions of the license of that module. An independent
>> module is a module which is not derived from or based on this library. If
>> you modify this library, you may extend this exception to your version of
>> the library, but you are not obliged to do so. If you do not wish to do so,
>> delete this exception statement from your version.
>> ​[1 ]​
>>
>
> ​--adam​
>
>
> ​[1] https://www.gnu.org/software/classpath/license.html​
>
>
> On Tue Feb 24 2015 at 5:08:12 PM Oleg Hahm  wrote:
>
>> Hi Matthias!
>>
>> >   but the name (or license branding). We had this discussion before.
>> > Rather unknown licenses need to be explained. Using eCos license is
>> > similar to use a RIOT license.
>>
>> Yes, I agree, but at least it's listed (approved?) by FSF. Another option
>> (see
>> citation from the OSI list from my previous mail) we could just state GPL
>> as a
>> license and point to the exception for commercial users. I think the text
>> on
>> the eCos page is pretty comprehensible.
>>
>> The Wikipedia is even claiming that the perception "that without applying
>> the
>> linking exception, code linked with GPL code may only be done using a
>> GPL-compatible license" is "unsupported by any legal precedent or
>> citation".
>>
>> >   I'm just wondering if eCos is the first license with the introduced
>> > exception -- I will not research on this ;).
>>
>> I don't think so, but it's the only listed license from FSF that
>> specifies the
>> linking exception.
>>
>> >   I never said it's impossible. In this type of discussion you will
>> > always find counterexamples. I just wanted to point out that I see it as
>> > an advantage to use an OSI approved license.
>>
>> I agree, but if the choice is between a FSF approved license (as I
>> understand
>> eCos License is) that matches our needs and a less matching OSI approved
>> license, I'm willing to bite this bullet.
>>
>> > > At least eCos, ERIKA and ChibiOS are very similar to RIOT from a
>> > > software architecture point of view (OS for embedded hardware).
>> > >
>> >   No comment ;).
>>
>> For clarification: I was referring to the fact that these systems have a
>> similar use case as RIOT, not that there concept or feature set is
>> similar to
>> RIOT.
>>
>> > > Long story short: I see your concerns, but for me GPL + Linking
>> > > Exception is a common license model that works well for many
>> > > well-known and mature projects. Personally, I would think that GPL +
>> > > Linking Exception matches our needs far better than LGPL.
>> > >
>> >   Can you explain in one our two sentences why? Because it's more
>> > inclusive?
>>
>> Again taken from the Wikipedia article: "the LGPL formulates more
>> requirements
>> to the linking exception: you must allow modification of the portions of
>> the
>> library you use and rever