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

The Linux Foundation has a Bugzilla instance that we should be able to use. * Peter Williams <peter.williams@...> [2010-09-07 16:25]: -- Martin Michlmayr Open Source Program Office,

Now that the technical sub-group has initiated its work i think it would be worth having a issue tracking system. This would allow us to reliably track issues with the spec and to make sure nothing

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

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

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