Re: SPDX Agenda/Minutes


hi Soeren

On Thu, Sep 9, 2010 at 2:05 AM, <Soeren_Rabenstein@...> wrote:
Dear All,

By uncoupling licenses and standard, I see a high risk, that we end up in many different quasi-sub-standards of spdx.

As in the example, what if several users of the license C and D give different license name tags to them, before they eventually get adopted by the license list?

One Spdx file says
1. Standard      | License A
2. Standard      | License B
3. Custom        | License C (attached license text x)
4. Custom        | License D (attached license text y)

Another one, describing the same package, says
1. Standard      | License A
2. Standard      | License B
3. Custom        | License 3 (attached license text x)
4. Custom        | License 4 (attached license text y)

And another spdx file, describing a DIFFERENT package says
1. Standard      | License A
2. Standard      | License B
3. Custom        | License C (attached license text z)
4. Custom        | License D (attached whatever)
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
all extracted
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 like

DeclaredLicense = GPLv2
LicenseVariation = yes
VariationContents =
++ As a special exception, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other works to produce a work based on this file, this file does not by itself cause the resulting work to be covered by the GNU General Public License.
++ However the source code for this file must still be made available in accordance with section (3) of the GNU General Public License.
++ This exception does not invalidate any other reasons why a work based on this file might be covered by the GNU General Public License.
This 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.


Join to automatically receive all group messages.