Hi Robin,
Got a chance to read through the document. Thanks for clearly laying out the issues with representing aggregated projects in SPDX - I think this is a good problem to solve for the general community and once we're done, I would like to include this in the SPDX best practices document (minus the DoSOCS specifics) if that is OK with you. A couple high level points and feedback: · In general, I agree with the approach. · For Maven, you can map the Maven dependency scope to the SPDX relationship type. You can see what I chose as mapping in the Java method scopeToRelationshipType in the SpdxDependencyInformation.java <https://github.com/goneall/spdx-maven-plugin/blob/master/src/main/java/org/spdx/maven/SpdxDependencyInformation.java> file. If you see anything you disagree with - do me a favor and log an issue in the Git repository. · I would only use PACKAGE_OF if the included package is compiled in source as a sub-project (e.g. a subdirectory) or if it is a complete independent package being distributed as part of a larger distribution. In a Maven POM file, they are likely dymaically linked dependencies. From the PDF document, I wasn't sure of the specifics on the example - but they kind of looked liked dynamically linked dependencies. · Definition of Package, Application and Project - Here's the definition of a package from the RDF terms: " A Package represents a collection of software files that are delivered as a single functional component. " Would this definition apply to Project (e.g. the "files" would be the metadata files)? We should consider adding this definition to the PDF specification to be consistent (or re-discussing the definition if any disagrees with the RDF definition). I think it would be useful to define certain types of packages for the use in best practices (e.g. simple packages containing only source files, complex packages including dependency specifications, project packages which only contain metadata files, etc.). Gary From: [email protected] [mailto:[email protected]] On Behalf Of Robin Gandhi Sent: Sunday, March 20, 2016 7:35 PM To: [email protected] Subject: Representing Projects Using SPDX 2.0 Hello all, In our work with a industry partner at the University of Nebraska-Omaha, a request that has come up often is related to project-level visibility of license information. While project-level information can be managed separately from SPDX, there is value in maintaining the project-level information in a manner similar to the individual project components. However, from a tooling perspective, the project-level view is different from the typical “one-shot” SPDX document generation for a directory or compressed files. After examining the possibilities with the SPDX 2.0 spec, we have come-up with a proposal to handle project-level information in DoSOCSV2 implementation. Please see the attached document. Any and all feedback is welcome in helping us “figure” this out. Especially, if our interpretation and usage of the SPDX spec is appropriate. We also had some early discussions with Kate regarding this. Best Regards, Robin and the UNO DoSOCSv2 team (Matt, Uday and Josiah)
_______________________________________________ Spdx mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx
