Topics

Names of licenses we currently support / where should licensetext live?

Soeren_Rabenstein@...
 

Peter Williams wrote:
Once a license is "approved" and placed in the repo it should be
immutable. That way there is no chance of the text changing once the
license name is in use.
I agree.
Also: If an spdx document is supposed to contain all the license texts, isn't there a danger that we end up documenting 10 KB of source code with 1 MB of license texts? (Yes I know, if there one thing America needs it's more license texts: http://www.youtube.com/watch?v=0u9JAt6gFqM).

Imho the spdx list of standard licenses should cover as many licenses as possible (whereas coverage of x % of the licenses in a common Linux Distribution is not necessarily the standard of completeness, as spdx is not only for Linux) and their texts should be held in a repository.

The only concern I have is accountability for accuracy of the license repository.
*One possible* way to overcome this is, that we may specify what is a standard compliant spdx license text repository as well. Then there can be the default PURL repository (without warranty), but companies may also host their own repository, and include to their spdx files a pointer to that adress. (However if I say, this is a sdpx version x.y compliant repository, I may not represent LGPL 2.1 as LGPL 3.0 in there.)

Kind regards

Soeren Rabenstein

____________________________________________________________
 
ASUSTeK COMPUTER INC.
 
Soeren Rabenstein, LL.M.
Legal Affairs Center - Legal Compliance Dept.
15, Li-Te Rd., Taipei 112, Taiwan
Tel.: (+886) 2 2894 3447 Ext.2372
Fax.: (+886) 2 2890 7674
soeren_rabenstein@...
____________________________________________________________



=====================================================================================================================================
This email and any attachments to it contain confidential information and are intended solely for the use of the individual to whom it
is addressed.If you are not the intended recipient or receive it accidentally, please immediately notify the sender by e-mail and delete
the message and any attachments from your computer system, and destroy all hard copies. If any, please be advised that any unauthorized
disclosure, copying, distribution or any action taken or omitted in reliance on this, is illegal and prohibited. Furthermore, any views
or opinions expressed are solely those of the author and do not represent those of ASUSTeK. Thank you for your cooperation.
=====================================================================================================================================

Peter Williams <peter.williams@...>
 

On 8/29/10 8:07 PM, Soeren_Rabenstein@... wrote:

The only concern I have is accountability for accuracy of the license repository.
*One possible* way to overcome this is, that we may specify what is a standard compliant spdx license text repository as well. Then there can be the default PURL repository (without warranty), but companies may also host their own repository, and include to their spdx files a pointer to that adress. (However if I say, this is a sdpx version x.y compliant repository, I may not represent LGPL 2.1 as LGPL 3.0 in there.)
I can see some benefits to this approach. It will result in multiple URIs for the same logical license, though. This might cause some complications for certain classes of tools that consume SPDX. We could overcome this by requiring that licenses in private repos provide a isVersionOf[1] property whose value is the URI of the equivalent license in the standard SPDX repo.

It is not clear to me that many organizations would need, or want, to duplicate the main repo if it is maintained by an organization that can credibly assert that once licenses are approved they are never modified. However, supporting multiple repos is pretty easy.

Such functionality would also provide an organic way to grow the set of standardized licenses. Licenses would start in private repos. Over time the common ones would be approved into the main repo. Then private repos could be update to indicate they are versions of the standardized license.

Peter

[1]: http://dublincore.org/documents/dcmi-terms/#terms-isVersionOf