As I was going through the best practices for indicating external dependencies, I realized that there doesn’t seem to be one for dependencies that are known at the package level rather than the file level. A component developer trying to make an SPDX document for his offering has three methods available for defining external dependencies:
* The artifactOf property on a File. However, this property is file-specific and does not effectively communicate the dependency on a package level. Must a component developer go through each file in his/her project and indicate which external projects it relates to? The artifactOf also does not communicate the exact relationship of a file to the external entity. Is a file a part of the target project? Generated by/from the target project? Something else? * A relationship to the SPDX document describing the target entity. This is the suggested alternative to artifactOf property where the target project has an available SPDX document. However, as most open-source components available today do not have published SPDX documents, the developer appears forced to create and publish his own document for each component the project depends on. This does not appear to be appropriate. * The current package entity seems best suited for describing a dependency, offering supplier, download location, homepage, license information, etc. Additionally, the package can already have an optional “described by” relationship to an external SPDX document if such document exists, while still providing meaningful information when it doesn’t. The problem with this approach is that the current spec mandates that a package have a “package verification code”. If each component developer produces his own verification code for each external package, his choice of excluded or included files may not agree with that of another developer(source vs. built artifacts, including vs. not including dependencies, etc), thus yielding verification codes that don’t verify anything. So instead, I propose adding an ExternalPackage entity. An ExternalPackage would contain only the subset of the Package attributes that describe the source and origin of the package. Specifically * description * downloadLocation * homepage * licenseDeclared * originator * packageFilename * checksum (of the downloaded package file) * supplier * versionInfo * external system identifiers (if implemented per Bill Schineller’s suggestion at http://wiki.spdx.org/view/Technical_Team/Minutes/2015-05-15#External_.2F_Package_Management_systems_identifiers). If an SPDX document describing the package is available, it can be referenced via the “described by” relationship. I’ve documented this proposal on Bugzilla at https://bugs.linuxfoundation.org/show_bug.cgi?id=1298. I will put it on the wiki as soon as I have access to it. :-) Thanks. [cid:7EA68D51-363B-4FAD-A939-D9CD926D70AB] Yev Bronshteyn Senior Software Engineer Black Duck Software Black Duck Software<http://www.blackducksoftware.com/> | OpenHUB<https://www.openhub.net/> | OSDelivers<http://osdelivers.blackducksoftware.com/> | OSS Logistics<https://www.blackducksoftware.com/oss-logistics> [cid:E33E6B21-2C3E-4C55-8796-46161EE14AC6] <http://twitter.com/black_duck_sw> [cid:EDB9C095-85D8-437C-A4CF-A515712839CA] <https://www.linkedin.com/company/black-duck-software> [cid:8D343C4D-B65C-473A-96DE-792AF2B5D16E] <https://www.facebook.com/BlackDuckSoftware> [cid:3FCDCA9B-C8EA-4EB2-9184-457FF1A9AB5D] <https://plus.google.com/+Blackducksoftware/> [cid:D1E6BBB6-3622-496C-B3BF-7DC86A214CB8] <http://www.slideshare.net/blackducksoftware> [cid:B8FD9DF1-3230-44BF-80DA-AEA16CB00E29] JP Morgan Chase & Co. Hall of Innovation Inductee <https://www.youtube.com/user/BlackDuckSoftware> <https://www.youtube.com/user/BlackDuckSoftware>
_______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
