Date   
Re: Request for adding Eclipse Distribution License - v 1.0

Philippe Ombredanne
 

Hi Aurelien:

On Tue, Dec 10, 2019 at 6:36 PM CARLIER Aurelien
<@acarlier> wrote:
I would like to request addition of the Eclipse Distribution License in the SPDX license list.
The EDL-1.0 is a variation of the New BSD License
As far as I can remember, since this is the same as the BSD-3-Clause
license text (using the matching guidelines), it was never added as
its own license id.

--
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombredanne@...
DejaCode - What's in your code?! - http://www.dejacode.com
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com

Re: Request for adding Eclipse Distribution License - v 1.0

Wayne Beaton
 

We've discussed this previously (at my suggestion on behalf of the Eclipse Foundation).

My recollection is that it was decided that SPDX would not add EDL-1.0 or any other licenses based on the BSD-3-Clause template because doing so would set a precedent drawing in literally hundreds of other licenses based on that template.

For Eclipse projects that use EDL-1.0, we just use BSD-3-Clause as the SPDX code.

Wayne

On Tue, Dec 10, 2019 at 12:36 PM CARLIER Aurelien <aurelien.carlier@...> wrote:

Hello,

 

I would like to request addition of the Eclipse Distribution License in the SPDX license list. The EDL-1.0 is a variation of the New BSD License (fixing . Here is what I would suggest:

 

1.    License name: Eclipse Distribution License 1.0

2.    Proposed Identifier: EDL-1.0

3.    URL: https://www.eclipse.org/org/documents/edl-v10.php

4.    See attached file.

5.    Indicate whether the license is OSI-approved : “The Eclipse Distribution License is an OSI Approved Open Source License by means of the New BSD License.” As said on the license’s full text page

6.    This license is used by Eclipse JGIT https://github.com/eclipse/jgit/blob/master/LICENSE with the following text:

This program and the accompanying materials are made available

under the terms of the Eclipse Distribution License v1.0 which

accompanies this distribution, is reproduced below, and is

available at http://www.eclipse.org/org/documents/edl-v10.php

 

Thank you in advance to take this request into account.

 

Regards,

Aurélien

 

[@@ THALES GROUP INTERNAL @@]

 



--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.

Request for adding Eclipse Distribution License - v 1.0

CARLIER Aurelien
 

Hello,

 

I would like to request addition of the Eclipse Distribution License in the SPDX license list. The EDL-1.0 is a variation of the New BSD License (fixing . Here is what I would suggest:

 

1.    License name: Eclipse Distribution License 1.0

2.    Proposed Identifier: EDL-1.0

3.    URL: https://www.eclipse.org/org/documents/edl-v10.php

4.    See attached file.

5.    Indicate whether the license is OSI-approved : “The Eclipse Distribution License is an OSI Approved Open Source License by means of the New BSD License.” As said on the license’s full text page

6.    This license is used by Eclipse JGIT https://github.com/eclipse/jgit/blob/master/LICENSE with the following text:

This program and the accompanying materials are made available

under the terms of the Eclipse Distribution License v1.0 which

accompanies this distribution, is reproduced below, and is

available at http://www.eclipse.org/org/documents/edl-v10.php

 

Thank you in advance to take this request into account.

 

Regards,

Aurélien

 

[@@ THALES GROUP INTERNAL @@]

 

Re: New License/Exception Request: CAL-1.0 and CAL-1.0-with-exception

Steve Winslow
 

Hi Van, thanks for submitting this. I've copied it over to an issue in the SPDX license-list-XML repo, so that comments and input can be aggregated there -- see https://github.com/spdx/license-list-XML/issues/953

Best,
Steve


On Thu, Dec 5, 2019 at 1:30 AM Lindberg, Van <VLindberg@...> wrote:

Hello,

 

I have received a preliminary positive report from OSI’s license committee on the Cryptographic Autonomy License v.1.0, or “CAL”.

The CAL also includes a built-in “Combined Works Exception” that seems like it would fit with your exception grammar.

1.       1. Provide a proposed Full Name for the license or exception:

2.       Cryptographic Autonomy License, v1.0, or
Cryptographic Autonomy License version 1.0, with Combined Work Exception”

3.      

4.       2. Provide a proposed Short Identifier.

5.       CAL-1.0 or CAL-1.0-with-exception

6.        

7.       3. Provide a functioning url reference to the license or exception text, either from the author or a community recognized source.

8.       https://docs.google.com/document/d/1-eD9EH6i3wdSXgG4XJbF-a0cSSknOERjYzlVonOwAQ0/edit?usp=sharing

9.        

10.   4. Create and attach a text file with the license or exception text from the url provided in #3.

11.   Attached.

12.    

13.   5. Indicate whether the license is OSI-approved (see: http://www.opensource.org/licenses/alphabetical) or whether it has been submitted for approval to the OSI and is currently under review.
It is currently under review and I expect approval.

14.   6. Provide a short explanation regarding the need for this license or exception to be included on the SPDX License List, including identifying at least one program that uses this license.

15.   I expect this will be approved by the OSI shortly. As soon as it is approved, Holochain will be moving to use it.

 


Dykema
Van Lindberg
Member
VLindberg@...
210-554-5294 Direct
210-554-5500 Main
855-256-1479 Fax
214-364-7985 Mobile
112 E. Pecan Street, Suite 1800 
San Antonio, Texas  78205
www.dykema.com

*** Notice from Dykema Gossett PLLC: This Internet message may contain information that is privileged, confidential, and exempt from disclosure. It is intended for use only by the person to whom it is addressed. If you have received this in error, please (1) do not forward or use this information in any way; and (2) contact me immediately. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message.



--
Steve Winslow
Director of Strategic Programs
The Linux Foundation

New License/Exception Request: CAL-1.0 and CAL-1.0-with-exception

Lindberg, Van <VLindberg@...>
 

Hello,

 

I have received a preliminary positive report from OSI’s license committee on the Cryptographic Autonomy License v.1.0, or “CAL”.

The CAL also includes a built-in “Combined Works Exception” that seems like it would fit with your exception grammar.

1.       1. Provide a proposed Full Name for the license or exception:

2.       Cryptographic Autonomy License, v1.0, or
Cryptographic Autonomy License version 1.0, with Combined Work Exception”

3.      

4.       2. Provide a proposed Short Identifier.

5.       CAL-1.0 or CAL-1.0-with-exception

6.        

7.       3. Provide a functioning url reference to the license or exception text, either from the author or a community recognized source.

8.       https://docs.google.com/document/d/1-eD9EH6i3wdSXgG4XJbF-a0cSSknOERjYzlVonOwAQ0/edit?usp=sharing

9.        

10.   4. Create and attach a text file with the license or exception text from the url provided in #3.

11.   Attached.

12.    

13.   5. Indicate whether the license is OSI-approved (see: http://www.opensource.org/licenses/alphabetical) or whether it has been submitted for approval to the OSI and is currently under review.
It is currently under review and I expect approval.

14.   6. Provide a short explanation regarding the need for this license or exception to be included on the SPDX License List, including identifying at least one program that uses this license.

15.   I expect this will be approved by the OSI shortly. As soon as it is approved, Holochain will be moving to use it.

 


Dykema
Van Lindberg
Member
VLindberg@...
210-554-5294 Direct
210-554-5500 Main
855-256-1479 Fax
214-364-7985 Mobile
112 E. Pecan Street, Suite 1800 
San Antonio, Texas  78205
www.dykema.com

*** Notice from Dykema Gossett PLLC: This Internet message may contain information that is privileged, confidential, and exempt from disclosure. It is intended for use only by the person to whom it is addressed. If you have received this in error, please (1) do not forward or use this information in any way; and (2) contact me immediately. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message.

Minutes from 3 Dec joint tech/legal meeting

Gary O'Neall
 

Minutes from today’s joint legal / technical has been posted to joint tech/legal call here: https://wiki.spdx.org/view/Technical_Team/Minutes/2019-12-03

 

Gary

 

-------------------------------------------------

Gary O'Neall

Principal Consultant

Source Auditor Inc.

Mobile: 408.805.0586

Email: gary@...

CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

 

Invitation: SPDX joint legal/tech team meeting @ Tue Dec 3, 2019 1pm - 2pm (EST) (spdx-legal@lists.spdx.org)

Steve Winslow
 

You have been invited to the following event.

SPDX joint legal/tech team meeting

When
Tue Dec 3, 2019 1pm – 2pm Eastern Time - New York
Where
https://zoom.us/j/663426859 (map)
Calendar
spdx-legal@...
Who
swinslow@... - organizer
spdx-legal@...

With apologies for the late notice:


For folks who are able to attend today, the weekly SPDX tech team meeting will likely include discussions of topics relating to SPDX 3.0 planning, which may be of interest to participants on the SPDX legal team. The call will be at 1PM EDT / 10AM PDT, and invite details are below.



= = = = =



https://zoom.us/j/663426859
Meeting ID: 663 426 859

 Tuesdays at 17:00 UTC (and best guess for local time - 10:00AM PDT, 11:00 MDT, 12:00PM CDT, 1:00PM EDT, 18:00 WAT, 19:00 CEST).
 Australia +61 2 8015 2088
 Canada +1 647 558 0588
 Germany +49 30 3080 6188
 Japan +81 3 4578 1488
 US Toll-free 877 369 0926
 Find your local number: https://zoom.us/u/ac9KKJWzJT

Going (spdx-legal@...)?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account spdx-legal@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More.

No SPDX Legal team meeting this Thursday

Steve Winslow
 

This week's SPDX legal team meeting will be cancelled due to the US holiday on Thursday. You should receive a calendar cancellation sent to this list shortly.

We will likely be holding a joint legal / tech team call to discuss SPDX 3.0 spec changes and related matters on Tuesday, Dec. 3 at 1PM Eastern US time / 10AM Pacific. We'll circulate an invite for that call after the time is confirmed.

Best,
Steve

--
Steve Winslow
Director of Strategic Programs
The Linux Foundation

SPDX Legal team meeting now

Steve Winslow
 

This week's legal team meeting is beginning momentarily, apologies for the very late notice...

Optional dial in number: 415-881-1586

--
Steve Winslow
Director of Strategic Programs
The Linux Foundation

Meeting today, Oct. 31

Steve Winslow
 

Hello all,

The next Legal Team meeting will be today, Thursday, Oct. 31 at 9AM PT / 12PM ET.

The agenda will include:
1) update from the joint legal/tech meeting last week
2) discussing a couple of long-pending issues ([1], [2] below) that should be addressed in 3.8
3) continuing discussion of updates to license inclusion guidelines

**Please note** the updated UberConference URL below for the call.

Dial-in info:
Web conference: https://www.uberconference.com/room/SPDXTeam
Optional dial in number: 415-881-1586

Best,
Steve

[1] GFDL / "no invariant sections": https://github.com/spdx/license-list-XML/issues/686

--
Steve Winslow
Director of Strategic Programs
The Linux Foundation

Advice/guidance/input from the SPDX community for Arch Linux

Santiago Torres Arias <santiago@...>
 

Hi,

The Arch Linux community recently started a discussion around adopting
SPDX license identifiers to simplify/improve their license handling:

https://lists.archlinux.org/pipermail/arch-dev-public/2019-October/029695.html

I imagine that the SPDX community may be interested in chiming in if
there are any known pitfalls on doing so, or general advice around it.

Cheers!
-Santiago.

Updates to SPDX 3.0 Proposal

William Bartholomew
 

I have added a new section at the bottom of this document that maps the fields to profiles, I've incorporated nearly all of the original proposal content into that table:

I'd appreciate your input on these mappings and the other comments. One important comment is that "mandatory" means mandatory if you have adopted that profile, otherwise it is optional.

Regards,
William Bartholomew

Re: [spdx-tech] Advice/guidance/input from the SPDX community for Arch Linux

William Bartholomew
 

My feedback (and feel free to pass this onto their list) would be to ensure they adopt SPDX Expressions (https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60) rather than accepting a single SPDX license id (which is often overly simplistic) or an array (which is ambiguous as to whether it means AND or OR). There are a number of parsers out there for this format.

Regards,
William Bartholomew


On Tue, Oct 22, 2019 at 12:33 PM Santiago Torres Arias <santiago@...> wrote:
Hi,

The Arch Linux community recently started a discussion around adopting
SPDX license identifiers to simplify/improve their license handling:

    https://lists.archlinux.org/pipermail/arch-dev-public/2019-October/029695.html

I imagine that the SPDX community may be interested in chiming in if
there are any known pitfalls on doing so, or general advice around it.

Cheers!
-Santiago.



3.7 License List release

Steve Winslow
 

Hello all,

The version 3.7 release of the license list is now tagged and live at https://spdx.org/licenses. Along with documentation updates and markup tweaks, 6 new licenses and exceptions were added to the list:

* etalab-2.0
* MulanPSL-1.0
* OGL-Canada-2.0
* SSH-OpenSSH
* SSH-short
* UCL-1.0

A couple particular shout-outs for other contributions beyond these licenses:

* Thank you to Jilayne and Gary for debugging an issue with the license list publisher, which was occasionally causing "optional text" markup to not display as optional on the website version.

* Thank you to Kyle Mitchell for contributing a script to easily enable testing a single license XML file at a time, rather than re-testing the entire set — this has significantly improved the XML creation and testing process.


And with that, time to turn to the pending issues for 3.8  :)

--
Steve Winslow
Director of Strategic Programs
The Linux Foundation

Reminder: Joint SPDX tech & legal call - in 1 hour.

Kate Stewart
 

Hi all,
    Just a reminder we'll be having a joint legal & tech call for this month, in an hour from now.

Agenda:
- review some of the changes being discussed for SPDX 3.0 with focus on:
  - move from mandatory to optional for licensing fields, copyright, etc.
  - revisit CC0 as data license
  - unification of licensing fields across package, file, snippet section.

Participation Information: 
https://zoom.us/j/663426859
Meeting ID: 663 426 859

 Tuesdays at 17:00 UTC (and best guess for local time - 10:00AM PDT, 11:00 MDT, 12:00PM CDT, 1:00PM EDT, 18:00 WAT, 19:00 CEST).
 Australia +61 2 8015 2088
 Canada +1 647 558 0588
 Germany +49 30 3080 6188
 Japan +81 3 4578 1488
 US Toll-free 877 369 0926
 Find your local number: https://zoom.us/u/ac9KKJWzJT

Re: NTP/old style MIT licenses

Steve Winslow
 

Hi Armijn,

From a quick look at the licenses on the license list, I see a couple that are close, but which would be considered different licenses under the SPDX matching guidelines [1]:

* NTP [2] -- very similar but contains some additional non-optional text that isn't in the one you sent (e.g. requirements around copyright notices)
* HPND [3] -- similar to NTP but also includes second all-caps disclaimer paragraph

Given that NTP and HPND appear to require reproduction of copyright notices, and the one you sent doesn't appear to require it, I'd say that most likely it would be considered substantively different from those, given the way the SPDX legal team looks at licenses. In other words, probably makes sense to add this to the license list as a separate entry.

If you want to submit an issue for this to the license-list-XML repo [4], that would be excellent  :)

Steve


On Tue, Oct 22, 2019 at 11:42 AM Armijn Hemel - Tjaldur Software Governance Solutions <armijn@...> wrote:
hello,

I searched but I couldn't find it in the archives, so apologies if this
question has already come up.

Recently I looked at some old code from e2fsprogs:

https://github.com/tytso/e2fsprogs/blob/master/lib/et/et_name.c

The license is an old style MIT license:

https://fedoraproject.org/wiki/Licensing:MIT#Old_Style_.28no_advertising_without_permission.29

According to Dejacode (hi Philippe!) this license is equivalent to the
NTP license:

https://enterprise.dejacode.com/licenses/public/mit-old-style-no-advert/

but I have trouble finding any discussion about it. Am I looking in the
wrong place, or have these licenses not been under consideration yet? :-)

armijn


--
Armijn Hemel, MSc
Tjaldur Software Governance Solutions







--
Steve Winslow
Director of Strategic Programs
The Linux Foundation

NTP/old style MIT licenses

Armijn Hemel - Tjaldur Software Governance Solutions
 

hello,

I searched but I couldn't find it in the archives, so apologies if this
question has already come up.

Recently I looked at some old code from e2fsprogs:

https://github.com/tytso/e2fsprogs/blob/master/lib/et/et_name.c

The license is an old style MIT license:

https://fedoraproject.org/wiki/Licensing:MIT#Old_Style_.28no_advertising_without_permission.29

According to Dejacode (hi Philippe!) this license is equivalent to the
NTP license:

https://enterprise.dejacode.com/licenses/public/mit-old-style-no-advert/

but I have trouble finding any discussion about it. Am I looking in the
wrong place, or have these licenses not been under consideration yet? :-)

armijn


--
Armijn Hemel, MSc
Tjaldur Software Governance Solutions

Re: New License Request: Valgrind Client License

Steve Winslow
 

Hi Stefan, thanks for reaching out. It looks to me like this one is equivalent (for SPDX matching purposes) to bzip2-1.0.6 which is currently on the license list [1]. So I don't expect that this would lead to a new entry on the list, unless there are substantive differences under the SPDX matching guidelines [2].

As a heads-up, new license requests are probably best submitted through the GitHub issues list [3], as that is the primary place where participants review the requests and prepare additions to the list.

Best,
Steve


On Fri, Oct 18, 2019 at 10:31 PM Stefan Brüns <stefan.bruens@...> wrote:
Valgrind (http://valgrind.org) is mostly licensed under GPL-2.0-or later, but
includes several permissively licensed header files for inclusion in arbitrary
client programs.

Proposed Full Name: Valgrind BSD-Style Client Header License
Short Identifier: Valgrind-BSD-Client-Header

The license is included in the following files:
https://sourceware.org/git/?p=valgrind.git;a=blob;f=include/valgrind.h
https://sourceware.org/git/?p=valgrind.git;a=blob;f=callgrind/callgrind.h
https://sourceware.org/git/?p=valgrind.git;a=blob;f=drd/drd.h
https://sourceware.org/git/?p=valgrind.git;a=blob;f=hellgrind/hellgrind.h
https://sourceware.org/git/?p=valgrind.git;a=blob;f=memcheck/memcheck.h

The actual license clauses are identical for all 5 files.

Full Text (valgrind.h):
   ----------------------------------------------------------------

   Notice that the following BSD-style license applies to this one
   file (valgrind.h) only.  The rest of Valgrind is licensed under the
   terms of the GNU General Public License, version 2, unless
   otherwise indicated.  See the COPYING file in the source
   distribution for details.

   ----------------------------------------------------------------

   This file is part of Valgrind, a dynamic binary instrumentation
   framework.

   Copyright (C) 2000-2017 Julian Seward.  All rights reserved.

   Redistribution and use in source and binary forms, with or without
   modification, are permitted provided that the following conditions
   are met:

   1. Redistributions of source code must retain the above copyright
      notice, this list of conditions and the following disclaimer.

   2. The origin of this software must not be misrepresented; you must
      not claim that you wrote the original software.  If you use this
      software in a product, an acknowledgment in the product
      documentation would be appreciated but is not required.

   3. Altered source versions must be plainly marked as such, and must
      not be misrepresented as being the original software.

   4. The name of the author may not be used to endorse or promote
      products derived from this software without specific prior written
      permission.

   THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS
   OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
   WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
   ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
   DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
   DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
   GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
   INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
   WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
   NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
   SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

   ----------------------------------------------------------------

Kind regards,

Stefan

--
Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
home: +49 241 53809034     mobile: +49 151 50412019





--
Steve Winslow
Director of Strategic Programs
The Linux Foundation

New License Request: Valgrind Client License

Stefan Brüns <stefan.bruens@...>
 

Valgrind (http://valgrind.org) is mostly licensed under GPL-2.0-or later, but
includes several permissively licensed header files for inclusion in arbitrary
client programs.

Proposed Full Name: Valgrind BSD-Style Client Header License
Short Identifier: Valgrind-BSD-Client-Header

The license is included in the following files:
https://sourceware.org/git/?p=valgrind.git;a=blob;f=include/valgrind.h
https://sourceware.org/git/?p=valgrind.git;a=blob;f=callgrind/callgrind.h
https://sourceware.org/git/?p=valgrind.git;a=blob;f=drd/drd.h
https://sourceware.org/git/?p=valgrind.git;a=blob;f=hellgrind/hellgrind.h
https://sourceware.org/git/?p=valgrind.git;a=blob;f=memcheck/memcheck.h

The actual license clauses are identical for all 5 files.

Full Text (valgrind.h):
----------------------------------------------------------------

Notice that the following BSD-style license applies to this one
file (valgrind.h) only. The rest of Valgrind is licensed under the
terms of the GNU General Public License, version 2, unless
otherwise indicated. See the COPYING file in the source
distribution for details.

----------------------------------------------------------------

This file is part of Valgrind, a dynamic binary instrumentation
framework.

Copyright (C) 2000-2017 Julian Seward. All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.

2. The origin of this software must not be misrepresented; you must
not claim that you wrote the original software. If you use this
software in a product, an acknowledgment in the product
documentation would be appreciated but is not required.

3. Altered source versions must be plainly marked as such, and must
not be misrepresented as being the original software.

4. The name of the author may not be used to endorse or promote
products derived from this software without specific prior written
permission.

THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS
OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

----------------------------------------------------------------

Kind regards,

Stefan

--
Stefan Brüns / Bergstraße 21 / 52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019

Re: [spdx-tech] matching guidelines updates

William Bartholomew <iamwillbar@...>
 

During the discussion about SPDX 3.0 and positioning SPDX as an option for the various SBoM efforts that are going on, one of the discussion points was about making the specification more digestible by moving content that is secondary to the format of an SPDX document out of the specification and into a separate document (or documents), this suggestion included the license list, license matching guidelines, and applying SPDX identifiers to source code.

There is a variety of content we could position beside the specification (best practices, sample scenarios and example documents, how to apply to source code, license matching) so I don't think we should be beholden to how it is laid out today and possible create a new section on the site that could house that information (which could be referenced from the specification where relevant). I'm happy to help out with the technical aspects of that but since I'm focusing on SPDX 3.0 for the moment I'd prefer to do it in the context of that if it's not urgent.


On Thu, Oct 17, 2019 at 7:41 AM J Lovejoy <opensource@...> wrote:
Thanks Mike - responses below!

On Oct 17, 2019, at 7:34 AM, Michael Dolan <mdolan@...> wrote:

My personal responses in-line below. I've not discussed this with Steve or anyone... (and I will openly admit I'm not as familiar with these parts are you all are).


On Wed, Oct 16, 2019 at 11:14 PM J Lovejoy <opensource@...> wrote:

1) what do we do with the webpage/URL and various places that link to such? redirect to the appendix in the spec? but then what happens when the spec updates?  (It’s really important for people to be able to easily read/find this).  Could we generate the webpage from the spec Appendix markup?

For specs that have subcomponents with faster moving sections, we have had other communities pull those out into separate GitHub .md file and the spec includes the current snapshot of that file at the time of the spec being approved and published as final. That way they have a record of the version at the time it was approved in the spec itself. But the .md file evolves at the pace it needs to.

Yes, I think this is how it has been set up in the PR - as it’s own Appendix and .md file, so one can refer to it separately there. I suppose we could change links to point to the Github .md, rather than the spec, that way it’s “standalone” - but I’m not familiar enough with how the spec is pushed and updated at the individual PR/file level, so could use Gary and Kate’s input here. 
 

2) does this then mean the matching guidelines must follow the cycles/versions of the spec? (it has had it’s own cycle because it doesn’t update very often)

Similar to my answer above, but is it possible to move the "current source" for the guidelines out into a separate .md file? 
yes, already done.
 

3) what about the list of equivalent words- can we have that live as a separate file in the license list Github repo and then have the main relevant matching guideline link to it? and if so, should that list live in the license list repo or with the spec?

Similar reaction as above.
I think the idea of having this list as a separate file is the easy part (apparently this makes it easier for tools to consume), but the question is: where should that file live?