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

Hi Phil Please just make sure you indicate times in UTC, which equals toGMT (or to “Zulu-Time” in the NATO language.) But last week you indicated in something like ‘GreenwichDaylight Saving

http://www.spdx.org/wiki/20100909-minutes 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

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

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

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

Rather 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

Dear all 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

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

hi Soeren 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

Dear All, 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

I’ll be on the call, but I thought I would throw in my 2cents in advance of the call. I like and agree with the proposal. I think it adds a lotof value to the spec. One slight

Thanks Kim, Will add it into the agenda to discuss tomorrow on the SPEC section. If anyone feels strongly about this field, and can't attend the call, please send email to the list so we have

Hi Kim, Daniel, 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

+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

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

Kim Weins said on Wed, Sep 08, 2010 at 05:05:46PM -0600: Which 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

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

From the minutes: Our implicit path had tied a fixed license list of licenses to the spec rev, but JohnE put forth an impassioned argument as to why they should be decouples... I throw my support

Per discussion late meeting, agendas will be going out in bodies of emails and minutes will go out as links to archive at spdx.org. I'll strive to get minutes out a week in advance, though I'm behind