Re: [riot-devel] LGPL compliance testing
Thanks Martine, You are right. I have created new pull request to : https://github.com/RIOT-OS/RIOT/pull/2501 It is my first GIT and GITHUB experience :) Regards. Murat. From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Martine Lenders Sent: Thursday, February 26, 2015 11:46 PM To: RIOT OS kernel developers Subject: Re: [riot-devel] LGPL compliance testing Hi Murat, You made the PR to your own repository. You have to open a Pull Request to our repository. Hope I could help, Martine 2015-02-26 16:56 GMT+01:00 Murat CAKMAK mailto:m...@muratcakmak.net> >: Hi Ludwig, Pull request link : https://github.com/cakmakmurat2000/RIOT/pull/1 It is my first GIT experience. I might miss something :) Regards. -Original Message- From: devel [mailto:devel-boun...@riot-os.org <mailto:devel-boun...@riot-os.org> ] On Behalf Of Ludwig Ortmann Sent: Thursday, February 26, 2015 8:32 AM To: RIOT OS kernel developers Subject: Re: [riot-devel] LGPL compliance testing 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 mailto:ludwig.ortm...@fu-berlin.de> >: >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 >mailto:m...@muratcakmak.net> >: >>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 >><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 depen
Re: [riot-devel] LGPL compliance testing
Hi Murat, You made the PR to your own repository. You have to open a Pull Request to our repository. Hope I could help, Martine 2015-02-26 16:56 GMT+01:00 Murat CAKMAK : > Hi Ludwig, > > Pull request link : https://github.com/cakmakmurat2000/RIOT/pull/1 > It is my first GIT experience. I might miss something :) > > Regards. > > -Original Message- > From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Ludwig Ortmann > Sent: Thursday, February 26, 2015 8:32 AM > To: RIOT OS kernel developers > Subject: Re: [riot-devel] LGPL compliance testing > > 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. > >&
Re: [riot-devel] LGPL compliance testing
Hi Ludwig, Pull request link : https://github.com/cakmakmurat2000/RIOT/pull/1 It is my first GIT experience. I might miss something :) Regards. -Original Message- From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Ludwig Ortmann Sent: Thursday, February 26, 2015 8:32 AM To: RIOT OS kernel developers Subject: Re: [riot-devel] LGPL compliance testing 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 >><http://www.htsoft.com/news/070309_Whitepaper-OmniscientCodeGeneration >>_FINAL >>.pdf> >>http://www.htsoft.com/news/070309_Whitepaper-OmniscientCodeGeneration_FINA L. >>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 woul
Re: [riot-devel] LGPL compliance testing
Hi, On 02/25/2015 09:46 PM, Murat CAKMAK wrote: So, What is the latest decision? No decision, yet. Stay tuned. ;) Should I withdraw my “pull request” for PsoC 5LP port? Definately not. I guess whatever the license discussion will lead to, it will be possible to use that port even for proprietary application. Kaspar ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing
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 >><http://www.htsoft.com/news/070309_Whitepaper-OmniscientCodeGeneration_FINAL >>.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 >>sup
Re: [riot-devel] LGPL compliance testing
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 ><http://www.htsoft.com/news/070309_Whitepaper-OmniscientCodeGeneration_FINAL >.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 > >> > decis
Re: [riot-devel] LGPL compliance testing
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> 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> mailto:waehli...@ieee.org .. <http://www.inf.fu-berlin.de/~waehl> http://www.inf.fu-berlin.de/~waehl :. Also: <http://inet.cpt.haw-hamburg.de> http://inet.cpt.haw-hamburg.de .. <http://www.link-lab.net> http://www.link-lab.net ___ devel mailing list <mailto:devel@riot-os.org> devel@riot-os.org <http://lists.riot-os.org/mailman/listinfo/devel> 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] 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
Re: [riot-devel] LGPL compliance testing - This is just to state an opinion of a different kind :-)
Hi, On 02/20/15 13:50, Thomas C. Schmidt wrote: sorry to interrupt here: You are discussing the question whether Linux is available for more hardware than RIOT ??? No. We're discussing if developing proprietary products using RIOT is comparable to developing proprietary products using embedded Linux. Kaspar ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing - This is just to state an opinion of a different kind :-)
Hi guys, sorry to interrupt here: You are discussing the question whether Linux is available for more hardware than RIOT ??? Even though this discussion may be a nice amusing chat for tea time (imagining a 'native port' of Linux running as a RIOT Thread, RIOT on a CRAY Supercomputer, RIOT operating the fridge of the Space Shuttle), it seems completely irrelevant with respect to the subject "LGPL compliance testing". Instead of broadening the debate further and further, I would very much like to see this subject converge ... and vanish. If I remember correctly, we had a pretty convergent perspective about half a year ago ... and nothing new or relevant has sprung to my eyes since then. May be I miss important details ... but I'm actually more attached to moving forward than discussing in widest broadness. Cheers & happy weekend Thomas On 20.02.2015 13:35, Emmanuel Baccelli wrote: Hi Matthias, On Thu, Feb 19, 2015 at 11:47 PM, Matthias Waehlisch mailto:m.waehli...@fu-berlin.de>> wrote: Hi Kaspar, sorry for the silence! As you pointed out in your email, there are scenarios where the approach will not help due to technical reasons (and using a weird compiler might have technical reasons as well). You may consider these as irrelevant. But there is one aspect for sure in the IoT, the IoT is much more heterogenous compared to the current Internet. This is a crucial difference making the approach less suitable compared to developing for Linux, for example. 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. Linux runs on a wide variety of 32bit and 64bit hardware. RIOT aims to do the same on other (smaller) hardware, for a wide variety of 32bit, 16bit (and to some extent 8bit) platforms. At first sight, I don't see a huge difference here in terms of heterogeneity. How would you quantify/qualify this difference? Best Emmanuel -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing
Hi Matthias, On Thu, Feb 19, 2015 at 11:47 PM, Matthias Waehlisch < m.waehli...@fu-berlin.de> wrote: > Hi Kaspar, > > sorry for the silence! > > As you pointed out in your email, there are scenarios where the > approach will not help due to technical reasons (and using a weird > compiler might have technical reasons as well). You may consider these > as irrelevant. But there is one aspect for sure in the IoT, the IoT is > much more heterogenous compared to the current Internet. This is a > crucial difference making the approach less suitable compared to > developing for Linux, for example. > > 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. > > Linux runs on a wide variety of 32bit and 64bit hardware. RIOT aims to do the same on other (smaller) hardware, for a wide variety of 32bit, 16bit (and to some extent 8bit) platforms. At first sight, I don't see a huge difference here in terms of heterogeneity. How would you quantify/qualify this difference? Best Emmanuel ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing
Hi, On 02/20/15 13:07, Emmanuel Baccelli wrote: 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. What do you mean by "proprietary device"? Routers, access points, media players, smartphones, ... Any device combining e.g., Linux with proprietary code. Kaspar ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing
Hi Kaspar, On Fri, Feb 20, 2015 at 12:24 PM, Kaspar Schleiser wrote: > Hey Matthias, > > On 02/19/15 23:47, Matthias Waehlisch wrote: > >>As you pointed out in your email, there are scenarios where the >> approach will not help due to technical reasons (and using a weird >> compiler might have technical reasons as well). You may consider these >> as irrelevant. But there is one aspect for sure in the IoT, the IoT is >> much more heterogenous compared to the current Internet. This is a >> crucial difference making the approach less suitable compared to >> developing for Linux, for example. >> > Interesting how technical reasons are the main point you've read out my > email. > > Let me correct myself. > > There are no technical reasons against using LGPLed RIOT to develop > proprietary applications. > > 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. > > 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. > > What do you mean by "proprietary device"? From a professional point of view, I would not base strategic >> decisions on the discussed PR/idea. >> > What profession would that be? > > LGPL *is* putting restrictions on how and where the code is used. > That's the whole idea of a copyleft license. > > Kaspar > > ___ > 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] LGPL compliance testing
Hi, On 02/20/15 12:41, Oleg Hahm wrote: 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. It's a political reason for the compiler vendor/provider - not for the person or company that wants to use RIOT and has to do it with that compiler for technical reasons. Opting for a device or environment that forces the use of such a compiler is a non-technical (political) decision by that person or company. Expecting the RIOT community to take that into account when deciding how to write code (see pointer discussion) or how to excercise our copyright is twisted. LGPL *is* putting restrictions on how and where the code is used. That's the whole idea of a copyleft license. Isn't there a "not" missing in your sentence? It's the other way around: "Copyleft guarantees that every user has freedom." (https://www.gnu.org/copyleft/) Which implicitly removes the freedom to take that freedom from others. That's the restriction. It's like, your liberty to swing your arm ends where my nose begins. Unrestricted freedom leads to a world of pain. Kaspar ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing
Hey Kaspar! > 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. It's a political reason for the compiler vendor/provider - not for the person or company that wants to use RIOT and has to do it with that compiler for technical reasons. > LGPL *is* putting restrictions on how and where the code is used. > That's the whole idea of a copyleft license. Isn't there a "not" missing in your sentence? It's the other way around: "Copyleft guarantees that every user has freedom." (https://www.gnu.org/copyleft/) Cheers, Oleg -- If no space is available nothing happens. RIOT/sys/net/include/pktbuf.h pgptpNg2_oJZ3.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing
Hey Matthias, On 02/19/15 23:47, Matthias Waehlisch wrote: As you pointed out in your email, there are scenarios where the approach will not help due to technical reasons (and using a weird compiler might have technical reasons as well). You may consider these as irrelevant. But there is one aspect for sure in the IoT, the IoT is much more heterogenous compared to the current Internet. This is a crucial difference making the approach less suitable compared to developing for Linux, for example. Interesting how technical reasons are the main point you've read out my email. Let me correct myself. There are no technical reasons against using LGPLed RIOT to develop proprietary applications. 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. 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. From a professional point of view, I would not base strategic decisions on the discussed PR/idea. What profession would that be? LGPL *is* putting restrictions on how and where the code is used. That's the whole idea of a copyleft license. Kaspar ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing
Hi Kaspar, sorry for the silence! As you pointed out in your email, there are scenarios where the approach will not help due to technical reasons (and using a weird compiler might have technical reasons as well). You may consider these as irrelevant. But there is one aspect for sure in the IoT, the IoT is much more heterogenous compared to the current Internet. This is a crucial difference making the approach less suitable compared to developing for Linux, for example. 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. From a professional point of view, I would not base strategic decisions on the discussed PR/idea. Cheers matthias On Mon, 16 Feb 2015, Kaspar Schleiser wrote: > Hi Matthias, > > On 02/16/15 01:39, Matthias Waehlisch wrote: > > all IoT scenarios. You gave one example -- I wouldn't claim general > > applicability. > Agreed. > > >Several concerns have already been raised that developing for the IoT > > world is not the same as developing for the non-IoT world. Separating > > objects files might help in some cases. Other cases are described here, > > for example: > > https://www.tablix.org/~avian/blog/archives/2013/03/contiki_and_libopencm3_licensing/ > Let me try to describe how RIOT licensed under LGPL relates to the examples > given in the article (all quotes taken from that site): > > "I can see how this can be hard to comply with from the point of the typical > firmware developer. Such linking requires an unusual build process that might > be hard to setup in IDEs. Additionally, modern visual tools often hide the > object files and linking details completely. Using proprietary compilers it > might even be impossible to have any kind of portable binary objects. In any > way, this is seen by some as enough of a hurdle to make reimplementation of > LGPL code easier than complying with the license." > > As RIOT typically is not a library that is supposed to be linked into some > already working environment, but actually a whole OS coming with it's own > build system, using it's code from whithin a completely different build system > (e.g., one that comes with a proprietary IDE) can either be trivial or a > fundamental change to RIOT. > It would be trivial if the IDE can use RIOT's make based build system, > including easy seperation of object files. > If, on the other hand, a proprietary compiler/linker for proprietary hardware > is being used to compile RIOT's code, bypassing RIOT's build system, it might > indeed be hard to comply to LGPL's requirements. > That would be the case if the proprietary build system cannot be configured to > output proprietary object files seperatly and offer the possibility to link > precompiled object files during the build process. > > While I personally wouldn't use such restricting development environments in > the first place, using RIOT for proprietary development here probably wouldn't > be feasible. > > Does anyone have examples of such environments? > Maybe PsoC Creator IDE falls in this category? > > "First such case was where software modification can enable fraud (for > instance energy meters) or make the device illegal to use (for instance due to > FCC requirements for radio equipment) or both. In a lot of these cases however > there is a very simple answer: if the user does not own the device (as is > usually the case for metering equipment), no license requires the owner to > enable software modification or even disclose the source code. Where that is > not the case, usually the technical means are only one part of the story. The > user can be bound by a contract not to change particular aspects of the device > and subject to inspections. The anti-tivoization clause also does not prevent > tampering indicators. However it might be that in some cases software covered > by anti-tivoization might simply not be usable in practice." > > Fraud or radio equipment abuse can easily be prevented using LGPLed RIOT, by > keeping the respecting code proprietary. Distributing the object files does > not make this any harder from a technical point of view. > > "make the device illegal to use (for instance due to FCC requirements for > radio equipment)" -> as LGPLed RIOT allows completely proprietary drivers, the > code to actually drive the radio hardware can be as proprietary and close as > with a BSDed OS codebase. Distributing the object files doesn't make tempering > with the radio hardware fundamentally different than if having to extract the > (binary) firmware from the device before changing the compiled radio code. > (This assuming that the compiled binaries for a fully proprietary radio device > are never distributed apart from the actual hardware, which is usually not the > case, even for locked-in GSM modems as found on our smart phones). > > If law
Re: [riot-devel] LGPL compliance testing
Hey Kaspar! > While I personally wouldn't use such restricting development environments in > the first place, using RIOT for proprietary development here probably > wouldn't be feasible. Well, that's not always feasible. I remember that my old company was somehow forced to use a proprietary IDE (we decided for IAR), because our customer decided for the MSP430F5x which was not supported by gcc back then. > Does anyone have examples of such environments? > Maybe PsoC Creator IDE falls in this category? I don't recall if the IAR IDE/compiler can be configured to produce separated binary files. Maybe people from OpenWSN community can answer this since they're supporting IAR as well. Cheers, Oleg -- The best thing about declarative jokes is that you only have to prescribe laughter, no need to actually tell the joke. pgpTO1tA1sN8_.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing
Hi Matthias, On 02/16/15 01:39, Matthias Waehlisch wrote: all IoT scenarios. You gave one example -- I wouldn't claim general applicability. Agreed. Several concerns have already been raised that developing for the IoT world is not the same as developing for the non-IoT world. Separating objects files might help in some cases. Other cases are described here, for example: https://www.tablix.org/~avian/blog/archives/2013/03/contiki_and_libopencm3_licensing/ Let me try to describe how RIOT licensed under LGPL relates to the examples given in the article (all quotes taken from that site): "I can see how this can be hard to comply with from the point of the typical firmware developer. Such linking requires an unusual build process that might be hard to setup in IDEs. Additionally, modern visual tools often hide the object files and linking details completely. Using proprietary compilers it might even be impossible to have any kind of portable binary objects. In any way, this is seen by some as enough of a hurdle to make reimplementation of LGPL code easier than complying with the license." As RIOT typically is not a library that is supposed to be linked into some already working environment, but actually a whole OS coming with it's own build system, using it's code from whithin a completely different build system (e.g., one that comes with a proprietary IDE) can either be trivial or a fundamental change to RIOT. It would be trivial if the IDE can use RIOT's make based build system, including easy seperation of object files. If, on the other hand, a proprietary compiler/linker for proprietary hardware is being used to compile RIOT's code, bypassing RIOT's build system, it might indeed be hard to comply to LGPL's requirements. That would be the case if the proprietary build system cannot be configured to output proprietary object files seperatly and offer the possibility to link precompiled object files during the build process. While I personally wouldn't use such restricting development environments in the first place, using RIOT for proprietary development here probably wouldn't be feasible. Does anyone have examples of such environments? Maybe PsoC Creator IDE falls in this category? "First such case was where software modification can enable fraud (for instance energy meters) or make the device illegal to use (for instance due to FCC requirements for radio equipment) or both. In a lot of these cases however there is a very simple answer: if the user does not own the device (as is usually the case for metering equipment), no license requires the owner to enable software modification or even disclose the source code. Where that is not the case, usually the technical means are only one part of the story. The user can be bound by a contract not to change particular aspects of the device and subject to inspections. The anti-tivoization clause also does not prevent tampering indicators. However it might be that in some cases software covered by anti-tivoization might simply not be usable in practice." Fraud or radio equipment abuse can easily be prevented using LGPLed RIOT, by keeping the respecting code proprietary. Distributing the object files does not make this any harder from a technical point of view. "make the device illegal to use (for instance due to FCC requirements for radio equipment)" -> as LGPLed RIOT allows completely proprietary drivers, the code to actually drive the radio hardware can be as proprietary and close as with a BSDed OS codebase. Distributing the object files doesn't make tempering with the radio hardware fundamentally different than if having to extract the (binary) firmware from the device before changing the compiled radio code. (This assuming that the compiled binaries for a fully proprietary radio device are never distributed apart from the actual hardware, which is usually not the case, even for locked-in GSM modems as found on our smart phones). If law dictates that the compiled obect files or firmware must not be distributed seperately from the device in question, LGPLed RIOT cannot be used. "The other case was where changed firmware can have harmful effects. Some strong opinions were voiced that people hacking firmware on certain dangerous devices can not know enough not to be a danger to their surroundings. This is certainly a valid concern, but the question I see is, why suddenly draw the line at firmware modification?" IMHO the argument that a hackable device which might do harm if improperly hacked should be "hardened" using closed source is complete bullshit. I fail to see a valid example that is specific to object file distribution when using an LGPLed base OS. The article has some more points regarding anti-tivoization, wich do not apply to LGPLv2.1 as it doesn't have those clauses. To summarize, some use cases might be impossible or not feasible using LGPLed RIOT. LGPL is a copyleft lic
Re: [riot-devel] LGPL compliance testing
Hi Kaspar, I already understood your point that generating separate object files helps to comply with the LGPL requirements (http://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic). My point was: What you introduced does not bring a fundamental difference to what we had before. In particular, it is unclear if this approach works for all IoT scenarios. You gave one example -- I wouldn't claim general applicability. Several concerns have already been raised that developing for the IoT world is not the same as developing for the non-IoT world. Separating objects files might help in some cases. Other cases are described here, for example: https://www.tablix.org/~avian/blog/archives/2013/03/contiki_and_libopencm3_licensing/ Cheers matthias On Fri, 13 Feb 2015, Kaspar Schleiser wrote: > Hi Matthias, > > On 02/13/15 11:49, Matthias Waehlisch wrote: > > the core technical argument that you gave is: Your approach simplifies > > compliance check. Simplification is nice but does not introduce > > additional new functions in principle. From this perspective I don't see > > how this approach allows us to do things that we have not been able to > > do before (except we can do it 'easier'). Would you agree on this? > Not sure what you mean. > > This is not a technical tool for anything. Complying to LGPL is *easy*, and > this makes it even easier. > > Part of the license discussion was the question how developers can develop > proprietary (closed source) applications / products using LGPLed RIOT. > > LGPL puts some restrictions on doing that, it is a copyleft license. > > Those restrictions require the vendor of such an application to provide a way > to relink the proprietary code with a newer version of the used library (RIOT > in this case). > > So I created a make target which packs together everything needed to comply to > that part of the license. > > Anyone using RIOT for building proprietary application now has an easy method > of providing the files needed for that part of LGPL compliancy, "the files" > meaning compiled object files. Those that would have been shipped as part of a > firmware file anyways. They don't expose more code than a full compiled > binary, it's the same. > > Compared to other systems, any proprietary binary using an LGPLed library > (e.g., the GNU libc used on all major Linux distributions) implicitly ships > compiled object files and allows relinking. > > As RIOT uses static linking, the proprietary object files have to be saved > before completing the static link in order to enable replacing the LGPLed part > later. This is basically all this PR tries to make supertrivial. > > IMHO this does make developing proprietary code using LPGLed RIOT comparable > to writing any proprietary application for other systems like Linux, MacOS, > Windows, ... with slight differences only because of the nature of embedded > systems. > > Kaspar > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > -- 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
Re: [riot-devel] LGPL compliance testing
Hi, On 02/13/15 17:59, Emmanuel Baccelli wrote: Can we claim that this solution offers the same level of "comfort" than bearing with LGPL + closed source in other well-known contexts (for example: Linux + closed source), which we could refer to ? This "solution" just makes the neccessary steps to comply to LGPL, which are technically trivial but hard-to-understand for anyone not into linking, dead easy. IMHO, this enables developing proprietary applications for RIOT with the same level of comfort as, e.g., developing any proprietary application for Linux using LGPLed libraries (which probably means all as even the GNU C library used on all major Linux distributions is LGPL). Kaspar ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing
Hi Matthias, On 02/13/15 11:49, Matthias Waehlisch wrote: the core technical argument that you gave is: Your approach simplifies compliance check. Simplification is nice but does not introduce additional new functions in principle. From this perspective I don't see how this approach allows us to do things that we have not been able to do before (except we can do it 'easier'). Would you agree on this? Not sure what you mean. This is not a technical tool for anything. Complying to LGPL is *easy*, and this makes it even easier. Part of the license discussion was the question how developers can develop proprietary (closed source) applications / products using LGPLed RIOT. LGPL puts some restrictions on doing that, it is a copyleft license. Those restrictions require the vendor of such an application to provide a way to relink the proprietary code with a newer version of the used library (RIOT in this case). So I created a make target which packs together everything needed to comply to that part of the license. Anyone using RIOT for building proprietary application now has an easy method of providing the files needed for that part of LGPL compliancy, "the files" meaning compiled object files. Those that would have been shipped as part of a firmware file anyways. They don't expose more code than a full compiled binary, it's the same. Compared to other systems, any proprietary binary using an LGPLed library (e.g., the GNU libc used on all major Linux distributions) implicitly ships compiled object files and allows relinking. As RIOT uses static linking, the proprietary object files have to be saved before completing the static link in order to enable replacing the LGPLed part later. This is basically all this PR tries to make supertrivial. IMHO this does make developing proprietary code using LPGLed RIOT comparable to writing any proprietary application for other systems like Linux, MacOS, Windows, ... with slight differences only because of the nature of embedded systems. Kaspar ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing
Hi everyone, for me it is unclear what are the technical limitations of the approach proposed by Kaspar (I am not a specialist in static/dynamic linking issues). Can we claim that this solution offers the same level of "comfort" than bearing with LGPL + closed source in other well-known contexts (for example: Linux + closed source), which we could refer to ? If yes: we might have both a technical method and a powerful argument that is easy to grasp for most people. If no: what do we have exactly? Best, Emmanuel On Fri, Feb 13, 2015 at 11:49 AM, Matthias Waehlisch < m.waehli...@fu-berlin.de> wrote: > Hi Kaspar, > > the core technical argument that you gave is: Your approach simplifies > compliance check. Simplification is nice but does not introduce > additional new functions in principle. From this perspective I don't see > how this approach allows us to do things that we have not been able to > do before (except we can do it 'easier'). Would you agree on this? > > Please note that I explicitly do not discuss if the simplification is > useful or not (actually, I think the simplification is questionable) > because I don't think that this the point now. > > > Cheers > matthias > > On Thu, 12 Feb 2015, Kaspar Schleiser wrote: > > > Hi, > > > > On 02/11/15 16:36, Matthias Waehlisch wrote: > > > > So in theory, developers shouldn't be able to affect the system .a's > > > > files. > > > > And I can't think of anything that might do so by accident, when a > > > > developer > > > > *wants* to be LGPL compliant, just writes an application, maybe adds > a > > > > proprietary driver but otherwise "behaves" regarding build system > > > > manipulation. > > > > > > >I think that was a misunderstanding. I was more asking about the > > > "realm" of applications. The counter-arguments we had in the LGPL > > > discussion were not primarily "can we proof LGPL compliance" but more > > > "can we build reasonable, proprietary IoT applications" without > > > violating LGPL compliance. > > Well, yes we can. There's just no perfect way of proving an application > is > > compliant. > > > > Assuming RIOT is already ported to a specific device, writing any > proprietary > > application on top of that, even adding drivers for proprietary > hardware, is > > possible without violating LGPL. > > > > A basic RIOT port (not including drivers for all components) for the > target > > probably needs to be LGPLed, though. > > > > Our "method" here offers a make target that makes it easy to distribute > > everything necessary to enable re-linking, thus complying with that part > of > > the LGPL. For everyone wanting to stay LGPL-compliant, this is > > useful. > > > > > > There are probably a million ways to sneak in modified RIOT code and > still > > > > have a valid verification using our method here. > > > > So even if the verification passes, that alone is not proof that LGPL > > > > hasn't > > > > been violated. > > > > > > >From a legal perspective it then seems worthless. > > Probably right. But there is no technical way to prove any license > compliancy > > while keeping some code closed. > > > > OTOH, the benefit of modifying RIOT itself and concealing it has *no* > > commercially viable use case to me, while being a huge burden on the > > development itself compared to just sharing the modifications in the > first > > place. > > > > So anyone writing a proprietary application and distributing it like this > > method proposes very probably complies to LGPL. > > > > Everyone else would just not mention RIOT and ship it's product breaking > LGPL, > > as the criminal energy to be not license compliant is there and going > through > > the pain of pretending to be compliant just doesn't make sense. > > > > Also, if any project passes this verification and *is* compliant, one <5 > > minute possibly NDAed look at the actual proprietary code would prove > that > > nothing is concealed, making the defense to any "you are not compliant" > > accusations extremely easy. > > > > That works the other way, too. If someone distributes code in this > method's > > manner but conceals dirty tricks in order to ship LGPL breaking code, a > <5 > > minute look would uncover such tricks. > > > > So while this doesn't give legal proof, it makes making a case for the > actual > > "truth" (proving compliancy / proving non-compliancy) a lot easier. > > > > Anything passing this verification, but breaking LGPL on purpose is > easily > > spotted with one look at the actual code. > > >To be honest: I like the idea from an exercise point of view but I > > > don't see how this approach can help us wrt the license discussion. > > I don't agree. > > > > LGPL requires distribution of proprietary object files and everything > else to > > enable re-linking the LGPLed code with the proprietary code. > > This make target makes exactly that very easy, removing most if not all > > developer time consuming aspects of LGPL compliancy. > > > > IMHO this e
Re: [riot-devel] LGPL compliance testing
Hi Kaspar, the core technical argument that you gave is: Your approach simplifies compliance check. Simplification is nice but does not introduce additional new functions in principle. From this perspective I don't see how this approach allows us to do things that we have not been able to do before (except we can do it 'easier'). Would you agree on this? Please note that I explicitly do not discuss if the simplification is useful or not (actually, I think the simplification is questionable) because I don't think that this the point now. Cheers matthias On Thu, 12 Feb 2015, Kaspar Schleiser wrote: > Hi, > > On 02/11/15 16:36, Matthias Waehlisch wrote: > > > So in theory, developers shouldn't be able to affect the system .a's > > > files. > > > And I can't think of anything that might do so by accident, when a > > > developer > > > *wants* to be LGPL compliant, just writes an application, maybe adds a > > > proprietary driver but otherwise "behaves" regarding build system > > > manipulation. > > > > >I think that was a misunderstanding. I was more asking about the > > "realm" of applications. The counter-arguments we had in the LGPL > > discussion were not primarily "can we proof LGPL compliance" but more > > "can we build reasonable, proprietary IoT applications" without > > violating LGPL compliance. > Well, yes we can. There's just no perfect way of proving an application is > compliant. > > Assuming RIOT is already ported to a specific device, writing any proprietary > application on top of that, even adding drivers for proprietary hardware, is > possible without violating LGPL. > > A basic RIOT port (not including drivers for all components) for the target > probably needs to be LGPLed, though. > > Our "method" here offers a make target that makes it easy to distribute > everything necessary to enable re-linking, thus complying with that part of > the LGPL. For everyone wanting to stay LGPL-compliant, this is > useful. > > > > There are probably a million ways to sneak in modified RIOT code and still > > > have a valid verification using our method here. > > > So even if the verification passes, that alone is not proof that LGPL > > > hasn't > > > been violated. > > > > >From a legal perspective it then seems worthless. > Probably right. But there is no technical way to prove any license compliancy > while keeping some code closed. > > OTOH, the benefit of modifying RIOT itself and concealing it has *no* > commercially viable use case to me, while being a huge burden on the > development itself compared to just sharing the modifications in the first > place. > > So anyone writing a proprietary application and distributing it like this > method proposes very probably complies to LGPL. > > Everyone else would just not mention RIOT and ship it's product breaking LGPL, > as the criminal energy to be not license compliant is there and going through > the pain of pretending to be compliant just doesn't make sense. > > Also, if any project passes this verification and *is* compliant, one <5 > minute possibly NDAed look at the actual proprietary code would prove that > nothing is concealed, making the defense to any "you are not compliant" > accusations extremely easy. > > That works the other way, too. If someone distributes code in this method's > manner but conceals dirty tricks in order to ship LGPL breaking code, a <5 > minute look would uncover such tricks. > > So while this doesn't give legal proof, it makes making a case for the actual > "truth" (proving compliancy / proving non-compliancy) a lot easier. > > Anything passing this verification, but breaking LGPL on purpose is easily > spotted with one look at the actual code. > >To be honest: I like the idea from an exercise point of view but I > > don't see how this approach can help us wrt the license discussion. > I don't agree. > > LGPL requires distribution of proprietary object files and everything else to > enable re-linking the LGPLed code with the proprietary code. > This make target makes exactly that very easy, removing most if not all > developer time consuming aspects of LGPL compliancy. > > IMHO this even more reduces the license discussion to monetarization > attractiveness vs. freedom for users. > > Kaspar > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > -- 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
Re: [riot-devel] LGPL compliance testing
Hi, On 02/11/15 16:36, Matthias Waehlisch wrote: So in theory, developers shouldn't be able to affect the system .a's files. And I can't think of anything that might do so by accident, when a developer *wants* to be LGPL compliant, just writes an application, maybe adds a proprietary driver but otherwise "behaves" regarding build system manipulation. I think that was a misunderstanding. I was more asking about the "realm" of applications. The counter-arguments we had in the LGPL discussion were not primarily "can we proof LGPL compliance" but more "can we build reasonable, proprietary IoT applications" without violating LGPL compliance. Well, yes we can. There's just no perfect way of proving an application is compliant. Assuming RIOT is already ported to a specific device, writing any proprietary application on top of that, even adding drivers for proprietary hardware, is possible without violating LGPL. A basic RIOT port (not including drivers for all components) for the target probably needs to be LGPLed, though. Our "method" here offers a make target that makes it easy to distribute everything necessary to enable re-linking, thus complying with that part of the LGPL. For everyone wanting to stay LGPL-compliant, this is useful. There are probably a million ways to sneak in modified RIOT code and still have a valid verification using our method here. So even if the verification passes, that alone is not proof that LGPL hasn't been violated. From a legal perspective it then seems worthless. Probably right. But there is no technical way to prove any license compliancy while keeping some code closed. OTOH, the benefit of modifying RIOT itself and concealing it has *no* commercially viable use case to me, while being a huge burden on the development itself compared to just sharing the modifications in the first place. So anyone writing a proprietary application and distributing it like this method proposes very probably complies to LGPL. Everyone else would just not mention RIOT and ship it's product breaking LGPL, as the criminal energy to be not license compliant is there and going through the pain of pretending to be compliant just doesn't make sense. Also, if any project passes this verification and *is* compliant, one <5 minute possibly NDAed look at the actual proprietary code would prove that nothing is concealed, making the defense to any "you are not compliant" accusations extremely easy. That works the other way, too. If someone distributes code in this method's manner but conceals dirty tricks in order to ship LGPL breaking code, a <5 minute look would uncover such tricks. So while this doesn't give legal proof, it makes making a case for the actual "truth" (proving compliancy / proving non-compliancy) a lot easier. Anything passing this verification, but breaking LGPL on purpose is easily spotted with one look at the actual code. To be honest: I like the idea from an exercise point of view but I don't see how this approach can help us wrt the license discussion. I don't agree. LGPL requires distribution of proprietary object files and everything else to enable re-linking the LGPLed code with the proprietary code. This make target makes exactly that very easy, removing most if not all developer time consuming aspects of LGPL compliancy. IMHO this even more reduces the license discussion to monetarization attractiveness vs. freedom for users. Kaspar ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing
Hi Kaspar, On Tue, 10 Feb 2015, Kaspar Schleiser wrote: > >(3) Fine-grained object archives: Having separate object archives that > > reflect RIOT modules is the key idea of the approach. Two questions > > remain: (a) Which types of applications can someone create without > > affecting the "core" (i.e., other .a-files) of the OS. (b) What is the > > "core" of the OS? > Actually, the *archives* don't really matter. The linker extracts all archives > and only considers contained .o files for linking. > > That the application objects are conveniently archived into one .a file that > can be easily used for this license verification is just a by-product. > OK. > (a) Usually the "core" .a files are searched before the application .a. > That way, even if a developer accidently overwrites symbols (e.g., functions > or variables) that should have been supplied by RIOT, the linker would > probably just ignore it. Have to try that. > > So in theory, developers shouldn't be able to affect the system .a's files. > And I can't think of anything that might do so by accident, when a developer > *wants* to be LGPL compliant, just writes an application, maybe adds a > proprietary driver but otherwise "behaves" regarding build system > manipulation. > I think that was a misunderstanding. I was more asking about the "realm" of applications. The counter-arguments we had in the LGPL discussion were not primarily "can we proof LGPL compliance" but more "can we build reasonable, proprietary IoT applications" without violating LGPL compliance. > There are probably a million ways to sneak in modified RIOT code and still > have a valid verification using our method here. > So even if the verification passes, that alone is not proof that LGPL hasn't > been violated. > From a legal perspective it then seems worthless. To be honest: I like the idea from an exercise point of view but I don't see how this approach can help us wrt the license discussion. 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
Re: [riot-devel] LGPL compliance testing
Hi, On 02/10/15 15:52, Matthias Waehlisch wrote: (1) Compiling with RIOT_VERSION: Including the RIOT_VERSION works as a trust anchor to identify the source code base. Assuming a single (valid) and trustworthy version, you wouldn't need this ingredient. Right? Correct. (2) MD5 hash: This is for convenient reasons. You could also do a bitwise comparison. Right? Correct. I assume that MD5-hashing is practically equivalent to bitwise comparison. (3) Fine-grained object archives: Having separate object archives that reflect RIOT modules is the key idea of the approach. Two questions remain: (a) Which types of applications can someone create without affecting the "core" (i.e., other .a-files) of the OS. (b) What is the "core" of the OS? Actually, the *archives* don't really matter. The linker extracts all archives and only considers contained .o files for linking. That the application objects are conveniently archived into one .a file that can be easily used for this license verification is just a by-product. (a) Usually the "core" .a files are searched before the application .a. That way, even if a developer accidently overwrites symbols (e.g., functions or variables) that should have been supplied by RIOT, the linker would probably just ignore it. Have to try that. So in theory, developers shouldn't be able to affect the system .a's files. And I can't think of anything that might do so by accident, when a developer *wants* to be LGPL compliant, just writes an application, maybe adds a proprietary driver but otherwise "behaves" regarding build system manipulation. There are probably a million ways to sneak in modified RIOT code and still have a valid verification using our method here. So even if the verification passes, that alone is not proof that LGPL hasn't been violated. (b) In this context, by "core" I mean all the RIOT code, build system, linker scripts etc., everything that is not "the application". Maybe the git checkout or the unzipped distribution archive? (4) Can you explain why your approach would not be possible in other OSes, e.g., Contiki? That would be great. ;) But this is possible with these OSs as well. RIOT's build system just made this really easy as all "aplicatin" code is already compiled in one .a, and RIOT happily builds if that .a is supplied pre-compiled without the code. Kaspar ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing
Hi Kaspar, thanks for the wiki entry. I would like to understand the different steps better. Following questions and comments: (1) Compiling with RIOT_VERSION: Including the RIOT_VERSION works as a trust anchor to identify the source code base. Assuming a single (valid) and trustworthy version, you wouldn't need this ingredient. Right? (2) MD5 hash: This is for convenient reasons. You could also do a bitwise comparison. Right? (3) Fine-grained object archives: Having separate object archives that reflect RIOT modules is the key idea of the approach. Two questions remain: (a) Which types of applications can someone create without affecting the "core" (i.e., other .a-files) of the OS. (b) What is the "core" of the OS? (4) Can you explain why your approach would not be possible in other OSes, e.g., Contiki? Thanks matthias On Mon, 26 Jan 2015, Kaspar Schleiser wrote: > Hey guys, > > here's an initial draft on how to check for LGPL compliance: > > https://github.com/RIOT-OS/RIOT/wiki/LGPL-compliancy-guide > > This is for showing that some proprietary code has been compiled and linked > with a specific version of RIOT. > > I wrote the wiki entry out of my head, so maybe I missed something, but the > general method worked in prior testing. ;) > > Should we go and automate this, or am I missing something? > > Kaspar > > p.s.: This is in no way any conclusion to the license discussion, see it as > purely technical please. > ___ > 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] LGPL compliance testing
Hi, to "refuel" the disussion on license switching and working with LGPL and closed source I've opened #2357 [1]. Best regards, Martin [1] https://github.com/RIOT-OS/RIOT/pull/2357 On 27.01.2015 14:04, Kaspar Schleiser wrote: Hi, On 01/27/15 13:55, Emmanuel Baccelli wrote: how about adding a line in the guide about this md5 check, as a concrete example to "prove" that the files are indeed identical? Then we could ask some FSF people or lawyers if md5 check is considered a valid proof ;) Done! Kaspar ___ 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] LGPL compliance testing
Hi, On 01/27/15 13:55, Emmanuel Baccelli wrote: how about adding a line in the guide about this md5 check, as a concrete example to "prove" that the files are indeed identical? Then we could ask some FSF people or lawyers if md5 check is considered a valid proof ;) Done! Kaspar ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing
Hi Kaspar, how about adding a line in the guide about this md5 check, as a concrete example to "prove" that the files are indeed identical? Then we could ask some FSF people or lawyers if md5 check is considered a valid proof ;) Cheers Emmanuel On Mon, Jan 26, 2015 at 5:43 PM, Kaspar Schleiser wrote: > Hi, > > On 01/26/2015 05:36 PM, Joakim Gebart wrote: > >> Is RIOT_VERSION the only thing that is automatically generated for each >> build? >> > Seems like... > > I mean, if even a build date is included somewhere the result will not >> be identical. >> > I tried this on ARM (for the hello-world example) and the resulting files > had a matching MD5. > > Kaspar > > ___ > 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] LGPL compliance testing
Hi,
On 01/27/15 08:36, Martin wrote:
So, building a specific RIOT version with the applied patch for the
hooks, linked with the provided library should be equal with the binary
(If I'm not confusing something)
It should...
Note that the current build system adds something to the RIOT_VERSION
string ("-dirty" IIRC) if you modify the current git HEAD. Both applying
a patch (without committing) or removing the source files of your
application will trigger that.
That's why I set RIOT_VERSION in the examples.
You might want to either commit your patch to the core locally and use
the resulting git revision for building/validating, or live with the
dirty RIOT version, which should also work (in theory).
Kaspar
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing
Hi, yes, I will provide a diff patch to apply hooks to a closed library inside of a core .c file, that must be applied in the build process of RIOT to use the shipped library. The patch and the hooks are of course open source and provided under LGPL. So, building a specific RIOT version with the applied patch for the hooks, linked with the provided library should be equal with the binary (If I'm not confusing something) Best regards, Martin On 27.01.2015 08:32, Kaspar Schleiser wrote: Hey, On 01/27/15 06:25, Martin wrote: I will try today how it would be possible to replace and validate when someone change parts of say the core, not the whole core though. Well, if you change anything in the core, the resulting binary after relinking *will* be different. Kaspar ___ 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] LGPL compliance testing
Hey, On 01/27/15 06:25, Martin wrote: I will try today how it would be possible to replace and validate when someone change parts of say the core, not the whole core though. Well, if you change anything in the core, the resulting binary after relinking *will* be different. Kaspar ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing
Hi, On 01/26/15 22:46, Hauke Petersen wrote: I'm too tired to really think through it, but how does this fit in when keeping parts more close to the hardware proprietary? Say I don't want to publish my device driver, and maybe I don't want to share my pin-mapping? Well, if your device driver compiles into object files, there's no difference to any "application" code. It doesn't matter if you recompile the rest of the code and relink. What pin mapping your driver uses doesn't matter, either. If you have to change core RIOT's linkerscript or board defines, you are changing LGPLed code and have to share those changes to be LGPL compliant. Kaspar ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing
Hi, nice, I will try today how it would be possible to replace and validate when someone change parts of say the core, not the whole core though. Best regards, Martin On 01/26/2015 10:46 PM, Hauke Petersen wrote: Nice! I'm too tired to really think through it, but how does this fit in when keeping parts more close to the hardware proprietary? Say I don't want to publish my device driver, and maybe I don't want to share my pin-mapping? Cheers, Hauke On 26.01.2015 16:43, Kaspar Schleiser wrote: Hey guys, here's an initial draft on how to check for LGPL compliance: https://github.com/RIOT-OS/RIOT/wiki/LGPL-compliancy-guide This is for showing that some proprietary code has been compiled and linked with a specific version of RIOT. I wrote the wiki entry out of my head, so maybe I missed something, but the general method worked in prior testing. ;) Should we go and automate this, or am I missing something? Kaspar p.s.: This is in no way any conclusion to the license discussion, see it as purely technical please. ___ 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 ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LGPL compliance testing
Nice! I'm too tired to really think through it, but how does this fit in when keeping parts more close to the hardware proprietary? Say I don't want to publish my device driver, and maybe I don't want to share my pin-mapping? Cheers, Hauke On 26.01.2015 16:43, Kaspar Schleiser wrote: Hey guys, here's an initial draft on how to check for LGPL compliance: https://github.com/RIOT-OS/RIOT/wiki/LGPL-compliancy-guide This is for showing that some proprietary code has been compiled and linked with a specific version of RIOT. I wrote the wiki entry out of my head, so maybe I missed something, but the general method worked in prior testing. ;) Should we go and automate this, or am I missing something? Kaspar p.s.: This is in no way any conclusion to the license discussion, see it as purely technical please. ___ 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] LGPL compliance testing
Is RIOT_VERSION the only thing that is automatically generated for each build? I mean, if even a build date is included somewhere the result will not be identical. I like the idea, however. Best regards, Joakim Gebart Eistec AB www.eistec.se On 01/26/2015 04:43 PM, Kaspar Schleiser wrote: > Hey guys, > > here's an initial draft on how to check for LGPL compliance: > > https://github.com/RIOT-OS/RIOT/wiki/LGPL-compliancy-guide > > This is for showing that some proprietary code has been compiled and > linked with a specific version of RIOT. > > I wrote the wiki entry out of my head, so maybe I missed something, > but the general method worked in prior testing. ;) > > Should we go and automate this, or am I missing something? > > Kaspar > > p.s.: This is in no way any conclusion to the license discussion, see > it as purely technical please. > ___ > 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] LGPL compliance testing
Hi, On 01/26/2015 05:36 PM, Joakim Gebart wrote: Is RIOT_VERSION the only thing that is automatically generated for each build? Seems like... I mean, if even a build date is included somewhere the result will not be identical. I tried this on ARM (for the hello-world example) and the resulting files had a matching MD5. Kaspar ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] LGPL compliance testing
Hey guys, here's an initial draft on how to check for LGPL compliance: https://github.com/RIOT-OS/RIOT/wiki/LGPL-compliancy-guide This is for showing that some proprietary code has been compiled and linked with a specific version of RIOT. I wrote the wiki entry out of my head, so maybe I missed something, but the general method worked in prior testing. ;) Should we go and automate this, or am I missing something? Kaspar p.s.: This is in no way any conclusion to the license discussion, see it as purely technical please. ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
