Re: [riot-devel] What is UHCP?
On Fri, 6 Nov 2020, Martine Sophie Lenders wrote: > To my knowledge and last time I checked dnsmasq did not support > server-side prefix delegation, if that is wrong: great, let's use it. > `dist/tools/dhcpv6-pd_ia` is not a DHCPv6 server on its own, but a > dispatcher script that installs and runs a DHCPv6 server, using the > operating systems installation services (like APT or pacman). > Currently, Kea [2] is used for that, again last time I checked, is the > only open source DHCPv6 server, that supports prefix delegation. It > has however the distinct disadvantage, > "it" doesn't mean Kea but the way Kea is installed? > I think the simplest solution to get rid of UHCP could be, to have a > very simple DHCPv6 server that just provides Prefix Delegation at > hand, that could be compiled (if it is not a script) as fast as UHCPD > can be and allows for easy non-root deployment. > anybody any experiences with https://github.com/HenriWahl/dhcpy6d (they claim prefix delegation support) cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Survey: Mailing lists, forum ...
Dear RIOTers, we currently evaluate new communication channels to improve discussions within the RIOT community. We consider introducing a forum, implemented in Discourse (https://www.discourse.org/). As your opinion matters, we kindly ask you to participate in the following brief survey, which we hope will help us to decide on the next steps: * https://www.unipark.de/uc/riot/bf58/ The survey consists of max. 10 questions and should not take more than five minutes. Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] RIOT at hackster.io & GitHub tags
Dear RIOTers, in the community break-out session during this year's RIOT Summit, we discussed options to give RIOT projects more visibility. We now have a channel on hackster.io: https://www.hackster.io/riot-os/. There are already some RIOT projects published, https://www.hackster.io/search?i=projects=riot-os. Please, link to RIOT if you publish on hackster.io. And if you have a GitHub repo that relates to RIOT, please, add a "riot-os" tag as this makes it easier to find RIOT code, see https://github.com/search?q=%23riot-os. Thanks to Jelle for bringing this up! thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] FOSDEM 2020 RIOT BoF summary
Hi Christian,
many thanks for the minutes!
Any details who (or how many) attended the meeting?
Thanks
matthias
On Sun, 2 Feb 2020, chrysn wrote:
> Hi,
>
> On Fri, Jan 31, 2020 at 03:55:08PM +0100, Koen Zandberg wrote:
> > For those of us attending FOSDEM this year, I plan to grab a BoF room
> > time slot to have a small RIOT meet-up.
>
> I've taken some notes on this:
>
> After we've finished admiring his PineTime, discussion started about fields
> which we could improve in RIOT, with a focus on the input RIOT users and
> newcomers. (Please apologize my sketchy notes)
>
> * Documentation
> * Document modules (and make them discoverable)
> * Document how to use in them, in addition to what-are-its internals
> * Is Doxygen sufficient for this purpose? There was a PR to Sphinx
> some time ago, but would such a migration even feasible?
> * Grouping of drivers and/or examples in documentation and paths
> * "When developing an X, how do I..." for X in application, driver
> etc.
> * Module dependencies, esp. how they are done, and pseudomoldules (and
> which are there?)
> * Gaëtan wrote basic doc on what a module is ... where is it? is it
> sufficient?
> * How are networks configured?
> * Many of those are currently solved by people coming to IRC / Matrix
> * Document environment variables inside the makefile. BOARDSDIR?
> EXTERNAL_MODULES_DIR? Make them searchable.
> * PR experience: PR workflow is insufficiently described in
> CONTRIBUTING, some relevant information is in the maintainer
> documentation ("Why doesn't murdock build?")
> * PRs not being responded to. Use GitHub code owners file (even though
> we call it something else, but that's their file name)?
> * Preselection of PRs? Making someone feel responsible for code?
> * Run CI for PRs if nothing else running?
> * security implications
> * "When I got an ACK, why isn't it merged immediately?" Maybe have
> murdock reply to PRs on what is required?
> * uncrustify -- What do I need to address, what is a suggestion, what
> will maintainers enforce?
> * When is a "*ping*" OK, is it encouraged, etc.? Ping whom?
> * More often, for annoying little stuff, push to contributor branch
> (if allowed by contributer)?
> * How do people who did some comments stay in the reviewers list? Whom
> to add, what happens if nobody is assigned after triage when someone
> removed themselves?
> * The dependency graph is not accessible: There can't be a `make
> info-module-tree`.
> * When will we run into make limitations? Won't need to replace make
> for everything, just for determining USE_MODULES.
> * Defaults for pseudomodules, and optional orders of preferences?
> stdio_cdc_acm vs stdio_uart etc
>
> This certainly doesn't cover all topics touched, and might even have
> missed proposed solutions, but might help spark further discussion
> and/or identify points where improvement would be quite welcome.
>
> KR
> chrysn
>
>
--
Matthias Waehlisch
. Freie Universitaet Berlin, Computer Science
.. http://www.cs.fu-berlin.de/~waehl___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] IoT Hackathon in Amsterdam this weekend
Hi, those of you who want to spend some time on hacking, please consider the tenth RIPE NCC Hackathon, which will take on the Internet of Things (IoT) from 12-13 October 2019 in Rotterdam. There are some seats left. More details and registration via https://labs.ripe.net/Members/becha/iot-hackathon-at-ripe-79-in-rotterdam Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Support for Embedded World 2020?
Hi, over the last years some of the RIOT maintainers presented RIOT at Embedded World. This was always supported by companies or other organizations such that RIOTers did not need to pay for the booths. Unfortunately, this option is not available for next year. If you can spare some space at your booth where RIOT developers can present RIOT and show RIOT applications, please reply, either on or off list. Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] RIOT Summit 2019: Registration open
Dear RIOTers, the fourth RIOT Summit (https://summit.riot-os.org/) will take place in Helsinki/Espoo, Finland at the Aalto Design Factory on September 5-6, 2019. The first day is dedicated to single-track presentations and demos. The second day allows for breakout sessions and coding. If you want to attend, please register as soon as possible: https://riot-summit2019.eventbrite.com/. **Talks** Keynote by Jari Arkko (former IETF Chair and Senior Expert at Ericsson Research) on "Call for Action: The Internet Threat Model Needs a Change". More speakers: http://summit.riot-os.org/2019/#speakers **Social* After the talks of the first day, we have organized a casual social at Suomenlinna, a UNESCO World Heritage site (https://www.suomenlinna.fi/en/conferences-and-banquets//). Food is sponsored. **Hotels** There are a couple of nearby accommodations in Espoo (https://summit.riot-os.org/2019/#accommodations) but you can also choose hotels in Helsinki. **Registration** Participation at the RIOT Summit is free of charge. However, registration is required: https://riot-summit2019.eventbrite.com/ **Supporters** We gratefully thank the following companies for their generous support: Cisco, Ericsson, wolfSSL, Zühlke. We also thank Freie Universitaet Berlin, HAW Hamburg, and INRIA. Looking forward to meet all of you in Helsinki/Espoo!___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Save the date: RIOT Summit 2019
Dear RIOTers, this is a reminder that the Call for Contributions https://summit.riot-os.org/2019/call-for-contributions/ is still open. If you have something that you want to share with your fellow RIOTers, please submit. Thanks matthias On Sun, 31 Mar 2019, Matthias Waehlisch wrote: > Dear RIOTers, > > after very successful RIOT Summits in the last three years, the fourth > RIOT Summit is scheduled for September 5-6, 2019 in Helsinki/Espoo. > > All details are available at https://summit.riot-os.org/2019/. > > To make the RIOT Summit 2019 a successful event again, we need your > help. It's a community activity! > > If you have detailed ideas on how to shape the Summit, please consider > the Call for Contributions. We are looking for talks, demos, and other > valuable input: https://summit.riot-os.org/2019/call-for-contributions > > If you are willing to provide financial support, please consider the > Call for Sponsors: > https://summit.riot-os.org/2019/call-for-sponsors > > > The RIOT Summit is organized by FU Berlin, HAW Hamburg, INRIA, and > locally supported by Aalto University and Ericsson. If you have > questions, feel free to contact us via sum...@riot-os.org. > > > Thanks > matthias (on behalf of the RIOT Summit organizers) > > > > -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Save the date: RIOT Summit 2019
Dear RIOTers, after very successful RIOT Summits in the last three years, the fourth RIOT Summit is scheduled for September 5-6, 2019 in Helsinki/Espoo. All details are available at https://summit.riot-os.org/2019/. To make the RIOT Summit 2019 a successful event again, we need your help. It's a community activity! If you have detailed ideas on how to shape the Summit, please consider the Call for Contributions. We are looking for talks, demos, and other valuable input: https://summit.riot-os.org/2019/call-for-contributions If you are willing to provide financial support, please consider the Call for Sponsors: https://summit.riot-os.org/2019/call-for-sponsors The RIOT Summit is organized by FU Berlin, HAW Hamburg, INRIA, and locally supported by Aalto University and Ericsson. If you have questions, feel free to contact us via sum...@riot-os.org. Thanks matthias (on behalf of the RIOT Summit organizers) -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Embedded World 2019
Dear RIOTers, just to let you know: Some of the RIOT maintainers will present RIOT at the Embedded World 2019 (https://www.embedded-world.de/en). When * February 26-28, 2019 Where * Hall 4, stand 4-168 (OSADL booth) * Nuremberg, Germany That might be a perfect chance to meet your fellow RIOTers f2f. If you are an exhibitor who shows something that is based on RIOT, please share! Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Driver design rules in RIOT
On Wed, 26 Sep 2018, Gunar Schorcht wrote: > Unfortunaly, it seem not to be reachable from the top level wiki page or > problems of wiki, where information kills itself ;). Done: https://github.com/RIOT-OS/RIOT/wiki#general-hints Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] RIOT Summit 2018: Slides, Videos, Photos
Dear RIOTers, last Thursday and Friday, we had the third yearly get-together of the RIOT community. If you were not able to attend, you will find some material here: Slides: http://summit.riot-os.org/2018/slides/ Videos of the plenary sessions: https://www.youtube.com/playlist?list=PLDXXQJiSjPKGJPbDvaZI_DymPsiVqMfvf Photos: https://www.flickr.com/photos/142412063@N07/albums/72157673532948288 Hope to see more of you next year! ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] RIOT Summit 2018: Registration open
Dear RIOTers, there are still some free tickets available to join the RIOT Summit 2018 in Amsterdam. Registration is free (thanks to our sponsors!) but mandatory: https://riot-summit18.eventbrite.com/ Highlights: - Keynote by Jaime Jimenez, Ericsson - 12 talks on networking, security, applications, and future directions - Tutorials - Demos - Social at Rolling Rock Kitchen Amsterdam - For more details: see http://summit.riot-os.org/ We gratefully thank the following companies for their generous support: Cisco, RIPE NCC, Savoir-faire Linux, SIDN Labs, STMicroelectronics, wolfSSL, Zühlke. Looking forward to meet all of you in Amsterdam!___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] RIOT Summit: Call for Presentations
Dear RIOTers, this is a friendly reminder: If you want to present something at RIOT Summit 2018, please consider https://summit.riot-os.org/2018/blog/call-for-contributions/ Thanks matthias On Wed, 14 Mar 2018, Matthias Waehlisch wrote: > Dear RIOTers, > > after very successful RIOT Summits in 2016 and 2017, the third RIOT > Summit is scheduled for September 13-14, 2018 in Amsterdam. > > All details are available at https://summit.riot-os.org/2018/. > > To make the RIOT Summit 2018 a successful event again, we need your > help. It's a community activity! > > If you have detailed ideas on how to shape the Summit, please consider > the Call for Contributions: > https://summit.riot-os.org/2018/blog/call-for-contributions/ > > If you are willing to provide financial support, please consider the > Call for Sponsors: > https://summit.riot-os.org/2018/blog/call-for-sponsors/ > > > We very much hope to meet many of you. To make travelling a bit more > efficient for you, right before the RIOT Summit will start, the premier > conference on Cryptographic Hardware and Embedded Systems 2018 > (https://ches.iacr.org/2018/) will be held in Amsterdam. > > The RIOT Summit is organized by FU Berlin, HAW Hamburg, INRIA, and > locally supported by RIPE NCC. If you have questions, feel free to > contact us via sum...@riot-os.org. > > > Thanks > matthias (on behalf of the RIOT Summit organizers) > > > -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] RIOT Hackathon in Paris
... that's a good opportunity to emphasize: If you want to strengthen the RIOT community in your geographic area by organizing, for example, hackathons, let the community know. For this kind of events we can provide RIOT T-shirts and stickers to newcomers. Send an email to this list or to r...@riot-os.org. Cheers matthias On Thu, 19 Apr 2018, Alexandre Abadie wrote: > Dear RIOTers, > > We are organizing a 4 days hackathon, May 22-25th in Paris. > Information about this event can be found on the wiki [1]. > > Everyone is welcome to participate! > > Attendance is free, but registration is mandatory on the wiki. > To register, put your name on the list, and either add yourself to an > existing topic, or list a new topic. > > Doubts? Questions? PM or reply to this thread ;) > > Thanks! > > Alex > > [1] https://github.com/RIOT-OS/RIOT/wiki/Hackathon-in-Paris-May-22-25,-2018 > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Save the date: RIOT Summit 2018
Dear RIOTers, after very successful RIOT Summits in 2016 and 2017, the third RIOT Summit is scheduled for September 13-14, 2018 in Amsterdam. All details are available at https://summit.riot-os.org/2018/. To make the RIOT Summit 2018 a successful event again, we need your help. It's a community activity! If you have detailed ideas on how to shape the Summit, please consider the Call for Contributions: https://summit.riot-os.org/2018/blog/call-for-contributions/ If you are willing to provide financial support, please consider the Call for Sponsors: https://summit.riot-os.org/2018/blog/call-for-sponsors/ We very much hope to meet many of you. To make travelling a bit more efficient for you, right before the RIOT Summit will start, the premier conference on Cryptographic Hardware and Embedded Systems 2018 (https://ches.iacr.org/2018/) will be held in Amsterdam. The RIOT Summit is organized by FU Berlin, HAW Hamburg, INRIA, and locally supported by RIPE NCC. If you have questions, feel free to contact us via sum...@riot-os.org. Thanks matthias (on behalf of the RIOT Summit organizers) -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Embedded World 2018
Hi, over the last years some of the RIOT maintainers presented RIOT at Embedded World. This was always supported by companies or other organizations, such that RIOTers did not need to pay for the booths. Unfortunately, this option is not available this year, so far. If you attend Embedded World and show RIOT, or if you can spare some space at your booth where RIOT developers can show some RIOT applications, please reply, either on- or offlist. Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] RIOT Summit 2018: Call for venue support
Dear RIOTers, after two very successful events in Berlin, the third RIOT Summit will take place in Amsterdam from September 13-14, 2018. Amsterdam has two advantages: First, it is an important hub for the Internet community. Second, the conference on Cryptographic Hardware and Embedded Systems (CHES) will take place in Amsterdam from Sep. 9-12, and we think both communities can benefit from each other. Luckily, RIPE (https://ripe.net/) agreed to help us with the organization of the RIOT Summit 2018. Unfortunately, we currently don't have acccess to free premises to host the event, and Amsterdam is expensive. If you can help us with finding a place in Amsterdam where we can host the RIOT Summit 2018, either free or with tight budget, please contact m.waehli...@fu-berlin.de. Thanks matthias (on behalf of the RIOT Summit organizers) PS: A separate Call for Sponsors will be announced as usual, as soon as the venue is clearer. -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Hackathon in Berlin: January 18-19, 2018
Dear RIOTers, We would like to invite you to join IoThon, Europe's first open source hackathon on IoT, blockchains, RIOT, and ICN (Information Centric Networking). The hackathon will take place on January 18-19, 2018 in Berlin! Read more about the event at https://iothon.io/ IoThon is a free-of-charge event for students, developers, and anyone interested in developing IoT software and hardware projects with blockchains and/or ICN, two new technologies that have the potential of changing our future. The participants have about 24 hours to develop their own projects and solving challenges provided by organisers and partner companies, offering: * Tutorials on RIOT, blockchains, ICN, and more * 24+ hours hacking together * Main prize 1000 EUR * Free food and drinks The number of the participants is limited, so by applying quickly you enhance your chances to be admitted. Application deadline is December 23th. We will evaluate the applications continuously, announcing the participants no later than December 27th. This provides at least three weeks to book flights and make other travel arrangements. Happy hacking and see you in Berlin! ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Updates to the build system - modules definition
On Thu, 30 Nov 2017, Kaspar Schleiser wrote: > When are you gonna take a look at my ninja-based build system? It > solves 1-3 quite nicely, and more. You could save a lot of time. > Pointer? Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Updates to the build system - modules definition
Hi Kaspar, On Thu, 30 Nov 2017, Kaspar Schleiser wrote: > > 1. The current build system isn't suitable to support the front end for > > RAPstore that Hendrik developed for his bachelor thesis, which requires > > that certain information can be displayed to the users. > > I hear about this for the first time. Are there any pointers? > it was briefly presented during the RIOT Summit this year. As soon as we have a public demo ready, we will post on the list. Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] RIOT Summit 2017: Program and Registration
Dear RIOTers, the second RIOT Summit (http://summit.riot-os.org/) will take place in Berlin, Germany from September 25-26, 2017, at FU Berlin. The first day is dedicated to single-track presentations. The second day allows for break-out sessions and coding. If you want to attend, please register as soon as possible: https://riot-summit17.eventbrite.com/. **Talks** Keynote by Gilles Van Assche (STMicroelectronics) - Permutation-based cryptography for the Internet of Things IoT Security - SOFIE: Securely and Openly Federating IoT systems, Pekka Nikander - Progressively Securing RIOT-OS!, Kaleb Himes - Have a secure RIOT, Eric Sesterhenn - Post-Quantum Cryptography for IoT, Simona Samardjiska Virtualisation & Bootstrapping - Large scale experiments on virtual ICN-based IoT networks with vICN, Marcel Enguehard - Multiple Personalities - Thoughts on a Virtualized RIOT, Kai Beckmann - Fast modelling & deployment of IoT applications from the cloud to RIOT devices, Ian Thomas Use Cases - How RIOT-ready is industry?, Oliver Hahm - Cloudy with a Chance of RIOTs - Towards an Open Industrial Internet, Michal Frey - Introduction to the Calliope mini, Joern Alraun Network - RIOT and CAN, Vincent Dupont - DropWatcher: A real world LoRaWAN application on RIOT, José Ignacio Alamos - Adaptive radio output scaling for power and bandwidth saving, Koen Zandberg **Social and related events** Social - After the talks of the first day, we have organized a casual dinner at a very nice place close to the river Spree. Food is sponsored. Three side events - If you consider attending the RIOT Summit, you should also consider attending the following side events related to IoT: ACM ICN, T2TRG, ICNRG. These events will take place right before and after the Summit at the same venue. Separate registration is required, and more information is available at http://summit.riot-os.org/2017/#registration **Registration** Participation at the RIOT Summit is free of charge. However, registration is required: https://riot-summit17.eventbrite.com/ **Supporters** We gratefully thank the following companies for their generous support: Arrow Electronics, Cisco, Fujitsu, OTAkeys, and wolfSSL, We also thank Freie Univeristaet Berlin, HAW Hamburg, and INRIA. Looking forward to meet all of you in Berlin!___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] RIOT Summit 2017
Dear RIOTers, after the very successful RIOT Summit last year, the second RIOT Summit is scheduled for September 25-26, 2017 in Berlin. We decided for Berlin again, as multiple side events related to IoT will take place during the same week (more below). All details are available at http://summit.riot-os.org/2017/. To make the RIOT Summit 2017 a successful event again, we need your help. It's a community activity! If you have detailed ideas on how to shape the Summit, please consider the Call for Contributions: http://summit.riot-os.org/2017/call-for-contributions/ If you are willing to provide financial support, please consider the Call for Sponsors: http://summit.riot-os.org/2017/call-for-sponsors/ We very much hope to meet many of you. To make travelling a bit more efficient for you, one day before the Summit will start, the T2TRG interim meeting (https://datatracker.ietf.org/rg/t2trg/about/) will be held in Berlin. Directly after the Summit, the ACM Conference on Information-centric Networking (http://conferences.sigcomm.org/acm-icn/2017//) will take place. The RIOT Summit is organized by FU Berlin, HAW Hamburg, and INRIA. If you have questions, feel free to contact us via sum...@riot-os.org. Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] RIOT Summit?
Yes, either before or after ACM ICN. If you guys have a preference on the date (Su/Mo vs. Fr/Sa), let us know. Thanks matthias On Thu, 2 Mar 2017, Emmanuel Baccelli wrote: > Hi Ken, > yes there is. It is planned in September, in Berlin. > > The dates are not 100% set in stone, but very probably it will be Sept. 29th > and 30th, in > conjunction with ACM ICN conference [1]. > > We will announce it soon. > > Would you be able to come by? Would be great. > > Cheers, > > Emmanuel > > [1] http://conferences.sigcomm.org/acm-icn/2017/ > > On Thu, Mar 2, 2017 at 5:00 PM, Ken Bannister <kb...@runbox.com> wrote: > Is there any thought ongoing toward a second RIOT Summit this year? > > Thanks, > Ken > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > > > > -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] wolfSSL port to RIOT OS
Hi Kaleb, +1 -- in particular, if you plan to continue the maintenance of the port! Cheers matthias On Wed, 30 Nov 2016, Thomas Eichinger wrote: > > Hi Kaleb, > > Personally I would be very much stoked to see a port of wolfSSL to RIOT and I > think many others think > the same. > > Let us know how we can help with it and I'm sure we will figure something out! > > Best, Thomas > > On 30 Nov 2016, at 13:09 PST(-0800), kaleb himes wrote: > > Hi @RIOT_OS developers, > @wolfSSL is considering doing a port to the Revolutionary Internet of Things > Operating System. We > wanted to reach out to the RIOT_OS developers group to see if this is > something that interests > you. > > Please let us know your thoughts, we look forward to hearing from you! > > i...@wolfssl.com > supp...@wolfssl.com > > Regards, > > Kaleb and the wolfSSL Team > > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > > > -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Silicon Labs Microcontroller handed out at summit
Hi all, the colleagues from Silicon Labs asked to share the following link with you https://www.dropbox.com/s/90hhnswiktcfjzz/BRD4160.zip?dl=0 Here you can download a ZIP archive including schematic, assembly drawing, and BOM. Cheers matthias On Wed, 20 Jul 2016, Bas Stottelaar wrote: > Hi all, > No official documentation yet, but I just found this > link: > https://www.mit.bme.hu/system/files/oktatas/targyak/9979/Silabs_Wireless_Gecko_MIT.pdf. > Page > 32 describes all the sensors. > > Seems like the part number/name is SLTB001A, and Thunderboard Sense is just > the marketing name. > > Kind regards, > > Bas Stottelaar > > > 2016-07-18 11:21 GMT+02:00 Bas Stottelaar <basstottel...@gmail.com>: > Hi Mathias, > There are two chips: one is the board controller (for mbed-related stuff, > virtual com, mass > storage). > > The other is the actual chip, an EFR32MG1P132F256GM48 (as seen > here: > https://github.com/basilfx/EFM2Riot/blob/master/dist/doc/images/thunderboard_sense.png). > That is, definitely a M4 with FPU. > > Kind regards, > > Bas Stottelaar > > > 2016-07-18 10:45 GMT+02:00 Mathias Tausig > <mathias.tau...@fh-campuswien.ac.at>: > Hy! > > Great that you already started working on it. > But I don't think that datasheet is quite accurate. The chip on the > backside of > the board states, that it is a Cortex-M3 processor, not an M4. > > On Mon, 2016-07-18 at 10:23 +0200, Bas Stottelaar wrote: > > Hi Mathias, > > > > I managed to get it working, based on the SLSTK3401a. I was lucky > that it > > shared the same pinout regarding the RX/TX. The reference manual and > > datasheet are available. I put the links in here: > > > https://github.com/basilfx/EFM2Riot/blob/master/dist/doc/Thunderboard%20Sense. > > md > > > > > > You can find my PR here: https://github.com/RIOT-OS/RIOT/pull/5652. > Since I > > also work on other EFM32 targets, I have more to see here: > > https://github.com/basilfx/EFM2Riot. > > > > I don't have a driver for the radio. I leave that (the actual > challenge) up > > to who wants to win the hoodie :-) > > > > Kind regards, > > > > Bas Stottelaar > > > > > > 2016-07-18 10:15 GMT+02:00 Mathias Tausig < > > mathias.tau...@fh-campuswien.ac.at>: > > > > > > > > Hy! > > > > > > Does anyone have a link to the specification (or even some sort of > > > dccumentation) for the Silicon Labs microcontroller that was handed > out on > > > Friday at the summit? Unfortunately, the silabs website knows no > product > > > of that > > > name or part number. > > > > > > cheers > > > Mathias > > > > > > -- > > > DI Mathias Tausig, > > > Kompetenzzentrum für IT-Security, > > > > > > FH Campus Wien, > > > Informationstechnologien und Telekommunikation. > > > > > > Favoritenstrasse 226, Raum B.2.18, > > > 1100 Wien, Austria. > > > T: +43 1 606 68 77-2142, F: +43 1 606 68 77-2139. > > > mathias.tau...@fh-campuswien.ac.at > > > PGP Key-ID: 75656BBF > > > > > > ___ > > > devel mailing list > > > devel@riot-os.org > > > https://lists.riot-os.org/mailman/listinfo/devel > > > > > > > > ___ > > devel mailing list > > devel@riot-os.org > > https://lists.riot-os.org/mailman/listinfo/devel > -- > DI Mathias Tausig, > Kompetenzzentrum für IT-Security, > > FH Campus Wien, > Informationstechnologien und Telekommunikation. > > Favoritenstrasse 226, Raum B.2.18, > 1100 Wien, Austria. > T: +43 1 606 68 77-2142, F: +43 1 606 68 77-2139. > mathias.tau...@fh-campuswien.ac.at > PGP Key-ID: 75656BBF > > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > > > > > -- Dr. Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:m.waehli...@fu-berlin.de .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.haw-hamburg.de .. http://www.link-lab.net___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] First RIOT Summit
Dear RIOTers, RIOT was officialliy launched in 2013. After three successful years it's time to give the RIOT community a forum to meet face-to-face. For this reason FU Berlin, HAW Hamburg, and INRIA are organizing the first RIOT Summit July 15-16, 2016 in Berlin. The RIOT Summit aims for bringing together RIOTers, beginners and experts, as well as people interested in the IoT in general and decision makers who plan to deploy RIOT in the future. The event combines plenary talks, hands-on tutorials, and demos. The Summit will not only inform about latest developments and recent case studies, but will also help to gather feedback from the community to shape the future of RIOT. Registration for the event is required but no fees will be charged. All details are available at http://summit.riot-os.org/. To make RIOT Summit 2016 a successful event, we need your help. It's a community activity! If you have detailed ideas on how to shape the Summit, please consider the Call for Contributions: http://summit.riot-os.org/call-for-contributions/ If you are willing to provide financial support, please consider the Call for Sponsors: http://summit.riot-os.org/call-for-sponsors/ We very much hope to meet many of you. To make travelling a bit more efficient for you, the Summit takes place two days before IETF 96 (http://www.ietf.org) will start in Berlin. Thanks 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 https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Is RIOT right?
Hi, On Fri, 20 Nov 2015, Hauke Petersen wrote: > 3) Robustness: please be honest, is RIOT robust and mature enough for a > large scale > use? Do you know of commercial products that integrates it? > at least there are some companies who explicitly note selling their hw with RIOT, such as http://www.phytec.de/de/produkte/internet-of-things/evaluierungskit/produktdetails/p/iot-enablement-kit.html http://www.eistec.se/mulle/ Btw, we will work on a more comprehensive overview soon. 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 https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] RIOT Release 2015.09
_____ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > > > > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > > > > ___ > devel mailing list > devel@riot-os.org > https://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 https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] RPL for linux
Hi, the watr.li people used an implementation from Rosand: http://watr.li/wrapup.html and http://rosand-tech.com/downloads/index.html Maybe they can comment directly. Cheers matthias On Thu, 2 Apr 2015, Ralph Droms (rdroms) wrote: I asked the same question on the IETF roll WG mailing list a couple of days ago. No responses, yet. I'll forward any information I find... - Ralph On Apr 2, 2015, at 9:05 AM 4/2/15, Maxence Chotard maxence.chot...@xsoen.com wrote: Hello, Is there somebody who knows if there is any port of RPL on linux to create a border router for RIOT ? Cheers, Maxence ___ devel mailing list devel@riot-os.org https://riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://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 https://riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Repository for Docker builds
Hi, +1 for riotdocker, riotbuild is confusing. Cheers matthias On Tue, 24 Feb 2015, Joakim Gebart wrote: riotdocker is more descriptive for the github repo name, I like it. Best regards, Joakim On Feb 24, 2015 8:20 AM, Oleg Hahm oliver.h...@inria.fr wrote: Hi Joakim! What is a suitable name for the new repo? I have been using riotbuild for my Docker development at https://github.com/gebart/riotbuild I don't have any particular ideas for the name, so, for me riotbuild (or riotdocker) would be fine. Also, I need to have an organisation owner (Oleg, Kaspar, Emmanuel or Matthias Wählisch) create the repo since maintainers do not have the proper access to do it. Sure, I can do so. Let's wait if no one objects against the proposed name. Cheers, Oleg -- The problem with git jokes is everyone has their own version. ___ 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] Switch to BSD?
Hi Oleg, On Wed, 25 Feb 2015, Oleg Hahm wrote: I thought that we already decided to exclude exotic licenses. Yes. GPL + Linker Exception is not exotic. 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. With respect to this specific license: (1) We cannot use the license because the license text is specific to eCos (e.g., eCos is distributed [...]). And original BSD license (http://directory.fsf.org/wiki/License:BSD_4Clause) is specific to Computer Systems Engineering group at Lawrence Berkeley Laboratory, which is obviously no blocker to be adopted elsewhere. I don't see why replacing the name of the project should invalidate a license. Misunderstanding. I'm just wondering if eCos is the first license with the introduced exception -- I will not research on this ;). (2) We should not use the license because it is not approved by the Open Source Initiative. OSI approval is important for some open source funding programmes etc. Seems to work quite successfully for eCos, ERIKA [1], GNU Guile [2], libgcc [3], NetBeans [4], ChibiOS [5] and several other bigger projects. Would be interesting what FSF says about it. 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. At least eCos, ERIKA and ChibiOS are very similar to RIOT from a software architecture point of view (OS for embedded hardware). No comment ;). If you want to spend more time on this, I recommend the thread http://projects.opensource.org/pipermail/license-review/2014-August/000853.html, in particular http://projects.opensource.org/pipermail/license-review/2014-September/000910.html. I haven't found any clear answers in these two mails and don't want to spend the rest of the evening reading through another license discussion, I have enough with this one here. From what I've read, I gather that oSI doesn't want to approve it, because there's no need to approve it: why not simply stop referring to 'the eCos License 2.0' as though it were a special license and instead characterize eCos as being licensed as 'GPLv2 or later' with a permissive exception? I've encountered other projects using similarly-worded GPL exceptions but to my recollection those projects characterize themselves as being GPL-licensed. 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? As I see it now, we won't come to any conclusion for or against switching to a non-copyleft license that satisfies everyone, because the goals and visions where to go with RIOT are too different. At least we don't get new basic insights with this thread. 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] Switch to BSD?
Hi Oleg, I thought that we already decided to exclude exotic licenses. With respect to this specific license: (1) We cannot use the license because the license text is specific to eCos (e.g., eCos is distributed [...]). (2) We should not use the license because it is not approved by the Open Source Initiative. OSI approval is important for some open source funding programmes etc. If you want to spend more time on this, I recommend the thread http://projects.opensource.org/pipermail/license-review/2014-August/000853.html, in particular http://projects.opensource.org/pipermail/license-review/2014-September/000910.html. Cheers matthias On Tue, 24 Feb 2015, Oleg Hahm wrote: Dear RIOTers, I just found the eCos license: [1] http://ecos.sourceware.org/license-overview.html It's basically a modified version of the GPL with linker exception. The interesting point: it is officially recognised as a GPL-compatible Free Software License: https://www.gnu.org/licenses/license-list.html#eCos20 and it seems to enable exactly what most of us want for RIOT: it makes it possible to implement proprietary applications on top of the OS, but any changes to the OS have to be made freely available. It seems also possibly to apply this exception on device drivers if this driver is implemented in a particular way. A very quick search revealed immediately one commercial user of this rule: https://help.eyefi.com/hc/en-us/articles/301754-eCos-Open-Source-License To me this looks very promising. What do you think? Cheers, Oleg [1] eCos is another free open source real-time operating system intended for embedded applications. -- 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 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 dictates that the compiled obect files or firmware must not be distributed seperately
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 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 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
[riot-devel] IoT Awards Nominations
Folks, RIOT has several nominations in the #IoT Awards, which are organized by Postscapes. Feel free to participate in the poll! Deadline is Jan 22nd. (1) Open Source Project: http://poll.fm/53j8x (2) Technical Enabler: Device and Hardware: http://poll.fm/53jc3/ 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] Switch to BSD?
On Tue, 16 Dec 2014, Johann Fischer wrote: If RIOT is BSD'ed, for *me* personally time spent on it is not fun time I like to in my unpaid spare time anymore, it becomes work that is also fun. Work others can (and will) sell under their terms. I totally don't get this point. How do more possibilities to work with RIOT for *others*, take fun away from *you*? (L)GPL guarantees that my contribution will stay part of something that might improve, but is always available to me under clear tearms. I disagree. The RIOT community guarantees that your and everyone else's contribution stay part of open and free software that might improve. Additionally, it might become part of something else, true. I agree with Kaspar. but this is hard to understand. (L)GPL does not guarantee that Kaspar's contribution will stay part of something that might improve, but is always available to him under clear tearms. Anyone can take the code, modify or remove Kaspar's part and re-publish it. As Oleg said it is the community around the software that shapes the software. Also as a company we have interests that if a competitor uses our work, it would be forced to admit changes or improvements back. Sure that is a typical economic argument. 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] Switch to BSD?
Hi Adam, On Mon, 8 Dec 2014, Adam Hunt wrote: There's another option on the table that would allow a potential license change to be put off for some time while still being able to do it with minimal headache down the road. Any license change is obviously going to require all the past contributors to agree to it so what about keeping the LGPL license for now and asking those contributors and future contributors to sign an SLA. One of the downsides to an SLA is that a legal entity (e.g. RIOT e.v.) would have to be created and managed. we thought about this. In the current context, this will only help in case of relicensing. However, relicensing will require a lot of resources, which we should spend in technical development. Even with a BSD/MIT license, creating a legal entity and deploying a CLA should be part of our agenda. 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] Switch to BSD?
Hi Kevin, On Tue, 9 Dec 2014, ROUSSEL Kévin wrote: I'm not absolutely against licence switch but... I actually feel uneasy about about this kind of demands... If I understand right, some corporations which have probably contributed nothing to the project just barges in and said : if you want us to use your work, you have to let us make whatever we want with it, ask nothing in return, no code contribution, no financial help (since this is free software), nothing. To be honest, I find this kind of behavior quite... displaced. I think that is the wrong impression. In particular, BSD/MIT does not mean that companies will not contribute back. But LGPL means for many companies that they will not start to *think about* using the software. Moreover, with that software patent crap that flourishes almost everywhere out of EU (and maybe even here in the future), wouldn't that change make us vulnerable to being sued for just developing our own code? As Rene Kijewski said, if we must change, we should find a license that protects us from that kind of trap... Why is MIT conflicting with this? Of course, it's good to broaden RIOT community, but what kind of members will be attracted by that kind of move? I can just wonder. Honestly, I don't think we should argue in this direction, i.e., the bad and good people on earth. There are several very nice people and good programmers that contribute only to BSD projects. PS: sorry for my lack of contribution these last weeks, I'm finishing some paper submissions Good luck! 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
