Note: lists.spdx.org will be down for maintenance on Wednesday, October 5th, starting at 9AM Pacific Time (4PM Wednesday October 5, 2022 UTC), for approximately one hour.
|
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:
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,
toggle quoted messageShow 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" Peter Williams wrote: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: repository. *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 ***********************************
|
|
|
|
|
|
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@...> 1) I noticed the license list included some of the GPLText for each exception, should include exception and original 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. 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 onre: 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.
toggle quoted messageShow quoted text
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]:This is fantastic, thanks Martin! I'll bring the content from FedoraDrupal is a great CMS, but it is not such a great wiki.Sure, I'd agree with that. The Drupal wiki functionality has been 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 havean/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@...
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. 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,
toggle quoted messageShow quoted text
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@...>
|
|
|
|
|
|
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.
toggle quoted messageShow quoted text
Jeff
-----Original Message-----
|
|
|
|
|
|
Re: shout out re: SPDX RDF 'sub-group'
Gary O'Neall
Tuesday 11AM eastern (8AM pacific) works for me.
toggle quoted messageShow quoted text
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. 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@...
--- On Thu, 9/2/10, Bill Schineller <bschineller@...> wrote:
|
|
|
|
|
|
Re: anybody has been successful at using Ninka?
Armijn Hemel <armijn@...>
hi!
Is anybody being successful at building and using ninka? So far I haveIt 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,
toggle quoted messageShow quoted text
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, --
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
|
|
|
|