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 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
_______________________________________________
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
