Re: Hello World!


Hi Peter


Quality standards make perfect sense. I think however that spdx itself should stay completely neutral of them and may merely convey the information which quality standards have been complied with, they may also include a verification code or the like, but should not define the standards in any way.

Maybe the “creator”-identifier could be used for QA information?



Mit freundlichen Grüßen / Kind regards


Sören Rabenstein



Sören Rabenstein, LL.M.
Senior Legal Counsel

ASUS Legal Affairs Center - Europe

Tel.: (+49) 2102 5609 317
Fax.: (+49) 2102 5609 309


ASUS Computer GmbH
Harkortstr. 21-23, 40880 Ratingen

Geschäftsführer: Eric Chen

Amtsgericht Düsseldorf: HRB43472





From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Wiedemann, Claus-Peter
Sent: Montag, 8. September 2014 10:43
To: Jilayne Lovejoy; Jeremiah Foster; Gisi, Mark
Cc: openchain@...
Subject: Re: [OpenChain] Hello World!


Hi everyone,


Thank you for bringing this up. Having this clarified is vital for the open chain activities. Let me add one more aspect. As Mark pointed out, SPDX is a format (like, say, XML). There are some tools (and hopefully many more in the future) to process/convert SPDX files. And once V2.0 with important features like hierarchy is out,  the adoption rate will increase. But when dealing with license information in the supply chain, the format is only one side of the story. It greatly impacts efficiency but not so much effectiveness. The crucial factor is the quality of the content. As we all know, every member of the supply chain is responsible for the license compliance of its deliveries, including all pieces delivered by other members of the supply chain. Ideally, one would take the SPDX files delivered, add  additional content for the pieces produced and pass on the combined SPDX to the downstream recipients. This is very efficient and duplicate work is avoided. But is it effective? Nobody knows, since there are no quality standards for license information. How was it produced? How was it verified? I think that open chain must focus on the “content” aspect rather than on the “format” aspect (which is basically solved with SPDX). We need some standards (like ISO 9001, CMMI,…) for dealing with license information and certification for organizations adhering to these standards.

What do you think?


Best regards



Von: openchain-bounces@... [mailto:openchain-bounces@...] Im Auftrag von Jilayne Lovejoy
Gesendet: Freitag, 29.
August 2014 20:46
An: Jeremiah Foster; Gisi, Mark
Cc: openchain@...
Betreff: Re: [OpenChain] Hello World!


Thanks for raising the question, Jeremiah, and to Mark for providing the excellent clarification – both to the benefit of all!




From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Jeremiah Foster
Sent: Friday, August 29, 2014 1:18 AM
To: Gisi, Mark
Subject: Re: [OpenChain] Hello World!


On Fri, Aug 29, 2014 at 7:37 AM, Gisi, Mark <Mark.Gisi@...> wrote:

Jeremiah raised some common concerns about SPDX that, as an early adopter, I wanted to share my experiences.


>> while SPDX looks great, its not widely adopted. Debian has its own format and Yocto is using SPDX

>> version 1.1. Its hard to use, has numerous supported versions (1.1, 1.2 and 2.0 in development)


SPDX is a specification and not a tool.


Okay, I confess I view it more as a tool, good to have this clarified for me.


It is analogous to PDF, which is also a specification. Specification details are largely relevant to tool developers and not so much to the tool end users. Most of us view PDF files using one tool or another, but very few of us know what the specifications looks like (nor should we need to). Therefore updates to a specification largely only impact tool developers. Adobe released multiple versions of the PDF spec over the course of the first few years.  This is to be expected.


>> Being Java based (there is Go code and python code now) its better suited for those working in a

>> Windows environment and while I'm certain that is a highly lucrative market,

>> for Free Software developers it tends to be anathema.


Since SPDX is a specification I assume you are referring to tool support. I understand your concerns here. Additional tool support is a place where SPDX could benefit.


>> For example, while SPDX looks great, its not widely adopted.


Although the jury is still out on SPDX, it is progressing through the typical stages of technology adoption as described in Geoffrey Moore’s entrepreneurial bible: “Crossing the Chasm”.  At Wind River we see early adopter participation rapidly increasing.  We have seen a tripling in customer usage over the past 12 months which includes traffic to our free SPDX file generation website ( Similarly, PDF too got off to a slow start, yet triumphed in the end.


>> and feels a bit like a solution looking for a problem.


Wind River’s adoption was heavily driven by a mission critical problem we faced. Wind River offers a Linux Distro kit consisting of more than 1000 software packages plus a kernel. In the beginning, customers demanded contractually that we deliver “complete” licensing information using their “customized” format. This was a nightmare. We were required to rummage through millions of source files to grab the specified licensing information to be put into the customer’s “custom” format.  After we preformed this task it was repeated by other organizations downstream in the supply chain. We understood this cost could be significantly mitigated if there was a commonly accepted file format we could use to record and exchange licensing information. SPDX directly solved this problem. We also utilize SPDX data in our internal compliance program.


Thanks very much for this email. Puts SPDX into the right perspective for me. I've sort of viewed it from a software engineer's view as this thing I have to add not knowing really why. If it does provide a software Bill of Materials that can effectively provide assurance in the supply chain then clearly its a solution to a very real problem.






-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

BearingPoint GmbH
Geschäftsführer: Marcel Nickler (Vorsitzender), Hans-Werner Wurzel (stellv. Vorsitzender), Kiumars Hamidian, Kai Wächter, Dr. Robert Wagner
Vorsitzender des Aufsichtsrats: Beat Leimbacher
Sitz: Frankfurt am Main
Registergericht: Amtsgericht Frankfurt am Main HRB 55490

The information in this email is confidential and may be legally privileged. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.

This email and any attachments to it contain confidential information and are intended solely for the use of the individual to whom it
is addressed.If you are not the intended recipient or receive it accidentally, please immediately notify the sender by e-mail and delete
the message and any attachments from your computer system, and destroy all hard copies. If any, please be advised that any unauthorized
disclosure, copying, distribution or any action taken or omitted in reliance on this, is illegal and prohibited. Furthermore, any views
or opinions expressed are solely those of the author and do not represent those of ASUSTeK. Thank you for your cooperation.

Join { to automatically receive all group messages.