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
On Fri, 13 Feb 2015, Kaspar Schleiser wrote:
> Hi Matthias,
>
> On 02/13/15 11:49, Matthias Waehlisch wrote:
> > the core technical argument that you gave is: Your approach simplifies
> > compliance check. Simplification is nice but does not introduce
> > additional new functions in principle. From this perspective I don't see
> > how this approach allows us to do things that we have not been able to
> > do before (except we can do it 'easier'). Would you agree on this?
> Not sure what you mean.
>
> This is not a technical tool for anything. Complying to LGPL is *easy*, and
> this makes it even easier.
>
> Part of the license discussion was the question how developers can develop
> proprietary (closed source) applications / products using LGPLed RIOT.
>
> LGPL puts some restrictions on doing that, it is a copyleft license.
>
> Those restrictions require the vendor of such an application to provide a way
> to relink the proprietary code with a newer version of the used library (RIOT
> in this case).
>
> So I created a make target which packs together everything needed to comply to
> that part of the license.
>
> Anyone using RIOT for building proprietary application now has an easy method
> of providing the files needed for that part of LGPL compliancy, "the files"
> meaning compiled object files. Those that would have been shipped as part of a
> firmware file anyways. They don't expose more code than a full compiled
> binary, it's the same.
>
> Compared to other systems, any proprietary binary using an LGPLed library
> (e.g., the GNU libc used on all major Linux distributions) implicitly ships
> compiled object files and allows relinking.
>
> As RIOT uses static linking, the proprietary object files have to be saved
> before completing the static link in order to enable replacing the LGPLed part
> later. This is basically all this PR tries to make supertrivial.
>
> IMHO this does make developing proprietary code using LPGLed RIOT comparable
> to writing any proprietary application for other systems like Linux, MacOS,
> Windows, ... with slight differences only because of the nature of embedded
> systems.
>
> Kaspar
> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel
>
--
Matthias Waehlisch
. Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
. Takustr. 9, D-14195 Berlin, Germany
.. mailto:waehli...@ieee.org .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
