Die 09. 08. 16 et hora 20.11.22 Jilayne Lovejoy scripsit:
> Perhaps LinuxCon Europe, by any chance… ??  :)

+1

There’s this:
https://linuxconcontainerconeurope2016.sched.org/event/7o9d/fossology-efficient-license-analysis-in-hd-michael-jaeger-siemens-ag

And from what I saw on the registration page there will also be the following
training, but unfortunately for a 100 US$ fee:

Die 10. 08. 16 et hora 15.42.55 Kate Stewart scripsit:
> We're piloting it in North America, so its free there.  ;-)

That makes sense then :)

> The FOSSology project doesn't have any funding associated with
> it though, so we're looking to charge the fee to recover costs
> (room, refreshments for participants, team travel) associated
> with holding the training.

Ah, didn’t realise that such an important piece of SW for business use is not
properly funded – which is surprising TBH.

I actually find the 100 US$ price tag fair, but was taken aback by the
difference between the two events so close together. Piloting for gratis makes
sense of course. :)

In addition, the tooling that does exist is often not suitable for things like embedded GNU/Linux, with clients running on Windows (which is just not used at all in many shops) and tools written in Java that don't integrate into things like Yocto or baserock.

 

One of the reasons to write tooling in Java is to keep it platform independent.

Speaking for the TripleCheck tooling, integration with Yocto should be possible.

Would just ask for some guidance because I'm not a Yocto distributor nor user, but would be happy to enable this feature if there is interest.

 

Best

Nuno

 

12.08.2016, 15:34, "Jeremiah Foster" <jeremiah.foster@pelagicore.com>:

On Fri, Aug 12, 2016 at 9:25 AM, Matija Šuklje <matija@...> wrote:

Die 10. 08. 16 et hora 15.42.55 Kate Stewart scripsit:
> We're piloting it in North America, so its free there.  ;-)

That makes sense then :)

> The FOSSology project doesn't have any funding associated with
> it though, so we're looking to charge the fee to recover costs
> (room, refreshments for participants, team travel) associated
> with holding the training.

Ah, didn’t realise that such an important piece of SW for business use is not
properly funded – which is surprising TBH.

 

This is the main issue -- LF has done a lot here, sponsoring OpenChain and giving resources to Fossology and more, but companies have not stepped up to provide a solid open source ecosystem around the tooling. OpenChain will do a great deal to help but there are currently the open source tooling is far away from the commercial tooling in quality and commercial tools can be expensive. In addition, the tooling that does exist is often not suitable for things like embedded GNU/Linux, with clients running on Windows (which is just not used at all in many shops) and tools written in Java that don't integrate into things like Yocto or baserock. 

 

I'm very thankful for the work of the LF and companies like ARM, Qualcomm, Wind River and of course others, but we need more tools that fit the embedded space and more training on use that is accessible to "engilawyers" as Google sometimes calls them.

 

I actually find the 100 US$ price tag fair, but was taken aback by the
difference between the two events so close together. Piloting for gratis makes
sense of course. :)

 

+1

 

Cheers,

 

Jeremiah 

,

_______________________________________________
OpenChain mailing list
OpenChain@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/openchain

 

 

--
http://triplecheck.net

 

On Fri, Aug 12, 2016 at 9:47 AM, Nuno Brito <nuno.brito@...> wrote:

In addition, the tooling that does exist is often not suitable for things like embedded GNU/Linux, with clients running on Windows (which is just not used at all in many shops) and tools written in Java that don't integrate into things like Yocto or baserock.

 

One of the reasons to write tooling in Java is to keep it platform independent.

Well, Java *is* the platform no? :-) Or rather the JVM, and it is definitely not independent, its owned by Oracle and even the open source versions suffer significant politics. Its also an enterprise language, not an embedded language, even Android (which is not Java) has a ton of apps that use C/C++, HTML, CSS, etc.

 

Speaking for the TripleCheck tooling, integration with Yocto should be possible.

We've done some integration with other Java Eclispse-based tooling in Yocto and it is a poor fit for build from source systems that rely on C, bash and python, for one thing it increases build times significantly. This is a problem when you're doing continuous integration and building entire OS images triggered by changes to git repos. In fact when Yocto integrated SPDX 1.1 it was in python. 

 

Would just ask for some guidance because I'm not a Yocto distributor nor user, but would be happy to enable this feature if there is interest.

I'd say look at the sources that Yocto preserves in a directory of its build image. That might be easy to go over and do SPDX reports on. Embedding a Java tool in Yocto will be quite difficult, not least because you build a cross-compiler toolchain on qemu. You might look at the earlier SPDX implementation to see if there is low-hanging fruit: http://www.pelagicore.com/using-yocto-and-fossology-to-get-spdx-licence-output/   Please note that this is old and SPDX is up to 2.2 for its spec I believe.

Well, Java *is* the platform no? :-) Or rather the JVM, and it is definitely not independent, its owned by Oracle and even the open source versions suffer significant politics. Its also an enterprise language, not an embedded language, even Android (which is not Java) has a ton of apps that use C/C++, HTML, CSS, etc.

 

OpenJDK is the default JVM. Oracle might dislike, but so is the GPL nature: https://en.wikipedia.org/wiki/OpenJDK#Release_of_the_class_library

 

Interesting enough is that Java is too an embedded language, reason why 2 billion older generation devices got a JVM by default before smartphones as Android surfaced, which also recently moved to OpenJDK: http://www.theregister.co.uk/2015/12/30/android_openjdk/ So, would say it is quite a battle field between major organizations, same as Linux or OpenStack alike. However, I am Java fan so anything that I write on this topic will be too biased towards making Java look good, my apologies.. :-)

 

We've done some integration with other Java Eclispse-based tooling in Yocto and it is a poor fit for build from source systems that rely on C, bash and python, for one thing it increases build times significantly. This is a problem when you're doing continuous integration and building entire OS images triggered by changes to git repos. In fact when Yocto integrated SPDX 1.1 it was in python.

 

You would probably have more interest in a command line edition than a GUI tool. On my work laptop a vanilla Linux kernel takes some 15 minutes on the first run to be analyzed and output an SPDX. After that only the modified files get scanned so we are talking about a few seconds to get the fresh SPDX file.

 

I'd say look at the sources that Yocto preserves in a directory of its build image. That might be easy to go over and do SPDX reports on. Embedding a Java tool in Yocto will be quite difficult, not least because you build a cross-compiler toolchain on qemu. You might look at the earlier SPDX implementation to see if there is low-hanging fruit: http://www.pelagicore.com/using-yocto-and-fossology-to-get-spdx-licence-output/   Please note that this is old and SPDX is up to 2.2 for its spec I believe.

 

Ok, will do. When ready will contact you in private to help on the testing side if you don't mind.

 

Thanks,

Nuno

 

 

 

12.08.2016, 16:05, "Jeremiah Foster" <jeremiah.foster@pelagicore.com>:

On Fri, Aug 12, 2016 at 9:47 AM, Nuno Brito <nuno.brito@...> wrote:

In addition, the tooling that does exist is often not suitable for things like embedded GNU/Linux, with clients running on Windows (which is just not used at all in many shops) and tools written in Java that don't integrate into things like Yocto or baserock.

 

One of the reasons to write tooling in Java is to keep it platform independent.

 

Well, Java *is* the platform no? :-) Or rather the JVM, and it is definitely not independent, its owned by Oracle and even the open source versions suffer significant politics. Its also an enterprise language, not an embedded language, even Android (which is not Java) has a ton of apps that use C/C++, HTML, CSS, etc.

 

Speaking for the TripleCheck tooling, integration with Yocto should be possible.

 

We've done some integration with other Java Eclispse-based tooling in Yocto and it is a poor fit for build from source systems that rely on C, bash and python, for one thing it increases build times significantly. This is a problem when you're doing continuous integration and building entire OS images triggered by changes to git repos. In fact when Yocto integrated SPDX 1.1 it was in python. 

 

Would just ask for some guidance because I'm not a Yocto distributor nor user, but would be happy to enable this feature if there is interest.

 

I'd say look at the sources that Yocto preserves in a directory of its build image. That might be easy to go over and do SPDX reports on. Embedding a Java tool in Yocto will be quite difficult, not least because you build a cross-compiler toolchain on qemu. You might look at the earlier SPDX implementation to see if there is low-hanging fruit: http://www.pelagicore.com/using-yocto-and-fossology-to-get-spdx-licence-output/   Please note that this is old and SPDX is up to 2.2 for its spec I believe.

 

Regards,

 

Jeremiah

 

 

Best

Nuno

 

12.08.2016, 15:34, "Jeremiah Foster" <jeremiah.foster@pelagicore.com>:

On Fri, Aug 12, 2016 at 9:25 AM, Matija Šuklje <matija@...> wrote:

Die 10. 08. 16 et hora 15.42.55 Kate Stewart scripsit:
> We're piloting it in North America, so its free there.  ;-)

That makes sense then :)

> The FOSSology project doesn't have any funding associated with
> it though, so we're looking to charge the fee to recover costs
> (room, refreshments for participants, team travel) associated
> with holding the training.

Ah, didn’t realise that such an important piece of SW for business use is not
properly funded – which is surprising TBH.

 

This is the main issue -- LF has done a lot here, sponsoring OpenChain and giving resources to Fossology and more, but companies have not stepped up to provide a solid open source ecosystem around the tooling. OpenChain will do a great deal to help but there are currently the open source tooling is far away from the commercial tooling in quality and commercial tools can be expensive. In addition, the tooling that does exist is often not suitable for things like embedded GNU/Linux, with clients running on Windows (which is just not used at all in many shops) and tools written in Java that don't integrate into things like Yocto or baserock. 

 

I'm very thankful for the work of the LF and companies like ARM, Qualcomm, Wind River and of course others, but we need more tools that fit the embedded space and more training on use that is accessible to "engilawyers" as Google sometimes calls them.

 

I actually find the 100 US$ price tag fair, but was taken aback by the
difference between the two events so close together. Piloting for gratis makes
sense of course. :)

 

+1

 

Cheers,

 

Jeremiah 

,

_______________________________________________
OpenChain mailing list
OpenChain@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/openchain

 

 

--
http://triplecheck.net

 

 

--

Jeremiah C. Foster

GENIVI COMMUNITY MANAGER

 

Pelagicore AB

Ekelundsgatan 4, 6tr, SE-411 18
Gothenburg, Sweden

M: +1.860.772.9242

jeremiah.foster@...

 

 

--
http://triplecheck.net