|
Re: MInutes from Sept 9 call
Armijn Hemel <armijn@...>
On Mon, 2010-09-13 at 08:09 -0400, Philip Odence wrote:
Thanks, Soeren. I believe in my memo (just to you) last week, IGMT is an old term and UTC is the new black. The good thing about UTC is that it does not change, no matter how many timezones the UK skips in summer (there used to be this thing called "double summer time" http://en.wikipedia.org/wiki/British_summer_time ). There are also plenty of places where there is no summer time (I believe even in the US). UTC makes sense then (ask the US military about their "zulu time") In any case, this time stuff is tricky.It's not that tricky: use UTC and a converter (like http://www.timeanddate.com/worldclock/converter.html ) to calculate your local timezone :-P armijn -- --------------------------------------------------------------------------- armijn@... || http://www.gpl-violations.org/ ---------------------------------------------------------------------------
|
|
|
|
|
|
Re: SPDX RDF Sub-group Mtg 2
Bruno Cornec <Bruno.Cornec@...>
Bill Schineller said on Fri, Sep 10, 2010 at 03:33:46PM -0400:
Those interested in participating in the RDF track, please reconvene nextSorry, I won't be able to attend this session, being at a customer site for a Workshop. Bruno. -- 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
|
|
|
|
|
|
Re: MInutes from Sept 9 call
Philip Odence
Thanks, Soeren. I believe in my memo (just to you) last week, I mentioned British Summer Time which according to my research does exist http://wwp.greenwichmeantime.com/info/bst.htm. It is the way that the UK refers to its timezone during the part of the year that the country goes one hour ahead of GMT.
toggle quoted messageShow quoted text
In any case, this time stuff is tricky. Because most participants on the calls are from the US, we'll keep the time consistent for the US. Regular Thursday calls will always be at 11am New York time. Apologies for the schedule change that will occur internationally in late October.
On Sep 12, 2010, at 9:55 PM, <Soeren_Rabenstein@...> <Soeren_Rabenstein@...> wrote:
|
|
|
|
|
|
Re: MInutes from Sept 9 call
Soeren_Rabenstein@...
Hi Phil
Please just make sure you indicate times in UTC, which equals to GMT (or to “Zulu-Time” in the NATO language.) But last week you indicated in something like ‘Greenwich Daylight Saving Time’, which doesn’t actually exist ;)
Best regards Soeren
From:
spdx-bounces@... [mailto:spdx-bounces@...] On Behalf
Of Philip Odence
International colleagues, While I am thinking of it, most countries shift from daylight time to regular time a few weeks before the US does on Nov 7. We'll keep running the regular meetings at 11 New York time, so please adjust accordingly. Sorry for the complication.
Phil L. Philip Odence Vice President of Business Development Black Duck Software, inc. 265 Winter Street, Waltham, MA 02451 Phone: 781.810.1819, Mobile: 781.258.9502
===================================================================================================================================== 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. =====================================================================================================================================
|
|
|
|
|
|
MInutes from Sept 9 call
Philip Odence
International colleagues, While I am thinking of it, most countries shift from daylight time to regular time a few weeks before the US does on Nov 7. We'll keep running the regular meetings at 11 New York time, so please adjust accordingly. Sorry for the complication. Phil L. Philip Odence Vice President of Business Development Black Duck Software, inc. 265 Winter Street, Waltham, MA 02451 Phone: 781.810.1819, Mobile: 781.258.9502
|
|
|
|
|
|
SPDX Rollout - slides from call yesterday
Kim Weins
Hi everyone,
Attached are the slides John Ellis and I put together to start to organize the tasks needed for the rollout of SPDX. We are going to be asking for help — from you or others in your organization. Please check out the slides, including the Appendix, and see where you might be willing & able to provide some help from your organization. I will be reaching out in the coming weeks to see who is interested. Kim Kim Weins | Senior Vice President, Marketing kim.weins@... Follow me on Twitter @KimAtOpenLogic 650 279 0410 | cell www.openlogic.com Follow OpenLogic on Twitter @OpenLogic OpenLogic, Inc. Headquarters, Broomfield, Colorado
|
|
|
|
|
|
SPDX RDF Sub-group Mtg 2
Bill Schineller
Colleagues,
Those interested in participating in the RDF track, please reconvene next Tuesday. Among other hot topics, we'd like to take a closer look at the ontology, which for collaborative review purposes has been loaded at free online tool http://knoodl.com/ui/groups/SPDX/vocab/SPDX(dev-only) SPDX RDF Sub-group Mtg 2 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 to join meeting: http://blackducksoftware.na6.acrobat.com/r41859185/ 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
|
|
|
|
|
|
DOAP / SPDX collaboration
Bill Schineller
Hello Edd (DOAP project owner),
The SPDX (http://spdx.org) working group is involved in defining a standard format for communicating the components, licenses and copyrights associated with a software package. A number of our members including myself are very familiar with RDF and DOAP. For the same reasons you picked RDF XML and leveraged FOAF, we likewise picked RDF XML and realize our vocabulary can reference DOAP. Currently, the SPDX effort is in the process of translating the specification from wiki format into an OWL format. (Our site does not yet reflect very well our choice of RDF XML as the machine readable format...) SPDX is focused on a deep analysis (on a per file level) of the licenses used within an spdx:Package. As such SPDX is a specialist community and actually does have the desire to own identifiers for licenses, and create RDF descriptions of the licenses. (You stated this is out of scope of DOAP http://www.ibm.com/developerworks/xml/library/x-osproj3/) An spdx:Package is really any tarball of analyzed source code. Although there is some (considerable?) overlap between concepts in SPDX and DOAP, we believe the focus of SPDX is sufficiently narrow that it makes sense to keep it separate from DOAP (i.e. not suggest we introduce new concepts into DOAP). Rather, reference DOAP as appropriate. For example, in some cases, an spdx:Package is equivalent to a http://usefulinc.com/ns/doap#file-release And in some cases, perhaps one might assert that spdx:File spdx:origin doap:Project (e.g. a specific file foo.java came from http://usefulinc.com/software/gnome-bluetooth ) Also, we're experimenting with collaborating on the development of our ontology using a free online tool knoodl.com (Note: we have no affiliation with knoodl.com) In order to facilitate developing our ontology to reference DOAP, it may be useful to have the DOAP ontology loaded onto knoodl. I took the liberty of uploading doap.rdf into knoodl.com being sure to reference you and your site; it lives at http://knoodl.com/ui/groups/DOAP/vocab/DOAP(trunk,19) We would welcome you to join the SPDX group (self register for the mailing list at spdx.org). We would value your advice and collaboration. 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: New proposed field for project that a file came from
Peter Williams <peter.williams@...>
On 9/8/10 11:58 PM, Gary O'Neall wrote:
One slight modification/addition. Having just the name of the OSSRather than having two optional fields, perhaps we should have one optional field whose value is a doap:Project[1]. the DOAP[2] project has produced a great model of project information and we can easily leverage the subset of it that is useful to SPDX. This would allow tools to embed as much or as little project information into the SPDX file as desired. It would also allow the utilization of existing data sources when they exist and doing so is desirable to participants of the data exchange. 5.6 Origin 5.6.1 Purpose: Identify the project where this file originated. 5.6.2 Intent: By providing data regarding the project where this file originated the reader can better identify the source and use it to do further research if needed. 5.6.3 Cardinality: Optional, single instance 5.6.4 Tag: "origin" 5.6.5 RDF: /RDF/SPDXDoc/Describes/File/origin 5.6.6 Data Format: doap:Project 5.6.7 Example: Origin: Project: name: JUnit homepage: http://www.junit.org Peter <http://openlogic.com> [1]: http://en.wikipedia.org/wiki/Description_of_a_Project [2]: http://trac.usefulinc.com/doap
|
|
|
|
|
|
Re: Decouple license list from the spec
Soeren_Rabenstein@...
Dear all
toggle quoted messageShow quoted text
I perfectly understand the concerns. But I would like to emphasize that imho one of the benefits of spdx for the industry is to have unequivocal names/indicator for licenses. Now if there are let's say five new licenses, the names of which are Amazing Public License, American Public License, Amateur Public License, Amoral Public License, and Amusing Public License. ...and all of them get tagged "AmPL" in the name tag by someone, then I will certainly end up with misunderstandings and confusion, notwithstanding the fact that the text of the different AmPLs are embedded in the file. For me the idea of unequivocal "declared license" tags has a lot of beauty, as this way compliance can be streamlined and partly automatized, as I can trigger a certain process for a given license tag appearing in the spdx. If I still need to legally review each spdx, because many of the applicable license texts are embedded there, I lose some of the benefits that spdx can have in daily industrial application. Best regards Soeren
-----Original Message-----not the intended recipient or a person responsible for its delivery to thethey =====================================================================================================================================toughshould be decouples... 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 Agenda/Minutes
Philip Odence
I have a thought that may help resolve. In section 2 specify, in addition to the spec version, a license list version. So, to be compliant, an SPDX file MUST (Kate's emphasis) recognize all of the licenses in the license version list. In Kim's example, the SPDX file could be rev'ed to the new version of the list. So the 1/1/11 version of the file would be compatible with SPDX V1.0/License List V1.0 and the 3/1/11 would be compatible with SPDX V1.0/License List V1.1. If someone was looking at two descriptions of the same package and there was a difference in the licenses, first thing they could do is check to see if both files used the same license list version.
On Sep 8, 2010, at 10:14 PM, <kate.stewart@...> <kate.stewart@...> wrote:
|
|
|
|
|
|
Re: SPDX Agenda/Minutes
dmg
hi Soeren
On Thu, Sep 9, 2010 at 2:05 AM, <Soeren_Rabenstein@...> wrote: Dear All,I think for a version 1 this is a very acceptable outcome. The package is described in a very simple way. We know it has 4 licenses, they are all extracted and placed in a well defined "blurb". All a person (or more likely a tool) needs to do is parse the 4 blurbs. That is addresses one of the major problems of Ninka and Fossology want to address: to find the license. Sure the files will work on their own. But if I eventually want to update them all to the newest standard, I will end up in either a lot of mismatches, or in a lot of manual work; i.e. the very two things spdx shall avoid (in my understanding).The way I'd solve t is by allowing two types of license descriptor: 1. A text blurb that embeds the license (simple and straightforward) 2. A meta-license descriptor. A meta license descriptor is a URI (any URI, not only spdx, but spdx ones would be assumed to be widely known). The URI would indicate information such as: type of license (reference or inclusion), any variable parameters that need to be identified, any potential variability (such as known variations in spelling or punctuation). So we end with two standards: 1. Describing the licensing of the package (where a license is a URI described by the license spec, it does not list _any_ specific license) 2. The one describing the licenses form (which describes the forms that licenses take). This way the standards do not change when a new license is added. Finally, SPDX will publish a list of (accepted|approved|blessed|loved) licenses, including their URI. But others will be allowed to published their own URIs for licenses. This could be standard #3. The license describer could rather look likeThis is not a variant of the license, it is a different license. IMO, variants really the same license but have different text (diff would yield different results, I.e. British vs American spelling). Variants are usually by inclusion. --dmg
|
|
|
|
|
|
Re: SPDX Agenda/Minutes
Soeren_Rabenstein@...
Dear All,
toggle quoted messageShow quoted text
By uncoupling licenses and standard, I see a high risk, that we end up in many different quasi-sub-standards of spdx. As in the example, what if several users of the license C and D give different license name tags to them, before they eventually get adopted by the license list? One Spdx file says 1. Standard | License A 2. Standard | License B 3. Custom | License C (attached license text x) 4. Custom | License D (attached license text y) Another one, describing the same package, says 1. Standard | License A 2. Standard | License B 3. Custom | License 3 (attached license text x) 4. Custom | License 4 (attached license text y) And another spdx file, describing a DIFFERENT package says 1. Standard | License A 2. Standard | License B 3. Custom | License C (attached license text z) 4. Custom | License D (attached whatever) Sure the files will work on their own. But if I eventually want to update them all to the newest standard, I will end up in either a lot of mismatches, or in a lot of manual work; i.e. the very two things spdx shall avoid (in my understanding). Therefore my opinion is to include in V.1.0 as many licenses as possible. Target should not be: include 80% of the licenses in Red-Hat; Target should rather be: include 100% of the licenses we know of. Why would it hurt us to include more licenses in the standard upfront? Once we have done this, there should not be so many revisions due to additional licenses. How many new FOSS licenses are established per year? I do not think it is too much nowadays. The only thing that may happen frequently is that someone adds a single special clause to a well known license. For these cases I would like to propose again to include a system to capture such slight variations by referring to the original version and describe the changes only. E.g. The newer ECos-License (http://ecos.sourceware.org/license-overview.html) does not need to be an own license in the standard. The license describer could rather look like DeclaredLicense = GPLv2 LicenseVariation = yes VariationContents = ++ As a special exception, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other works to produce a work based on this file, this file does not by itself cause the resulting work to be covered by the GNU General Public License. ++ However the source code for this file must still be made available in accordance with section (3) of the GNU General Public License. ++ This exception does not invalidate any other reasons why a work based on this file might be covered by the GNU General Public License. ... or something the like. 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@... ____________________________________________________________
-----Original Message-----===================================================================================================================================== 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: New proposed field for project that a file came from
Gary O'Neall
I’ll be on the call, but I thought I would throw in my 2 cents in advance of the call.
I like and agree with the proposal. I think it adds a lot of value to the spec.
One slight modification/addition. Having just the name of the OSS package may not be sufficient to uniquely identify the package. I would propose having a URL which references the OSS project homepage – or – a free text field with the OSS project name. To make this easier to parse by non-humans, I would suggest having 2 optional fields:
5.6 OSS Project (ass proposed) 5.7 OSS Project URL 5.7.1 Purpose: Identify the project home page of the open source
package or project where this file originated.
Gary From: spdx-bounces@...
[mailto:spdx-bounces@...] On Behalf Of kate.stewart@...
|
|
|
|
|
|
Re: New proposed field for project that a file came from
kate.stewart@...
--- On Wed, 9/8/10, Kim Weins <kim.weins@...> wrote:
|
|
|
|
|
|
Re: SPDX Agenda/Minutes
kate.stewart@...
Hi Kim, Daniel,
toggle quoted messageShow quoted text
Use case I'm worried about is how do we say what MUST be recognized when all the licenses are on the web. What happens when we don't have a stable base set of "must recognize" to conform. If we make everything on the web, then the use case of including in the spdx file, the full text of ALL licenses discovered (even if they are ones that have a short form) - will conform to the specification. Comparisons between analysis of the same package will become "interesting". Consider package "1" has licenses A, B, C, D in it. A, B, are on the web site, C, D aren't. One analysis tool produces a file with short form of A & B in the spec, C & D included verbatim. Another analysis tool produces a file with A, B, C, & D included verbatim. Both can be said to be SPDX 1.0, but if you compare both to each other, you may not draw the conclusion that they are talking about the same package. On the other hand, I do understand the concern over not rev'ing the spec too often to conform to license changes. What do people think about the following for 1.0? There is a base set of licenses, that MUST be recognized and included as short forms, to conform, and they are captured in Appendix I of the SPEC, as well as being on the web site. This gives the potential for creating a spec which is all inclusive - full text of licenses recognized as short forms, which others on the list have indicated a need for. We include language in the spec, saying these are the ones that MUST be recognized, but others on the website CAN be recognized as well. When there is critical mass of changes to rev the spec to 2.0; the set that is on the web site at that time, becomes the MUST be recognized, and additions after that are CAN be recognized. This avoids the point revision churn for licenses that John's afraid of, allows an enforcement of a minimum set, and give a path to add new licenses as they are nominated into the "active set". Thoughts? Kate
--- On Wed, 9/8/10, Kim Weins <kim.weins@...> wrote:
From: Kim Weins <kim.weins@...>
|
|
|
|
|
|
Re: Decouple license list from the spec
Michael J Herzog <mjherzog@...>
+2 for decoupling the spec from the licenses. We need to be able to update the spec and the license list on different cycles. We should also anticipate that many orgs may want to keep a local copy of the SPDX license list.
toggle quoted messageShow quoted text
Regards, Michael Michael J. Herzog +1 650 380 0680 | mjherzog_at_nexB.com nexB [Open by Design] http://www.nexb.com CONFIDENTIALITY NOTICE: This e-mail (including attachments) may contain information that is proprietary or confidential. If you are not the intended recipient or a person responsible for its delivery to the intended recipient, do not copy or distribute it. Please permanently delete the e-mail and any attachments, and notify us immediately at (650) 380-0680.
On 9/8/2010 4:05 PM, Kim Weins wrote:
I also agree that we should decouple spec from licenses. We need a way to
|
|
|
|
|
|
New proposed field for project that a file came from
Kim Weins
I would like to propose a new field in the file section. The field would be used to identify the OSS component/package that a file originated from. This is important since many packages will bundle other packages. Knowing the license is important, but if you need to do any research on the file, knowing the component is even more important. I am proposing this would be an Optional field. 5.6 OSS Project 5.6.1 Purpose: Identify the name of the open source package or project where this file originated. 5.6.2 Intent: By providing the open source package, the reader can better identify the source and use it to do further research if needed. 5.6.3 Cardinality: Optional, single instance 5.6.4 Tag: "Project" 5.6.5 RDF: /RDF/SPDXDoc/Describes/File/Project 5.6.6 Data Format: Freeform text string 5.6.7 Example: Project: jUnit Kim Kim Weins | Senior Vice President, Marketing kim.weins@... Follow me on Twitter @KimAtOpenLogic 650 279 0410 | cell www.openlogic.com Follow OpenLogic on Twitter @OpenLogic OpenLogic, Inc. Headquarters, Broomfield, Colorado
|
|
|
|
|
|
Re: SPDX Agenda/Minutes
Bruno Cornec <Bruno.Cornec@...>
Kim Weins said on Wed, Sep 08, 2010 at 05:05:46PM -0600:
The only issue is that you may get an SPDX file that has something marked asWhich in fact solves the point I had during the conf call this week. If the license is known to spdx, then we can point to a uri/url linked to spdx.org having it full text. If not, the full text is then embedded, as long as the license doesn't become official, in which case, it can be further offloaded from the SPDX file. Meaning we could have: File A has Std license: "http://www.spdx.org/license/GPLv2" File B has Other license embedded "this is the free beer license..." Thus keeping duplication to a minimum. Bruno. -- 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
|
|
|
|
|
|
Re: SPDX Agenda/Minutes
Kim Weins
I also agree that we should decouple spec from licenses. We need a way to
add licenses without having to rev the spec. Otherwise we will get lots of spec revisions or very few license updates. I know there has been some concern that if the list of licenses is not "fixed" with the spec version, you won't know what list of licenses you need to be able to "understand" when you get an SPDX file based on a particular version of the spec. I'd like to dig into this use case more, since it seems to me that any tooling or even manual review processes can be designed to just pull the latest and greatest version of licenses from the website. The only issue is that you may get an SPDX file that has something marked as an "Other" license that is now in the standard license repo. That shouldn't really be a problem, since all the "Other" licenses will have full license text in the SPDX file. Here's an example: Company A creates SPDX on 1/1/2011 using latest set of standard licenses at that point. They identify: File A has Standard License A File B has Standard License B File C has Other License C File D has Other License D On 2/1/2011, License C is added to standard license repo Company B reviews SPDX on 3/1/2011 All of the info is still valid -- since License C and D are in the SPDX file. Company B could choose to update the SPDX file as: File A has Standard License A File B has Standard License B File C now has STANDARD License C File D has Other License D Am I missing something here? Kim On Wed 9/8/10 12:48 PM, "dmg" <dmg@...> wrote: From the minutes: Kim Weins | Senior Vice President, Marketing kim.weins@... Follow me on Twitter @KimAtOpenLogic 650 279 0410 | cell www.openlogic.com Follow OpenLogic on Twitter @OpenLogic OpenLogic, Inc. Headquarters, Broomfield, Colorado
|
|
|
|