Date
1 - 3 of 3
Spdx Digest, Vol 1, Issue 16
Jilayne Lovejoy <Jlovejoy@...>
Hello,
I'm new to the mailing list so forgive me if any of my
questions/observations are redundant or minimally informed.
I had a couple thoughts regarding various posts and the license list
included in Issue 14.
1) I noticed the license list included some of the GPL exceptions such
as Autoconf and Bison. My understanding is that the text for these
exceptions would be the exception itself (not the full license) and so
there would need to be a way to pair the exception with the proper GPL
version in such a way that is distinct from dual and disjunctive
licensing situations. Otherwise, we would need to list each GPL version
with each exception as separate and whole licenses.
2) I noticed the license list included in the mailing list is more
comprehensive than the one on the website - am I correct to assume this
is only because the website has not been updated? Regardless, I'd be
happy to help sort through the BSD and MIT licenses once the text is
available.
3) Regarding the BSD and Apache 1.1 licenses in particular - both of
these incorporate the name of the author within the license text. This
is especially difficult in Apache 1.1 as it affects the third, fourth,
and fifth clauses. Where the license text is otherwise verbatim, do we
have a way to handle this in terms of how the standard license will
appear in the master list, as well as some sort of protocol for how
"exact" a license must be to be matched to the standard version?
4) Agree with Peter that the CeCILL licenses should be on the list,
which then begs the question of how to deal with a license that is
available in multiple languages (EUPL also comes to mind)?
Cheers,
Jilayne Lovejoy | Corporate Counsel
jlovejoy@...
720 240 4545 | phone
720 240 4556 | fax
1 888 OpenLogic | toll free
www.openlogic.com
OpenLogic, Inc.
Headquarters, Broomfield, Colorado 80021
toggle quoted message
Show quoted text
I'm new to the mailing list so forgive me if any of my
questions/observations are redundant or minimally informed.
I had a couple thoughts regarding various posts and the license list
included in Issue 14.
1) I noticed the license list included some of the GPL exceptions such
as Autoconf and Bison. My understanding is that the text for these
exceptions would be the exception itself (not the full license) and so
there would need to be a way to pair the exception with the proper GPL
version in such a way that is distinct from dual and disjunctive
licensing situations. Otherwise, we would need to list each GPL version
with each exception as separate and whole licenses.
2) I noticed the license list included in the mailing list is more
comprehensive than the one on the website - am I correct to assume this
is only because the website has not been updated? Regardless, I'd be
happy to help sort through the BSD and MIT licenses once the text is
available.
3) Regarding the BSD and Apache 1.1 licenses in particular - both of
these incorporate the name of the author within the license text. This
is especially difficult in Apache 1.1 as it affects the third, fourth,
and fifth clauses. Where the license text is otherwise verbatim, do we
have a way to handle this in terms of how the standard license will
appear in the master list, as well as some sort of protocol for how
"exact" a license must be to be matched to the standard version?
4) Agree with Peter that the CeCILL licenses should be on the list,
which then begs the question of how to deal with a license that is
available in multiple languages (EUPL also comes to mind)?
Cheers,
Jilayne Lovejoy | Corporate Counsel
jlovejoy@...
720 240 4545 | phone
720 240 4556 | fax
1 888 OpenLogic | toll free
www.openlogic.com
OpenLogic, Inc.
Headquarters, Broomfield, Colorado 80021
-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...]
On Behalf Of spdx-request@...
Sent: Monday, August 30, 2010 12:00 PM
To: spdx@...
Subject: Spdx Digest, Vol 1, Issue 16
Send Spdx mailing list submissions to
spdx@...
To subscribe or unsubscribe via the World Wide Web, visit
https://fossbazaar.org/mailman/listinfo/spdx
or, via email, send a message with subject or body 'help' to
spdx-request@...
You can reach the person managing the list at
spdx-owner@...
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Spdx digest..."
Today's Topics:
1. RE: Names of licenses we currently support / where should
licensetext live? (Soeren_Rabenstein@...)
2. Some feedback I've received on the latest draft (Ciaran Farrell)
3. CeCILL licences (Patrick MOREAU)
4. Re: Names of licenses we currently support / where should
licensetext live? (Peter Williams)
----------------------------------------------------------------------
Message: 1
Date: Mon, 30 Aug 2010 10:07:49 +0800
From: <Soeren_Rabenstein@...>
Subject: RE: Names of licenses we currently support / where should
licensetext live?
To: <spdx@...>
Message-ID:
<BD0D39FA6F74634D856A51ADCC26F9452D95C7@...>
Content-Type: text/plain; charset="iso-8859-1"
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.
========================================================================
=============================================================
------------------------------
Message: 2
Date: Mon, 30 Aug 2010 09:25:28 +0200
From: Ciaran Farrell <cfarrell@...>
Subject: Some feedback I've received on the latest draft
To: spdx@...
Message-ID: <201008300925.28406.cfarrell@...>
Content-Type: text/plain; charset="utf-8"
Hi,
here is some feedback I received recently - I'm not sure how much of it
is
(still) relevant.
Ciaran
========================================================================
======
Page 4: 1.1 typo? "to share + and component"
Page 7: 2.2.7 stray capitalization? LicenseFInd
Page 14: 4.1.3 and 4.2.3 cardinality mandatory single instance
This seems incorrect, as the nonstandard license field is optional and
needed
only in case a nonstandard license is present.
"Should be present if" cannot map to "cardinality mandatory" in the
common use
of the term mandatory, which implies always, without if ands or buts.
Page 16: section 5
Cardinality mandatory is again used here, but the file list is not
present in
the tomcat examples on the site (nor, in my opinion, should be -- making
the
file list mandatory means making supplying these descriptions needlessly
harder. DOAP does not include mandatory file lists and it is the better
for
it, so neither should SPDX).
========================================================================
======
--
Ciaran Farrell __o
cfarrell@... _`\<,_
Phone: +49 (0)911 74053 262 (_)/ (_)
SUSE Linux Products GmbH,
GF: Markus Rex, HRB 16746 (AG N?rnberg)
Maxfeldstrasse 5, 90409, Nuremberg, Germany
/?ki?.r?n/
------------------------------
Message: 3
Date: Mon, 30 Aug 2010 14:53:38 +0200
From: Patrick MOREAU <Patrick.MOREAU@...>
Subject: CeCILL licences
To: "spdx@..." <spdx@...>
Message-ID:
<2F9743F08B7C8141BD6CB648C4304F1F44AAC42C05@...>
Content-Type: text/plain; charset="iso-8859-1"
Bonjour
I work in INRIA since 2009 and I follow all the exchanges about SPDX
specification.
I have read the V1.0 beta draft. This document seems very complete. I
have just one comment. We would like to mention also CeCILL licences
(http://www.cecill.info/licences.fr.html) that are used, at least, in
France.
I propose:
CeCILL-1.0
1.1. Formal Name: Ce(A)C(nrs)I(NRIA)L(ogiciel)L(ibre) V1
1.2. Official Download URL: http://www.cecill.info/licences.fr.html
1.3. SPDX Template Reference Copy: TBD
CeCILL-2.0
1.1. Formal Name: Ce(A)C(nrs)I(NRIA)L(ogiciel)L(ibre) V2
1.2. Official Download URL: http://www.cecill.info/licences.fr.html
1.3. SPDX Template Reference Copy: TBD
CeCILL-B-1.0
1.1. Formal Name: Ce(A)C(nrs)I(NRIA)L(ogiciel)L(ibre)-B
1.2. Official Download URL: http://www.cecill.info/licences.fr.html
1.3. SPDX Template Reference Copy: TBD
CeCILL-C-1.0
1.1. Formal Name: Ce(A)C(nrs)I(NRIA)L(ogiciel)L(ibre)-C
1.2. Official Download URL: http://www.cecill.info/licences.fr.html
1.3. SPDX Template Reference Copy: TBD
Best regards
Patrick
_________________________________________
Patrick Moreau
INRIA
Technology Transfer and Innovation Department
Software Assets Manager
Domaine de Voluceau - Rocquencourt
B.P. 105 - 78153 Le Chesnay Cedex
T?l: +33 1 39 63 78 40
Mob.: +33 6 77 84 58 15
Fax: +33 1 39 63 51 14
E-mail: patrick.moreau@...
------------------------------
Message: 4
Date: Mon, 30 Aug 2010 10:31:26 -0600
From: Peter Williams <peter.williams@...>
Subject: Re: Names of licenses we currently support / where should
licensetext live?
To: spdx@...
Message-ID: <4C7BDCDE.6060602@...>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 8/29/10 8:07 PM, Soeren_Rabenstein@... wrote:
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
------------------------------
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
End of Spdx Digest, Vol 1, Issue 16
***********************************
From: spdx-bounces@... [mailto:spdx-bounces@...]
On Behalf Of spdx-request@...
Sent: Monday, August 30, 2010 12:00 PM
To: spdx@...
Subject: Spdx Digest, Vol 1, Issue 16
Send Spdx mailing list submissions to
spdx@...
To subscribe or unsubscribe via the World Wide Web, visit
https://fossbazaar.org/mailman/listinfo/spdx
or, via email, send a message with subject or body 'help' to
spdx-request@...
You can reach the person managing the list at
spdx-owner@...
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Spdx digest..."
Today's Topics:
1. RE: Names of licenses we currently support / where should
licensetext live? (Soeren_Rabenstein@...)
2. Some feedback I've received on the latest draft (Ciaran Farrell)
3. CeCILL licences (Patrick MOREAU)
4. Re: Names of licenses we currently support / where should
licensetext live? (Peter Williams)
----------------------------------------------------------------------
Message: 1
Date: Mon, 30 Aug 2010 10:07:49 +0800
From: <Soeren_Rabenstein@...>
Subject: RE: Names of licenses we currently support / where should
licensetext live?
To: <spdx@...>
Message-ID:
<BD0D39FA6F74634D856A51ADCC26F9452D95C7@...>
Content-Type: text/plain; charset="iso-8859-1"
Peter Williams wrote:I agree.
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.
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.
========================================================================
=============================================================
------------------------------
Message: 2
Date: Mon, 30 Aug 2010 09:25:28 +0200
From: Ciaran Farrell <cfarrell@...>
Subject: Some feedback I've received on the latest draft
To: spdx@...
Message-ID: <201008300925.28406.cfarrell@...>
Content-Type: text/plain; charset="utf-8"
Hi,
here is some feedback I received recently - I'm not sure how much of it
is
(still) relevant.
Ciaran
========================================================================
======
Page 4: 1.1 typo? "to share + and component"
Page 7: 2.2.7 stray capitalization? LicenseFInd
Page 14: 4.1.3 and 4.2.3 cardinality mandatory single instance
This seems incorrect, as the nonstandard license field is optional and
needed
only in case a nonstandard license is present.
"Should be present if" cannot map to "cardinality mandatory" in the
common use
of the term mandatory, which implies always, without if ands or buts.
Page 16: section 5
Cardinality mandatory is again used here, but the file list is not
present in
the tomcat examples on the site (nor, in my opinion, should be -- making
the
file list mandatory means making supplying these descriptions needlessly
harder. DOAP does not include mandatory file lists and it is the better
for
it, so neither should SPDX).
========================================================================
======
--
Ciaran Farrell __o
cfarrell@... _`\<,_
Phone: +49 (0)911 74053 262 (_)/ (_)
SUSE Linux Products GmbH,
GF: Markus Rex, HRB 16746 (AG N?rnberg)
Maxfeldstrasse 5, 90409, Nuremberg, Germany
/?ki?.r?n/
------------------------------
Message: 3
Date: Mon, 30 Aug 2010 14:53:38 +0200
From: Patrick MOREAU <Patrick.MOREAU@...>
Subject: CeCILL licences
To: "spdx@..." <spdx@...>
Message-ID:
<2F9743F08B7C8141BD6CB648C4304F1F44AAC42C05@...>
Content-Type: text/plain; charset="iso-8859-1"
Bonjour
I work in INRIA since 2009 and I follow all the exchanges about SPDX
specification.
I have read the V1.0 beta draft. This document seems very complete. I
have just one comment. We would like to mention also CeCILL licences
(http://www.cecill.info/licences.fr.html) that are used, at least, in
France.
I propose:
CeCILL-1.0
1.1. Formal Name: Ce(A)C(nrs)I(NRIA)L(ogiciel)L(ibre) V1
1.2. Official Download URL: http://www.cecill.info/licences.fr.html
1.3. SPDX Template Reference Copy: TBD
CeCILL-2.0
1.1. Formal Name: Ce(A)C(nrs)I(NRIA)L(ogiciel)L(ibre) V2
1.2. Official Download URL: http://www.cecill.info/licences.fr.html
1.3. SPDX Template Reference Copy: TBD
CeCILL-B-1.0
1.1. Formal Name: Ce(A)C(nrs)I(NRIA)L(ogiciel)L(ibre)-B
1.2. Official Download URL: http://www.cecill.info/licences.fr.html
1.3. SPDX Template Reference Copy: TBD
CeCILL-C-1.0
1.1. Formal Name: Ce(A)C(nrs)I(NRIA)L(ogiciel)L(ibre)-C
1.2. Official Download URL: http://www.cecill.info/licences.fr.html
1.3. SPDX Template Reference Copy: TBD
Best regards
Patrick
_________________________________________
Patrick Moreau
INRIA
Technology Transfer and Innovation Department
Software Assets Manager
Domaine de Voluceau - Rocquencourt
B.P. 105 - 78153 Le Chesnay Cedex
T?l: +33 1 39 63 78 40
Mob.: +33 6 77 84 58 15
Fax: +33 1 39 63 51 14
E-mail: patrick.moreau@...
------------------------------
Message: 4
Date: Mon, 30 Aug 2010 10:31:26 -0600
From: Peter Williams <peter.williams@...>
Subject: Re: Names of licenses we currently support / where should
licensetext live?
To: spdx@...
Message-ID: <4C7BDCDE.6060602@...>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 8/29/10 8:07 PM, Soeren_Rabenstein@... wrote:
repository.
The only concern I have is accountability for accuracy of the license
*One possible* way to overcome this is, that we may specify what is astandard 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
------------------------------
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
End of Spdx Digest, Vol 1, Issue 16
***********************************
kate.stewart@...
Hi Jilayne,
Welcome. :)
--- On Mon, 8/30/10, Jilayne Lovejoy <Jlovejoy@...> wrote:
Maybe suffix to determine language used? not sure... how common are the non-english licenses in practice?
Thanks, Kate
Welcome. :)
--- On Mon, 8/30/10, Jilayne Lovejoy <Jlovejoy@...> wrote:
From: Jilayne Lovejoy <Jlovejoy@...>
Subject: RE: Spdx Digest, Vol 1, Issue 16
To: spdx@...
Date: Monday, August 30, 2010, 1:50 PM
1) I noticed the license list included some of the GPLText for each exception, should include exception and original licenses.
exceptions such
as Autoconf and Bison. My understanding is that the
text for these
exceptions would be the exception itself (not the full
license) and so
there would need to be a way to pair the exception with the
proper GPL
version in such a way that is distinct from dual and
disjunctive
licensing situations. Otherwise, we would need to
list each GPL version
with each exception as separate and whole licenses.
2) I noticed the license list included in the mailingWeb site is behind on being updated. What is most accurate right now is the spec document at http://www.spdx.org/spec/current. Its behind some of the proposals on the mail list. So if you could help sort out the BSD and MIT licenses that should be proposed to be added, it would be very much appreciated.
list is more
comprehensive than the one on the website - am I correct to
assume this
is only because the website has not been updated?
Regardless, I'd be
happy to help sort through the BSD and MIT licenses once
the text is
available.
To address this, we have been discussing the notion of a template version of the license, but haven't gotten around to figuring out the syntax of the parts that can vary and still comply. If you've got ideas here, feel free to propose to list, Daniel G. and Bob G. have been commenting on this as well.
3) Regarding the BSD and Apache 1.1 licenses in particular
- both of
these incorporate the name of the author within the license
text. This
is especially difficult in Apache 1.1 as it affects the
third, fourth,
and fifth clauses. Where the license text is
otherwise verbatim, do we
have a way to handle this in terms of how the standard
license will
appear in the master list, as well as some sort of protocol
for how
"exact" a license must be to be matched to the standard
version?
4) Agree with Peter that the CeCILL licenses should be onre: EUPL... good question. Ideas are welcome. Probably need to treat each language version as separate version to be explicitly recognized.
the list,
which then begs the question of how to deal with a license
that is
available in multiple languages (EUPL also comes to mind)?
Maybe suffix to determine language used? not sure... how common are the non-english licenses in practice?
Thanks, Kate
Soeren_Rabenstein@...
Provided that we still go with the license text repository, what about something like a "diff"-standard for exceptions and variations of the standard licenses? (i.e. a standardized syntax describing lines to add to / delete from the original license text)1) I noticed the license list included some of the GPLText for each exception, should include exception and original licenses.
exceptions such
as Autoconf and Bison. My understanding is that the
text for these
exceptions would be the exception itself (not the full
license) and so
there would need to be a way to pair the exception with the
proper GPL
version in such a way that is distinct from dual and
disjunctive
licensing situations. Otherwise, we would need to
list each GPL version
with each exception as separate and whole licenses.
BR
Soeren
=====================================================================================================================================
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.
=====================================================================================================================================