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
