Fix FAQ to properly describe LGPL in proprietary applications

[aeruder]

The "Why LGPL?" section of the FAQ is VERY misleading and opens any proprietary application writers up to any number of very valid requests for source code or object code to their application. The LGPL only allows linking to a proprietary application in very specific instances. Section 6 outlines this with section 6b being the most often used option. It specifically requires that an end-user be able to replace the LGPL library with a modified version. Without some support for a dynamic linking application loader in RIOT this is basically impossible.

Long story short, the license for this project is actually pretty inappropriate if it intends to support proprietary applications. In the meantime the Why LGPL? section should be cleaned up. I know it is a Wiki but just wanted to solicit some conversation before having some random stranger show up and start changing the Wiki.

Also: as a project, the stance may be that the LGPL requirements are being loosened, but since copyright assignment is not required it opens up a proprietary application writer to requests from anyone holding copyright to any code in RIOT OS no matter how insignificant their contributions may have been.

[emmanuelsearch]

The community is aware of the issues with LGPL for RIOT. We are currently considering a switch to BSD (see http://lists.riot-os.org/pipermail/devel/2014-December/001468.html). If not done already, please register to the devel@riot-os.org and/or users@riot-os.org, and chip in your opinion there too!

[aeruder]

Will subscribe and I was informed on IRC that the license discussion was taking place. I am only advocating that the wiki be updated in the meantime. I would think that perhaps doing a strike-through through the whole Why LGPL section and a link to the BSD thread on the mailing list might be a good thing to do.

[kaspar030]

It specifically requires that an end-user be able to replace the LGPL library with a modified version.
Without some support for a dynamic linking application loader in RIOT this is basically impossible.

That is not correct. LGPL doesn't make a difference between dynamically and statically linked code.
LGPL basically forces any developer of proprietary code to release a RIOT version for the used MCU under LGPL, in addition to the proprietary "application" object files used to create the final binary firmware image.
This can easily be supported by minor improvements in the build process.

[aeruder]

kaspar030, I agree and even put "object files" in my initial post, but this is still pretty surprising vs the wording of the "Why LGPL?" section, don't you think? I ship an end user a device and they can request object files to build their own updated firmware?

[kaspar030]

@aeruder agreed, the FAQ section wording is not optimal.

Having to provide object files doesn't differ much from providing firmware files.
Obviously LGPL doesn't go well with firmware encryption schemes or even non-upgradable, locked-up devices.

RIOT will definately have security problems that might be remotly exploitable. The notion that an embedded device can be sold once without the ability to upgrade it is something that should be ditched for any internet connected device. Same goes with the idea that any vendor can or will respond to security problems that come up after a customer has already paid for a device.

[LudwigKnuepfer]

Compare http://lists.riot-os.org/pipermail/devel/2014-December/thread.html#1468

[emmanuelsearch]

I updated the FAQ on the topic "why LGPL". Does it address the concerns?
https://github.com/RIOT-OS/RIOT/wiki/FAQ

[aeruder]

The FAQ is fine but the technical guide linked from the FAQ is perfect.

[emmanuelsearch]

@aeruder just to make sure: you are saying that the technical guide [1] is appropriate, right?
(I'm confused because of the "but" in your comment ;)
Else, if the technical guide is not appropriate in your opinion, can you elaborate?

[1] https://github.com/RIOT-OS/RIOT/wiki/LGPL-compliancy-guide

[aeruder]

Sorry for the confusion. Yes, the compliancy guide is good.