SPDX Wiki - User contributions [en]

General Meeting

2014-11-18T22:40:03Z

MartinMichlmayr: Link to minutes rather than latest minutes since latest minutes are broken

This is the working area for the General Team. This team has primary responsibility for summarizing the activities of the three working teams and discussing cross-functional issues. The minutes of this monthly meeting provide a good summary of what's going on across the SPDX group, so signing up for the General Meeting mailing list is a good way to stay in touch.

The General Team meets on the first Thursday of every month at 16:00 GMT (8:00AM PT, 9:00AM MT, 10:00AM CT, 11:00ET).
Dial-in number: 1.877.435.0230 (US and Canada) or 1.253.336.6732 (International)
Conference code: 7812589502

* [[General_Meeting/Priorities|Current Priorities]]
* [[General_Meeting/Minutes|Meeting Minutes]]
* [[General_Meeting/Presentation_Materials|Presentation Materials]]
* [[General_Meeting/Old|Older Items]]

[[Category:General]]

Technical Team/Minutes

2014-07-16T15:00:59Z

MartinMichlmayr: switch kidsonly to no

{{#subpages:|format=ul|kidsonly=no|pathstyle=none|sort=desc}}

[[Category:Technical|Minutes]]
[[Category:Minutes]]
[[Technical Team/Minutes/CollabSummitPhotos|White Boards from Collab Summit]]

Legal Team/Minutes

2014-07-16T14:58:38Z

MartinMichlmayr: switch kidsonly to no

{{#subpages:|format=ul|kidsonly=no|pathstyle=none|sort=desc}}

[[Category:Legal|Minutes]]
[[Category:Minutes]]

General Meeting/Latest Minutes

2014-07-16T14:35:43Z

MartinMichlmayr: switch kidsonly to no

These are the latest meeting minutes for the General Meeting.

{{#subpages:|page=General_Meeting/Minutes|format=ul|kidsonly=no|pathstyle=none|sort=desc|limit=5}}

A [[General_Meeting/Minutes|complete list of minutes]] is available too.

General Meeting/Minutes

2014-07-16T14:35:17Z

MartinMichlmayr: switch kidsonly to no

These are the meeting minutes and decisions for the General Meeting.

{{#subpages:|format=ul|kidsonly=no|pathstyle=none|sort=desc}}
[[Category:General|Minutes]]
[[Category:Minutes]]

Business Team/Launch/1.1

2013-09-05T13:10:29Z

MartinMichlmayr: Fix link to 1.0 press release

[http://lcna2012.sched.org/event/d6abd8bb5f87585c538181d3dce0825f?iframe=yes&w=900&sidebar=yes&bg=no#sched-body-outer LinuxCon SPDX Panel Discussion]

[[Business_Team/Launch/1.0/Press_Release|SPDX 1.0 Press Release]]

[http://www.linuxfoundation.org/news-media/announcements/2012/08/linux-foundation%E2%80%99s-spdx%E2%84%A2-workgroup-releases-new-version-software SPDX 1.1 Press Release]

Press Release Content

The SPDX workgroup, hosted by The Linux Foundation, today announced the release of version 1.1 of its Software Package Data Exchange (SPDX™) standard.

* Expanded license list -- 12new licenses added in the 1.1 release and we now have a process in place to accomodate new license requests.
* OSI announces that is has adopted SPDX short identifiers (quote and pointer)
* Based on feedback from the community the SPDX data license was changed from PddL to CC0. (get a quote from Karen C)
* Summary of changes from 1.0 to 1.1. (Kate)
* Talk about the availability of both commercial and open source tools that support SPDX.

A key enabler to the adoption of SPDX is tooling to automate the production of SPDX files and we are pleased to see both commercial and open source projects stepping up to this challenge.

Reach out to commercial vendors for quotes:

* Antelink
* Blackduck
* OpenLogic
* NexB
* Palamida
* Protecode

Reach out to Open Source projects for quotes:

* UNO Fossology project (Matt Germonprez)
* Source Auditor (Gary ONeall)
* University of Victoria (Daniel German)

[[Category:Business]]
[[Category:Archived]]

Business Team/Launch/1.0/Press Release

2013-09-05T13:09:31Z

MartinMichlmayr: Add 1.0 press release from old site

'''SPDX Workgroup Releases Software Package Data Exchange Standard to Widespread Industry Support'''

''Standard format for communicating open source license and copyright information throughout supply chain ensures better, easier compliance''

LINUXCON, Vancouver, B.C., August 17, 2011 – The SPDX workgroup, hosted by The Linux Foundation, today announced the release of version 1.0 of its Software Package Data Exchange (SPDX™) standard.

The SPDX standard helps facilitate compliance with free and open source software licenses by standardizing the way license information is shared across the software supply chain. SPDX reduces redundant work by providing a common format for companies and communities to share important data about software licenses and copyrights, thereby streamlining and improving compliance.

SPDX was developed with participation by a wide range of industry and open source community heavyweights, including: Alcatel-Lucent, Antelink, Black Duck Software, Canonical, HP, Micro Focus, Motorola Mobility, nexB Inc, OpenLogic, Palamida, Protecode, Source Auditor, Texas Instruments and Wind River. Participants in the SPDX beta program included Antelink, HP, Motorola Mobility, Texas Instruments and Wind River.

“The SPDX 1.0 standard is an example of how open compliance and collaboration can enable the advancement of Linux and open source software,” said Jim Zemlin, executive director of The Linux Foundation. “We applaud the SPDX workgroup for its important work on providing a consistent way to report and view license information for software technology components, making it even easier for companies to maximize their investments in free and open source software.”

Most technology products today are assembled from multiple components that contain free and open source software, as well as commercial software; these components are created, delivered, and received by companies throughout the supply chain. Because of the distributed nature and complexity of the global software supply chain, it has become cumbersome and time consuming for each organization to prepare the license information for these components in the multiple distinct formats prescribed by others in their supply chain.

By enabling communities and companies to provide license information in a common format that can be easily analyzed and shared, the SPDX standard helps to accelerate the adoption of Linux and other free and open source software across industries, including the consumer electronics marketplace, by easing the burden of compliance through transparent sharing of license information.

“Today we’re seeing collaboration among industry experts come to fruition in SPDX 1.0,” said Esteban Rockett, co-founder of SPDX and lead software counsel at Motorola Mobility (an SPDX beta participant). “Representatives from the community, vendors and companies that use open source have come together to deliver a standard, accompanied with tools, that will make it easier to determine and comply with license obligations in a software bill of materials. This reduces compliance anxiety and costs, and further accelerates the adoption of Linux and other free and open source software.”

“The announcement of the initial release of the SPDX standard is a welcome event, because SPDX is a crucial building block in an industry-wide system of automated license compliance administration,” said Eben Moglen, executive director of the Software Freedom Law Center. “The efforts of the SPDX workgroup will ultimately help to realize large cost savings for all parties making commercial use of embedded FOSS, as well as substantially increased assurance of license compliance for FOSS licensors.”

The SPDX standard defines a standard file format that lists detailed license and copyright information for a software package and each file it comprises. The SPDX community has also provided open source tools to convert SPDX files to and from spreadsheet formats.

Visit the SPDX website for more details on what is in the SPDX standard or to participate in the SPDX community: www.spdx.org.

A video overview of SPDX is available at http://www.linuxfoundation.org/programs/legal/compliance/webinars/introduction-to-spdx

'''Widespread Industry Support for SPDX 1.0'''

'''Antelink''' 
“SPDX gives us an easy way to get data about licenses in open source projects,” said Guillaume Rousseau, CEO, Antelink. “As a participant in the SPDX beta program, we have found the SPDX specification to be simple, straightforward and easy to work with. We’re very happy to support the SPDX efforts, and look forward to implementing SPDX 1.0 in our search engine of open source files!”

'''Black Duck Software''' 
“Black Duck’s mission is to enable open source adoption while automating governance and compliance. SPDX is completely aligned with this mission, and so from the outset, we have been eager to invest our resources and expertise in the initiative,” said Phil Odence, vice president of Business Development, Black Duck Software.

'''Canonical''' 
“We look forward to the opportunity of working with upstream projects using SPDX and/or DEP5 to make it easier to understand the licensing associated with those projects,” said Kate Stewart, Ubuntu Release Manager.

'''Debian''' 
“Having a consistent way to describe licenses that’s shared by Debian’s DEP5 and the SPDX working group will help the entire ecosystem provide accurate licensing information for open source projects,” said Steve Langasek, Debian DEP5 co-editor.

'''Fedora''' 
“Fedora is pleased to have participated in the development of the SPDX specification. SPDX will help shine a light on Free and Open Source Software licensing,” said Tom “spot” Callaway, Fedora Engineering Manager.

'''HP''' 
“Open source is an extremely valuable asset to HP and the technology industry. With so many open source components throughout the software supply chain, organizations need a common format to simplify their license compliance efforts,” said Phil Robb, director, HP Open Source Program Office. “By streamlining the process, the SPDX standard addresses how license information is shared, while reducing the risks and costs of compliance for organizations. This represents the next step of industry-wide due diligence to ensure the ongoing success of open source into the future by respecting the rights and wishes of its authors.”

'''Micro Focus''' 
“The broad adoption of SPDX by independent software vendors will substantially reduce the overhead involved in open source adoption and compliance,” said Thomas Incorvia, vice president of Product Licensing at Micro Focus.

'''nexB Inc.''' 
“SPDX 1.0 is a crucial first step toward establishing the processes and tools that will support the application of supply chain best practices to component-based software development,” said Michael Herzog, CEO of nexB Inc. “It will assist organizations of all sizes and types in their efforts to comply with open source license obligations, and it also provides a solid building block for managing other types of software license data in the future.”

'''OpenLogic''' 
“As we work with enterprises to help them comply with open source licenses, one of the challenges they face is getting a complete understanding of what open source licenses are included in their products. SPDX will provide an important step forward by standardizing the way that licenses information is communicated and sharing that information across the software supply chain,” said Kim Weins, senior vice president of Marketing at OpenLogic. “Our audit and scanning tools will support the SPDX spec to help automate these compliance processes.”

'''OSI''' 
“We applaud the work of the SPDX working group on helping to simplify and standardize references to software licenses and build on the naming work that OSI’s volunteers were already doing. OSI has already adopted SPDX in the definitive list of licenses at http://opensource.org/licenses,” said Michael Tiemann, president, the Open Source Initiative (OSI). “The SPDX workgroup has leveraged more than a decade of the work at OSI in reviewing licenses for their impact on software freedom. By using the SPDX set of standard short-form license names, the entire open source ecosystem will be able to communicate in a consistent manner, especially to identify and avoid code under SPDX-identified licenses that are not OSI-approved.”

'''Protecode''' 
“SPDX will enable more organizations to freely use open source software in their products and streamline the license compliance process. Having a standard in place will benefit both the Linux and open source communities as a whole. All of our System 4 products will fully support SPDX 1.0,” Kamal Hassin, VP of Product Management, Protecode.

'''Source Auditor''' 
“Source Auditor is pleased to be a contributor to SPDX specification and tools,” said Gary O’Neall, CEO of Source Auditor. “By incorporating SPDX into our processes and tools, we will enable our customers and their suppliers to reduce the cost and complexity of complying with open source license obligations.”

'''Texas Instruments''' 
“SPDX is a great resource that allows TI to understand all licensing information for the open source components of our software packages,” said Jack Manbeck, manager, Open Source Review Board, TI. “TI is committed to providing customers with full knowledge of all components included in TI software packages and assuring compliance with all applicable open source licenses. SPDX enables us to do this quickly, efficiently and cost-effectively.”

'''Wind River''' 
“SPDX is another step towards advancing Linux and open source software in embedded markets,” said Paul Anderson, vice president of marketing and strategy for Linux products at Wind River. “As an active participant in both the SPDX workgroup and Beta program, Wind River has developed a strong understanding and appreciation of how SDPX can benefit embedded device vendors. SPDX can ease compliance by standardizing the way license and copyright information is shared across the entire supply chain.”

'''About SPDX''' 
The Software Package Data Exchange® (SPDX™) specification is a standard format for communicating the components, licenses and copyrights associated with a software package. This SPDX Community is a workgroup sponsored by The Linux Foundation and associated with FOSSBazaar. The specification has been adopted as one of the key elements of the Linux Foundation’s Open Compliance Program. Further, the SPDX naming conventions are now in use at the industry’s repository of record for open source licenses, maintained by the Open Source Initiative at http://opensource.org/licenses. The SPDX specification itself is under the Creative Commons Attribution License 3.0. For more information about SPDX, please visit: http://spdx.org/

'''About The Linux Foundation''' 
The Linux Foundation is a nonprofit consortium dedicated to fostering the growth of Linux. Founded in 2007, the organization sponsors the work of Linux creator Linus Torvalds and promotes, protects and advances the Linux operating system by marshaling the resources of its members and the open source development community. The Linux Foundation provides a neutral forum for collaboration and education by hosting Linux conferences, including LinuxCon, and generating original Linux research and content that advances the understanding of the Linux platform. Its web properties, including Linux.com, reach approximately two million people per month. The organization also provides extensive Linux training opportunities that feature the Linux kernel community’s leading experts as instructors. Follow The Linux Foundation on Twitter.

Trademarks: The Linux Foundation and SPDX are trademarks of The Linux Foundation. Linux is a trademark of Linus Torvalds.

Legal Team/Priorities

2013-07-10T14:52:21Z

MartinMichlmayr: add link

Additional information related to current priorities and work in progress is stored here. More information about these items may also be captured in the relevant meeting minutes.

* [[Legal_Team/License_List/Licenses_Under_Consideration|Licenses Under Consideration]]
* [[Legal_Team/License_List/License-templates|License templates]]
* [[Legal_Team/Current_Projects_and_Issues|Current Projects and Issues]]

[[Category:Legal]]

Technical Team/Minutes/2013-05-07

2013-05-15T10:02:40Z

MartinMichlmayr: Remove redundant info

== Attendees ==
* Gary O’Neall
* Bill Schineller
* Kate Stewart
* Marshall Clow
== Agenda ==
* Review of plugfest results
==Review of plugfest results==
* Concluded/asserted license inconsistency (bug 1114) – need to send over to legal [Gary to forward on to Jilayne]
* Convention for file path – need best practice document – Added bug
* Need to add a 1.2 release for the bugs database – Kate will add
* Need to change default owner from Peter Williams for bugs database – Kate will update
* Extracted license text – do we need to add another field for the complete text? Need a discussion. Added a documentation bug.
* Add “old style MIT’ license to license list – found in install.sh license. Added a bug.
* GPL 2.0 and GPL 2.0 and Later have identical standard license text – bug added
* Add header to the standard license list – suggested for 1.2 – bug added 1121
* Different between SPDX document authors vs. reviewer – added bug for usage guidelines
* Use of ArtifactOf clarify the use – bug added for usage guidelines
* Clarify the use of parenthesis for non-compound licenses (e.g. “(GPL-2.0)”) – bug added
Stopped at middle of page 5

Technical Team/Minutes/2013-05-14

2013-05-15T10:02:18Z

MartinMichlmayr: Remove redundant info

== Attendees ==
* Gary O’Neall
* Bill Schineller
* Kate Stewart
* Kirsten Newcomer
* Michael Herzog
== Agenda ==
* Review of plugfest results
==Review of plugfest results==
* ArtifactOf best practices – documentation bug added
* Reviewer – not sure what this issue was – request more information from the distribution list, if no one remembers we will drop – Kate to send out email
* Download location – Best practice should point to location that is likely to be preserved – file level locations may go away, git locations are likely to be preserved – document best practice bug
* Home page URL – enhancement to add a second URL which is the project home page – bug added
* Once the home page URL is implemented, we should revisit the download location. The best practice may be to be specific to the file location even though the URL may go away. – documented in the download location documentation bug
* Sorting filenames – documented best practice for SPDX Tag/Value format files; added bug for SPDX tools to follow the best practice
*4.14 in 1.1 is copyright text aggregated from all files, proposal to add an optional field for package level copyright if it exists
* Field on file for notices – bug added for enhancement
* License ref – assign name. Would need some way to make unique. Bug added for enhancement. General consensus that this would be a 2.0 item.
[[Category:Technical|Minutes]]
[[Category:Minutes]]

Business Team/Minutes/2013-05-02

2013-05-09T20:09:06Z

MartinMichlmayr: Typo fix

== Attendees ==

* Jack Manbeck
* Mark Gisi
* Gary O'Neall
* Phil Odence
* Pierre Lapointe
* Matt Germonprez
* Jilayne Lovejoy
* Mike Dolan

== Agenda ==

# Survey update – Phil
# Requirements capture worksheet update – Mark
# Documents we are working on
## Consuming SPDX – Jack
## Producing SPDX - ? (okay I forgot who volunteered for this)
## Umbrella SPDX document – Mark
# Any other business

== Notes ==

=== Survey Update ===
* We had about 20 some responses so far.
* Phil will send out a summary of survey results to the business team. The summary will not have names or companies as the survey was confidential.
* There was discussion on how long to leave the survey open. general consensus was that we leave it open until we hit a wall where we do not seem to be getting any new responses in.
* Mike Dolan from the LF said they were going to send out a newsletter and they could include the survey link and a blurb. Phil was going to email him the information.
* As the results need to be confidential, we can do a summary report after all the results are in and see what is actionable for SPDX.
* Survey results on their raw form will not be part of the requirements collection we are doing due to the anonymity clause. The idea was that if you did not include a business or user name then the survey was confidential but it may not have been clearly explained. Therefore, if either are entered the results will be treated as anonymous.
* Scott will also send out a link to the survey on the European Legal network mailing list.

=== Requirements Worksheet ===

* Mark had not started yet, too busy with the prep for Collab.
* Debated whether requirements should be kept on wiki or on something like Google Docs for now. It was decided to use Google Docs for the raw data. At some point once the information was massaged it could be moved to the wiki.

=== Umbrella Document ===

* Mark is about 3/4 of the way done with this.

=== Consuming SPDX Document ===

* No update on this as Jack was busy with planning and prep for Collab.
* Matt offered to help Jack with the document. he suggested that it include real business use cases of people consuming SPDX. It was a good idea and will be incorporated.
* It was suggested that the documents share a common structure. Jack to send something out on that for the next meeting.

=== Producing SPDX ===

* It seems Scott was the one who volunteered to drive the producing document. No update as Scott was busy with Collab.

=== Other Business ===

* Jack really needs to update the calendar invite with the right call in code.
* Mike Dolan from the Linux Foundation will be our new contact.
* Matt said OpenMAMA will start using SPDX. he will be working with them

[[Category:Business|Minutes]]
[[Category:Minutes]]

Business Team/Minutes/2013-05-02

2013-05-09T20:08:48Z

MartinMichlmayr: Fix MediaWiki syntax

== Attendees ==

* Jack Manbeck
* Mark Gisis
* Gary O'Neall
* Phil Odence
* Pierre Lapointe
* Matt Germonprez
* Jilayne Lovejoy
* Mike Dolan

== Agenda ==

# Survey update – Phil
# Requirements capture worksheet update – Mark
# Documents we are working on
## Consuming SPDX – Jack
## Producing SPDX - ? (okay I forgot who volunteered for this)
## Umbrella SPDX document – Mark
# Any other business

== Notes ==

=== Survey Update ===
* We had about 20 some responses so far.
* Phil will send out a summary of survey results to the business team. The summary will not have names or companies as the survey was confidential.
* There was discussion on how long to leave the survey open. general consensus was that we leave it open until we hit a wall where we do not seem to be getting any new responses in.
* Mike Dolan from the LF said they were going to send out a newsletter and they could include the survey link and a blurb. Phil was going to email him the information.
* As the results need to be confidential, we can do a summary report after all the results are in and see what is actionable for SPDX.
* Survey results on their raw form will not be part of the requirements collection we are doing due to the anonymity clause. The idea was that if you did not include a business or user name then the survey was confidential but it may not have been clearly explained. Therefore, if either are entered the results will be treated as anonymous.
* Scott will also send out a link to the survey on the European Legal network mailing list.

=== Requirements Worksheet ===

* Mark had not started yet, too busy with the prep for Collab.
* Debated whether requirements should be kept on wiki or on something like Google Docs for now. It was decided to use Google Docs for the raw data. At some point once the information was massaged it could be moved to the wiki.

=== Umbrella Document ===

* Mark is about 3/4 of the way done with this.

=== Consuming SPDX Document ===

* No update on this as Jack was busy with planning and prep for Collab.
* Matt offered to help Jack with the document. he suggested that it include real business use cases of people consuming SPDX. It was a good idea and will be incorporated.
* It was suggested that the documents share a common structure. Jack to send something out on that for the next meeting.

=== Producing SPDX ===

* It seems Scott was the one who volunteered to drive the producing document. No update as Scott was busy with Collab.

=== Other Business ===

* Jack really needs to update the calendar invite with the right call in code.
* Mike Dolan from the Linux Foundation will be our new contact.
* Matt said OpenMAMA will start using SPDX. he will be working with them

[[Category:Business|Minutes]]
[[Category:Minutes]]

General Meeting/Minutes/2013-04-CollabSummit

2013-04-27T11:44:41Z

MartinMichlmayr: Improve formatting

'''COLLABORATION SUMMIT SUMMARY'''

For those of you who didn’t make it to the Collaboration Summit, below is a summary of the different components of the event. It was pretty inspiring in a number of ways…for me, it felt like the rubber is finally meeting the road seeing real tools—our own, from academia, and commercial—putting out real live SPDX docs. The every positive KarenC summed it up as “The discussions have much more of a feeling that this has to happen – the only questions are around how.” And I agree.

All the team leads did an outstanding job organizing our ever expanding involvement in Linux event. (Now we even get our own track.) Gary, MarkG and Adam were also key in pulling this off.

== Tech Team Working Session ==

In this session we went through the current model proposal for 2.0, and discussed options that would simplify the model, and still meet the use cases we're targeting. We were also able to start off the relationship and element usage enumerations. Full details can be found at: [[Technical_Team/Minutes/2013-04-16]].

== Legal Team Working Session ==

The SPDX Legal Team met at the LF Collab Summit to hash out the remaining bits of the License Matching guidelines. Namely whether SPDX should provide "guidelines only" in regards to what is to be considered substantive text of a license for matching purposes or whether SPDX should go further and provide some kind of actual markup or examples in regards to text than can be ignored or considered "replaceable" for matching purposes. And, if the latter, to what extent and in what format to provide such markup or examples. The legal team, with good representation from various tool makers and tech team members, decided that markup was needed to avoid potential differences in interpretation by tool makers. It was decided to use simple markup that could be illustrated within a .txt file, as that is the (mostly) preferred download format for the licenses. The exact details of the markup are being worked out and the Legal Team (with help from anyone else in the SPDX Workgroup) will manage getting the markup created for the entire current SPDX License List.

== Open SPDX Discussion ==

Mark Gisi from Windriver and Adam Cohn from Cisco held this session on Tuesday afternoon. It was held under Chatham House Rules which means “When a meeting, or part thereof, is held under the Chatham House Rule, participants are free to use the information received, but neither the identity nor the affiliation of the speaker(s), nor that of any other participant, may be revealed.”. Now before you say hey you just said you weren’t supposed to mention names, these two were the chairs as listed on the SPDX schedule.There was a lot of good discussion. One individual talked about how they are fully integrating SPDX into what they their company delivers and how they are shipping, and I believe the number was, over 500 SPDX documents with each release. They also had a website for generating SPDX documents. Others talked about how they have started to integrate SPDX into their compliance process using it for reviews but not yet quite shipping. The reasons seemed to vary for that but they appeared to be more procedural than SPDX related. One individual did raise a concern on the amount of time that it might take to generate SPDX documents adding that it increased the cost of their compliance it was not something they could do. A few individuals talked about the adoption of SPDX among open source projects. There was some discussion on how this could be done now as there are a few open source tools that have appeared to generate SPDX documents. One individual talked about how they would like to see SPDX become more fully integrated into the community meaning that practices normally associated with an open source project such as peer review and so forth were used and considered part of the process of generating, reviewing and editing SPDX documents.

== SPDX Morning Sessions ==

Mark Gisi (the man that Scott calls “the spiritual leader of SPDX adoption”) kicked off the morning with License to Kill…You Code, a very cogent treatise on why it’s important for copyright holders to get it right if they want their projects to thrive.
Then Gary “the Toolman” O’Neall lead a panel on Tooling up for SPDX. He gave an over view of group, community and commercial tools that are now compatible with SPDX. Gary was joined by Matt Germonprez of the University of Nebraska Omaha and Sameer Ahmed from Wind River Systems who both talked in some detail about work their groups have done to “tool up.”
Conclusion: This stuff is real! And to prove it…

== SPDX Bakeoff ==

The SPDX Bakeoff was held Wednesday afternoon. Our main objective was to compare SPDX output from different tools in order to identify bugs and resolve different interpretations of the specification. We had great representation from the various tool providers, members of the SPDX working group, and a number of other interested parties. Gary O’Neall’s excellent spreadsheet comparison tool was used as the basis for comparison of the various SPDX files. Per the agenda, we first stepped through the complete Time package on a file by file basis. Following that we dove into Busybox but only at the package level. There was a lot good discussion and yes we did find some bugs in the tools and areas where the specification needs to be improved. All in all it was a very productive session and should serve to advance the adoption of SPDX. The spreadsheet along with notes from the session are captured on in this Google doc folder: https://drive.google.com/?tab=mo&authuser=0#folders/0BxKdX878M2HCTlZIbkZSMXN6SGc

General Meeting/Minutes/2013-04-CollabSummit

2013-04-27T11:43:37Z

MartinMichlmayr: Use internal link

'''COLLABORATION SUMMIT SUMMARY'''

For those of you who didn’t make it to the Collaboration Summit, below is a summary of the different components of the event. It was pretty inspiring in a number of ways…for me, it felt like the rubber is finally meeting the road seeing real tools—our own, from academia, and commercial—putting out real live SPDX docs. The every positive KarenC summed it up as “The discussions have much more of a feeling that this has to happen – the only questions are around how.” And I agree.

All the team leads did an outstanding job organizing our ever expanding involvement in Linux event. (Now we even get our own track.) Gary, MarkG and Adam were also key in pulling this off.

'''Tech Team Working Session'''

In this session we went through the current model proposal for 2.0, and discussed options that would simplify the model, and still meet the use cases we're targeting. We were also able to start off the relationship and element usage enumerations. Full details can be found at: [[Technical_Team/Minutes/2013-04-16]].
Legal Team Working Session
The SPDX Legal Team met at the LF Collab Summit to hash out the remaining bits of the License Matching guidelines. Namely whether SPDX should provide "guidelines only" in regards to what is to be considered substantive text of a license for matching purposes or whether SPDX should go further and provide some kind of actual markup or examples in regards to text than can be ignored or considered "replaceable" for matching purposes. And, if the latter, to what extent and in what format to provide such markup or examples. The legal team, with good representation from various tool makers and tech team members, decided that markup was needed to avoid potential differences in interpretation by tool makers. It was decided to use simple markup that could be illustrated within a .txt file, as that is the (mostly) preferred download format for the licenses. The exact details of the markup are being worked out and the Legal Team (with help from anyone else in the SPDX Workgroup) will manage getting the markup created for the entire current SPDX License List.

'''Open SPDX Discussion'''

Mark Gisi from Windriver and Adam Cohn from Cisco held this session on Tuesday afternoon. It was held under Chatham House Rules which means “When a meeting, or part thereof, is held under the Chatham House Rule, participants are free to use the information received, but neither the identity nor the affiliation of the speaker(s), nor that of any other participant, may be revealed.”. Now before you say hey you just said you weren’t supposed to mention names, these two were the chairs as listed on the SPDX schedule.There was a lot of good discussion. One individual talked about how they are fully integrating SPDX into what they their company delivers and how they are shipping, and I believe the number was, over 500 SPDX documents with each release. They also had a website for generating SPDX documents. Others talked about how they have started to integrate SPDX into their compliance process using it for reviews but not yet quite shipping. The reasons seemed to vary for that but they appeared to be more procedural than SPDX related. One individual did raise a concern on the amount of time that it might take to generate SPDX documents adding that it increased the cost of their compliance it was not something they could do. A few individuals talked about the adoption of SPDX among open source projects. There was some discussion on how this could be done now as there are a few open source tools that have appeared to generate SPDX documents. One individual talked about how they would like to see SPDX become more fully integrated into the community meaning that practices normally associated with an open source project such as peer review and so forth were used and considered part of the process of generating, reviewing and editing SPDX documents.

'''SPDX Morning Sessions'''

Mark Gisi (the man that Scott calls “the spiritual leader of SPDX adoption”) kicked off the morning with License to Kill…You Code, a very cogent treatise on why it’s important for copyright holders to get it right if they want their projects to thrive.
Then Gary “the Toolman” O’Neall lead a panel on Tooling up for SPDX. He gave an over view of group, community and commercial tools that are now compatible with SPDX. Gary was joined by Matt Germonprez of the University of Nebraska Omaha and Sameer Ahmed from Wind River Systems who both talked in some detail about work their groups have done to “tool up.”
Conclusion: This stuff is real! And to prove it…

'''SPDX Bakeoff'''

The SPDX Bakeoff was held Wednesday afternoon. Our main objective was to compare SPDX output from different tools in order to identify bugs and resolve different interpretations of the specification. We had great representation from the various tool providers, members of the SPDX working group, and a number of other interested parties. Gary O’Neall’s excellent spreadsheet comparison tool was used as the basis for comparison of the various SPDX files. Per the agenda, we first stepped through the complete Time package on a file by file basis. Following that we dove into Busybox but only at the package level. There was a lot good discussion and yes we did find some bugs in the tools and areas where the specification needs to be improved. All in all it was a very productive session and should serve to advance the adoption of SPDX. The spreadsheet along with notes from the session are captured on in this Google doc folder: https://drive.google.com/?tab=mo&authuser=0#folders/0BxKdX878M2HCTlZIbkZSMXN6SGc

Technical Team/Minutes/2013-04-23

2013-04-24T13:17:13Z

MartinMichlmayr:

== Attendees ==

* Gary O’Neall
* Bill Schineller
* Kirsten Newcomer
* Kate Stewart
* Jack Manbeck
* Michael Herzog
* Marshall Clow
== Agenda ==
* Review of changes to Model
* 1.2 release
== Review of model ==
* Update model page to better reflect
* Additional Usage enumeration for contrib library use case – “Optional”
== Review of the plugfest results ==
* 1.2 ideas
** RDF is case sensitive
* 2.0 ideas
** Do we want to add a package home page (may different from the download location)?
* Tools ideas
** Compare utility – using file checksums instead of file names
** Update tag to RDF to be case insensitive on the tag values
* Usage convention
** Version should generally not be in the name but in the version fields unless it is part of the formal names
** Originator/supplier/source info clarifications
** Download location – use of mirrors
** Concluded license conventions – use of conjunctive licenses even when the licenses may contradict (depending on interpretation)
* Legal Team
** For concluded license – if incompatible licenses are found, should we state the licenses in the conjunctive form

[[Category:Technical|Minutes]]
[[Category:Minutes]]

Technical Team/Proposals/2012-02-01/Merged Model Proposal

2013-04-24T13:08:26Z

MartinMichlmayr: Use internal link

Below is a class diagram merging Ed Warnicke's proposed SPDX Element model with the 1.0 model. Definately a work in progress. Most of the class definitions can be found in the 1.0 spec in the RDF appendix (model) or in [[Technical_Team/Proposals/Rough_proposal_for_provenance,_hierarchy_and_aggregation,_and_supply_chain_friendliness_in_SPDX_2.0|Ed's proposal]].

The goals of this proposal are to:

* Support the use cases for the 2.0 spec
* Support the supply chain use cases
* Support the "hierarchical" or embedded package use cases
* Provide a more abstract model which can simplify the application of SPDX to some of the more complex use cases

This proposal extends the existing proposals by adding an SPDX Element Relationship which describes the type of relationship from one SPDX element to another.

See the attached document for the mapping between the SPDX 1.0 properties and this proposal.

See the attached document for a proposal on creating RDF references to other Licensable documents which can be verified through checksums.

Model updated per minutes of 2013 Linux Collab Summit: [[Technical_Team/Minutes/2013-04-16]]

[[Image:Model-4-16-2013.png|909px|Class Diagram]]

[[Category:Technical]]

Technical Team/Minutes/2013-04-23

2013-04-24T13:06:54Z

MartinMichlmayr: Fix MediaWiki syntax

== Attendees ==

* Gary O’Neall
* Bill Schineller
* Kirsten Newcomer
* Kate Stewart
* Jack Manbeck
* Michael Herzog
* Marshall Clow
== Agenda ==
* Review of changes to Model
* 1.2 release
== Review of model ==
* Update model page to better reflect
* Additional Usage enumeration for contrib library use case – “Optional”
== Review of the plugfest results ==
* 1.2 ideas
** RDF is case sensitive
* 2.0 ideas
* Do we want to add a package home page (may different from the download location)?
* Tools ideas
** Compare utility – using file checksums instead of file names
** Update tag to RDF to be case insensitive on the tag values
* Usage convention
** Version should generally not be in the name but in the version fields unless it is part of the formal names
** Originator/supplier/source info clarifications
** Download location – use of mirrors
** Concluded license conventions – use of conjunctive licenses even when the licenses may contradict (depending on interpretation)
* Legal Team
** For concluded license – if incompatible licenses are found, should we state the licenses in the conjunctive form

[[Category:Technical|Minutes]]
[[Category:Minutes]]

Wiki Conventions

2013-04-12T12:53:14Z

MartinMichlmayr: Update link to getting started page

This page describes conventions that should be followed on the SPDX wiki. You can also read the page on [[Getting started with the SPDX wiki|getting started]].

== SubPages ==

This wiki uses subpages to provide a hierarchy. For example, the minutes for the business team are located under <code>Business Team/Minutes</code>.

When you add a new page, please make sure to use the correct hierarchy. If you want to create a new business related page, choose <code>Business Team/name of page</code> If you'd like to add new business minutes, add them as <code>Business Team/Minutes/YYYY-MM-DD</code>

== Categories ==

We use [[Special:Categories|categories]] to organize pages. You should add one of these categories at the bottom of each new page:
* <nowiki>[[Category:Business]]</nowiki>
* <nowiki>[[Category:General]]</nowiki>
* <nowiki>[[Category:Legal]]</nowiki>
* <nowiki>[[Category:Technical]]</nowiki>

== Adding minutes ==

The list of minutes is updated automatically but this requires minutes to be added in the right location. Please use <code>XXX Team/Minutes/YYYY-MM-DD</code> for new minutes.

Additionally, minutes should have the category <nowiki>[[Category:Minutes]]</nowiki> in addition to the category defining the subject area.

== Headings ==

Make sure not to use a heading starting with <nowiki>=</nowiki> as this reserved for the title of the page. Headings should start with <nowiki>==</nowiki>. See the [http://www.mediawiki.org/wiki/Help:Formatting MediaWiki wiki syntax] page for more information.

== Commenting on pages ==

If you'd like to comment on pages, please click on "discussion" on the top of a page.

Main Page

2013-04-12T12:52:34Z

MartinMichlmayr: Update link to getting started page

The Software Package Data Exchange® (SPDX®) [http://spdx.org/content/spdx-specification specification] is a standard format for communicating the components, licenses and copyrights associated with a software package. This wiki site is the workspace for SPDX Teams. Please see [http://spdx.org spdx.org] for general information, the current specification, license list, etc.

* [[Getting started with the SPDX wiki]]
* [[General Meeting]]
* [[Business Team]]
* [[Legal Team]]
* [[Technical Team]]
* [[Old|Older Information]]

Getting started with the SPDX wiki

2013-04-12T12:50:38Z

MartinMichlmayr: MartinMichlmayr moved page Getting started to Getting started with the SPDX wiki: Better name

This is the wiki for the [http://spdx.org/ SPDX project]. Here is some information to help you get started.

== User registration and access ==

You need an account in order to make changes to this wiki. Because of spam concerns, we turned off account registration on this wiki. If you'd like to have an account, please send your prefered user name to wiki@spdx.org and we'll quickly create an account for you.

== Editing the wiki ==

The wiki uses MediaWiki. You can read about the [http://www.mediawiki.org/wiki/Help:Formatting wiki syntax] used by MediaWiki. We also provide a WYSIWYG (what you see is what you get) editor to make it easy to edit this wiki.

== Wiki conventions ==

There are certain conventions you should follow when editing this wiki, please see the page [[Wiki Conventions|wiki conventions]].

== Subscribing to pages ==

If you have an account on this wiki, you can follow certain pages in order to stay up to date with changes made to these pages. Simply click on "watch" at the top of a page in order to add it to your watch list.

You can choose to be informed about changes to pages on your wtch list by email. Go to [[Special:Preferences]], scroll down in the "User profile" tab, go to "E-mail options" and enable "E-mail me when a page or file on my watchlist is changed".

== Help and questions ==

If you need any help, please contact the [http://lists.spdx.org/mailman/listinfo/spdx SPDX mailing list]. If you want to contact the admin of this wiki, email wiki@spdx.org

Getting started

2013-04-12T12:50:38Z

MartinMichlmayr: MartinMichlmayr moved page Getting started to Getting started with the SPDX wiki: Better name

#REDIRECT [[Getting started with the SPDX wiki]]

Legal Team

2013-04-12T08:46:36Z

MartinMichlmayr: Reverted edits by Lfadmin (talk) to last revision by MartinMichlmayr

This is the working area for the Legal Team. The SPDX Legal Team supports and provides recommendations to the SPDX working groups regarding licensing issues for the specification itself; maintains the [http://spdx.org/licenses/ SPDX License List]; and promotes the SPDX specification to the legal community at-large.

The Legal Team meets every other Thursday at 18:00 GMT (10:00AM PT, 11:00 MT, 12:00 CT, 1:00PM ET).
Dial-in number: 1.866.740.1260 (US Toll-free) or 1.303.248.0285 (International)
Conference code: 2404545

* [[Legal_Team/Priorities|Current Priorities and Work in Progress for the Legal Team]]
* [[Legal_Team/Minutes|Meeting Minutes of the Legal Team]]
* [[Legal_Team/Decisions|Decisions of the Legal Team]]
* [[Legal_Team/Old|Older Items for the Legal Team]]

[[Category:Legal]]

Legal Team/Minutes/2013-04-11

2013-04-11T18:41:51Z

MartinMichlmayr: fix link

== Attendees ==
*Jilayne Lovejoy, OpenLogic
*Tom Incorvia, Incorvia
*Dennis Clark, NexB
*Jack Manbeck, TI
*Zac White, Entente
*Paul Madick, HP
*Phil Odence, Black Duck
*Tom Vidal, Abrams Garfinkel Margolis Bergson

== New site and wiki is up!!! ==

== Public Domain explanation page ==
see http://wiki.spdx.org/view/Legal_Team/Decisions/Dealing_with_Public_Domain_within_SPDX_Files_(DRAFT)
updated to reflect Jason Buttara's excellent revisions and one small edit by Jilayne in last paragraph. All on call agreed it looked good, so will be considered done once updated with proper links and reference to spec

== Approve final text for SPDX License List Overview page: ==
please see draft here: http://wiki.spdx.org/view/Legal_Team/License_List/Overview_and_License_Inclusion_Guidelines_(draft_for_review)
*call for comments/feedback on the general list and meeting last week resulted in only a few tweaks as follows:
**Somewhere early on, probably in the background, we should make a parenthetical statement to the effect that the standard is able to handle any license, it doesn't have to be on the list. It's just more convenient if it is.
*** all on call agreed, sentence to this effect added to end of second paragraph
**whack the para that starts "Although SPDX…" Seems to me the next para handles the issue.
*** all on call agreed that having this paragraph was helpful and cutting it didn't save that much space, so left it in
**This seems too strong: "Because the present focus of SPDX is the collection and presentation of the open-source software licenses contained in a software package, any license that is a candidate for inclusion on the SPDX License List must be an "open source" license. maybe: "…must have the attributes of an OSS license" or "…must be OSS-like…" or "…must be characterized as an…"
***changed to "must have the attributes of an open source license"
***changes will be made, page posted on official site and the draft page on the wiki will go away

== license list issues that came up as Jilayne went to update and release v1.18: ==

: A) license list language issue (all licenses on list are in native language with links to other official translations. License for which this is an issue are "Cecill, EUPL. and now, the German Public License
:*discussed that this dovetails with license matching guidelines - should official translations be considered equivalent and hence only need one short identifier for the license or should we have each translation as a separately listed license with it's own short identifier?
:*have there been any claims or issues related to translations? not that anyone knows of...
:**decided to leave as is, that is with license text included for native language and links to official translations in the note field. therefore for German Public License, will use the German full name and text for purposes of the License List; slight update to license overview description of fields to make sure this is explained there
:*** good issue to add to list for license matching guidelines discussion next week at Collab Summit
:B) MITRE Collaborative Virtual Workspace License - had decided to add (old license that is OSI approved) but the license text itself includes its own 6 clauses plus the text of the GPL and the text of the MPL with a choice of either.
:*should license text for matching purposes only be the 6 clauses, as whatever license (GPL or MPL) is chosen would/should be indicated with the short identifier for those licenses?
:*talked through how this might work within an SPDX document, the SPDX License List, and the license matching guidelines...
:**decided in spirit of releasing v1.18 of the license list and not making a hurried decision on this topic, which could impact the way other similar licenses are dealt with, to leave license off list for now and also discuss issue at license matching guideline meeting next week.

[[Category:Legal|Minutes]]
[[Category:Minutes]]

Wiki Conventions

2013-04-11T10:38:27Z

MartinMichlmayr: Link to category page

This page describes conventions that should be followed on the SPDX wiki. You can also read the page on [[Getting started|getting started]].

== SubPages ==

This wiki uses subpages to provide a hierarchy. For example, the minutes for the business team are located under <code>Business Team/Minutes</code>.

When you add a new page, please make sure to use the correct hierarchy. If you want to create a new business related page, choose <code>Business Team/name of page</code> If you'd like to add new business minutes, add them as <code>Business Team/Minutes/YYYY-MM-DD</code>

== Categories ==

We use [[Special:Categories|categories]] to organize pages. You should add one of these categories at the bottom of each new page:
* <nowiki>[[Category:Business]]</nowiki>
* <nowiki>[[Category:General]]</nowiki>
* <nowiki>[[Category:Legal]]</nowiki>
* <nowiki>[[Category:Technical]]</nowiki>

== Adding minutes ==

The list of minutes is updated automatically but this requires minutes to be added in the right location. Please use <code>XXX Team/Minutes/YYYY-MM-DD</code> for new minutes.

Additionally, minutes should have the category <nowiki>[[Category:Minutes]]</nowiki> in addition to the category defining the subject area.

== Headings ==

Make sure not to use a heading starting with <nowiki>=</nowiki> as this reserved for the title of the page. Headings should start with <nowiki>==</nowiki>. See the [http://www.mediawiki.org/wiki/Help:Formatting MediaWiki wiki syntax] page for more information.

== Commenting on pages ==

If you'd like to comment on pages, please click on "discussion" on the top of a page.

Legal Team/Decisions/Inclusion Guidelines (Background)

2013-04-11T10:24:04Z

MartinMichlmayr: Convert to MediaWiki syntax

== Background ==

Work on the SPDX License List (SPDX-LL) began sometime in 2010. The first SPDX-LL had approximately one hundred licenses on it. The initial set of licenses was included based on informal discussion and consensus. Although various "guidelines" were identified in regards to which licenses to include or not during this time, formal guidelines were not recorded beyond the meeting minutes. We had to start somewhere, and the obvious was the easy beginning point. Decisions or guidelines that evolved out of discussion or by implication included the following:

* include commonly found open source licenses. Although discussion was not explicit in regards to how to define an "open source license," this was always an implicit guiding principle
* include all OSI approved licenses, both current and those approved but now deprecated. Rationale being that once OSI-approved, always OSI-approved and deprecated licenses still appear "in the wild"
* in regards to "public domain": public domain dedications (because, it cannot technically be a "license"...) that are commonly found, well-established, or associated with a commonly found packages will be included on the SPDX-LL (e.g., ANTLR, Sax, CC-0). However, the idea of having a "generic" identifier for something that it released into the public domain was rejected after some discussion. This would not be practical for a number of reasons:
*# the concept of public domain does not necessarily translate across jurisdictions and the conditions under which a work can be released to the public domain vary on an country-by-country basis. Thus, having a short identifier could potentially only introduce ambiguity as to what that short identifier precisely means (and ambiguity - at least insofar as it comes to accurately identifying a license - is not the goal)
*# where something is noted with a public domain dedication, it can be captured the same was as any (other) license. That is, if it is something is part of the SPDX License List, it will have a short identifier, full name and exact text match like the examples above, and if it is not on the SPDX License List, it can be captured the same way as any (other) license not on the list via a license reference.
* recognition that the need for a more formal process for requesting new licenses to be added to the SPDX-LL. Such a process was discussed in terms of an ideal goal and pragmatic approach for the current reality. A process that bridged the former, with more weight on the latter was implemented in April 2012.

== Current State ==

And that brings us to the waning days of 2012 when the need to make it clear and transparent to the world what criteria we are using to maintain this list in terms of determining when to "accept" or "reject" a request to add a license to the SPDX-LL became impossible to ignore. Repeated abbreviated discussions around the issue of "freeware" or open source-ish licenses came up on a multiple occasions and so discussion ensued and a first draft and one round of revisions were completed by December 2012.

== Goal ==

The goal here is to come up with a set of guiding principles for licenses to be added or not added to the SPDX-LL. This way, when a license request is submitted the guidelines can be referenced (instead of one-off rationales for each license, which is inefficient), thus providing some consistency and reliable expectations for what the SPDX-LL includes.

Please review the meeting minutes on the following dates for a summary of discussion thus far:

* initially brought up briefly (and in regards to Sun/Oracle licenses which are commonly found, but not really "open source" licenses) in mid-August 2012. We discussed briefly on a few calls, but tabled for a later date due to other priorities or pre-determined agenda items.
* Request for addition of FLora license [[Legal_Team/Minutes/2012-10-31]]
* [[Legal_Team/Minutes/2012-11-13]]
* subsequent email discussion centered around the need for the guidelines to also comment on the addition of such things as public domain dedications or other notices that do not, per se, constitute a "license" but may otherwise fit the existing/initial criteria (commonly found/common package)

Also see the attached document below for the second draft, which includes some comments and track changes.

Additional discussion has been ongoing via the mailing list at legal at spdx.org. Alternatively, you can comment on this page below.

[[Category:Legal]]

Legal Team/Current Projects and Issues

2013-04-11T10:22:04Z

MartinMichlmayr: Fix broken link

LAST UPDATED: 17 Jan 2013

'''1) License List'''

'''1A) Licenses to add? ''(Kirstin Newcomer to track progress and lead; GROUP to make decisions; may need to delegate research on particular licenses to others - ongoing, check in on this each call)'''''

# "old" MIT? see http://blog.gmane.org/gmane.comp.licenses.spdx.legal/day=20121201
# FLORA License - decided not to add at this point in time, pending guidelines mentioned in #3 below. see http://blog.gmane.org/gmane.comp.licenses.spdx.legal/month=20121101 for most recent thread on the topic
# Unlicense - see thread here: http://search.gmane.org/?query=unlicense&group=gmane.comp.licenses.spdx.legal
# add US Gov't works - add short identifier to list; see email from David Wheeler
# add in Notes field for all GNU licenses that short identifier "GPL-2.0" = GPL v2 only and vice versa - more discussion on this?

'''1B) OSI outstanding issues: ''(Jilayne - goal to have these resolved by end of June or next rev of SPDX-LL)'''''

# Artistic license issue
# futher clarification on a few previous issues (were APSL-1.0, APSL-1.1, and GPL-2.0 ever approved?)
# zlib/ libpng license clarification
# Jabber Open Source License v1.0 -
# Jabber Open Source License v1.0 – decided to add and in doing so noticed the archived text here (http://archive.jabber.org/core/JOSL.pdf) is not the same as the OSI has on their site (it was OSI approved). What do we do about this? (see attached .doc file for comparison. text says "draft" at bottom... decided because it's an old license to hold off and not add to list yet - and resolve with OSI (with goal of having on list b/c it was OSI approved and we endeavored to have all OSI licenses on SPDX list, even if old). license text also can be found at: http://code.google.com/p/jabber-net/wiki/FAQ_License

'''1C) GPL exceptions: ''(Tom Vidal - goal to have this reasonably done by end of June)'' ''' We don't have them all and there are also the issue of inconsistencies "in the wild" among named exceptions and actual text (i.e. not all exceptions found called Foo exception have the exact same text; how do we deal with this?)

'''1D) Better system for saving/updating SPDX License List ''(Jilayne to coordinate with Gary - goal to have this done by end of February)'' ''' Currently the SPDX-LL is kept and updated by Jilayne. This is not an optimal system (hit by a bus factor not accounted for). Need to change to some kind of respository that tracks changes and can be viewed by all (But not edited by all).

'''2) Community outreach and list coordination:'''Goal of coordinating with various other license lists to make sure SPDX has licenses from these lists and check short name matching (or create "translation" document if different)

'''2A) Fedora license list ''(Paul Madick - goal for first pass by end of first quarter?? TBD, Paul to report on timing next call)''''' will need to check lists for discrepancies, i.e. are there licenses on Fedora list that are not on SPDX-LL and if so, decide to add; also need to create short-name matching matrix due to Fedora using different type of categorization for its short names. Coordinate and communicate with Tom Calloway throughout.

'''2B) Fossology (''ASSIGN)''''' coordinate with Bob Gobeille, see http://www.fossology.org/projects/fossology/wiki/MatchSPDXLicenceIDs

'''2C) Gentoo - ''(ASSIGN)'''''

'''2D) Suse ''(ASSIGN)''''' list found here: https://docs.google.com/spreadsheet/pub?key=0AqPp4y2wyQsbdGQ1V3pRRDg5NEpGVWpubzdRZ0tjUWc (courtesy of Ciaran Farrell from 6/27/12 email list thread)

'''2E) FSF license list match-up''' from http://www.gnu.org/licenses/license-list.html. completed for v1.17. any outstanding license questions were added to #1(A)

'''3) General guidelines for what licenses are included on the SPDX License List ''(Tom Vidal - conclude by end of March)''''' General statement or guidelines needed in regards to the types of license that are to be included on the SPDX-LL; in particular in regards to requests fo r adding a new license. e.g., only open source licenses? what about freeware licenses? see meeting minutes from 31-Oct and 13-Nov for background and discussion thus far. draft of guidelines began by Tom Vidal see [[Legal_Team/License_List/Inclusion_Guidelines_(Background)]] for overview of issue and latest revision - To Be Continued with larger group

'''3A) Also review process for requesting a new license''' once above is done to see if anything should be updated as we refine the process, etc.

'''4) License Match Guidelines ''(GROUP - needs an owner and would like to make a priority)''''' not enough people on 6/27 legal call for quorum/to complete; see meeting minute for 6/27 and several prior meetings. Matching guidelines updated as of 6/27, see [[Legal_Team/License_List/License_Matching_Guidelines]]

'''5) Website updates ''(Jilayne - time frame TBD)'''''

# add page for explaining public domain discussion
# update page re: change of "data license" from PddL to MIT
# add page to wiki that outlines progress regarding varioud license list coordination (OSI, FSF, Fedora, etc.) we have or have yet to coordinate with
# other past decisions further explained?

'''6) Formatting and "master list" for License List (i.e. actual license text files) ''(Phil)''''' Currently the "master" consists of spreadsheet with list + individual .txt files for license text field = downloadable zip file. This is then converted into html pages for website. Peter, Gary, and Jilayne have had initial discussion on this issue; to be discussed further with more fleshed out proposal

PROPOSAL: License text files formatted in HTML instead of .txt files as default; can convert from there into text file with tool if people want that too; Option to use HTML to indicate some of matching rules?

'''7) Recommendations or guidance on how to best determine license for a particular file''' how to identify the license for an open source project - ex. Within the file versus whether there's a copying file on top of the directory ? provide guidance/suggstion (industry practice?) that license in the file is more determinate than the license in the directoryShould the legal group aggregate industry best practices and come up with a group of guidelines and provide some influence on that?

[[Category:Legal]]

General Meeting/SPDX Web Site Cleanup

2013-04-11T09:53:02Z

MartinMichlmayr: Link to talk page

The following table lists the curret issues/improvments that need to be made to the SPDX website following our conversion thiis past month from the old site to the new one.

The list was intiially populated by Jack Manbeck but feel free to add to or modify the contents. Note: I found it a little challenging to add a table to the wiki and to be able to format it. I ended up restorting to HTML. This may make it challangeing for some to add items. If thats the case, please feel free to post to the list and I can make the appopriate changes or add a line after the table stating who you are and what your feedback is.

The Assigned To and Status fields will be taken care of by the web revamp team.

{| style="width: 637px" border="1"
| style="width: 40px" valign="top" |
'''Item'''
| style="width: 315px" valign="top" |
'''Description'''
| style="width: 95px" valign="top" |
'''Source'''
| style="width: 95px" valign="top" |
'''Assigned To'''
| style="width: 110px" valign="top" |
'''Status'''
|-
| style="width: 40px" valign="top" |
1
| style="width: 315px" valign="top" |
I noticed that the link on the home page for spdx-tech lower right under roles and responsibilities goes to a basically empty page (http://spdx.org/content/technical-0) . I’m not sure if the page just needs to be filled in or if it should link to http://spdx.org/wiki/spdx/spec-development
| style="width: 95px" valign="top" |
Gary
| style="width: 95px" valign="top" |

| style="width: 110px" valign="top" |

|-
| style="width: 40px" valign="top" |
2
| style="width: 315px" valign="top" |
Raise up SPDX License List on the menu hierarchy
| style="width: 95px" valign="top" |
Jilayne
| style="width: 95px" valign="top" |

| style="width: 110px" valign="top" |

|-
| style="width: 40px" valign="top" |
3
| style="width: 315px" valign="top" |
SPDX Tech Page Comments
* Add Bug Tracking page. Seperate for spec and tools. Have anonymous qeuries.
* Need a page added for the current spec so we can park the use case indfo. Maybe move to the spec area?
| style="width: 95px" valign="top" |
Tech team Review
| style="width: 95px" valign="top" |

| style="width: 110px" valign="top" |

|-
| style="width: 40px" valign="top" |
4
| style="width: 315px" valign="top" |
Under http://spdx.org/about-spdx it says: "This site is the home for everything SPDX and is the workspace for SPDX Groups." I think this should be rephrased to: "This site is the home for everything SPDX and is the workspace for the SPDX sub-groups (Legal, Technical and Business)." On that same page, sometimes we call it "SPDX Standard" and then "SPDX Specification". Are these used interchangeably? It's unclear.
| style="width: 95px" valign="top" |
Ibrahim
| style="width: 95px" valign="top" |

| style="width: 110px" valign="top" |

|-
| style="width: 40px" valign="top" |
5
| style="width: 315px" valign="top" |
I think this paragraph can use some rephrasing: Original: "The SPDX specification is developed by the SPDX workgroup, which is hosted by the Linux Foundation. The grass-roots effort includes representatives from more than 20 organizations—software, systems and tool vendors, foundations and systems integrators—all committed to creating a standard for software package data exchange formats." Suggested: "The SPDX project is hosted at the Linux Foundation that provides a neutral environment for collaboration. The SPDX standard is developed by the participants of the project which include representatives from more than 20 organizations—software, systems and tool vendors, open source foundations and systems integrators. The SPDX participants are committed to creating a standard for software package data exchange formats."
| style="width: 95px" valign="top" |
Ibrahim
| style="width: 95px" valign="top" |

| style="width: 110px" valign="top" |

|-
| style="width: 40px" valign="top" |
6
| style="width: 315px" valign="top" |
Term-wise: SPDX is a Working Group of the Linux Foundation. It's Technical, Business and Legal teams are considered sub-groups. This needs to be updated through out the pages. For instance, the blue box "PARTICIPATE - Join a Working Group" need to be changed to something like "PARTICIPATE - Join a Task Force" or "PARTICIPATE - Join a Working Sub-Group" or something of that sort. (Update) I later read also that these are called teams. This needs to be updated to be consistent.
| style="width: 95px" valign="top" |
Ibrahim
| style="width: 95px" valign="top" |

| style="width: 110px" valign="top" |

|-
| style="width: 40px" valign="top" |
7
| style="width: 315px" valign="top" |
Under http://spdx.org/about-spdx/background you jump to this page from: http://spdx.org/about-spdx
| style="width: 95px" valign="top" |
Ibrahim
| style="width: 95px" valign="top" |

| style="width: 110px" valign="top" |

|-
| style="width: 40px" valign="top" |
8
| style="width: 315px" valign="top" |
The background is repetitive from the first landing page and thats fine. I think there is no need to force new page jump again for the user to see new content. I suggest moving the text from History and "Vision, Strategy and Execution" to http://spdx.org/about-spdx/background. Currently they have their own URLs.
| style="width: 95px" valign="top" |
Ibrahim
| style="width: 95px" valign="top" |

| style="width: 110px" valign="top" |

|-
| style="width: 40px" valign="top" |
9
| style="width: 315px" valign="top" |
Under http://spdx.org/content/tutorials Aesthetics aside, is it possible to provide a 1-2 lines description of what the paper, webinar and spec are? For an example, visit http://www.linuxfoundation.org/publications/workgroup and scroll towards the end where we feature the SPDX paper.

The SPDX video is hosted on BlackDuck site. I think this should live under spdx.org. You can get a youtube or vimeo account for spdx and host videos there and embed them on the spdx.org site.

If I click on "Read the Spec" blue box I get transfered to http://www.linuxfoundation.org/publications/workgroup. This is not a tutorial. On that new URL, there is also a mention of License List. For new reader, this is first mention. I think you may need some basic description. It feel that the site keeps throwing users from one page to another.
| style="width: 95px" valign="top" |
Ibrahim
| style="width: 95px" valign="top" |

| style="width: 110px" valign="top" |

|-
| style="width: 40px" valign="top" |
10
| style="width: 315px" valign="top" |
UNDER http://spdx.org/content/how-participate How to participate? I think this pages requires an overhall in terms of reorganizing the material, 1) I could not find anything at all about the project governance. How decisions are made? by whom? who drives the project? how roadmap items get decided? who does the work? is participation tied to providing resources? how to become a chair in a sub-workgroup? how to be a chair of SPDX? etc etc. 2) Participation seems to be treated differently than Contributing. This is related to item 1) above - governance. 3) It feels as if this is treated as an open source project. I may be wrong. However, in all of the similar efforts I participated in for the past 12 years (at OSDL and other efforts at the LF), a standard similar to SPDX has usually two branches: the specs itself driven by committed companies who want to move the standard and get it adopted and use it, and the reference implementation which is open to anyone and everyone to participate in. Is this something you considered? 4) Also under this page, it mentions the 3 sub-groups with links to the page of each of them. The pages for all 3 sub-groups are formatted in a different way with different set of info presented. (Update) Later on I discovered new pages that discuss what the teams do (totally random). http://spdx.org/content/business and http://spdx.org/content/legal and http://spdx.org/content/technical.
| style="width: 95px" valign="top" |
Ibrahim
| style="width: 95px" valign="top" |

| style="width: 110px" valign="top" |

|-
| style="width: 40px" valign="top" |
11
| style="width: 315px" valign="top" |
Lots of empty pages. As examples, Roles and Responsibilities" page is empty: http://spdx.org/content/roles-responsibilities, Archive Specifications" page ie empty http://spdx.org/content/archive-specifications "White Papers" page is empty http://spdx.org/content/white-papers "Working Group Roster" page is empty http://www.spdx.org/content/working-group-roster "SPDX Users" page is empty http://www.spdx.org/content/spdx-users
| style="width: 95px" valign="top" |
Ibrahim
| style="width: 95px" valign="top" |

| style="width: 110px" valign="top" |

|-
| style="width: 40px" valign="top" |
12
| style="width: 315px" valign="top" | I am not sure if I covered all pages.. In any case, generally speaking, the site needs updates on its: - Structure / Brows-ability / Usability - Updating text / content - Updating menu items - Consistency in terminology - Removing dead pages and consolidating existing pages - Formatting text on pages - Page divisions and linkages between pages - Governance information is either absent or I could not find it - Roadmap information is either absent or I could not find it ( Priorities page is empty http://spdx.org/content/current-priorities-work-progress-2)
| style="width: 95px" valign="top" |
Ibrahim
| style="width: 95px" valign="top" |

| style="width: 110px" valign="top" |

|-
| 13
| The Collateral material here need to be cleaned up and a final version published (incl new pdf file): http://spdx.org/documentation/beta-collateral What's "Email blurb for recruiting beta sites" at the top of that page? Another collateral page: http://spdx.org/content/spdx-launch-collateral - maybe merge with http://spdx.org/documentation/beta-collateral?
| Ibrahim
|
|
|-
| 14
| Are the contacts still valid? http://spdx.org/about/spdx/contact
| Ibrahim
|
|
|-
| 15
| Add self subsubscribing pages for membership
| Jack
|
|
|-
| 16
| Workgroups are posting meeting info on their main page and under the menu item for meeting calnedar and access. Propose to only put under the meeting calendar and access page. Its a little confusing in two places and often the text is not the same.
| Jack
|
|
|-
| 17
| Add new mission and vision to the site
| Jack
|
|
|-
| 18
| Add links to tools that support SPDX (perhaps on the tools page that is empty?)
| Jack
|
|
|-
| 19
| The Roles and reponsibilities pages are empty. Should move that info from the sub team pages to here.
| Jack
|
|
|-
| 20
| Add an overall meeting calendar for the year and dates for F2F meetings (can link out to wiki for agendas)
| Jack/Steve
|
|
|-
| 21
| We should use generic SPDX email names instead of personal ones on the site for people (people move on, etc).
| Business Team
|
|

|}

If you find it difficult to add a new line you can also [[Talk:General_Meeting/SPDX_Web_Site_Cleanup|comment here]].

[[Category:General]]
[[Category:Archived]]

Legal Team/Decisions/SPDX Metadata License: Rationale for CC0

2013-04-11T09:21:14Z

MartinMichlmayr: Fix format of bullet points

== Overview ==

SPDX files represent a summary of license information extracted from software source code. The SPDX Legal working group evaluated different licenses that can be used to cover the data contained in a SPDX file. One challenge was that the working group did not want to imply that the data contained in a SPDX file is potentially copyright protected. On the other hand, in some jurisdictions, data could be considered intellectual property. In those jurisdictions the working group stride to provide a license that mitigates the risk of someone obtaining controlling IP rights over SPDX data. The following were the core requirements driving the license evaluation process. We sought a license that:

* does not imply that SPDX data is intellectual property;
* in jurisdictions that permit data to be intellectual property - prevents others from claiming controlling ownership over the data contained in a SPDX file;
* will not hinder adoption of the SPDX format by the open source community;
* minimizes further license proliferation in the open source community;
* permits the exchange of SPDX files under confidentiality terms (potentially temporarily) for special situations that may require it.

After careful consideration the Creative Commons Zero 1.0 Universal license was chosen. The rationale for each of the license candidates considered can be found below.

== License Candidates ==

'''Public Domain Dedication and License (PDDL)'''

PDDL is the current designated license for SPDX files as required by the SPDX 1.0 specification. PDDL was initially chosen because it was a “data” license. That is, it was initially design to be used with data as opposed to software or other copyrightable works. The reception of PDDL as the SPDX file data license has been mixed and somewhat controversial at times. A copy of the PDDL license can be found here: http://opendatacommons.org/licenses/pddl/1.0/

* Pros
** Designed for licensing data.
** Useful in jurisdictions where intellectual property rights are granted to data (bases).
** Attempts to make data freely accessible (in a similar spirit that open source licenses do for software).
** Permits the exchange of SPDX files under confidentiality terms.

* Cons
** Lengthy license (6 pages) – will take time for people to review and understand.
** Yet another new license for open source community to review, understand and accept. Would likely add friction to SPDX adoption.
** A major open source foundation pointed out it would be hard to get PDDL approved by their organization as well as other foundations. This is especially true when considering a license that is not familiar to the community (as is the case with PDDL).
** Use of the license implies that SPDX data is copyright protected.

'''MIT Style SPDX Draft'''

The license text is based on the MIT open source license. A copy of the MIT Style license draft can be found in the appendix of this document.''''''

* Pros
** Viewed more as a disclaimer notice than a data license. The intent is to view the SPDX file content as data as opposed to protected intellectual property.
** Serves more as a license in jurisdictions where data is considered protectable intellectual property.
** The license text is short and easy to understand.
** The license is familiar to the open source community and would likely not add much friction to the adoption of SPDX.
** Permits the exchange of SPDX files under confidentiality terms
* Cons
** The license is based on the MIT open source license which was designed to be used with software as opposed to data.
** Requires attribution. Many different SPDX files used in a project or supply chain may potentially require the publication of many different attribution notices.

'''CC0 1.0 - Universal Public Domain Dedication license '''

Creative Commons (CC) is a non-profit organization devoted to expanding the range of creative works available for others to build upon legally and to share. The organization has released several copyright-licenses known as “Creative Commons” licenses, free of charge to the public. One such license is the CC0 1.0 which allows one to contribute their work to the public domain. A copy of the CC0 1.0 license can be found here: http://creativecommons.org/publicdomain/zero/1.0/

* Pros
** License text is short and easy to understand.
** License is familiar to the open source community and therefore would likely not to add significant friction to the adoption of SPDX.
** Achieves object of having the data be considered public domain in those jurisdictions where data can be protected as intellectual property.
** Permits the exchange of SPDX files under confidentiality terms.
* Cons
** License was not designed to be used with data.
** Use of the license implies that SPDX data is copyright protected.

'''No License Provided'''

One option is to take the position that no license applies.

* Pros
** Easy to understand. Does not add friction to adoption of SPDX.
** Promotes the idea that the SPDX data is not intellectual property (e.g., not copyrightable).
** Permits the exchange of SPDX files under confidentiality terms.
* Cons
** Does not prevent one from trying to obtain controlling rights in jurisdictions where data is potentially considered intellectual property.

[[Category:Legal]]

MediaWiki:Sidebar

2013-04-11T07:19:51Z

MartinMichlmayr: Undo revision 2372 by Lfadmin (talk)

User:MartinMichlmayr

2013-04-10T22:50:53Z

MartinMichlmayr: Created page with "I am Martin Michlmayr. You can find out more about me on [http://www.cyrius.com my home page]."

I am Martin Michlmayr. You can find out more about me on [http://www.cyrius.com my home page].

Main Page

2013-04-10T22:30:49Z

MartinMichlmayr: Link to getting started

The Software Package Data Exchange® (SPDX®) [http://spdx.org/content/spdx-specification specification] is a standard format for communicating the components, licenses and copyrights associated with a software package. This wiki site is the workspace for SPDX Teams. Please see [http://spdx.org spdx.org] for general information, the current specification, license list, etc.

* [[Getting started]]
* [[General Meeting]]
* [[Business Team]]
* [[Legal Team]]
* [[Technical Team]]
* [[Old|Older Information]]

Technical Team/Use Cases/2.0/Graveyard

2013-04-10T18:42:10Z

MartinMichlmayr: Convert to MediaWiki syntax

We had several sources to begin pulling for SPDX Use Cases:

# The Pad from earlier conversations collected at [[Technical_Team/Old/Use_Cases_Collected_during_1.x_timeframe|Use Cases For SPDX 2.0 Discussion]]
# The old [[Technical_Team/Old/Sandbox_for_Sharing_Examples/SPDX_Use_Case_1|SPDX 1.0 Use Cases]] as well as the [[:File:ecosystem.jpg|SDPX 1.0 Use Case Picture]].
# Soliciting use cases in 2012 (especially at Linux Collab Summit in April)

'''NOTE''': On May 29, 2012, we removed use cases which were not yet fleshed out. A snapshot of 'all' the use cases was saved in child page SPDX 2.0 Use Cases Graveyard. The process followed was to flesh out use cases here by having a brief summary listed here as a link to a more detailed child page. Note, these use cases should be *'''doable'''* but in general not *'''required'''*. Any item listed here that is not a link, should have a child page created for it.

# Code commits (original work intended for the project)
## [[Technical_Team/Use_Cases/2.0/Committers_provides_SPDX_data_for_a_code_being_committed|Committer provides SPDX data]]
## [[Technical_Team/Use_Cases/2.0/Contributor_makes_commit_subject_to_existing_SPDX_data_of_project|Contributor makes commit subject to existing SPDX data of project]]
## Contributor makes commit subject to existing SPDX data of a dual licensed project and selects one license
# [[Technical_Team/Use_Cases/2.0/Committer_annotates_source_files_with_SPDX_data|Committer annotates source files with SPDX data]]
# Patches (original work intended for the project)
## [[Technical_Team/Use_Cases/2.0/Patch_provider_provides_SPDX_data_for_the_patch|Patch provider provides SPDX data for the patch]]
## [[Technical_Team/Use_Cases/2.0/Patch_provider_provides_SPDX_data_for_the_patch_indicating_it_is_licensed_however_the_hell_its_applied|Patch provider provides SPDX data for the patch indicating it is licensed however the hell its applied]]
## [[Technical_Team/Use_Cases/2.0/Patch_provider_provides_patch_subject_to_existing_SPDX_data_of_project|Patch provider provides patch subject to existing SPDX data of project]]
# Patch provider provides a patch that modifies existing SPDX data of project
## [[Technical_Team/Use_Cases/2.0/Downstream_consumers_contributing_patches_to_provide_SPDX_data_to_an_upstream_that_doesnt_have_it|Downstream consumers contributing patches to provide SPDX data to an upstream that doesn't have it.]]
## [[Technical_Team/Use_Cases/2.0/Downstream_consumers_contributing_patches_to_provide_corrections_to_SPDX_data_for_an_upstream_that_does_have_it|Downstream consumers contributing patches to provide corrections to SPDX data for an upstream that does have it.]]
# [[Technical_Team/Use_Cases/2.0/Upstream_maintainer_providing_SPDX_data|Upstream maintainer providing SPDX data]]
## [[Technical_Team/Use_Cases/2.0/Upstream_maintainer_providing_SPDX_data_in_source_archive|Upstream maintainer providing SPDX data in source archive]]
## [[Technical_Team/Use_Cases/2.0/Upstream_maintainer_providing_SPDX_data_in_SCM|Upstream maintainer providing SPDX data in SCM]]
## [[Technical_Team/Use_Cases/2.0/Upstream_maintainer_providing_SPDX_data_at_a_URL|Upstream maintainer providing SPDX data at a URL]]
## [[Technical_Team/Use_Cases/2.0/Downstream_consumers_contributing_patches_to_provide_SPDX_data_to_an_upstream_that_doesnt_have_it|Upstream maintainer preparing release artifacts (including SPDX data).]]
## Intended usage communicated by the auditee (how/will the audited item get included in delivered/deployed bits) [Bill Schineller]]
# Project maintainer incorporates another project
## [[Technical_Team/Use_Cases/2.0/Project_maintainer_incorporates_another_project_by_including_source|Project maintainer incorporates another project by including source]]
## [[Technical_Team/Use_Cases/2.0/Project_maintainer_incorporates_another_project_by_including_binary|Project maintainer incorporates another project by including binary]]
## [[Technical_Team/Use_Cases/2.0/Project_maintainer_pulling_individual_files_out_of_another_project_(subsetting)|Project maintainer pulling individual files out of another project (subsetting)]]
# Project maintainer incorporates another copyrightable artifact by reference (think maven, possibly linking cases)
## by static reference (the referenced library is included with a redistribution)
## by dynamic reference (express runtime dependency on the external library, but not redistributing it)
## Maven case
# SPDX-Lite:
## [[Technical_Team/Use_Cases/2.0/Low_cost_SPDX_file|Allow a low investment SPDX producer to produce valid SPDX data]]
## [[Technical_Team/Use_Cases/2.0/Producing_valid_SPDX_files_in_the_face_of_missing_data|Produce a valid SPDX dataset even if some data is missing]]
# Intermediate packager (rpm, deb, etc) passing on and adding to SPDX Data
## Intermediate packager builds source package from upstream source
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_builds_source_package_from_upstream_source_that_provides_SPDX_data|Intermediate packager builds source package from upstream source that provides SPDX data]]
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_builds_source_package_from_upstream_source_that_does_not_provide_SPDX_data|Intermediate packager builds source package from upstream source that does not provide SPDX data]]
## Intermediate packager builds binary package from upstream source
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_builds_binary_package_from_upstream_source_that_provides_SPDX_data|Intermediate packager builds binary package from upstream source that provides SPDX data]]
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_builds_binary_package_from_upstream_source_that_does_not_provides_SPDX_data|Intermediate packager builds binary package from upstream source that does not provides SPDX data]]
## Intermediate packager adds patches to upstream source
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_adds_patches_to_upstream_source_that_provides_SPDX_data|Intermediate packager adds patches to upstream source that provides SPDX data]]
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_adds_patches_to_upstream_source_that_does_not_provide_SPDX_data|Intermediate packager adds patches to upstream source that does not provide SPDX data]]
## Intermediate packager adds someone else's patches to upstream source
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_adds_someone_elses_patches_to_upstream_source_that_provides_SPDX_data|Intermediate packager adds someone else's patches to upstream source that provides SPDX data]]
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_adds_someone_elses_patches_to_upstream_source_that_does_not_provide_SPDX_data|Intermediate packager adds someone else's patches to upstream source that does not provide SPDX data]]
## Intermediate packager subsetting upstream source
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_subsetting_upstream_source_that_provides_SPDX_data|Intermediate packager subsetting upstream source that provides SPDX data]]
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_subsetting_upstream_source_that_does_not_provide_SPDX_data|Intermediate packager subsetting upstream source that does not provide SPDX data]]
## Intermediate packager chooses to distribute one of multiple available under licenses provided for by upstream (check with legal team)
## Intermediate packager reviews SPDX data provided by upstream.
# Build systems (build systems want to pass on SPDX data for the thing they are building)
## [[Technical_Team/Use_Cases/2.0/Build_System_Yocto|Yocto]]
### How does SPDX work in an environment where the sources aren't there, but are pulled from git or a mirror and patched.
## Maven [Brian Fox]
### Rolling into release artifacts things only referenced in the POM file
### Shading (subsetting) portions of a transitive dependency for inclusion in your artifact
## Continuous integration around SPDX files (fixing SPDX files for commits coming in etc).
## Linking
### [[Technical_Team/Use_Cases/2.0/Debian_has_an_interest_in_only_building_things_that_are_linking_license_compatible|Debian has an interest in only building things that are linking license compatible]]
#### If a tool is consuming SPDX data to interact with heuristics.
## Java complications [Richard Fontana]]
### What to do about installers that download JDK directly from sun.
## I just made a binary out of some source
### [[Technical_Team/Use_Cases/2.0/SPDX_data_indicating_subset_of_the_source_that_made_it_into_a_particular_binary_or_binary_package|SPDX data indicating subset of the source that made it into a particular binary or binary package]]
## Tool used to produce software infecting distribution license of the software itself [Kevin Fleming] (e.g. code-generator? Bison? ..)
# Aggregator aggregating many 'copyrightable items' for redistribution
## [[Technical_Team/Use_Cases/2.0/Linux_Distros|Linux Distros]]
## [[Technical_Team/Use_Cases/2.0/Embedded_Images_(e.g._router_images,_switch_images)|Embedded Images (e.g. router images, switch images)]]
## SDKs [Jack Manbeck]
## [[Technical_Team/Use_Cases/2.0/Reference_Implementations|Reference implementations] [Jack Manbeck]
## Eclipse/OSGI distributions
## [[Technical_Team/Use_Cases/2.0/Application_which_ships_with_documentation_and_media_and_software|Application which ships with documentation + media + software]] [Jack Manbeck]
## [[Technical_Team/Use_Cases/2.0/Application_which_ships_with_a_contrib_libraries|Application which ships with a contrib libraries]]
## [[Technical_Team/Use_Cases/2.0/Application_which_ships_with_development_tools|Application which ships with development tools]]
## Receiving what appears to be commercial software but that commercial software contains Open Source
## Receiving what appears to be opensource software but that opensource software contains commercial software
## [[Technical_Team/Use_Cases/2.0/Subsetting_out_only_the_shippable_bits_of_stuff_coming_from_an_SDK|Subsetting out only the shippable bits of stuff coming from an SDK]]
## [[Technical_Team/Use_Cases/2.0/Aggregators_aggregating_other_aggregations_for_redistribution|Aggregators aggregating other aggregations for redistribution]]
# Consumers receiving SPDX data
## Procurement needs to view it and review it
## Legal department needs to review
## Comply with licensing when there are multiple rights holders each with licensing use under a different license
## [[Technical_Team/Use_Cases/2.0/Provide_sufficient_data_to_allow_consumer_to_comply_with_licenses_on_redistribution|Provide sufficient data to allow consumer to comply with licenses on redistribution]]
## Bradley want to extract all rights holders for a particular file
## Multiple SPDX files you need to reconcile
## Recognizing the same SPDX data for the same code coming from multiple supply chain paths
## Flagging potential issues revealed by the SPDX
### License conflicts
### Listing out obligations
## Helping to meet the obligations of the licenses (Given that I receive an SPDX file, does the info in SPDX file allow me to extract what I need to meet basic kinds of obligations)
### How to capture attribution information for binaries
### Help with redistribution obligations
## Equivalence classes of binaries and tracking back to the same source and source SPDX data.
### Consider what to do about license metafiles
### COPYING files
### LICENSE.* files
### README.*
### Think about how to handle NOTICE files and Apache
# [[Technical_Team/Use_Cases/2.0/Consuming_code_snippets|Consuming code snippets]] (God help us all) (subfile pieces of code not originally intended for the project)
## Make sure that the license and copyright information for a snippet is reflected in the SPDX data for the file
## Track differently licensed snippets explicitly
## Handle the case where code is copied and pasted through online forums etc.
# Signoff/multiple signoff on SPDX data
## [[Technical_Team/Use_Cases/2.0/Contracts_with_multiple_parties_requiring_signoff_by_all|Contracts with multiple parties requiring signoff by all]] [Kate Stewart]
## Signing off on only a subset of the SPDX data (of an SPDX document in progress?)
# Third party does licensing analysis
## [[Technical_Team/Use_Cases/2.0/Third_party_produces_bill_of_materials_for_software_package|Third party generates license analysis]]
## Actual usage communicated
## Did the code that I shipped (the binaries) match the copyrightable items? i.e. be able to produce an SPDX file that applies to binary code
## [[Technical_Team/Use_Cases/2.0/Collecting_enough_information_to_allow_auditor_to_make_recommendations_to_remove_or_not_a_component|Collecting enough information to allow auditor to make recommendations to remove or not a component]]
## Tooling to assist with copyright (change copyright date and list of contributors/copyright holders, even as license and most of code remains unchanged) for changes between versions
## Unaffiliated third party provides SPDX data for a project
# Auditor Analyzing/Sanity-checking/correcting Bill of Material he's handed
## [[Technical_Team/Use_Cases/2.0/Backtrack_from_binary_to_source_files|Backtrack from compiled/binary file to constituent files]]
## outbound: validate that SPDX goes hand in hand with what's being shipped [Kirsten Newcomer]
### [[Technical_Team/Use_Cases/2.0/Check_to_see_if_the_SPDX_data_provided_matches_the_files_provided_and_is_trustworthy_and_most_current_for_package|Check to see if the SPDX data provided matches the files provided]]
### Check to see if the SPDX file is internally consistent (do I have a license refs to match licenses)
### Did the code that I shipped (the binaries) match the copyrightable items.
## inbound: validate that SPDX goes hand in hand with what's being brought in [Kirsten Newcomer]
### Chcek to see if the SPDX data matches the files you are shipping [Kirsten Newcomer]
### Check to see if the SPDX file is internally consistent (do I have a license refs to match licenses)
## SPDX lint
## Incomplete SPDX data you may need to complete
## Asserting corrections to SPDX data provided by others further upstream
# Migrating from one version of the SPDX spec to another (moving a file from SPDX 1.0 to 2.0 for example)
## e.g. knit together a bunch of 1.0 files into a 2.0...
# Extensions:
## [[Technical_Team/Use_Cases/2.0/Communicate_data_beyond_what_is_described_in_spec|Communicate data beyond what is described in spec between consenting parties w/o breaking consumers that are not in the know]]
## Experimental improvements to SDPX files w/o breaking consumers that are not in the know. [Peter Williams]
## [[Technical_Team/Use_Cases/2.0/License_list_extension|License list extensions, how do you handle folks who have more licenses than SPDX]]
## [[Technical_Team/Use_Cases/2.0/Decorating_an_already_produces_and_signed_SPDX_dataset_with_extension_data|Decorating an already produces and signed SPDX dataset with extension data]] [Bill Schineller]
## Recording per ExtractedLicenseText a comment detailing exactly which pattern matching technique / string found that Extracted License Text (so that SPDX file doesn't need to repeat in every matched File instance) [D. M. German]
## Recording free-form tribal knowledge about a file which is not otherwise visible in the text of the file itself (e.g. commit history from git repo, origin information such as scanning against a knowledge base of open source could provide) [Mark Gisi]
## Conveying Encryption content (Export Control implications) of a package/file in a package [someone at collab summit]
## Conveying Security Vulnerability information [Jianshen O.- Huawei]
# Look at a 'pingback' (URL string similar for blogs)kind of mechanism for original providers of SPDX (to allow them to figure out where it's used) [Andrew Hsu]
# Cloud
## Materializing a VM and making sure it's OK from a licensing mechanism
## SugarCRM case, obligation by virtue of using web service interface
# Legal Use Cases:
## Allow the NDA status of an SPDX document to be communicated in a machine readable way (not just a comment) for organizations that don't want the SPDX document to be publicly released [Mark Baushke from Juniper]
## How are we going to handle Public Domain (not in license list... region specific...)

==Cross-cutting concerns==

# Provenance (the need to optionally use signing to validate who said what)
# Trust
# Handling staleness of data
# Composite licensing
# Ease of sharing information
## Collecting tribal knowledge along the way
# Guarding against file bloat
# Simple simple simple
# SPDX-Lite:
# Clarity
# Automation/toolifiability
# Regionality

==Themes:==

Looking at these Use Cases, there are some underlying themes:

# Root of data (closer to upstream the better)
# Subsetting of copyrightable things (and their SPDX data) ('''Note''': Subsets of copyrightable things are usually also copyrightable things)
# Aggregation of copyrightable things (and their SPDX data) ('''Note''': Aggregations of copyrightable things are usually also copyrightable things).

[[Category:Technical]]
[[Category:Archived]]

MediaWiki:Licenses

2013-04-10T18:36:53Z

MartinMichlmayr: Add list of licenses

* Unknown|I don't know exactly
* Free licenses:
** PD|PD: public domain
** CC-by-sa-2.5|Creative Commons Attribution ShareAlike 2.5
** CC-by-sa-3.0|Creative Commons Attribution ShareAlike 3.0

Wiki Conventions

2013-04-10T16:57:59Z

MartinMichlmayr: Add wiki conventions for our new MediaWiki wiki

This page describes conventions that should be followed on the SPDX wiki. You can also read the page on [[Getting started|getting started]].

== SubPages ==

This wiki uses subpages to provide a hierarchy. For example, the minutes for the business team are located under <code>Business Team/Minutes</code>.

When you add a new page, please make sure to use the correct hierarchy. If you want to create a new business related page, choose <code>Business Team/name of page</code> If you'd like to add new business minutes, add them as <code>Business Team/Minutes/YYYY-MM-DD</code>

== Categories ==

We use categories to organize pages. You should add one of these categories at the bottom of each new page:
* <nowiki>[[Category:Business]]</nowiki>
* <nowiki>[[Category:General]]</nowiki>
* <nowiki>[[Category:Legal]]</nowiki>
* <nowiki>[[Category:Technical]]</nowiki>

== Adding minutes ==

The list of minutes is updated automatically but this requires minutes to be added in the right location. Please use <code>XXX Team/Minutes/YYYY-MM-DD</code> for new minutes.

Additionally, minutes should have the category <nowiki>[[Category:Minutes]]</nowiki> in addition to the category defining the subject area.

== Headings ==

Make sure not to use a heading starting with <nowiki>=</nowiki> as this reserved for the title of the page. Headings should start with <nowiki>==</nowiki>. See the [http://www.mediawiki.org/wiki/Help:Formatting MediaWiki wiki syntax] page for more information.

== Commenting on pages ==

If you'd like to comment on pages, please click on "discussion" on the top of a page.

Getting started with the SPDX wiki

2013-04-10T16:53:58Z

MartinMichlmayr: Create getting started document

Talk:General Meeting/SPDX Web Site Cleanup

2013-04-10T15:41:27Z

MartinMichlmayr: Import comments from Drupal site

== Additional feedback on web site ==

Some additional feedback - I attach a mock up for what the SPDX home page can be. The figure is available from [[:File:Spdx-mockup.png]]

I suggest to follow the same structure/template used by other WGs where the home page would include:

* List of participating organizations
* List of upcoming events
* Latest blog entry (instead of publishing blog entries on private or companies web site)
* etc.

Additional content that is needed:

* "Value Proposition" to various ecosystem players (from silicon vendors all the way up in the chain to end users)
* Add an "FAQ" section
* Add a page with a visual "Roadmap" - where roadmap covers spec releases, tools, F2F, event presence, new content release (such as new papers, data sheets, etc)
* Once governance is set - add a "Governance" page
* Add section on "Contribution Guidelines"
* Add section on "Processes" or "How-to" - examples: How to submit feedback or proposals for new features in the specs? How to submit bug fixes, new code for the tools? etc.
* Add a section on "Participation". Examples include:
** Contact the lead(s) of the team(s) you want to contribute to, get briefed on current state of affairs, and where help is needed the most.
** Join the mailing lists and participate in the discussions.
** Attend the calls as scheduled by the various teams.
** Submit feedback on the specifications following the process set in place.
** Submit bug reports/code contributions to the tools following the development process set in place.
** Submit new use cases, or feedback on existing ones
** Join SPDX™ track at Linux Foundation conferences.
** Create content for SPDX™: papers, web site improvements, blogs, etc.
** Create SPDX™ files for your favorite open source projects
* Add a section for "Users" of SPDX that provides guidance for various users of SPDX that include:
** Users who generate SPDX™ files for downstream users
** Users who request SPDX™ files from upstream suppliers
** User who know how to use, update and maintain an SPDX file that comes in, and who passes that SPDX downstream
* Guidance to "Users" can come in different forms - such as:
** Documentation: How-to style to educate uses about using SPDX™ and also proper ways to submit feedback & questions or even request help for complex cases that the SPDX™ specs may have not covered yet.
** Users 1-day Forum: Parallel to other SPDX™ or Linux Foundation events. The focus of such a forum is to provide tutorial style presentations on using SPDX™.
** Hosted SPDX™ seminars: These seminars could be hosted at companies that are on their way to or have already adopted SPDX™ and they need to educate their (compliance) teams.
* A section for "Developers", discussing as a developer what you need to be doing in your project:
** If you are an open source developer
** If you are a maintainer of an open source project
** If you are acorporate developers working on proprietary code that will be open sourced
** etc.
* Providing information on release methodology
* Etc.

-- Submitted by ibrahimhaddad on Tue, 2012-08-14 22:26.

Talk:Technical Team/Proposals/2012-06-18/standardNotice field for License class

2013-04-10T15:38:44Z

MartinMichlmayr: Import comments from Drupal site

== Interoperability needs to be preserved ==

Tag value would need to change if we're adopting this. Otherwise it violates the interoperability between the tag and RDF versions.

-- Submitted by Anonymous on Sat, 2012-07-07 14:21.

Talk:Legal Team/License List/License Matching Guidelines

2013-04-10T15:37:33Z

MartinMichlmayr: Import comments from Drupal site

== outstanding issues ==

2.1.1 Standard Headers guideline - currently standard headers only appear in spreadsheet and not on HTML license pages. This field needs to be added. Suggestion: if switch to HTML "master" file for license text, suggest adding Standard Header field there so same formatting can be used. and then in spreadsheet change field to simply yes or no.

4.1.1 states to treat all upper and lower case as lower case. Does it really matter? Can't we simply say, treat all upper and lower case as the same? -- Submitted by jlovejoy on Wed, 2012-06-27 19:36.

== Trade, etc. marks ==

We should probably have equivalency rules for ™, ®, ℠ to their ascii representations. -- Submitted by pezra on Thu, 2012-06-21 17:03.

: not added to guidelines at this time, as it doesn't seem to show up that often as far as I know. Using "TM" as an equivalent to the superscript version could cause a problem if those two letters appear together otherwise (not that I can think of an example...) -- Submitted by jlovejoy on Thu, 2012-06-21 19:44.

== Ignore Copyright owner, why not ignore name of license? ==

Does the name of the license need to be match? I don't think so. So for the Apache v1.1 it is not necessary to match neither the name of the license or the copyright owner. -- Submitted by dmg on Thu, 2012-06-14 18:17.

: incorporated this guideline - see #11 -- Submitted by jlovejoy on Wed, 2012-09-05 18:03.

== Detecting the end of copyright notices ==

How should tool makers determine where a copyright notice ends? -- Submitted by pezra on Wed, 2012-06-13 15:30.

== Handling of Non-ASCII characters ==

Do we have a guideline how to process characters outside the 7-bit ASCII range? E.g. the german ü character appears in various different encodings depending on the locale used.

Suggested rule 1: We assume all texts are UTF8, whenever there are no UTF8 syntax errors. Otherwise offending characters are stripped and replaced by a single replacement character (To be defined) so that correct UTF8 results.

Suggested rule 2: All UTF8 characters having a corresponding ASCII character are considered to be equal to that ASCII character. (e.g. variations of quotes, hyphens, asterisks, bullets) -- Submitted by jnweiger on Fri, 2012-03-02 15:15.

: These rules are being developed in terms of characters, rather than byte sequence. I'd prefer to stay away from implementation details such as character encoding for the matching rules.

: I think we should add a rule stating that any sequence of characters that whose glyphs appear the same when rendered should be considered equivalent for the purposes of matching.

: This will handle the various ways combining characters such as umlauts can be represented in unicode by allowing comparision of the normalized form KC of the strings. It is also general enough that people who dislike unicode (which do exist) can apply the rule to whatever encoding they prefer. -- Submitted by pezra on Mon, 2012-03-05 19:38.

== Combined Punctuation and whitespace ==

suggested rule: any punctuation that is not directly followed by whitespace is treated as if it were followed by whitespace.

Idea is to consider 'foo,bar or baz' equals 'foo, bar or baz'.

Question: What is the exact definition to be used for puncuation. I'd default to use ispunct() from the C-locale, which is any printable character which is not a space or an alphanumeric character. -- Submitted by jnweiger on Fri, 2012-03-02 14:57.

: Suggest that after every piece of punctuation, we normalize to assume a single white space. -- Submitted by Anonymous on Thu, 2012-06-21 15:56.

: On the question of what is punctuation, perhaps we should use the General Punctuation list compiled by the unicode spec. -- Submitted by pezra on Mon, 2012-03-05 19:46.

== Re: Bullets and Numbers ==

This rule could be extended to cover more cases:

a) The definition of 'a line starts with' should clearly say, that any whitespace at the start of the line (e.g. indentation) is ignored.

b) typical comment characters at the start of a line (e.g. /*, //, #, REM, ...) should also be ignored.

c) (ad hoc idea:) any punctuation at the start of a line is ignored. -- Submitted by jnweiger on Fri, 2012-03-02 14:53.

: a) I think this is already covered by the whitespace guideline

: b) true. new guideline for this has been added

: c) might require more thought. going with narrower suggestion in b for now... -- Submitted by jlovejoy on Thu, 2012-06-21 19:51.

== Preambles/epilogue ==

How should adding a preamble/epilogue to a license text effect matching? -- Submitted by pezra on Wed, 2012-02-08 16:38.

: I'd say for the most part preambles are included, but epilogues (where there is instructions on how to apply the license) can probably be considered "optional" text. This is just off the top of my head based on what I've seen included and omitted for various license in the wild (e.g. I've seen the instructions for applying GPL at the end of the license omitted, but never seen the preamble omitted)

: I think this will ultimately need to be dealt with on a license-by-license determination, using the {{ }} indicators as to what can be ignored for matching purposes as discussed on the 6/21 call -- Submitted by jlovejoy on Thu, 2012-06-21 20:24.

== hyphenation ==

We should probably point out that any word that is hyphenated to span lines should be consider equivalence to the unhyphenated word. -- Submitted by pezra on Wed, 2012-02-08 16:16.

: Suggested Rule 1: all hyphen, endash, mdash, etc characters are considered the same.

: Suggested Rule 2: if a line ends in a hyphen, and there is a word directly in front of the hyphen, and a word directly at the beginning of the next line, then the hyphen and whitespace is removed, so that both words are joined into one.

: There is a slight risk, that a compound word like e.g. 'built-in' would lose its hyphen, if its hyphen happens to be used for line breaks. I'd say, we can accept that risk. -- Submitted by jnweiger on Fri, 2012-03-02 14:45.

:: added guideline re: equating hyphens and various forms of dashes. but not sure how to handle hyphenated words at the end of the line, since the whitespace is already accounted for in another guideline... -- Submitted by jlovejoy on Thu, 2012-06-21 20:20.

Talk:General Meeting/License Field Discussion

2013-04-10T15:36:42Z

MartinMichlmayr: Import comments from Drupal site

== An auditor's view ==

From reading many of the comments posted, some of the consumers of SPDX plan would not use the concluded license since they would trust only their own analysis based on the file level information, some consumers would trust only the package author (declared license), and some would find the concluded license useful.

From an auditor’s point of view, having a concluded license allows for the inclusion of licensing information discovered during the auditing process. One relatively common scenario is a package licensed under a non-copyleft license including source code from a copyleft package. The inclusion of the copyleft code would cause the concluded license to be the copyleft license.

Since the SPDX standard makes it clear that this concluded license is based on analysis (and not stated by the author), the consumer of the package can choose to ignore the analysis and go with either the stated license or their own analysis based on file level information. Alternatively, the consumer can validate the conclusion. Note that there is judgment applied in the process and in many cases the conclusion depends on the usage of the source files (e.g. files used as tools for building the source may be under a copyleft license but will not affect the concluded licenses since these files are not distributed/deployed with the resultant binaries), so the results should always be validated in my opinion.

-- Submitted by Gary O'Neall on Mon, 2011-06-20 17:19.

== All License Info From Files ==

I think it's important to include section 4.8 in this dicussion as well. I've added the text from the June 5th version of the spec below.

4.8 All License Information from Files

4.8.1 Purpose: This field is to contain a list of all license found in the package by scanning the files, manually or using automated tools. The options to populate this list are limited to:

(a) the SPDX License List short form identifier if a detected license is on the SPDX License List;

(b) a reference to the license, denoted by LicenseRef-#, if the detected license is not on the SPDX License List;

(c)"NONE" if no license information is detected in any of the files; or

(d) “NOASSERTION” if the reviewer has not examined the contents of the actual files.

Note: The relationship between licenses (conjunctive, disjunctive) is not specified in this field -- it is simply a listing of all licenses found.

4.8.2 Intent: Here, we intend to capture all license information actually seen within the package detected in the actual files.

-- Submitted by Anonymous on Thu, 2011-06-16 15:26.

== Attributed licensing ==

Perhaps rather that having a lot of different types of licensing properties we have just one which is repeatable and allows the value to be attributed. This would allow an SPDX file to express something like "The original authors think the licensing is MIT, but supplier A thinks it is MIT and BSD, but audit company B thinks it is MIT, BSD and GPL".

This would look a bit like this in the RDF:

<http://example.org/some-package.tar.gz>
:license [
:declaredBy :copying_text;
:licensing [
:member license:MIT;
a :ConjunctiveLicenseSet];
a :LicensingInfo];

:license [
:declaredBy "Supplier A";
:licensing [
:member license:MIT, license:BSD;
a :ConjunctiveLicenseSet];
a :LicensingInfo];

:license [
:declaredBy "Openlogic, Inc";
:licensing [
:member license:MIT, license:BSD, license:GPL;
a :ConjunctiveLicenseSet];
a :LicensingInfo].

(I am sure we can come up with better names and a tag-value syntax for this if we decide to proceed.)

This would allow licensing information from various people/organizations to be included in an SPDX file. It would also make it explicit exactly who was doing the declaring of any particular licensing.

-- Submitted by pezra on Wed, 2011-06-15 16:41.

== Declared License ==

I believe that both of the fields are useful.

However, I do not have a clear understanding of what is intended to be included in Declared License. In particular, see my three examples below.

I have heard the Declared License field characterized as package-level license information. But, the Purpose says that it is "by the authors of the package". Is determination of who added particular license information relevant to whether it is included in the Declared License? That determination might be useful. But, the requirement for that judgment is departing from the goal of focusing on objective information. A definition that encompasses all package-level license information would be more objective; but, in some cases it would convey different information that a definition tied to the originator of the information.

Which is Declared License intended to be?

* limited to information "by the authors of the package"?
* any package-level information?

If the former, then is "authors of the package" intended to mean the primary authors of the software? Or is it intended to also include package maintainers?

The following are three examples of package-level license information. Are any of these intended to be captured in Declared License?

(A) One common piece of package-level information is a COPYING file found in the root of the source tree. Such files are often placed there by the primary authors of the software in that tree. However, lacking information from a version control system, one rarely has any way of knowing who put that file in the package. Suppose that the source files from which the software is built all have a BSD notice, but there are some GPL-licensed files that are used in the build process and the root of the source tree includes a copy of the GPL. Although we do not know for sure, it would seem very unlikely that the COPYING file represents the primary author's declaration of the license for the package.

(B) Another common piece of package-level information is the license field in the header of an RPM. That information is often NOT added by the primary author of the software.

(C) Debian packages include a COPYRIGHT file in which the Debian package maintainer has collected information about the licenses that apply to the package.

-- Submitted by Scott K. Peterson on Tue, 2011-06-14 21:59.

== The distinction is useful ==

The distinction is most useful and important when the scope is a package. The two fields should contrast what the Autor/Copyright holder says about the package with what can be found in the package. (4.9.2 says "the license identified in text in the actual package source code files", this makes me believe package scope is applicable).

Reading 4.9.2, I am surprised it is defined based on all source code files. For any bigger package, this is going to be many licenses. The better the scanning tool, the more get added here. The name declared license implies to me, the license that the author would use when talking about his work. Simplicity would be paramount. Example: Ask the FSF about gcc-4.5, they would respond with "GPL-3.0+". This is what I'd call the declared license. Going into the files with a scanner I get a collection like this "GPL-2.0+; GPL-2.0+(with linking); X11-MIT; LGPL-2.1+; LGPL-2.1+(with linking); BSD-3-Clause; GFDL-1.2; GFDL-1.1; Public-Domain; Zlib-License; EPL-1.0; BSD-4-Clause(UCB)". Is this the declared license?

If so, we'd need a third field to grasp the simplified concept that "gcc-4.5 is said to be under GPL-3.0+" The usefulness of this inaccuracy is it simplicity. But then, three fields "for basically the same thing" may already be too many, and thus become confusing again.

When the scope is a single file, and the file has a proper license header, then this is it. If a file is missing a proper license header, but there are several COPYRIGHT files in parent or nearby directories, then the reviewer adds value by discerning which of them effectivly governs a particular file.

4.7. is per definition opinionated. It should always be clear, who is the respective reviewer; Would the Schema allow this field multiple times, in case we want to document differning conclusions from multiple reviewers?

-- Submitted by jnweiger on Fri, 2011-06-10 19:18.

: As far as I can tell we have to determine useful & practical.

: I do not feel that distributing a file with multiple opinions about how to interpret how a package is licensed has practical value. The more opinions you collect the more confusing things will get. Much of the opinion forming should be an internal Company process and not necessarily recorded and redistributed.

: The ultimate objective I think we want to get to is to answer the question "What do I need to do to be compliant with the licenses for the code that I am getting in this Package"?

: Part of the challenge addressing this question begins with being very clear with what the term Package really represents. Does everyone agree that it is the colloquial meaning associated with something like an RPM or not? A functional unit of code that may depend on functionality of other packages? If so lets be clear about this scope and document it. Right now stating "A package can contain sub-packages, but the overview is a reference to the entire contents of the package listed." creates a scenario where Concluded and Declared may never make sense.

: Then lets look at what the developer/author of a Package has in mind (intent) from a licensing perspective. Did they intend to create a single Licensed work or to create ambiguity and confusion? If the latter is accidental (probably) then perhaps applying simplified SPDX can help fix this.

: If one asserts that a package is GPLv2, for example, and the package also contains BSD code does it matter that we look at the BSD code knowing that GPLv2 trumps BSD? By complying with GPLv2 your are likely complying with BSD anyway.

: Ultimately full compliance is not delivered from a decision on a concluded or declared license type if there is no clear License to apply. It is attained by being able to roll up the license constraints presented in the license files that comprise the package. Since these files are already captured in the SPDX file, with their own License conclusions, the value of having more than one opinion about the License that the package is associated with is a little lost on me.

: I would try to make packages less complicated and try to get to a point where one license applies.

: Not knowing how prevalent such complex packages are I also wonder how much this complexity has been created to address a corner case that is <20% of possible SPDX uses using the 80-20 rule.

: Submitted by stcroppe on Fri, 2011-06-10 22:44.

:: The distinction is useful most and important when the scope is a package. The two fields should contrast what the Autor/Copyright holder says about the package with what can be found in the package. (4.9.2 says "the license identified in text in the actual package source code files", this makes me believe package scope is applicable).

:: Reading 4.9.2, I am surprised it is defined based on all source code files. For any bigger package, this is going to be many licenses. The better the scanning tool, the more get added here. The name declared license implies to me, the license that the author would use when talking about his work. Simplicity would be paramount. Example: Ask the FSF about gcc-4.5, they would respond with "GPL-3.0+". This is what I'd call the declared license. Going into the files with a scanner I get a collection like this "GPL-2.0+; GPL-2.0+(with linking); X11-MIT; LGPL-2.1+; LGPL-2.1+(with linking); BSD-3-Clause; GFDL-1.2; GFDL-1.1; Public-Domain; Zlib-License; EPL-1.0; BSD-4-Clause(UCB)". Is this the declared license?

:: If so, we'd need a third field to grasp the simplified concept that "gcc-4.5 is said to be under GPL-3.0+" The usefulness of this inaccuracy is it simplicity. But then, three fields "for basically the same thing" may already be too many, and thus become confusing again.

:: When the scope is a single file, and the file has a proper license header, then this is it. If a file is missing a proper license header, but there are several COPYRIGHT files in parent or nearby directories, then the reviewer adds value by discerning which of them effectivly governs a particular file.

:: 4.7. is per definition opinionated. It should always be clear, who is the respective reviewer; Would the Schema allow this field multiple times, in case we want to document differning conclusions from multiple reviewers?

:: Submitted by jnweiger on Fri, 2011-06-10 19:14.

== License Field ==

''Is the distinction clear between the two fields?''

Yes

''Are both useful?''

Not really. If an Author of a Package (Person or Entity) states that the Package is licensed under GPLv2 then do we really want to second guess their assertion or do we want to make them responsible for that assertion? I feel strongly that the latter is the case.

The only purpose I can see for having these fields is if the SPDX file is not created by the Author(s) of the code it documents and someone else creates the SPDX file. If this is the case then I think we will have a hard time wrestling a conclusive statement about the license to the ground because we are second guessing the Author(s). Every recipient of the SPDX file will not be able to trust these fields and will likely want to do their own analysis. In this case not having this information at all is possibly better.

I would propose a single field such as "Package Author Declared" and then everyone can go back to the Package Author if something in the Package is wrong and it needs to be changed. If a Package is distributed through a Supply Chain and it is changed en route then a new Package is created and the new Author should declare the License associated with it. In this case the original (root) Open Source Author should still be maintained for verification that the current license is not wildly different from the license that was initially intended.

''Can you provide examples of where they are useful?''

I would like to see the examples here. They can help define the use cases to help with simplification, I would like to see us avoid using such examples as justification for SPDX complexity.

''Do you have an example that raises issues?''

Any example where there is no alignment on how to interpret the License governing a Package means that Compliance with the license will be problematic. I believe that the objective of SPDX is to provide information that simplifies compliance and doesn't make it complicated. I would like to see a focus on simplicity and a reduction in ambiguity.

If it is hard to assert what License a Package is governed by then perhaps the Package is too complex and should be decomposed into several smaller SPDX files that can be more definitive.

An example would be a Linux Distribution (I know this isn't necessarily a good example but serves my purpose). Technically a Linux Distribution could be documented by SPDX today. The problem is that a Linux Distribution is too noisy with License types. An SPDX file would be perfectly capable of documenting every single file and related license + Artifact etc. and also a rolled up summary of all unique licenses in the Package but making any statement about the whole work would be impossible. Another problem is that by treating a Linux Distribution as a blob you lose context for making license and compliance decisions.

A better approach is to open the Linux Distribution Package and go through each sub-package documenting each with its own SPDX file because things are now more manageable and it is easier to Declare a license. In a lot of cases a definitive Declaration is likely to be possible. In cases where it isn't perhaps another level of decomposition is necessary. This is where having the Author take responsibility for the SPDX file helps because a Linux Distribution would in most cases be a collection of Official SPDX files assembled from their points of Origin. I know there are exceptions.

I'll stop here to see what other commentary is added.

-- Submitted by stcroppe on Fri, 2011-06-10 02:08.

: I would like to add the aspect of a supplier - OEM relationship to this discussion: The supplier manufactures a product for the OEM, which the OEM will distribute. For this reason the OEM needs clear instructions from the supplier on relevant licensing restrictions. In most cases the supplier will be liable to the OEM for the product and correct information on distribution requirements.

: For this reason, I would like to see the possibility in SPDX to include the "supplier's warranted declaration" of the relevant FOSS license (this could be the use of the field "Concluded License"). Obviously, in most cases this should be the same as the Declared License. However, some packages are available under dual licensing scheme, and the way how the supplier incorporated the FOSS component could already exclude one of the two licensing choices. So the relevant licenses before integration into a product could be different from the applicable licenses after integration. Only the integrator knows if additional restrictions apply.

: Of course, I am assuming here that SPDX can also be used to describe the FOSS contents within a binary software or physical product.

: Submitted by sz on Thu, 2011-06-16 06:57.

:: From an OEM's point of view who receives a product from a supplier and needs to be able to distribute this product, it is essential to get clear instructions from the supplier which obligations apply. For this reason, I need a license field that reflects the unambiguous interpretation from the supplier for which the supplier will be liable to me. Also, in cases of dual licensing, I need to know which license was chosen by the supplier. Thus, while in the original software I may have the choice of two licenses, after integration into a product this may no longer be the case.

:: Submitted by Anonymous on Tue, 2011-06-14 08:18.

Talk:Business Team/Roadmap/2013

2013-04-10T15:33:17Z

MartinMichlmayr: Import comments from Drupal site

== How to approve and create ==

An interesting point that was raised in the biz team meeting was how to go about creating and approving the roadmap for SPDX. Since this is the first one, once we get all comments in by December 1 we can look for approval at the next general meeting. Going forward it may make sense to have the roadmap as an agenda for our second Face to Face where we can finalize and approve it. We are interested in others thoughts.

-- Submitted by JackM on Tue, 2012-10-30 18:46.

Talk:Business Team/Recruitment Plan

2013-04-10T15:32:43Z

MartinMichlmayr: Import comments from Drupal site

== New Presentation for recruitement ==

9/13/2012 – Ibrahim provided some insight, on the team call, for the New presentation for recruitment. We have slides on the site for the problem but we need slides on how SPDX operates for recruitment. Basically, why spdx is the solution.

-- Submitted by JackM on Thu, 2012-09-13 18:20.

Talk:General Meeting/Planning for Face to Face meeting in September-October 2012

2013-04-10T15:29:48Z

MartinMichlmayr: Import comments from Drupal site

== Other possible dates? ==
Can we add some additional possible dates after Oct. 7th?

-- Submitted by Gary O'Neall on Wed, 2012-08-15 16:07.

: Gary, I have Korea, then Japan, then Spain, starting Oct 7. This means pushing the mtg to mid november.

: -- Submitted by ibrahimhaddad on Thu, 2012-08-23 13:46.

== Added secondary agenda item ==

I added "2.0 Model Design" to the secondary agenda items per previous discussions on the tech weekly call.

-- Submitted by Gary O'Neall on Wed, 2012-08-15 16:04.

Talk:Business Team/SPDX Vision and Mission Discussion Document Final Draft

2013-04-10T15:28:41Z

MartinMichlmayr: Import comments from Drupal site

== Mission statement ==
I thought we agreed to change "Deliver" and "Develop" so it would be "Develop and promote adoption ..." To be clear this is the proposed Mission for the overall SPDX initiative not just the business team.

-- Submitted by Anonymous on Mon, 2012-06-25 13:29.

== Mission Statement ==

I think the mission statement is good, but I get a little lost (it's a very long sentence) at the point where it says, "that such party may create, alter, combine, pass on, or receive, and to make such information available..." it seems like there should be a noun after "create, alter, pass on, or receive." Also the combination of "or" in that clause followed by "and to make..." gets me a little lost as well. could this be broken into two sentences, perhaps?

-- Submitted by jlovejoy on Fri, 2012-06-22 22:58.

Talk:Technical Team/Use Cases/2.0/Build System Yocto

2013-04-10T15:26:53Z

MartinMichlmayr: Import comments from Drupal site

== Minor points here ==

A few comments:

: This needs verification but the license field is generally high leveland may not break down the complete licensing for a package. As an example, a package could be listed as GPL v2 which would be in the License field but the package may contain BSD, MIT, etc sub elements.

So, from a recipe perspective, each build artifact that is to be packaged should have it's license included in the LICENSE field of the recipe.

If a recipe contains multiple packages and those packages have different licenses, then we can specify the package's contained licenses via LICENSE_{$PN}. I'm sure there are cases where we don't do this but should.

: http://www.yoctoproject.org/docs/1.0/yocto-quick-start/yocto-project-qs.html

I'd use http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-... as it has the most up to date info.

Elizabeth Flanagan
Yocto Project
elizabeth.flanagan@intel.com

-- Submitted by Anonymous on Fri, 2012-05-25 03:30.

== Yocto Project not just Yocto please ==

The correct title for Yocto is "the Yocto Project"

-- Submitted by Anonymous on Thu, 2012-05-24 04:44.

Talk:Technical Team/Ideas for After 1.0 of Spec

2013-04-10T15:10:41Z

MartinMichlmayr: Import comments from Drupal site

== Deal with the case, where ==

Deal with the case, where the package is not one single file, but a collection of files in a directory. The openSUSE build Service is such a beast. How to take the SHA1 sum in that case, what is the machineName then?

Make http://www.spdx.org/licenses/ consitent with the license list in the draft PDF.'+' is used in the URLs in the pdf verbatim. This needs to be %2B, or will be interpreted as whitespace. /licenses/index.html contains 'LGPL-3.0%20with-exceptions' which uses whitespace. In HTML these two would be the same, but one is 'or later' while the other means 'only'.

Please add LGPL-2.1 instead of LGPL-2.0

Make the license list consitent within itself. 'GNU General Public License version 1.0 only' versus 'GNU General Public License version 2.0', either all with 'only' or none. 'BSD 3-clause "New" or "Revised" License' uses ", whereas 'GNU Library or “Lesser” General Public License version 2.0' use bipolar UTF-8 quotes. -- [[User:JNW|JNW]] on Wed, 2010-09-22 17:29

Talk:Technical Team/Proposals/2010-10-21/artifactOf

2013-04-10T15:10:32Z

MartinMichlmayr: Import comments from Drupal site

== 2010-11-18 general call feedback ==
By choosing to reference DOAP model, we are tacitly approving that an SPDX document may include with it additional information which is in the DOAP vocabulary.

We are requiring that an SPDX 1.0 compliant parser be able to understand only the 2 fields from DOAP (name and homepage).

If additional information from DOAP is included within the SPDX document, an SPDX 1.0 compliant parser may silently ignore the additional information.

Folks on the 2010-11-18 general call accepted the ArtifactOf proposal, and rejected the 'File origin' proposal. -- [[User:Bschineller|Bschineller]] on Thu, 2010-11-18 18:06

Technical Team/Minutes/2013-04-09

2013-04-10T12:47:21Z

MartinMichlmayr: Convert to MediaWiki syntax

== Attendees ==

* Gary O’Neall
* Bill Schineller
* Kirsten Newcomer
* Kate Stewart

== Agenda ==

* Updates

== Updates ==

* White Source (base in Israel) is interested in using the SPDX tools and integrating SPDX with their service
** Gary will coordinate on the use of SPDX tools
** Kate will encourage them to participate in the tech calls
** Visit with Matt G. Continuing collaboration
** Update on SPDX compare tool – spreadsheet version should be available next week, although it will not be fully tested
** Collab summit – Kirsten and Phil will be attending for Black Duck, but Bill will not be attending. Kirsten will be attending the bake-off/plug-fest and providing some SPDX documents.
*** Bill will send out the instance diagrams in advance

[[Category:Technical|Minutes]]
[[Category:Minutes]]

Technical Team/Use Cases/2.0

2013-04-09T15:41:13Z

MartinMichlmayr: Convert to MediaWiki syntax

We have several sources to begin pulling for SPDX Use Cases:

# The Pad from earlier conversations collected at [[Technical_Team/Old/Use_Cases_Collected_during_1.x_timeframe|Use Cases For SPDX 2.0 Discussion]]
# The old [[Technical_Team/Old/Sandbox_for_Sharing_Examples/SPDX_Use_Case_1|SPDX 1.0 Use Cases]] as well as the [[:File:ecosystem.jpg|SDPX 1.0 Use Case Picture]].

== Use Cases ==

I'd like to propose that we flesh out use cases here by having a brief summary listed here as a link to a more detailed child page. Note, these use cases should be '''doable''' but in general not '''required'''. Any item listed here that is not a link, should have a child page created for it.

# Code commits (original work intended for the project)
## [[Technical_Team/Use_Cases/2.0/Committers_provides_SPDX_data_for_a_code_being_committed|Committer provides SPDX data]] [OK]
## [[Technical_Team/Use_Cases/2.0/Contributor_makes_commit_subject_to_existing_SPDX_data_of_project|Contributor makes commit subject to existing SPDX data of project]] [OK]
# [[Technical_Team/Use_Cases/2.0/Committer_annotates_source_files_with_SPDX_data|Committer annotates source files with SPDX data]] [OK]
# Patches (original work intended for the project)
## [[Technical_Team/Use_Cases/2.0/Patch_provider_provides_SPDX_data_for_the_patch|Patch provider provides SPDX data for the patch]] [OK]
## [[Technical_Team/Use_Cases/2.0/Patch_provider_provides_SPDX_data_for_the_patch_indicating_it_is_licensed_however_the_hell_its_applied|Patch provider provides SPDX data for the patch indicating it is licensed however the hell its applied]] [OK]
## [[Technical_Team/Use_Cases/2.0/Patch_provider_provides_patch_subject_to_existing_SPDX_data_of_project|Patch provider provides patch subject to existing SPDX data of project]] [OK]
# Patch provider provides a patch that modifies existing SPDX data of project
## [[Technical_Team/Use_Cases/2.0/Downstream_consumers_contributing_patches_to_provide_SPDX_data_to_an_upstream_that_doesnt_have_it|Downstream consumers contributing patches to provide SPDX data to an upstream that doesn't have it.]] [OK]
## [[Technical_Team/Use_Cases/2.0/Downstream_consumers_contributing_patches_to_provide_corrections_to_SPDX_data_for_an_upstream_that_does_have_it|Downstream consumers contributing patches to provide corrections to SPDX data for an upstream that does have it.]] [OK]
# [[Technical_Team/Use_Cases/2.0/Upstream_maintainer_providing_SPDX_data|Upstream maintainer providing SPDX data]]
## [[Technical_Team/Use_Cases/2.0/Upstream_maintainer_providing_SPDX_data_in_source_archive|Upstream maintainer providing SPDX data in source archive]] [OK]
## [[Technical_Team/Use_Cases/2.0/Upstream_maintainer_providing_SPDX_data_in_SCM|Upstream maintainer providing SPDX data in SCM]] [OK]
## [[Technical_Team/Use_Cases/2.0/Upstream_maintainer_providing_SPDX_data_at_a_URL|Upstream maintainer providing SPDX data at a URL]] [OK]
## [[Technical_Team/Use_Cases/2.0/Upstream_maintainer_preparing_release_artifacts_(including_SPDX_data)|Upstream maintainer preparing release artifacts (including SPDX data).]] [OK]
# Project maintainer incorporates another project
## [[Technical_Team/Use_Cases/2.0/Project_maintainer_incorporates_another_project_by_including_source|Project maintainer incorporates another project by including source]] [OK]
## [[Technical_Team/Use_Cases/2.0/Project_maintainer_incorporates_another_project_by_including_binary|Project maintainer incorporates another project by including binary]] [OK]
## [[Technical_Team/Use_Cases/2.0/Project_maintainer_pulling_individual_files_out_of_another_project_(subsetting)|Project maintainer pulling individual files out of another project (subsetting)]] [OK]
# Ease adoption
## [[Technical_Team/Use_Cases/2.0/Low_cost_SPDX_file|Allow a low investment SPDX producer to produce valid SPDX data]] [OK-fathomed but not Approved for Implementation]
## [[Technical_Team/Use_Cases/2.0/Producing_valid_SPDX_files_in_the_face_of_missing_data|Produce a valid SPDX dataset even if some data is missing]] [OK]
# Intermediate packager (rpm, deb, etc) passing on and adding to SPDX Data
## Intermediate packager builds source package from upstream source
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_builds_source_package_from_upstream_source_that_provides_SPDX_data|Intermediate packager builds source package from upstream source that provides SPDX data]] [OK]
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_builds_source_package_from_upstream_source_that_does_not_provide_SPDX_data|Intermediate packager builds source package from upstream source that does not provide SPDX data]] [OK]
## Intermediate packager builds binary package from upstream source
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_builds_binary_package_from_upstream_source_that_provides_SPDX_data|Intermediate packager builds binary package from upstream source that provides SPDX data]] [OK]
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_builds_binary_package_from_upstream_source_that_does_not_provides_SPDX_data|Intermediate packager builds binary package from upstream source that does not provides SPDX data [OK]]
## Intermediate packager adds patches to upstream source
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_adds_patches_to_upstream_source_that_provides_SPDX_data|Intermediate packager adds patches to upstream source that provides SPDX data]] [OK]
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_adds_patches_to_upstream_source_that_does_not_provide_SPDX_data|Intermediate packager adds patches to upstream source that does not provide SPDX data [OK]]
## Intermediate packager adds someone else's patches to upstream source
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_adds_someone_elses_patches_to_upstream_source_that_provides_SPDX_data|Intermediate packager adds someone else's patches to upstream source that provides SPDX data]] [OK]
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_adds_someone_elses_patches_to_upstream_source_that_does_not_provide_SPDX_data|Intermediate packager adds someone else's patches to upstream source that does not provide SPDX data]] [OK]
## Intermediate packager subsetting upstream source
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_subsetting_upstream_source_that_provides_SPDX_data|Intermediate packager subsetting upstream source that provides SPDX data]] [OK]
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_subsetting_upstream_source_that_does_not_provide_SPDX_data|Intermediate packager subsetting upstream source that does not provide SPDX data [OK]]
# Build systems (build systems want to pass on SPDX data for the thing they are building)
## [[Technical_Team/Use_Cases/2.0/Build_System_Yocto|Yocto]] [OK]
## Linking
### [[Technical_Team/Use_Cases/2.0/Debian_has_an_interest_in_only_building_things_that_are_linking_license_compatible|Debian has an interest in only building things that are linking license compatible]] [OK]
## I just made a binary out of some source
### [[Technical_Team/Use_Cases/2.0/SPDX_data_indicating_subset_of_the_source_that_made_it_into_a_particular_binary_or_binary_package|SPDX data indicating subset of the source that made it into a particular binary or binary package]] [OK]
# Aggregator aggregating many 'copyrightable items' for redistribution
## [[Technical_Team/Use_Cases/2.0/Linux_Distros|Linux Distros]] [OK]
## [[Technical_Team/Use_Cases/2.0/Embedded_Images_(e.g._router_images,_switch_images)|Embedded Images (e.g. router images, switch images)]] [OK]
## [[Technical_Team/Use_Cases/2.0/Reference_Implementations|Reference implementations]] [OK]
## [[Technical_Team/Use_Cases/2.0/Application_which_ships_with_documentation_and_media_and_software|Application which ships with documentation + media + software]] [OK]
## [[Technical_Team/Use_Cases/2.0/Application_which_ships_with_a_contrib_libraries|Application which ships with a contrib libraries]] [OK]
## [[Technical_Team/Use_Cases/2.0/Application_which_ships_with_development_tools|Application which ships with development tools]] [OK]
## [[Technical_Team/Use_Cases/2.0/Subsetting_out_only_the_shippable_bits_of_stuff_coming_from_an_SDK|Subsetting out only the shippable bits of stuff coming from an SDK]] [OK]
## [[Technical_Team/Use_Cases/2.0/Aggregators_aggregating_other_aggregations_for_redistribution|Aggregators aggregating other aggregations for redistribution]] [OK]
# Consumers receiving SPDX data
## [[Technical_Team/Use_Cases/2.0/Provide_sufficient_data_to_allow_consumer_to_comply_with_licenses_on_redistribution|Provide sufficient data to allow consumer to comply with licenses on redistribution]] Alcatel-Lucent requirements attached [OK]
# [[Technical_Team/Use_Cases/2.0/Consuming_code_snippets|Consuming code snippets]] (God help us all) (subfile pieces of code not originally intended for the project) [OK]
# Signoff/multiple signoff on SPDX data
## [[Technical_Team/Use_Cases/2.0/Contracts_with_multiple_parties_requiring_signoff_by_all|Contracts with multiple parties requiring signoff by all]] [MORE INFO REQUESTED Kate Stewart]
# Third party does licensing analysis
## [[Technical_Team/Use_Cases/2.0/Third_party_produces_bill_of_materials_for_software_package|Third party generates license analysis]] [OK]
## [[Technical_Team/Use_Cases/2.0/Collecting_enough_information_to_allow_auditor_to_make_recommendations_to_remove_or_not_a_component|Collecting enough information to allow auditor to make recommendations to remove or not a component]] [OK]
# Auditor Analyzing/Sanity-checking/correcting Bill of Material he's handed
## [[Technical_Team/Use_Cases/2.0/Backtrack_from_binary_to_source_files|Backtrack from compiled/binary file to constituent files]] [MORE STUDY NEEDED]
## outbound: validate that SPDX goes hand in hand with what's being shipped (Kirsten Newcomer)
### [[Technical_Team/Use_Cases/2.0/Check_to_see_if_the_SPDX_data_provided_matches_the_files_provided_and_is_trustworthy_and_most_current_for_package|Check to see if the SPDX data provided matches the files provided]] [OK larger scope]
# Extensions:
## [[Technical_Team/Use_Cases/2.0/Communicate_data_beyond_what_is_described_in_spec|Communicate data beyond what is described in spec between consenting parties w/o breaking consumers that are not in the know]] [OK]
## [[Technical_Team/Use_Cases/2.0/License_list_extension|License list extensions, how do you handle folks who have more licenses than SPDX]] [OK]
## [[Technical_Team/Use_Cases/2.0/Decorating_an_already_produces_and_signed_SPDX_dataset_with_extension_data|Decorating an already produces and signed SPDX dataset with extension data]] [OK]
# Other arising during vetting...
## Given 2 SPDX files about the same codebase from the same source, be able to tell which is the later rev / more current and correct one. [DETAIL PAGE NEEDS TO BE WRITTEN - seems to be asking for something more robust than just a later date on one SPDX file vs. the other, rather 'signing with revisioning, where the later revision may reference the earlier and declare it is an amendment to the earlier one]

== Cross-cutting concerns ==

# Provenance (the need to optionally use signing to validate who said what)
# Trust
# Handling staleness of data
# Composite licensing
# Ease of sharing information
## Collecting tribal knowledge along the way
# Guarding against file bloat
# Simple simple simple
# SPDX-Lite:
# Clarity
# Automation/toolifiability
# Regionality

==Themes==

Looking at these Use Cases, there are some underlying themes:

# Root of data (closer to upstream the better)
# Subsetting of copyrightable things (and their SPDX data) ('''Note''': Subsets of copyrightable things are usually also copyrightable things)
# Aggregation of copyrightable things (and their SPDX data) ('''Note''': Aggregations of copyrightable things are usually also copyrightable things).

[[Category:Technical]]

Legal Team/License List/Overview and License Inclusion Guidelines (draft for review)

2013-04-09T15:40:59Z

MartinMichlmayr: Convert to MediaWiki syntax

'''The SPDX License List (SPDX-LL) is a list of commonly found open source software licenses for the purposes of being able to easily and efficiently identify such licenses in an SPDX document. The SPDX License List includes a standardized short identifier, full name, vetted license text, other basic information, and a canonical permanent URL for each license. By providing a short identifier, users can efficiently refer to a license without having to redundantly reproduce the full license.'''

'''By including a license on this list, the SPDX workgroup makes no judgement about its suitability or desirability. The list is meant only to standardize references to commonly used, open source licenses, not to promote or discourage the use of any license.'''

This page describes the current principles for the inclusion of a license on the SPDX-LL, as well as an explanation of the fields contained on the list.

* You may propose additional licenses be added to the SPDX License List by following the process at: [http://spdx.org/content/spdx-license-list-process-requesting-new-licenses-be-added SPDX License List: Process for requesting new licenses to be added].
* Guidelines for what constitutes a license match to the SPDX License List when generating an SPDX file can be found here: [http://spdx.org/content/spdx-license-list-license-matching-guidelines SPDX License List Match Guidelines.]

== License Inclusion Principles ==

=== Background Principles ===

The Software Package Data Exchange® (SPDX®) specification is a standard format for communicating the components, licenses, and copyrights associated with open source software packages. Use of this standard streamlines license identification across the supply chain while reducing redundant work.

The goal of SPDX is not to evaluate licensing information or to provide legal interpretations. The goal is solely to reliably and consistently communicate and share licensing information so that organizations using software components will have the information necessary to conduct their independent analysis and evaluation. Establishing a consistent, reliable, and reusable way to communicate license information for software components will then facilitate open source license compliance along the supply chain.

Although SPDX has traditionally focused on open source licensing, software may contain a mix of open-source licensed, commercially-licensed, freeware licensed, and other varieties of licensed packages. Thus, it is feasible that a future version of the standard may develop a standardized method of identifying non-open source licenses contained within software packages.

Because the present focus of SPDX is the collection and presentation of the open-source software licenses contained in a software package, any license that is a candidate for inclusion on the SPDX License List must be an "open source" license.

=== Open Source Definition ===

The terms "free software," "open source software," or their variants (FOSS, FLOSS, libre software, etc.) are defined differently by different organizations. At a minimum all definitions of open source or free software include the characteristic that the source code be made available for inspection and modification and that the source code may be freely distributed. However, there are a number of other characteristics that vary depending on the policy focus of the defining organization. Even though the various definitions of open source software differ in some respects, there are certain fundamental characteristics commonly incorporated in all these definitions.

The SPDX Legal Team uses the definition promulgated by the Open Source Initiative (OSI) as the basis for analyzing candidate licenses for inclusion on the SPDX License List. That definition provides as follows:

Introduction

Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria:

# Free Redistribution. The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
# Source Code. The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.
# Derived Works. The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
# Integrity of The Author's Source Code. The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.
# No Discrimination Against Persons or Groups. The license must not discriminate against any person or group of persons.
# No Discrimination Against Fields of Endeavor. The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
# Distribution of License. The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.
# License Must Not Be Specific to a Product. The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.
# License Must Not Restrict Other Software. The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.
# License Must Be Technology-Neutral. No provision of the license may be predicated on any individual technology or style of interface.

''Available on the world wide web at http://opensource.org/osd (March 14, 2013). ''

=== Candidate License Analysis ===

Determining whether a candidate license is deemed to be open source for purpose of inclusion on the SPDX License List requires the SPDX Legal Team to engage in a case-by-case evaluation of each candidate license. Any candidate license that substantially complies with the open source definition will be added to the SPDX License List. Nevertheless, the SPDX Legal Team does not require (1) strict compliance with all elements of the OSI Definition or (2) strict compliance with any particular element of the OSI Definition. Rather, it treats each of the elements of the definition as a factor to be balanced in light of the totality of the candidate license and SPDX's goals and objectives. Consequently, the SPDX Legal Team will determine whether and to what degree the candidate license addresses each of the elements of the open source definition. The SPDX Legal Team may also analyze “environmental” factors outside the open source definition, such as whether a candidate license is already included on the OSI license list or other such lists, whether the candidate license is in common use, or whether a commonly used open source project uses it (particularly where such open source project is a dependency on which other projects rely).

The SPDX Legal Team may prepare a memorandum explaining its reasoning, analysis, and conclusions with respect to a candidate license as a means of developing precedent and publish the same on the SPDX website. Nevertheless, the SPDX Legal Team is not required to do so.

'''Explanation of SPDX License List fields:'''

The following information describes how each field on the license list (whether on the webpage or within the spreadsheet) is treated.

'''A) Full Name of License'''

* The full license name my omit certain word, such as "the," for alphabetical sorting purposes
* No commas in full name of license
* Do not spell out “version” – use “v” or nothing to indicate license version (for space reasons)
* Use lower case v and no period or space b/w v and the number
* Remove any license abbreviations from parenthesis after full license name

'''B) License Identifier (aka "SPDX Short Identifier")'''

* Short identifier to be used to identify a license match to licenses contained on the SPDX-LL in the context of an SPDX file
* Identifier should have no spaces in it
* Identifier consists of a short name, abbreviation, or acronym for the license
* Where applicable, license abbreviation will be followed by a dash and then the version number, in X.Y format

'''C) Source/url'''

* Include url for license author’s website
* If the license is OSI approved, also include url for OSI license page
* Other website that has text version of license, if neither of the first two options are available
* Link to license in native language is used where specified (e.g. French for CeCILL). Link to English version where multiple, equivalent official translations (e.g. EUPL)

'''D) Notes'''

* Include date of release, if found, for licenses with multiple versions, using European date format: day – month – year
* Only factual information should be included here, e.g. the license has been deprecated.
* Does not contain information (or links to information) that includes any kind of interpretation or comment about the license (even if written by the license author)

'''E) OSI Approved'''

* If the license is OSI approved, this field will indicate "yes," otherwise left blank

'''F) Standard License Header'''

* Should only include text intended to be put in the header of source files or other files as specified in the license or license appendix when specifically delineated
* Indicate if there is any variation in the header (i.e. for files developed by a contributor versus when applying license to original work)
* Do not include NOTICE info intended for a separate notice file
* Leave this field blank if there is no standard header as specifically defined in the license

'''G) Text'''

* Full license text or, in the spreadsheet, reference to separate .txt file named by SPDX Short Identifier that contains full license text

Any additional information or columns contained in the spreadsheet version of the SPDX-LL are not part of the official SPDX License List and are included for tracking or informational purposes only.

[[Category:Legal]]

Technical Team/Minutes/2013-04-02

2013-04-09T15:36:04Z

MartinMichlmayr: Convert to MediaWiki syntax

== Attendees ==

* Gary O’Neall
* Jack Manbeck
* Bill Schineller
* Kirsten Newcomer
* Kate Stewart
* Michael Herzog

== Agenda ==

* Model Discussion
* Response to email from Oliver Fendt
* Prep for Collab Summit

== Model ==

* Bill will work on the instance diagram for future discussions

== Response to email from Oliver Fendt ==

* Michael and Dennis Clark will review the current usage guidelines
* Gary will respond to the licenses (concluded license used for choice)
* Kate will respond to the first half of the emails

== Prep for Collab Summit ==

* Work through prioritized set of use cases to cross check the models (“Merged” model + at least one other model)
* Compare the model
* Will use the instance diagram on time which Bill, Kirsten are working on – will cover use cases 8.3.1/2, 8.3.4, 8.4.1/2
* Jack will work on an instance diagram for one of the other use cases – 10.5 (contrib directories). Could be freeRtos, FFMPEG, Zlib
* UseCase/Model spreadsheet has been updated with the collab summit tasks
* Spreadsheet updated with the priority for discussion at collab summit

[[Category:Technical|Minutes]]
[[Category:Minutes]]