On Thu, Sep 9, 2010 at 2:05 AM, <Soeren_Rabenstein@asus.com> wrote:
Dear All,I think for a version 1 this is a very acceptable outcome. The package
is described in a very simple way. We know it has 4 licenses, they are
and placed in a well defined "blurb". All a person (or more likely a
tool) needs to do is parse the 4 blurbs. That is addresses one of the
major problems of
Ninka and Fossology want to address: to find the license.
Sure the files will work on their own. But if I eventually want to update them all to the newest standard, I will end up in either a lot of mismatches, or in a lot of manual work; i.e. the very two things spdx shall avoid (in my understanding).The way I'd solve t is by allowing two types of license descriptor:
1. A text blurb that embeds the license (simple and straightforward)
2. A meta-license descriptor.
A meta license descriptor is a URI (any URI, not only spdx, but spdx
ones would be assumed to be widely known). The URI would indicate
information such as: type of license (reference or inclusion), any
variable parameters that need to be identified,
any potential variability (such as known variations in spelling or punctuation).
So we end with two standards:
1. Describing the licensing of the package (where a license is a URI
described by the license spec, it does not list _any_ specific
2. The one describing the licenses form (which describes the forms
that licenses take).
This way the standards do not change when a new license is added.
Finally, SPDX will publish a list of (accepted|approved|blessed|loved)
licenses, including their URI. But others will be allowed to published
their own URIs for licenses. This could be standard #3.
The license describer could rather look likeThis is not a variant of the license, it is a different license. IMO,
variants really the same license but have different text (diff would
yield different results, I.e. British vs American spelling).
Variants are usually by inclusion.