Hi,
So in theory, developers shouldn't be able to affect the system .a's files.
And I can't think of anything that might do so by accident, when a developer
*wants* to be LGPL compliant, just writes an application, maybe adds a
proprietary driver but otherwise "behaves" regarding build system
manipulation.
I think that was a misunderstanding. I was more asking about the
"realm" of applications. The counter-arguments we had in the LGPL
discussion were not primarily "can we proof LGPL compliance" but more
"can we build reasonable, proprietary IoT applications" without
violating LGPL compliance.
Well, yes we can. There's just no perfect way of proving an application is compliant.
Assuming RIOT is already ported to a specific device, writing any proprietary application on top of that, even adding drivers for proprietary hardware, is possible without violating LGPL.
A basic RIOT port (not including drivers for all components) for the target probably needs to be LGPLed, though.
Our "method" here offers a make target that makes it easy to distribute everything necessary to enable re-linking, thus complying with that part of the LGPL. For everyone wanting to stay LGPL-compliant, this is
useful.
There are probably a million ways to sneak in modified RIOT code and still
have a valid verification using our method here.
So even if the verification passes, that alone is not proof that LGPL hasn't
been violated.
From a legal perspective it then seems worthless.
Probably right. But there is no technical way to prove any license compliancy while keeping some code closed.
OTOH, the benefit of modifying RIOT itself and concealing it has *no* commercially viable use case to me, while being a huge burden on the development itself compared to just sharing the modifications in the first place.
So anyone writing a proprietary application and distributing it like this method proposes very probably complies to LGPL.
Everyone else would just not mention RIOT and ship it's product breaking LGPL, as the criminal energy to be not license compliant is there and going through the pain of pretending to be compliant just doesn't make sense.
Also, if any project passes this verification and *is* compliant, one <5 minute possibly NDAed look at the actual proprietary code would prove that nothing is concealed, making the defense to any "you are not compliant" accusations extremely easy.
That works the other way, too. If someone distributes code in this method's manner but conceals dirty tricks in order to ship LGPL breaking code, a <5 minute look would uncover such tricks.
So while this doesn't give legal proof, it makes making a case for the actual "truth" (proving compliancy / proving non-compliancy) a lot easier.
Anything passing this verification, but breaking LGPL on purpose is easily spotted with one look at the actual code.
To be honest: I like the idea from an exercise point of view but I
don't see how this approach can help us wrt the license discussion.
I don't agree.
LGPL requires distribution of proprietary object files and everything else to enable re-linking the LGPLed code with the proprietary code.
This make target makes exactly that very easy, removing most if not all developer time consuming aspects of LGPL compliancy.
IMHO this even more reduces the license discussion to monetarization attractiveness vs. freedom for users.
Kaspar