OpenChain Workgroup Initial MeetingAudio portion: Conference Number: +1 (415) 906-5657 Pin: 88326 For international call instructions, please visit the website below. Please note you will have to enter the US Conference number as part of the instructions: Screen share (if used): go to http://uberconference.com/mdolan
Going? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Invitation from Google Calendar You are receiving this courtesy email at the account openchain@... because you are an attendee of this event. To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. |
Gothenburg, Sweden
Hello,Echoing the thanks to the LF for kindly hosting the WG.
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.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.
Please don't fork the compliance process. Please make it better, standardized, and transparent.
Thanks,
Dave
This event has been changed.Changed: OpenChain Workgroup Weekly MeetingAudio portion: Conference Number: +1 (415) 906-5657 Pin: 88326 For international call instructions, please visit the website below. Please note you will have to enter the US Conference number as part of the instructions: Screen share (if used): go to http://uberconference.com/mdolan
Going? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Invitation from Google Calendar You are receiving this courtesy email at the account openchain@... because you are an attendee of this event. To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. |
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
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
Gothenburg, Sweden
M: +46 (0)73 093 0506
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
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
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
Gothenburg, Sweden
M: +46 (0)73 093 0506
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.
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.
>
> > 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.
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.
Date: Fri, 29 Aug 2014 09:17:56 +0200
To: Mark Gisi <Mark.Gisi@...>
Cc: "openchain@..." <openchain@...>
Subject: Re: [OpenChain] Hello World!
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.
Does that work for folks? If that raises a concern am inviting comment on the list (for shared concerns) or directly to me (if preferred).
For the next call -- proposing for the week after next -- would suggest we discuss a schedule of key topics.
Thanks,
Dave
Perhaps for the schedule of topics, we might take your list of sub-components and flesh out what they mean, what kinds of materials or information is required, etc.
Jilayne
-----Original Message-----
From: openchain-bounces@... [mailto:openchain-
bounces@...] On Behalf Of Marr, David
Sent: Friday, August 29, 2014 10:39 AM
To: openchain@...
Subject: [OpenChain] Every other week
Based on feedback rec'd offline (time commitment; also some specific folks
who are out next week as they extend their US holiday week) it was
suggested we move our OpenChain calls to every other week.
Does that work for folks? If that raises a concern am inviting comment on the
list (for shared concerns) or directly to me (if preferred).
For the next call -- proposing for the week after next -- would suggest we
discuss a schedule of key topics.
Thanks,
Dave
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
-- 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
I also support meeting bi-weekly instead of weekly.
Best,
Eileen
Eileen Evans
Vice President & Deputy General Counsel, Cloud & Open Source
Hewlett-Packard Company
Mobile: 650.740.9909
3000 Hanover Street
Building 20B, MS 1050
Palo Alto, CA 94304 U.S.A.
|
|
|
From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Jilayne Lovejoy
Sent: Friday, August 29, 2014 10:54 AM
To: Marr, David; openchain@...
Subject: Re: [OpenChain] Every other week
I'd agree that every other week is a good idea.
Perhaps for the schedule of topics, we might take your list of sub-components and flesh out what they mean, what kinds of materials or information is required, etc.
Jilayne
> -----Original Message-----
> From: openchain-bounces@... [mailto:openchain-
> bounces@...] On Behalf Of Marr, David
> Sent: Friday, August 29, 2014 10:39 AM
> To: openchain@...
> Subject: [OpenChain] Every other week
>
> Based on feedback rec'd offline (time commitment; also some specific
> folks who are out next week as they extend their US holiday week) it
> was suggested we move our OpenChain calls to every other week.
>
> Does that work for folks? If that raises a concern am inviting
> comment on the list (for shared concerns) or directly to me (if preferred).
>
> For the next call -- proposing for the week after next -- would
> suggest we discuss a schedule of key topics.
>
> Thanks,
> Dave
> _______________________________________________
> OpenChain mailing list
> https://lists.linuxfoundation.org/mailman/listinfo/openchain
-- 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
_______________________________________________
OpenChain mailing list
https://lists.linuxfoundation.org/mailman/listinfo/openchain
Thanks for raising the question, Jeremiah, and to Mark for providing the excellent clarification – both to the benefit of all!
Jilayne
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.
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.
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
Mike, would you mind updating the invite to reflect that?
All, this means the next meeting is Tuesday 9/16.
Talk with you then!
Dave
Based on feedback rec'd offline (time commitment; also some specific folks who are out next week as they extend their US holiday week) it was suggested we move our OpenChain calls to every other week.
Does that work for folks? If that raises a concern am inviting comment on the list (for shared concerns) or directly to me (if preferred).
For the next call -- proposing for the week after next -- would suggest we discuss a schedule of key topics.
Thanks,
Dave
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
This event has been canceled and removed from your calendar.OpenChain Workgroup Weekly MeetingAudio portion: Conference Number: +1 (415) 906-5657 Pin: 88326 For international call instructions, please visit the website below. Please note you will have to enter the US Conference number as part of the instructions: Screen share (if used): go to http://uberconference.com/mdolan
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Invitation from Google Calendar You are receiving this courtesy email at the account openchain@... because you are an attendee of this event. To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. |
Mike Dolan
Director of Strategic Programs, The Linux Foundation
Email / Google Talk: mdolan@...
---
This event has been canceled and removed from your calendar.OpenChain Workgroup Weekly MeetingAudio portion: Conference Number: +1 (415) 906-5657 Pin: 88326 For international call instructions, please visit the website below. Please note you will have to enter the US Conference number as part of the instructions: Screen share (if used): go to http://uberconference.com/mdolan
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Invitation from Google Calendar You are receiving this courtesy email at the account openchain@... because you are an attendee of this event. To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. |
OpenChain Working Group (First and Third Tuesday each month)Audio portion: Conference Number: +1 (415) 906-5657 Pin: 88326 For international call instructions, please visit the website below. Please note you will have to enter the US Conference number as part of the instructions: Screen share (if used): go to http://uberconference.com/mdolan
Going? | ||||||||||||
Invitation from Google Calendar You are receiving this courtesy email at the account openchain@... because you are an attendee of this event. To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. |