Hi David,
Just wondering if putting out a tag:value SPDX file at the top level
suffice?
Both tag:value and RDF/XML are supported formats, and care has been taken
so that
translation between the two (and spreadsheets) is possible.
For example, Windriver's tools emit tag:value SPDX files for their
scans.
As an example (from the bakeoff last summer) time-1.7's information is:
<snip>
##-------------------------
## Package Information
##-------------------------
PackageName: time-1.7.tar.gz
PackageFileName: time-1.7.tar.gz
PackageDownloadLocation: NOASSERTION
PackageVerificationCode: dd5cf0b17bfef4284c6c22471b277de7beac407c
PackageChecksum: SHA1: dde0c28c7426960736933f3e763320680356cc6a
PackageLicenseConcluded: GPL-2.0+
PackageLicenseDeclared: GPL-2.0+
PackageLicenseInfoFromFiles: FSFULLR
PackageLicenseInfoFromFiles: GPL-2.0
PackageLicenseInfoFromFiles: GPL-2.0+
PackageLicenseInfoFromFiles: MIT
PackageCopyrightText: NOASSERTION
<snip>
The nice thing about putting out the full tag:value version is that you can
check if
something has changed out from under you., but its still nicely grep'able.
ie.
grep "PackageLicenseConcluded"
Kate
On Fri, Nov 20, 2015 at 4:52 PM, Wheeler, David A <[email protected]> wrote:
> I propose a convention that builds on the SPDX-2.0 specification, the
> "SPDX-LICENSE" file.
>
> Users of this convention would include a file named "SPDX-LICENSE" (all
> upper case) at the top-level of a software project (typically an open
> source software project). This file would ONLY contain a SPDX license
> expression, and is to be interpreted as an assertion by the project
> developers that "the software in this project is released under the terms
> of this SPDX license expression". Basically, this is like a "LICENSE" file
> (a current convention), but it's designed to be both machine-processable
> and human-readable. This is especially important in multi-license
> situations (it's not obvious if things are "AND" or "OR"), or in licenses
> where 'or later' text is common. The SPDX license expression would comply
> with the current SPDX specification and license list as it existed at the
> time this SPDX-LICENSE file was created or modified (modern version control
> systems can trivially tell you when that was).
>
> This convention obviously can't do everything the full SPDX 2.0 XML
> specification can do; if you need that, run to the full spec, currently at <
> https://spdx.org/SPDX-specifications/spdx-version-2.0>.
>
> However, many people just need a simple way to express their intent and to
> read others' intent. If all you want to do is state that you're releasing
> some OSS under "GPL-2.0+" or "(MIT OR CC-BY-4.0)", creating an XML file
> should not be necessary. A simple non-XML convention that supports simple
> cases would be a big plus for everyone, especially if it works the same way
> regardless of language or packaging system. Currently, tools have to
> figure out a number of different package formats, and grovel through
> natural language, to try to figure out the license. Let's make it SIMPLE.
> Even if you're building a more complex tool, having this additional
> information in at least some cases could be a real boon.
>
> --- David A. Wheeler
>
> _______________________________________________
> Spdx-tech mailing list
> [email protected]
> https://lists.spdx.org/mailman/listinfo/spdx-tech
>
_______________________________________________
Spdx-tech mailing list
[email protected]
https://lists.spdx.org/mailman/listinfo/spdx-tech
