1. spdx@lists.spdx.org
  2. Messages
   Date   
CeCILL licences

Patrick MOREAU
 

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@...

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

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

Re: 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

-----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"


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.
========================================================================
=============================================================



------------------------------

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:

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


------------------------------

_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx


End of Spdx Digest, Vol 1, Issue 16
***********************************

Re: Spdx Digest, Vol 1, Issue 16

kate.stewart@...
 

Hi Jilayne,
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 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. 
Text for each exception, should include exception and original 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.
Web 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.


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?
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.

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)?
re: EUPL... good question. Ideas are welcome. Probably need to treat each language version as separate version to be explicitly recognized.
Maybe suffix to determine language used? not sure... how common are the non-english licenses in practice?

Thanks, Kate

Re: Names of licenses we currently support / where should license text live?

dmg
 

Peter> Once a license is "approved" and placed in the repo it should be
Peter> immutable. That way there is no chance of the text changing once the
Peter> license name is in use.

Perhaps this is a good reason to go minimalistic in the very first
version (perhaps even not include ANY license at all). As people use the
draft it will become more clear what are the challenges of including
licenses in the standard, and potential pitfalls.

After all, if the license is not spdx-named, then it will have to be
included verbatim in the XML doc, which is not a bad thing. It can be
pragmatically upgraded once SPDX decides what licenses to include.

--dmg

--
Daniel M. German
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

Re: Names of licenses we currently support / where should license text live?

RUFFIN MICHEL
 

The problem is that except for licenses like GPL or Apache2 a lot of licenses MIT, BSD, Apache1.1 contain a part which is different from one license to another (such as the copyright and for old BSD the acknowledgement). And most licenses contain the obligation to propagate the copyright/license. So if you do not keep a copy of such license, the day you want to properly package your product with hundreds of open sources, you have again to do the job to look for most licenses.

Michel
Michel.Ruffin@..., PhD
Software Coordination Manager, Bell Labs, Corporate CTO Dpt
Distinguished Member of Technical Staff
Tel +33 (0) 1 3077 7045
Alcatel-Lucent HQ, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France

-----Message d'origine-----
De : spdx-bounces@... [mailto:spdx-bounces@...] De la part de D M German
Envoyé : mardi 31 août 2010 07:45
À : spdx@...
Objet : Re: Names of licenses we currently support / where should license text live?



Peter> Once a license is "approved" and placed in the repo it should be
Peter> immutable. That way there is no chance of the text changing once the
Peter> license name is in use.

Perhaps this is a good reason to go minimalistic in the very first
version (perhaps even not include ANY license at all). As people use the
draft it will become more clear what are the challenges of including
licenses in the standard, and potential pitfalls.

After all, if the license is not spdx-named, then it will have to be
included verbatim in the XML doc, which is not a bad thing. It can be
pragmatically upgraded once SPDX decides what licenses to include.

--dmg

--
Daniel M. German
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx

Re: fossbazaar wiki and LinuxCon followup

Martin Michlmayr
 

* Tom spot Callaway <tcallawa@...> [2010-08-24 21:26]:
Drupal is a great CMS, but it is not such a great wiki.
Sure, I'd agree with that. The Drupal wiki functionality has been
enough for our needs so far but MediaWiki (or another proper wiki) is
definitely more powerful.

I've installed MediaWiki on spdx.org now so you can play around with
it there. If we decide this is the way to go, we can point
spdx.org/wiki to it. I've installed the AuthDrupal extension so you
can log into the MediaWiki with your spdx.org account.

http://spdx.org/mediawiki/

--
Martin Michlmayr
Open Source Program Office, Hewlett-Packard

Re: fossbazaar wiki and LinuxCon followup

Tom "spot" Callaway
 

On 08/31/2010 08:53 AM, Martin Michlmayr wrote:
* Tom spot Callaway <tcallawa@...> [2010-08-24 21:26]:
Drupal is a great CMS, but it is not such a great wiki.
Sure, I'd agree with that. The Drupal wiki functionality has been
enough for our needs so far but MediaWiki (or another proper wiki) is
definitely more powerful.

I've installed MediaWiki on spdx.org now so you can play around with
it there. If we decide this is the way to go, we can point
spdx.org/wiki to it. I've installed the AuthDrupal extension so you
can log into the MediaWiki with your spdx.org account.

http://spdx.org/mediawiki/
This is fantastic, thanks Martin! I'll bring the content from Fedora
over to the spdx.org site this week.

Apologies for missing last Thursday's meeting (Thursdays are... busy for
me). Was there any feedback on the mockups I did?

~tom

Re: Names of licenses we currently support / where should license text live?

dmg
 

RUFFIN> The problem is that except for licenses like GPL or Apache2 a
RUFFIN> lot of licenses MIT, BSD, Apache1.1 contain a part which is
RUFFIN> different from one license to another (such as the copyright
RUFFIN> and for old BSD the acknowledgement). And most licenses
RUFFIN> contain the obligation to propagate the copyright/license. So
RUFFIN> if you do not keep a copy of such license, the day you want to
RUFFIN> properly package your product with hundreds of open sources,
RUFFIN> you have again to do the job to look for most licenses.

The license would be embedded in the SPDX file. In fact, you will have
all different licenses in a single place (the SPDX file) for every
project. No need to go back to the source, if it hasn't changed.

Next versions of the SPDX will allow you to extract the licenses from
the SPDX and name them.


By the way, Ninka is not bad at extracting this data. Here are two
examples This is a nice one:

* Copyright (c) 2001 Marko Kreen
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.

that results into:

AllRights,0,Copyright (c) 2001 Marko Kreen ,,
BSDpre,70,,<colon>
BSDcondSource,70,,,above ,,
BSDcondBinary,70,,,,
BSDasIs,10,,,THE AUTHOR AND CONTRIBUTORS ,,A,
BSDWarr,70,,,THE AUTHOR OR CONTRIBUTORS,

----------------------------------------------------------------------
And this one is more complicated:


* Copyright (c) 1983, 1990, 1993
* The Regents of the University of California. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE. */

that results into (yes, the all rights sentence misses the copyright
owner because it is in a different one):

AllRights,0,,,
BSDpre,70,,<colon>
BSDcondSource,70,,,above ,,
BSDcondBinary,70,,,,
BSDcondEndorse,70,,,,the University nor the names of its contributors,specific
BSDasIs,10,,,THE REGENTS AND CONTRIBUTORS ,,A,
BSDWarr,70,,,THE REGENTS OR CONTRIBUTORS,


--
--
Daniel M. German
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

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

Soeren_Rabenstein@...
 

The license would be embedded in the SPDX file. In fact, you will have
all different licenses in a single place (the SPDX file) for every
project. No need to go back to the source, if it hasn't changed.
an/listinfo/spdx

What is the intended use case for an spdx file? So far it appears to me
that it is supposed to describe one single software package.
If so, I indeed see us attaching giant data amounts of license texts to
tiny data amounts of code, if we embed all license texts into the spdx
file, instead of keeping them in a license repository.


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.
=====================================================================================================================================

Re: Spdx Digest, Vol 1, Issue 16

Soeren_Rabenstein@...
 

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.
Text for each exception, should include exception and original licenses.
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)

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.
=====================================================================================================================================

Re: CeCILL licences

kate.stewart@...
 

Bonjour Patrick,

CeCILL licenses have been mentioned before by others as well, so unless someone objects I'll just add them to the next draft with some of the others that have been discussed and advocated as candidates for 1.0 on the maillist.

Thank you for your input.

Merci,
Kate

--- On Mon, 8/30/10, Patrick MOREAU <Patrick.MOREAU@...> wrote:

From: Patrick MOREAU <Patrick.MOREAU@...>
Subject: CeCILL licences
To: "spdx@..." <spdx@...>
Date: Monday, August 30, 2010, 7:53 AM
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@...



 
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
shout out re: SPDX RDF 'sub-group'

Bill Schineller
 

SPDX colleagues:
As per the last con-call, here's a shout out to those who wish to
collaborate outside of the current bi-weekly calls to focus on the details
of the RDF representation of an SPDX document.

I've called out individually

peter.williams AT openlogic.com
Jeff AT palamida.com
gary AT sourceauditor.com
Bruno.Cornec AT hp.com

who I remember commenting on RDF specifics, and thus may form a 'quorum'
to get started, but anyone else who would like to be on this sub-group
please let me know.

Would you like to participate in a separate concall - I'm proposing
Tuesday Sept 7 at 11am Boston time? (same time as the bi-weekly calls, to
permit possibility of spanning CA-MA-Europe)


Sampling of issues to tackle:
working examples / tools
Jeff promised an update?
Gary's github repo for 'prettyprinter' github.com/goneall
validation
use of ontology to check integrity constraints ?
extensibility / relationship to DOAP
namespace rules / URI generation conventions
permanent URLs for licenses RDF (PURL)
license RDF (use rdfa ??)

Please respond on your availability and interest - I'd like to have a
'quorum' on our first call, and from there work out how best to collaborate.

Thanks,
Bill

Bill Schineller
Knowledge Base Manager
Black Duck Software Inc.
T: +1.781.810.1829
F: +1.781.891.5145
E: bschineller@...
http://www.blackducksoftware.com

Re: shout out re: SPDX RDF 'sub-group'

Jeff Luszcz
 

This will work for me.

Jeff

-----Original Message-----
From: Bill Schineller [mailto:bschineller@...]
Sent: Wednesday, September 01, 2010 7:09 AM
To: peter.williams@...; Jeff Luszcz; Gary SourceAuditor;
Bruno.Cornec@...; spdx@...
Subject: shout out re: SPDX RDF 'sub-group'

SPDX colleagues:
As per the last con-call, here's a shout out to those who wish to
collaborate outside of the current bi-weekly calls to focus on the details
of the RDF representation of an SPDX document.

I've called out individually

peter.williams AT openlogic.com
Jeff AT palamida.com
gary AT sourceauditor.com
Bruno.Cornec AT hp.com

who I remember commenting on RDF specifics, and thus may form a 'quorum'
to get started, but anyone else who would like to be on this sub-group
please let me know.

Would you like to participate in a separate concall - I'm proposing
Tuesday Sept 7 at 11am Boston time? (same time as the bi-weekly calls, to
permit possibility of spanning CA-MA-Europe)


Sampling of issues to tackle:
working examples / tools
Jeff promised an update?
Gary's github repo for 'prettyprinter' github.com/goneall
validation
use of ontology to check integrity constraints ?
extensibility / relationship to DOAP
namespace rules / URI generation conventions
permanent URLs for licenses RDF (PURL)
license RDF (use rdfa ??)

Please respond on your availability and interest - I'd like to have a
'quorum' on our first call, and from there work out how best to
collaborate.

Thanks,
Bill

Bill Schineller
Knowledge Base Manager
Black Duck Software Inc.
T: +1.781.810.1829
F: +1.781.891.5145
E: bschineller@...
http://www.blackducksoftware.com
Re: shout out re: SPDX RDF 'sub-group'

Gary O'Neall
 

Tuesday 11AM eastern (8AM pacific) works for me.

Gary

-----Original Message-----
From: Bill Schineller [mailto:bschineller@...]
Sent: Wednesday, September 01, 2010 7:09 AM
To: peter.williams@...; Jeff@...; Gary SourceAuditor;
Bruno.Cornec@...; spdx@...
Subject: shout out re: SPDX RDF 'sub-group'

SPDX colleagues:
As per the last con-call, here's a shout out to those who wish to
collaborate outside of the current bi-weekly calls to focus on the details
of the RDF representation of an SPDX document.

I've called out individually

peter.williams AT openlogic.com
Jeff AT palamida.com
gary AT sourceauditor.com
Bruno.Cornec AT hp.com

who I remember commenting on RDF specifics, and thus may form a 'quorum'
to get started, but anyone else who would like to be on this sub-group
please let me know.

Would you like to participate in a separate concall - I'm proposing
Tuesday Sept 7 at 11am Boston time? (same time as the bi-weekly calls, to
permit possibility of spanning CA-MA-Europe)


Sampling of issues to tackle:
working examples / tools
Jeff promised an update?
Gary's github repo for 'prettyprinter' github.com/goneall
validation
use of ontology to check integrity constraints ?
extensibility / relationship to DOAP
namespace rules / URI generation conventions
permanent URLs for licenses RDF (PURL)
license RDF (use rdfa ??)

Please respond on your availability and interest - I'd like to have a
'quorum' on our first call, and from there work out how best to collaborate.

Thanks,
Bill

Bill Schineller
Knowledge Base Manager
Black Duck Software Inc.
T: +1.781.810.1829
F: +1.781.891.5145
E: bschineller@...
http://www.blackducksoftware.com

SPDX RDF 'sub-group' meeting Tues Sept 7 invitation details

Bill Schineller
 

Anyone is welcome; Gary, Jeff, Peter have accepted.
Details below.

SDPX RDF Sub-group Mtg 1
Tuesday Sept 7, 11AM eastern time

Toll-free dial-in number (U.S. and Canada): (877) 435-0230
International dial-in number: (253) 336-6732
Conference code: 7833942033

URL:  http://blackducksoftware.na6.acrobat.com/r39125695/


On 9/1/10 4:44 PM, "Gary O'Neall" <gary@...> wrote:

Tuesday 11AM eastern (8AM pacific) works for me.

Gary


-----Original Message-----
From: Bill Schineller [mailto:bschineller@...]
Sent: Wednesday, September 01, 2010 7:09 AM
To: peter.williams@...; Jeff@...; Gary SourceAuditor;
Bruno.Cornec@...; spdx@...
Subject: shout out re: SPDX RDF 'sub-group'

SPDX colleagues:
   As per the last con-call, here's a shout out to those who wish to
collaborate outside of the current bi-weekly calls to focus on the details
of the RDF representation of an SPDX document.

   I've called out individually

peter.williams AT openlogic.com
Jeff AT palamida.com
gary AT sourceauditor.com
Bruno.Cornec AT hp.com

  who I remember commenting on RDF specifics, and thus may form a 'quorum'
to get started, but anyone else who would like to be on this sub-group
please let me know.

  Would you like to participate in a separate concall - I'm proposing
Tuesday Sept 7 at 11am Boston time?  (same time as the bi-weekly calls, to
permit possibility of spanning CA-MA-Europe)


Sampling of issues to tackle:
  working examples  / tools
    Jeff promised an update?
    Gary's github repo for 'prettyprinter' github.com/goneall
  validation
      use of ontology to check integrity constraints ?
  extensibility / relationship to DOAP
  namespace rules /   URI generation conventions
  permanent URLs for licenses RDF (PURL)
  license RDF (use rdfa ??)

  Please respond on your availability and interest - I'd like to have a
'quorum' on our first call, and from there work out how best to collaborate.

Thanks,
 Bill

Bill Schineller
Knowledge Base Manager
Black Duck Software Inc.
T: +1.781.810.1829
F: +1.781.891.5145
E: bschineller@...
http://www.blackducksoftware.com






Bill Schineller
Knowledge Base Manager
Black Duck Software Inc.
T: +1.781.810.1829
F: +1.781.891.5145
E: bschineller@...
http://www.blackducksoftware.com

anybody has been successful at using Ninka?

dmg
 

hi everybody,

Is anybody being successful at building and using ninka? So far I have
not heard from anybody (neither good or bad news).

Based on feedback we are planning to make a wider release.

thanks again!

--dmg



--
Daniel M. German
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

Re: SPDX RDF 'sub-group' meeting Tues Sept 7 invitation details

kate.stewart@...
 

Hi Bill,
    I can attend, and want to be considered part of the working group.

Thanks, Kate


--- On Thu, 9/2/10, Bill Schineller <bschineller@...> wrote:

From: Bill Schineller <bschineller@...>
Subject: SPDX RDF 'sub-group' meeting Tues Sept 7 invitation details
To: "Gary SourceAuditor" <gary@...>, "peter.williams@..." <peter.williams@...>, "Jeff@..." <Jeff@...>, "Bruno.Cornec@..." <Bruno.Cornec@...>, "spdx@..." <spdx@...>
Date: Thursday, September 2, 2010, 3:21 PM

Anyone is welcome; Gary, Jeff, Peter have accepted.
Details below.

SDPX RDF Sub-group Mtg 1
Tuesday Sept 7, 11AM eastern time

Toll-free dial-in number (U.S. and Canada): (877) 435-0230
International dial-in number: (253) 336-6732
Conference code: 7833942033

URL:  http://blackducksoftware.na6.acrobat.com/r39125695/


On 9/1/10 4:44 PM, "Gary O'Neall" <gary@...> wrote:

Tuesday 11AM eastern (8AM pacific) works for me.

Gary


-----Original Message-----
From: Bill Schineller [mailto:bschineller@...]
Sent: Wednesday, September 01, 2010 7:09 AM
To: peter.williams@...; Jeff@...; Gary SourceAuditor;
Bruno.Cornec@...; spdx@...
Subject: shout out re: SPDX RDF 'sub-group'

SPDX colleagues:
   As per the last con-call, here's a shout out to those who wish to
collaborate outside of the current bi-weekly calls to focus on the details
of the RDF representation of an SPDX document.

   I've called out individually

peter.williams AT openlogic.com
Jeff AT palamida.com
gary AT sourceauditor.com
Bruno.Cornec AT hp.com

  who I remember commenting on RDF specifics, and thus may form a 'quorum'
to get started, but anyone else who would like to be on this sub-group
please let me know.

  Would you like to participate in a separate concall - I'm proposing
Tuesday Sept 7 at 11am Boston time?  (same time as the bi-weekly calls, to
permit possibility of spanning CA-MA-Europe)


Sampling of issues to tackle:
  working examples  / tools
    Jeff promised an update?
    Gary's github repo for 'prettyprinter' github.com/goneall
  validation
      use of ontology to check integrity constraints ?
  extensibility / relationship to DOAP
  namespace rules /   URI generation conventions
  permanent URLs for licenses RDF (PURL)
  license RDF (use rdfa ??)

  Please respond on your availability and interest - I'd like to have a
'quorum' on our first call, and from there work out how best to collaborate.

Thanks,
 Bill

Bill Schineller
Knowledge Base Manager
Black Duck Software Inc.
T: +1.781.810.1829
F: +1.781.891.5145
E: bschineller@...
http://www.blackducksoftware.com






Bill Schineller
Knowledge Base Manager
Black Duck Software Inc.
T: +1.781.810.1829
F: +1.781.891.5145
E: bschineller@...
http://www.blackducksoftware.com


-----Inline Attachment Follows-----

_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
Re: anybody has been successful at using Ninka?

Armijn Hemel <armijn@...>
 

hi!

Is anybody being successful at building and using ninka? So far I have
not heard from anybody (neither good or bad news).
It was not entirely trivial to get it working: the documentation and the
actual names of files and patches are not in sync, so it cost me about
10 minutes to get everything working (I will send more detailed feedback
after I have had some sleep) but it works now. The output is of course
quite terse, but at least it's something :-)

$ ./ninka.pl ./ninka.pl
./ninka.pl;AGPLv3+;,;2

$ ./ninka.pl /tmp/blaat/gettext-0.15/gettext-tools/src/write-qt.h
/tmp/blaat/gettext-0.15/gettext-tools/src/write-qt.h;GPLv2+;,;1

armijn

--
---------------------------------------------------------------------------
armijn@... || http://www.gpl-violations.org/
---------------------------------------------------------------------------

Re: SPDX RDF 'sub-group' meeting Tues Sept 7 invitation details

Bruno Cornec <Bruno.Cornec@...>
 

Hello,

I may be able to attend the last half-hour of the talk, if my previous
conf call with my partner doesn't extend to much :-(.

Bruno.

kate.stewart@... said on Thu, Sep 02, 2010 at 10:10:20PM -0700:

Hi Bill,
    I can attend, and want to be considered part of the working group.

Thanks, Kate

--- On Thu, 9/2/10, Bill Schineller <bschineller@...> wrote:

From: Bill Schineller <bschineller@...>
Subject: SPDX RDF 'sub-group' meeting Tues Sept 7 invitation details
To: "Gary SourceAuditor" <gary@...>, "peter.williams@..." <peter.williams@...>, "Jeff@..." <Jeff@...>, "Bruno.Cornec@..." <Bruno.Cornec@...>, "spdx@..." <spdx@...>
Date: Thursday, September 2, 2010, 3:21 PM



SPDX RDF 'sub-group' meeting Tues Sept 7 invitation details
Anyone is welcome; Gary, Jeff, Peter have accepted.

Details below.



SDPX RDF Sub-group Mtg 1

Tuesday Sept 7, 11AM eastern time



Toll-free dial-in number (U.S. and Canada): (877) 435-0230

International dial-in number: (253) 336-6732

Conference code: 7833942033



URL:  http://blackducksoftware.na6.acrobat.com/r39125695/





On 9/1/10 4:44 PM, "Gary O'Neall" <gary@...> wrote:



Tuesday 11AM eastern (8AM pacific) works for me.



Gary





-----Original Message-----

From: Bill Schineller [mailto:bschineller@...]

Sent: Wednesday, September 01, 2010 7:09 AM

To: peter.williams@...; Jeff@...; Gary SourceAuditor;

Bruno.Cornec@...; spdx@...

Subject: shout out re: SPDX RDF 'sub-group'



SPDX colleagues:

   As per the last con-call, here's a shout out to those who wish to

collaborate outside of the current bi-weekly calls to focus on the details

of the RDF representation of an SPDX document.



   I've called out individually



peter.williams AT openlogic.com

Jeff AT palamida.com

gary AT sourceauditor.com

Bruno.Cornec AT hp.com



  who I remember commenting on RDF specifics, and thus may form a 'quorum'

to get started, but anyone else who would like to be on this sub-group

please let me know.



  Would you like to participate in a separate concall - I'm proposing

Tuesday Sept 7 at 11am Boston time?  (same time as the bi-weekly calls, to

permit possibility of spanning CA-MA-Europe)





Sampling of issues to tackle:

  working examples  / tools

    Jeff promised an update?

    Gary's github repo for 'prettyprinter' github.com/goneall

  validation

      use of ontology to check integrity constraints ?

  extensibility / relationship to DOAP

  namespace rules /   URI generation conventions

  permanent URLs for licenses RDF (PURL)

  license RDF (use rdfa ??)



  Please respond on your availability and interest - I'd like to have a

'quorum' on our first call, and from there work out how best to collaborate.



Thanks,

 Bill



Bill Schineller

Knowledge Base Manager

Black Duck Software Inc.

T: +1.781.810.1829

F: +1.781.891.5145

E: bschineller@...

http://www.blackducksoftware.com













Bill Schineller

Knowledge Base Manager

Black Duck Software Inc.

T: +1.781.810.1829

F: +1.781.891.5145

E: bschineller@...

http://www.blackducksoftware.com






-----Inline Attachment Follows-----

_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
--
Open Source & Linux Profession Lead EMEA / http://opensource.hp.com
HP/Intel/Red Hat Open Source Solutions Initiative / http://www.hpintelco.net
http://www.HyPer-Linux.org http://mondorescue.org http://project-builder.org
La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org

41 - 60 of 1626