iBet uBet web content aggregator. Adding the entire web to your favor.
iBet uBet web content aggregator. Adding the entire web to your favor.



Link to original content: https://github.com/RIOT-OS/RIOT/issues/2128
Fix FAQ to properly describe LGPL in proprietary applications · Issue #2128 · RIOT-OS/RIOT · GitHub
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix FAQ to properly describe LGPL in proprietary applications #2128

Closed
aeruder opened this issue Dec 3, 2014 · 10 comments
Closed

Fix FAQ to properly describe LGPL in proprietary applications #2128

aeruder opened this issue Dec 3, 2014 · 10 comments
Assignees
@emmanuelsearch
Labels
Type: question The issue poses a question regarding usage of RIOT

Comments

@aeruder
Copy link

aeruder commented Dec 3, 2014

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.
@Kijewski Kijewski added the Type: question The issue poses a question regarding usage of RIOT label Dec 3, 2014
@emmanuelsearch
Copy link
Member

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
Copy link
Author

aeruder commented Dec 4, 2014

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
Copy link
Contributor

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
Copy link
Author

aeruder commented Dec 4, 2014

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
Copy link
Contributor

@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
Copy link
Member

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

@emmanuelsearch
Copy link
Member

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

@aeruder
Copy link
Author

aeruder commented Apr 24, 2015

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

@aeruder aeruder closed this as completed Apr 24, 2015
@emmanuelsearch
Copy link
Member

@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
Copy link
Author

aeruder commented Apr 27, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@emmanuelsearch emmanuelsearch

Labels
Type: question The issue poses a question regarding usage of RIOT
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@aeruder @Kijewski @emmanuelsearch @LudwigKnuepfer @kaspar030