On Wed, Sep 13, 2017 at 11:07:52AM -0400, Richard Fontana wrote: > The other SPDX is the use of something that *superficially* looks > like SPDX-conformant license expressions to describe licensing in a > way that is, I guess, outside the intended scope of SPDX. Examples > of this nonconformant use of SPDX license expressions include > developers annotating the licensing of their own software as well as > distributors annotating the licensing of things they distribute.
That's officially supported by the spec with Appendix V (Using SPDX
short identifiers in Source Files [1], new in 2.1 [2]).
> In particular I would assert that these two uses of SPDX are
> fundamentally in conflict.
Can you go into more details about the conflict you see? License
expressions seem like they're designed to express the license of a
(possibly combined) work, including the declared license of a package
[3] or file [4]. Both of those fields take license-expression values,
with additional ‘NONE’ and ‘NOASSERTION’. That sounds like the exact
same use case to me as the SPDX-License-Identifier use case (which
also takes license-expression values [1]), with the differnce being
that an SPDX-License-Identifier entry in the file is the file author
declaring the license, and the PackageLicenseDeclared and
LicenseInfoInFile entries in an external SPDX file may have been
written by someone else. But in both cases, they're trying to express
a declared license for the file. The npm package.json license field
[5] is just like SPDX-License-Identifier, except it's the author
declaring a package-level license. All of these use cases need a
compact, machine-readable way to express the license of a work, and
license expressions seem like a good fit for all of them to me.
There is the difficulty that outside of an SPDX file, there's no way
to define custom licenses (LicenseRef-*). For most projects, the
licenses and exceptions they need are already in the SPDX license
list, so they don't need that functionality. For projects who need a
license that's not in the SPDX list in a license-expression-only
context, submitting the license for SPDX inclusion is fairly
straightforward. The only issue with submission is that sometimes the
license is rejected (although I don't have a link I can cite for this)
and sometimes it is judged sufficiently similar with an existing
license (e.g. “and” vs. “and/or” in ISC-ish licenses [6,7]). But
that's not an insurmountable problem. We can always add a:
LicenseURI "${URI}"
operator to license expressions that supports RFC 3986 URIs [8] to
provide folks with a way to reference not-in-the-SPDX-list licenses
(with a similar ExceptionURI for exceptions?).
You're obviously not going to have all the expressive power of a full
SPDX file in the license expression, but if all you're aiming for is
declaring a license, I don't see why you would need more structure
than license expressions.
Cheers,
Trevor
[1]: https://spdx.org/spdx-specification-21-web-version#h.twlc0ztnng3b
[2]: https://spdx.org/spdx-specification-21-web-version#h.1sh8jn1fc5zw
[3]: https://spdx.org/spdx-specification-21-web-version#h.1hmsyys
[4]: https://spdx.org/spdx-specification-21-web-version#h.111kx3o
[5]: https://docs.npmjs.com/files/package.json#license
[6]: https://lists.spdx.org/pipermail/spdx-legal/2015-April/001398.html
Subject: New License/Exception Request
Date: Thu Apr 30 17:56:52 UTC 2015
[7]:
https://github.com/spdx/license-list-XML/pull/423/commits/233ae572d9e30cf48bd4c887e9c069626e76a93b
[8]: https://tools.ietf.org/html/rfc3986
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
