Hi Jilayne, Thanks for working on this. I have been traveling, so hopefullyI am not too far behind the conversations. Here are a few very minor things: - I agree that we should

Hello All, Attached is a firstrun at the license list info in a spreadsheet format as Kate mentioned below. Ialso included a word document with some explanations, "guidelines" Imade up as I went

Today's call dial-in details: SPDX RDF Sub-group Mtg 7 (TODAY) Tuesday October 19, 11AM eastern time Toll-free dial-in number (U.S. and Canada): (877) 435-0230 International dial-in number: (253)

Hi Kate, I will be glad to give the license informationspreadsheet a good review when it is available (or review an interimdocument). Tom Tom Incorvia tom.incorvia@... Direct: (512)

Just to let you know that the spec is now back in WIKI form, and open again for questions and comments to be posted in it. It is now broken down into one page per section from the SPEC so, scope of

Sorry for the delay on getting this out, have been having a couple of issues with my computer on the road. :( Details for the call will be: Toll-free dial-in number (U.S. and Canada): (877)

As per my email last week, there will be a meeting tomorrow, Oct 14 at 8am PDT/11AM EDT/15:00 UTC. I will be on a plane, so Kate will host. She will provide an agenda at the beginning of the meeting.

On behalf of the SPDX RDF Sub-group, I would like to providethe larger SPDX organization a proposal to leverage some of the existing RDFvocabularies. After analyzing several existing vocabularies,

Today's requested agenda items: 1) rdfa/xhtml example - Peter (15 min) 2) Formal proposal to leverage other vocabularies - Gary (15 min) 3) SHA1 usage - Gary (15 min) Today's call dial-in

SPDX Group, Kate has been traveling in Europe and has not been able to free up the time for our meeting on Thursday, so we are pushing for one week. Next meeting will be October 14, 8am PDT/11AM

Today's call dial-in details: (I understand Kate is unavailable) SPDX RDF Sub-group Mtg 5 (TODAY) Tuesday October 5, 11AM eastern time Toll-free dial-in number (U.S. and Canada): (877)

I was unaware that OSI has a pattern for this already. I agree we should follow the pattern they have used. That is an excellent point. it seems reasonable to treat the copyright declarations that

* Armijn Hemel <armijn@...> [2010-09-29 20:31]: We used a different mailing list (called package-facts) in the past and decided not to open up those archives to the public since it was

Peter: my 2 cents: the idea is good, though we should not reinvent a license templates syntax when the OSI has alreday done something. They use angle brackets so I would suggest using the same, not

A judgment is always made. Even if the file says "licensed under the terms of the BSD License", you have to decide if you believe that or if you believe they copied the file from a GPL licensed

PErhaps the solution is to have a judgement field, that indicates if the license is matched perfectly, or a decision was made. I also think it would be very useful to extract the license statement of

Two more things about the zlib example: 1. The license of the ada subdirectory is GPLv2+ not, GPLv2. 2. There is another interesting example, which is labelled BSD-3 in the SPDX. Same issues

In my opinion, the problem with allowing "user judgement" in included license variability can lead to disagreements of what a license really is, or even worse, misunderstanding of what the license of

I completely agree. I think anyone that has actual tried to analyze a package for copyright/license info knows that a lot of judgment calls are required. I would say that as license(A) =

Thanks Peter for your clarifications. I think this shows, that the ones creating the files will be _making_ decisions. In this case, several have been made: 1. Files without a license share the