Hello World!
|
Jeremiah Foster <jeremiah.foster@...>
Hello, Firstly, and most importantly, I'd really like to thank those who've done the organization and brainstorming to get this list and idea off the ground. I know there are a lot of people behind the scenes at the Linux Foundation and other places who've done a lot of important work. Thank you.
Secondly, I have some concern around cadence. Telephone meetings once every week require momentum, otherwise its just a bit of conversation and while that is always good, it doesn't show much progress. I'd recommend once every other week unless its demonstrated that more is needed. If we stick to once a week, the project will likely have to have some project management -- milestones, deliverables, deadlines. There are already a lot of resources for people to discuss compliance, FSF compliance lists, FSFE legal, Debian-legal, etc. We don't need another list, we need codified methodology that's widely accepted both de facto and de jure.
Lastly, I'd strongly urge all of us to kill our darlings. We need to not try and chose technology winners. For example, 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) and feels a bit like a solution looking for a problem. 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. If SPDX is the right and only ISO certifiable solution, we ought to be able to demonstrate that in detail and with strong technical and legal support.
To be successful, you'll have to be widely adopted. This is the exact same measure of success FOSS software projects have to meet. The recent migration of systemd into Debian forcing Ubuntu to migrate away from Upstart ought to be a cautionary tale: forks often fail.
Please don't fork the compliance process. Please make it better, standardized, and transparent. Warm regards, Jeremiah Jeremiah C. Foster GENIVI COMMUNITY MANAGER
Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden M: +46 (0)73 093 0506  |
|
|
|
Dave Marr
On Aug 28, 2014, at 1:39 AM, Jeremiah Foster <jeremiah.foster@...> wrote:
Hello,Echoing the thanks to the LF for kindly hosting the WG. Secondly, I have some concern around cadence. Telephone meetings once every week require momentum, otherwise its just a bit of conversation and while that is always good, it doesn't show much progress. I'd recommend once every other week unless its demonstrated that more is needed. If we stick to once a week, the project will likely have to have some project management -- milestones, deliverables, deadlines. There are already a lot of resources for people to discuss compliance, FSF compliance lists, FSFE legal, Debian-legal, etc. We don't need another list, we need codified methodology that's widely accepted both de facto and de jure.Could not agree more. BTW in addition to Mike’s support on hosting the discussion, we already have a PM on this list. Kelly Williams is not an open source expert but here for the PM aspect. We must not allow this to devolve into another list. Lastly, I'd strongly urge all of us to kill our darlings. We need to not try and chose technology winners. For example, 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) and feels a bit like a solution looking for a problem. 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. If SPDX is the right and only ISO certifiable solution, we ought to be able to demonstrate that in detail and with strong technical and legal support.Agreed re no sacred cows. SPDX has a lot of thought built into it already by folks who understand the way software moves through software companies, hence the initial comments. Towards offering some initial thoughts re attribution formats, would think we’d want a format that (1) allows easy reuse, (2) automation potential via metadata-tagged fields, (3) essential data types defined, (4) a data schema that allows file-level tracking, and (5) integratability with the most popular version control systems. Probably more comes to mind by others. Would you be willing to work with Jilayne and others on the Workstream-still-to-be-formed on the appropriate options? To be successful, you'll have to be widely adopted. This is the exact same measure of success FOSS software projects have to meet. The recent migration of systemd into Debian forcing Ubuntu to migrate away from Upstart ought to be a cautionary tale: forks often fail.Again, could not agree more. As a separate note re Workstreams — a possible way for us to approach that is to first have a top level discussion on the desired characteristics of the needed elements before breaking that discussion off, into its Workstream. This discussion is an example. Thanks, Dave |
|
|
|
Mark Gisi
Hi Jeremiah,
>>> Secondly, I have some concern around cadence.
I am ok with either a weekly or biweekly cadence.
>>> Lastly, I'd strongly urge all of us to kill our darlings. We need to not try and chose technology winners.
I generally agree. One point I expressed at Tuesday’s meeting was that we need to focus on requirements (the what) and not specific processes or tools (the how). Different organizations will likely want to invest differently in processes and tools. As long as an organization can satisfy a standard set of requirements they should be good. We might provide example implementations or perhaps recommend certain technologies, but the effort should largely be requirements driven, and process and tool agnostic.
Taking off my OpenChain hat and putting on my SPDX hat - being one of the largest producers and consumers of SPDX data and an active participant in the SPDX working groups, I feel somewhat obliged to provide additional clarification on SPDX. I will do so in a separate email thread to avoid distracting from the spirit of your points.
- Mark
Mark Gisi | Wind River | Senior Intellectual Property Manager Tel (510) 749-2016 | Fax (510) 749-4552
From: openchain-bounces@... [mailto:openchain-bounces@...]
On Behalf Of Jeremiah Foster
Sent: Thursday, August 28, 2014 1:40 AM To: openchain@... Subject: [OpenChain] Hello World!
Hello,
Firstly, and most importantly, I'd really like to thank those who've done the organization and brainstorming to get this list and idea off the ground. I know there are a lot of people behind the scenes at the Linux Foundation and other places who've done a lot of important work. Thank you.
Secondly, I have some concern around cadence. Telephone meetings once every week require momentum, otherwise its just a bit of conversation and while that is always good, it doesn't show much progress. I'd recommend once every other week unless its demonstrated that more is needed. If we stick to once a week, the project will likely have to have some project management -- milestones, deliverables, deadlines. There are already a lot of resources for people to discuss compliance, FSF compliance lists, FSFE legal, Debian-legal, etc. We don't need another list, we need codified methodology that's widely accepted both de facto and de jure.
Lastly, I'd strongly urge all of us to kill our darlings. We need to not try and chose technology winners. For example, 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) and feels a bit like a solution looking for a problem. 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. If SPDX is the right and only ISO certifiable solution, we ought to be able to demonstrate that in detail and with strong technical and legal support.
To be successful, you'll have to be widely adopted. This is the exact same measure of success FOSS software projects have to meet. The recent migration of systemd into Debian forcing Ubuntu to migrate away from Upstart ought to be a cautionary tale: forks often fail.
Please don't fork the compliance process. Please make it better, standardized, and transparent.
Warm regards,
Jeremiah
-- Jeremiah C. Foster GENIVI COMMUNITY MANAGER
Pelagicore AB Ekelundsgatan 4, 6tr, SE-411 18
M: +46 (0)73 093 0506 |
|
|
|
Mark Gisi
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. 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 (spdx.windriver.com). 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.
Regards, Mark
From: openchain-bounces@... [mailto:openchain-bounces@...]
On Behalf Of Gisi, Mark
Sent: Thursday, August 28, 2014 11:40 AM To: Jeremiah Foster; openchain@... Subject: Re: [OpenChain] Hello World!
Hi Jeremiah,
>>> Secondly, I have some concern around cadence.
I am ok with either a weekly or biweekly cadence.
>>> Lastly, I'd strongly urge all of us to kill our darlings. We need to not try and chose technology winners.
I generally agree. One point I expressed at Tuesday’s meeting was that we need to focus on requirements (the what) and not specific processes or tools (the how). Different organizations will likely want to invest differently in processes and tools. As long as an organization can satisfy a standard set of requirements they should be good. We might provide example implementations or perhaps recommend certain technologies, but the effort should largely be requirements driven, and process and tool agnostic.
Taking off my OpenChain hat and putting on my SPDX hat - being one of the largest producers and consumers of SPDX data and an active participant in the SPDX working groups, I feel somewhat obliged to provide additional clarification on SPDX. I will do so in a separate email thread to avoid distracting from the spirit of your points.
- Mark
Mark Gisi | Wind River | Senior Intellectual Property Manager Tel (510) 749-2016 | Fax (510) 749-4552
From:
openchain-bounces@... [mailto:openchain-bounces@...]
On Behalf Of Jeremiah Foster
Hello,
Firstly, and most importantly, I'd really like to thank those who've done the organization and brainstorming to get this list and idea off the ground. I know there are a lot of people behind the scenes at the Linux Foundation and other places who've done a lot of important work. Thank you.
Secondly, I have some concern around cadence. Telephone meetings once every week require momentum, otherwise its just a bit of conversation and while that is always good, it doesn't show much progress. I'd recommend once every other week unless its demonstrated that more is needed. If we stick to once a week, the project will likely have to have some project management -- milestones, deliverables, deadlines. There are already a lot of resources for people to discuss compliance, FSF compliance lists, FSFE legal, Debian-legal, etc. We don't need another list, we need codified methodology that's widely accepted both de facto and de jure.
Lastly, I'd strongly urge all of us to kill our darlings. We need to not try and chose technology winners. For example, 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) and feels a bit like a solution looking for a problem. 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. If SPDX is the right and only ISO certifiable solution, we ought to be able to demonstrate that in detail and with strong technical and legal support.
To be successful, you'll have to be widely adopted. This is the exact same measure of success FOSS software projects have to meet. The recent migration of systemd into Debian forcing Ubuntu to migrate away from Upstart ought to be a cautionary tale: forks often fail.
Please don't fork the compliance process. Please make it better, standardized, and transparent.
Warm regards,
Jeremiah
-- Jeremiah C. Foster GENIVI COMMUNITY MANAGER
Pelagicore AB Ekelundsgatan 4, 6tr, SE-411 18
M: +46 (0)73 093 0506
|
|
|
|
Jeremiah Foster <jeremiah.foster@...>
On Thu, Aug 28, 2014 at 8:39 PM, Gisi, Mark <Mark.Gisi@...> wrote: > > Hi Jeremiah, > > > > >>> Secondly, I have some concern around cadence. > > > > I am ok with either a weekly or biweekly cadence. > > > > >>> Lastly, I'd strongly urge all of us to kill our darlings. We need to not try and chose technology winners. > > > > I generally agree. One point I expressed at Tuesday’s meeting was that we need to focus on requirements (the what) and not specific processes or tools (the how). Different organizations will likely want to invest differently in processes and tools. As long as an organization can satisfy a standard set of requirements they should be good. We might provide example implementations or perhaps recommend certain technologies, but the effort should largely be requirements driven, and process and tool agnostic. You said what I was trying to say, but you said it better. > > Taking off my OpenChain hat and putting on my SPDX hat - being one of the largest producers and consumers of SPDX data and an active participant in the SPDX working groups, I feel somewhat obliged to provide additional clarification on SPDX. I will do so in a separate email thread to avoid distracting from the spirit of your points. I look very much forward to hearing about your experience because tooling is something that is surely going to be important and WR's experience here is highly relevant. Thank you very much. Cheers,
Jeremiah |
|
|
|
Jeremiah Foster <jeremiah.foster@...>
On Thu, Aug 28, 2014 at 3:28 PM, Marr, David <dmarr@...> wrote: > > > On Aug 28, 2014, at 1:39 AM, Jeremiah Foster <jeremiah.foster@...> wrote: > > > Hello, > > > > Firstly, and most importantly, I'd really like to thank those who've done the organization and brainstorming to get this list and idea off the ground. I know there are a lot of people behind the scenes at the Linux Foundation and other places who've done a lot of important work. Thank you. > > Echoing the thanks to the LF for kindly hosting the WG. > > > Secondly, I have some concern around cadence. Telephone meetings once every week require momentum, otherwise its just a bit of conversation and while that is always good, it doesn't show much progress. I'd recommend once every other week unless its demonstrated that more is needed. If we stick to once a week, the project will likely have to have some project management -- milestones, deliverables, deadlines. There are already a lot of resources for people to discuss compliance, FSF compliance lists, FSFE legal, Debian-legal, etc. We don't need another list, we need codified methodology that's widely accepted both de facto and de jure. > > Could not agree more. BTW in addition to Mike’s support on hosting the discussion, we already have a PM on this list. Kelly Williams is not an open source expert but here for the PM aspect. We must not allow this to devolve into another list. Excellent news, hello Kelly! If I can be a PM resource in anyway, taking minutes, issue tracking, what have you, please let me know. > > > Lastly, I'd strongly urge all of us to kill our darlings. We need to not try and chose technology winners. For example, 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) and feels a bit like a solution looking for a problem. 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. If SPDX is the right and only ISO certifiable solution, we ought to be able to demonstrate that in detail and with strong technical and legal support. > > Agreed re no sacred cows. SPDX has a lot of thought built into it already by folks who understand the way software moves through software companies, hence the initial comments. > > Towards offering some initial thoughts re attribution formats, would think we’d want a format that (1) allows easy reuse, (2) automation potential via metadata-tagged fields, (3) essential data types defined, (4) a data schema that allows file-level tracking, and (5) integratability with the most popular version control systems. Probably more comes to mind by others. +1 > Would you be willing to work with Jilayne and others on the Workstream-still-to-be-formed on the appropriate options? I'm more than happy to provide time and resources to the workstream; I'm invested in OpenChain, I see it as a great opportunity to mitigate the last major hurdle to FOSS adoption. > > To be successful, you'll have to be widely adopted. This is the exact same measure of success FOSS software projects have to meet. The recent migration of systemd into Debian forcing Ubuntu to migrate away from Upstart ought to be a cautionary tale: forks often fail. > > > > Please don't fork the compliance process. Please make it better, standardized, and transparent. > > Again, could not agree more. As a separate note re Workstreams — a possible way for us to approach that is to first have a top level discussion on the desired characteristics of the needed elements before breaking that discussion off, into its Workstream. This discussion is an example. I agree and am heartened by the fact that so many on the list seem already well prepared, have thought about the issues and are stakeholders. That can be hard to measure at distance over the phone but I'm grateful to your response and Mark Gisi's which show this list has great potential.
Regards, Jeremiah |
|
|
|
Jeremiah Foster <jeremiah.foster@...>
On Fri, Aug 29, 2014 at 7:37 AM, Gisi, Mark <Mark.Gisi@...> wrote:
Okay, I confess I view it more as a tool, good to have this clarified for me.
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.
Regards, Jeremiah |
|
|
|
Philip Odence
Hey Jeremiah,
It’s been a while. Forgive me for doing a lousy job educating you on SPDX. Thanks, MarkG for filling in.
Having been involved in SPDX from the outset, I can tell you that there are many issues, but lack of a problem focus really isn’t one. Attached is the high level way we’ve expressed it. We’ve been well-focused, I believe, on providing a lingua franca for
partners in a supply chain to exchange software BoM information. There’s been external pressure, by the way, to expand our focus, for example into OpenChain type activities—thanks, Dave Marr, for starting OC and thereby relieving the pressure.
Adoption is a challenge, a real chicken/egg problem. How do you get people to communicate in your language when it’s hard to find others who are fluent? That said Wind River, TI, Siemens, Samsung, Alcatel-Lucent and others have all started using SPDX internally
and increasingly with partners. I have been heartened this year to learn of a number of companies using SPDX who have never been involved with the group developing the standard. We would love their involvement, but that fact that organizations can get value,
without being in the middle of SPDX specification development, says to me we’ve turned a corner and that the virtuous cycles are starting to spin.
The SPDX group will stay close to the OpenChain activities. As Bogart said, “I think this is the beginning of a beautiful friendship.”
Phil
L. Philip Odence
Chair, Linux Foundation SPDX Workgroup
Vice President and General Manager
Black Duck
8 New England Executive Park, Suite 211, Burlington MA 01803
Phone: 781.810.1819, Mobile: 781.258.9502
Skype: philip.odence
From: Jeremiah Foster <jeremiah.foster@...>
Date: Fri, 29 Aug 2014 09:17:56 +0200 To: Mark Gisi <Mark.Gisi@...> Cc: "openchain@..." <openchain@...> Subject: Re: [OpenChain] Hello World! On Fri, Aug 29, 2014 at 7:37 AM, Gisi, Mark
<Mark.Gisi@...> wrote:
Okay, I confess I view it more as a tool, good to have this clarified for me.
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.
Regards,
Jeremiah
|
|
|
|
Jilayne Lovejoy <Jilayne.Lovejoy@...>
Thanks for raising the question, Jeremiah, and to Mark for providing the excellent clarification – both to the benefit of all!
Jilayne
From: openchain-bounces@... [mailto:openchain-bounces@...]
On Behalf Of Jeremiah Foster
Sent: Friday, August 29, 2014 1:18 AM To: Gisi, Mark Cc: openchain@... 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.
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.
Regards,
Jeremiah
-- 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 |
|
|
|
Claus-Peter Wiedemann
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.
Best regards Claus-Peter
Von: openchain-bounces@... [mailto:openchain-bounces@...]
Im Auftrag von Jilayne Lovejoy
Thanks for raising the question, Jeremiah, and to Mark for providing the excellent clarification – both to the benefit of all!
Jilayne
From:
openchain-bounces@... [mailto:openchain-bounces@...]
On Behalf Of Jeremiah Foster Sent: Friday, August 29, 2014 1:18 AM
To: Gisi, Mark Cc: openchain@... 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.
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.
Regards,
Jeremiah
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. |
|
|
|
Soeren_Rabenstein@...
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. ASUS Legal Affairs Center - Europe Tel.: (+49) 2102 5609 317
ASUS Computer GmbH 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.
Best regards Claus-Peter
Von:
openchain-bounces@... [mailto:openchain-bounces@...]
Im Auftrag von Jilayne Lovejoy
Thanks for raising the question, Jeremiah, and to Mark for providing the excellent clarification – both to the benefit of all!
Jilayne
From:
openchain-bounces@... [mailto:openchain-bounces@...]
On Behalf Of Jeremiah Foster
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.
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.
Regards,
Jeremiah
BearingPoint GmbH
|
|
|
|
Jeremiah Foster <jeremiah.foster@...>
On Fri, Aug 29, 2014 at 1:19 PM, Philip Odence <podence@...> wrote:
Not at all! My misunderstanding is not due to your pedagogy. :P
I think Open Chain might complement SPDX quite well.
Version 2.0 does look promising. I think SPDX would benefit greatly from some more public roadmap description and perhaps a promise that the format churn might settle a little. Having to use version 1.1 in Yocto (with a paucity of good documentation) and wanting 2.0 features is a bit suboptimal, but then that is not SPDX's fault. Communicating a roadmap and promising some stability (1.1, 1.2, 2.0 seem to have come out rather quickly after each other) would potentially go a long way towards adoption. Cheers, Jeremiah
|
|
|
|
Claus-Peter Wiedemann
Hi Soren,
I fully agree that SPDX should stay neutral wrt to quality of the “content”. It is not a matter of the format, it is a matter of the process creating the content. The “creator” identifier is useful to identify the origin. But in real life, it is important to know who conveyed the SPDX file to you and if that person/entity is “certified”, i.e. adheres to a certain standard for creating the content.
Best regards Claus-Peter
Von: Soeren_Rabenstein@... [mailto:Soeren_Rabenstein@...]
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. ASUS Legal Affairs Center - Europe Tel.: (+49) 2102 5609 317
ASUS Computer GmbH 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.
Best regards Claus-Peter
Von:
openchain-bounces@... [mailto:openchain-bounces@...]
Im Auftrag von Jilayne Lovejoy
Thanks for raising the question, Jeremiah, and to Mark for providing the excellent clarification – both to the benefit of all!
Jilayne
From:
openchain-bounces@... [mailto:openchain-bounces@...]
On Behalf Of Jeremiah Foster
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.
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.
Regards,
Jeremiah
BearingPoint GmbH
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. |
|
|
|
Joseph Potvin
RE: "standards (like ISO 9001, CMMI,…)" & "Quality standards make perfect sense. I think however that spdx itself should stay completely neutral of them" During the past year there has been ongoing work under the ISO umbrella towards a guideline on "Compliance management systems". We included some useful links about it in the OSI "FLOW Syllabus" for Management Education on Free/Libre/Open Works : http://wiki.opensource.org/bin/Projects/flow-syllabus#HAComplianceManagementProcess:ISO19600 It's advantageous that ISO19600 is a guideline on compliance management systems generally, so that software license compliance management can more readily be operationalized and perceived as part of general corporate-wide conformance. Perhaps it could be useful for the OpenChain community to work towards creatin sort of a "good housekeeping seal of approval" that aligns with the emerging ISO19600, but that includes the particulars required for software license compliance management, and then more particularly with open source software license compliance management. This approach benefits from ISO19600, but remains separate from any eventual formal ISO certification in relation to that standard. The gerenic compliance systems baseline provided by ISO 19600 can also be useful towards creating organizationally and inter-organizationally consistent approaches to data and database license compliance, and other areas. -- Joseph Potvin Chair, OSI Management Education Working Group Coordinator, The FLOW Syllabus http://wiki.opensource.org/bin/Projects/flow-syllabus Operations Manager | Gestionnaire des opérations The Opman Company | La compagnie Opman jpotvin@... Mobile: 819-593-5983 On Mon, Sep 8, 2014 at 5:57 AM, Wiedemann, Claus-Peter <claus-peter.wiedemann@...> wrote:
--
Joseph Potvin Operations Manager | Gestionnaire des opérations The Opman Company | La compagnie Opman jpotvin@... Mobile: 819-593-5983 |
|
|
|
Balaji Viswanathan <bviswanathan@...>
My first post in this chain here. I’m managing a new Blackduck initiative for the supply chain.
I would call attention to the IPC’s PDX standard that is already in used in the electronics industry. We could leverage some ideas from them to enable a seamless interaction between hardware & software supply chains in the same industry. Does anyone else have experience with this?
IPC-2570 Supply Chain Communication (PDX) SUPPLY CHAIN COMMUNICATIONS (PDX) - IPC-257X PDX is the Product Data eXchange standard for the e-supply chain. Product Data eXchange is a multi-part standard, represented by the IPC 2570 series of specifications. The Product Data eXchange standardization effort is focused on the problem of communicating product content information between Original Equipment Manufacturers, Electronics Manufacturing Services providers and component suppliers. The standard is based on XML because this provides a simple yet powerful and flexible way to encode structured data into a format that is both human and machine-readable. The Product Data eXchange standard provides a way to describe product content (Bill of Materials (BOM), Approved Manufacturer Lists (AML), Drawings, etc.), Engineering Change Requests (ECR), Engineering Change Orders (ECO) and Deviations in an eXtensible Markup Language (XML) format. This standard will enable dramatic efficiency improvements throughout the supply chain since partners will have a way to exchange product content and changes in a common language.
http://webstds.ipc.org/standards.htm#x2570
From: openchain-bounces@... [mailto:openchain-bounces@...]
On Behalf Of Joseph Potvin
Sent: Monday, September 08, 2014 12:50 PM To: openchain@... Cc: Patrick Masson Subject: Re: [OpenChain] Hello World!
RE: "standards (like ISO 9001, CMMI,…)" & "Quality standards make perfect sense. I think however that spdx itself should stay completely neutral of them"
The gerenic compliance systems baseline provided by ISO 19600 can also be useful towards creating organizationally and inter-organizationally consistent approaches to data and database license compliance, and other areas. -- Coordinator, The FLOW Syllabus http://wiki.opensource.org/bin/Projects/flow-syllabus
On Mon, Sep 8, 2014 at 5:57 AM, Wiedemann, Claus-Peter <claus-peter.wiedemann@...> wrote: Hi Soren,
I fully agree that SPDX should stay neutral wrt to quality of the “content”. It is not a matter of the format, it is a matter of the process creating the content. The “creator” identifier is useful to identify the origin. But in real life, it is important to know who conveyed the SPDX file to you and if that person/entity is “certified”, i.e. adheres to a certain standard for creating the content.
Best regards Claus-Peter
Von:
Soeren_Rabenstein@... [mailto:Soeren_Rabenstein@...]
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. ASUS Legal Affairs Center - Europe Tel.:
(+49) 2102 5609 317
ASUS Computer GmbH Geschäftsführer: Eric Chen Amtsgericht Düsseldorf: HRB43472
From:
openchain-bounces@... [mailto:openchain-bounces@...]
On Behalf Of Wiedemann, Claus-Peter
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.
Best regards Claus-Peter
Von:
openchain-bounces@... [mailto:openchain-bounces@...]
Im Auftrag von Jilayne Lovejoy
Thanks for raising the question, Jeremiah, and to Mark for providing the excellent clarification – both to the benefit of all!
Jilayne
From:
openchain-bounces@...
[mailto:openchain-bounces@...]
On Behalf Of Jeremiah Foster
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.
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.
Regards,
Jeremiah
BearingPoint GmbH
BearingPoint GmbH
|
|
|
