Goneall: /* Questions and Clarifications from Thomas */

2017-01-31T21:11:14Z

‎Questions and Clarifications from Thomas

Goneall: Created page with "Jan. 31, 2017 == Attendees == * Gary O’Neall * Yev Bronshteyn * Bill Schineller * Jack Manbeck * Thomas Steenbergen ==Topics== * SPDX Tools Jena version upgrade * Google Su..."

2017-01-31T21:10:14Z

Created page with "Jan. 31, 2017 == Attendees == * Gary O’Neall * Yev Bronshteyn * Bill Schineller * Jack Manbeck * Thomas Steenbergen ==Topics== * SPDX Tools Jena version upgrade * Google Su..."

New page

Jan. 31, 2017
== Attendees ==
* Gary O’Neall
* Yev Bronshteyn
* Bill Schineller
* Jack Manbeck
* Thomas Steenbergen

==Topics==
* SPDX Tools Jena version upgrade
* Google Summer of Code
* Questions from Thomas on SPDX Spec and implementation
==SPDX Tools Jena version upgrade==
* Yev submitted a pull request which upgrades the Jena version
* The upgrade has a dependency on Java 8
* Agreed to create a branch “Java6Support” prior to merging the pull request
* Gary to create the branch
* Yev will merge in the branch after verifying the Java version in the POM file
==Google Summer of Code==
* Applications need to be in by Jan. 9
* Submittal is nearly ready (just need to upload the logo)
* Need a second administrator
** Waiting for a response from Philippe
** Jack agreed to co-sponsor if we don’t hear back by Thursday
* Discussed project ideas
** Leverage ideas from last year at http://wiki.spdx.org/view/Technical_Team/Ideas_List
** Some of the same library migrations apply
** Should add Git integration, but the project may need to be broken up into sub-projects. We’ll have a meeting on the topic at the leadership summit
** We should add online tools as a project idea (Gary)
** Jack suggested an attribution document generator tool (Gary will add)
** Build integration projects such as Gradle (could leverage the Maven integration)
** Thomas had some build and package manager related projects that may be appropriate for GSoC (Thomas will follow up and add to the project list wiki)
==Questions and Clarifications from Thomas==
Q1: I am correct to say “#” is the comment statement in tag-value format and I use it after a tag statement

It is invalid is to put a comment statement in SPDX tag-value behind value. It has to be on a separate line.

Example:

LicenseConcluded: Apache-2.0 #INVALID

#VALID
LicenseConcluded: Apache-2.0

Q2: If a big source file has license texts at line 3, 400 and 600 do one put in in one FileNotice within SPDX-File or into multiple SPDX-Files?

Combining all license text in a FileNotice within a SPDX-File is OK if it’s all of the different licensed code always below to the package. If the license statements come from code copied from other packages one should use SPDX-Snippet

@HERE we use “…” as delimiter to indicate multiple lines are present in the file between license texts
Example:

FileNotice:<text>

BSD-3-Clause full license text

…

Happy bunny full license text
</text>

Q3: How would you encode within the SPDX-File’s FileNotice scanner line number findings?

Example:

FileNotice: <text>
{ BSD-3-Clause full license text} <= line 250 – 350
…
{GPL-2.0 full license text } <= line 942 - 980
</text>

Solutions:

1. Use a comment statement

# BSD-3-Clause lines 250 – 350, GPL-2.0 line 942 - 980
FileNotice: <text>
{ BSD-3-Clause full license text}
…
{ GPL-2.0 full license text}
…
</text>

2. Use LicenseComments

FileNotice: <text>
{ BSD-3-Clause full license text}
…
{ GPL-2.0 full license text}
…
</text>
LicenseComments: <text>BSD-3-Clause lines 250 – 350, GPL-2.0 line 942 - 980</text>
3. @Yev Introduce a new relationship within SPDX so we can capture this in a relation between SPDX-File and SPDX-Package

Q4: Which of the below statement is correct. I think B is correct per the spec.

Answer: B is correct but commonly tools will support/implement A. This is a bug in the tooling. @Thomas: Our experience is that most novice SPDX users think A is correct for simplicity reasons but form spec point of view B makes sense.

A)

LicenseConcluded: (LicenseRef-FSF-MIT AND GPL-2.0+ WITH Autoconf-exception-2.0)
LicenseInfoInFile: LicenseRef-FSF-MIT
LicenseInfoInFile: GPL-2.0+ WITH Autoconf-exception-2.0

Or

B)

LicenseConcluded: (LicenseRef-FSF-MIT AND GPL-2.0+ WITH Autoconf-exception-2.0)
LicenseInfoInFile: LicenseRef-FSF-MIT
LicenseInfoInFile: GPL-2.0+

Q5: Can one do custom license exceptions for LicenseRefs in SPDX?

Answer: Use LicenseRef e.g. LicenseRef-MIT-WITH-Happy-Bunny

Q6: What are your ideas on modeling package managers in SPDX?
The current way we do it is to create a SPDX-FILE on the pom.xml and then use ExternalDocumentRef and Relationship tags to link to separate SPDX files for each dependency. PackageLicenseConcluded are per package.

Answer: @Gary: This is how I am currently doing it. @Thomas to provide some example for Wiki for various languages. Contact Jack Manbeck to get Wiki access.

Q7: Is it Ok to use “cvs” within PackageDownloadLocation? e.g. Is it Ok to extend <vcs_tool> with other version control systems other than the ones listed in https://pip.pypa.io/en/latest/reference/pip_install.html#vcs-support?

Answer: @Gary: Yes this is the correct way. We should look into adding cvs to the spec. TODO: Follow-up with Bill
[[Category:Technical|Minutes]]
[[Category:Minutes]]

@@ Line 88: / Line 88: @@
 { GPL-2.0 full license text}
 …
-</text>
+</text>LicenseComments: <text>BSD-3-Clause lines 250 – 350, GPL-2.0 line 942 - 980</text>
-              LicenseComments: <text>BSD-3-Clause lines 250 – 350, GPL-2.0 line 942 - 980</text>
 .      @Yev Introduce a new relationship within SPDX so we can capture this in a relation between SPDX-File and SPDX-Package

Technical Team/Minutes/2017-01-31 - Revision history

Goneall: /* Questions and Clarifications from Thomas */

Goneall: Created page with "Jan. 31, 2017 == Attendees == * Gary O’Neall * Yev Bronshteyn * Bill Schineller * Jack Manbeck * Thomas Steenbergen ==Topics== * SPDX Tools Jena version upgrade * Google Su..."