, 2015 11:46 PM
To: RIOT OS kernel developers
Subject: Re: [riot-devel] LGPL compliance testing
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
2015-02-26 16:56 GMT+01:00 Murat CAKMAK m...@muratcakmak.net
To: RIOT OS kernel developers
Subject: Re: [riot-devel] LGPL compliance testing
PS: can you send a link to your PR? I couldn't find it.
Cheers, Ludwig
Am 26. Februar 2015 07:23:52 MEZ, schrieb Ludwig Ortmann
ludwig.ortm...@fu-berlin.de:
Hi Murat,
Under what license are the generated files?
And also
experience. I might miss something :)
Regards.
-Original Message-
From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Ludwig Ortmann
Sent: Thursday, February 26, 2015 8:32 AM
To: RIOT OS kernel developers
Subject: Re: [riot-devel] LGPL compliance testing
PS: can you send a link
Hi,
On 02/25/2015 09:46 PM, Murat CAKMAK wrote:
So, What is the latest decision?
No decision, yet. Stay tuned. ;)
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
, February 21, 2015 5:09 PM
To: RIOT OS kernel developers
Subject: Re: [riot-devel] LGPL compliance testing
Hi Kaspar,
On Fri, 20 Feb 2015, Kaspar Schleiser wrote:
Let me correct myself.
There are no technical reasons against using LGPLed RIOT to develop
proprietary applications
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.
Hi,
On 02/20/15 13:07, Emmanuel Baccelli wrote:
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.
What do you mean by proprietary device?
Routers,
Hi Kaspar,
On Fri, Feb 20, 2015 at 12:24 PM, Kaspar Schleiser kas...@schleiser.de
wrote:
Hey Matthias,
On 02/19/15 23:47, Matthias Waehlisch wrote:
As you pointed out in your email, there are scenarios where the
approach will not help due to technical reasons (and using a weird
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
Hi,
On 02/20/15 13:50, Thomas C. Schmidt wrote:
sorry to interrupt here: You are discussing the question whether Linux
is available for more hardware than RIOT ???
No. We're discussing if developing proprietary products using RIOT is
comparable to developing proprietary products using embedded
Hi,
On 02/20/15 12:41, Oleg Hahm wrote:
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
Hi Matthias,
On Thu, Feb 19, 2015 at 11:47 PM, Matthias Waehlisch
m.waehli...@fu-berlin.de wrote:
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
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
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
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
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
Hi Kaspar,
On Tue, 10 Feb 2015, Kaspar Schleiser wrote:
(3) Fine-grained object archives: Having separate object archives that
reflect RIOT modules is the key idea of the approach. Two questions
remain: (a) Which types of applications can someone create without
affecting the core
Hi Kaspar,
thanks for the wiki entry. I would like to understand the different
steps better. Following questions and comments:
(1) Compiling with RIOT_VERSION: Including the RIOT_VERSION works as a
trust anchor to identify the source code base. Assuming a single (valid)
and trustworthy
Hi,
On 02/10/15 15:52, Matthias Waehlisch wrote:
(1) Compiling with RIOT_VERSION: Including the RIOT_VERSION works as a
trust anchor to identify the source code base. Assuming a single (valid)
and trustworthy version, you wouldn't need this ingredient. Right?
Correct.
(2) MD5 hash:
Hi,
On 01/26/2015 05:36 PM, Joakim Gebart wrote:
Is RIOT_VERSION the only thing that is automatically generated for each
build?
Seems like...
I mean, if even a build date is included somewhere the result will not
be identical.
I tried this on ARM (for the hello-world example) and the
Hey guys,
here's an initial draft on how to check for LGPL compliance:
https://github.com/RIOT-OS/RIOT/wiki/LGPL-compliancy-guide
This is for showing that some proprietary code has been compiled and
linked with a specific version of RIOT.
I wrote the wiki entry out of my head, so maybe I
Hi,
nice,
I will try today how it would be possible to replace and validate when
someone change parts of say the core, not the whole core though.
Best regards,
Martin
On 01/26/2015 10:46 PM, Hauke Petersen wrote:
Nice!
I'm too tired to really think through it, but how does this fit in
22 matches
Mail list logo
