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

Hi Matthias,

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 license, definately restricting the usage of covered code in some ways. Some are technical and mostly boil down to inflexible, proprietary software / tools used to develop a product. There might be some areas where actual laws prohibit the use of (partly) LGPLed software. (Usually these laws don't match any technical justification.)

This might be a slight disadvantage for RIOT adoption, but let's not forget the advantages an LGPLed ecosystem provides.

Kaspar

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

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

Hey Matthias,

   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

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." (What is Copyleft? - GNU Project - Free Software Foundation)

Cheers, Oleg

Hi,

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." (What is Copyleft? - GNU Project - Free Software Foundation)

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

Hi Kaspar,

Hi,

Hi Matthias,

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

Hi,

Hi Kaspar,

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 HTSOFT - Your MacOS software library).

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

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.

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

PS: can you send a link to your PR? I couldn't find it.

Cheers, Ludwig

Hi,

So, What is the latest decision?

No decision, yet. Stay tuned. :wink:

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

Hi Ludwig,

Pull request link : https://github.com/cakmakmurat2000/RIOT/pull/1 It is my first GIT experience. I might miss something :slight_smile:

Regards.

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

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 J

Regards.

Murat.