Hi Everyone Minutes on license meeting are now available on the wiki at the link below. We have a few remaining followups that are being chased down (per the minutes) and after that we will

Debian just moved DEP-5 from candidate to draft, so our window to harmonize with it starting to narrow. see: http://lists.debian.org/debian-devel-announce/2011/01/msg00000.html The spec can be found

All: - Please note, proposed minutes from our last meeting are posted on the SPDX Wiki under the Legal Workstream section. Sorry for the delay. We will allow an additional week for approval of

For the Beta program, there are two additional legal issues I want to raise for the legal team to discuss. What will be the OSS license for the SPDX tools we are providing? (ccing Gary since he

Just a follow-up on the OSS license for the SPDX tools . Attached is the Notice I included in the source. It contains a BSD 3-clause license for the source code provided by Source Auditor Inc. and

Hi Gary We were hoping that we might be able to license the tool under MIT, since that is what the LF uses. Is that a possibility? Kim On Thu 1/20/11 11:09 AM, "Gary O'Neall" <gary@...> wrote:

Hi Kim, MIT is fine with me for the contributions from Source Auditor. I can update the license notices before the Beta starts. Note that the Jenna code is licensed under the BSD 3 clause. Gary

Bear in mind that "LicenseInformation" is the Tag which is a short form of the full name, "License Information in File." This longer name was roundly supported by folks on the last Legal Team call,

"LicenseInfoInFile" removes the ambiguity, so going with that seems reasonable. Kate

While working on prototyping the spdx license registry i noticed that the full license texts in the spread sheet are not well formatted. Additionally, i some the license texts are incomplete (most of

At the recent SPDX general call, I offered to clarify Python licensing and to suggest standard names. This set of licenses is messy, and a long discussion is below. There is not a single logical

(Resend of 2/11/2011 email for today’s SPDX Legal call) At the recent SPDX general call, I offered to clarify Python licensing and to suggest standard names. This set of licenses is messy,

During the discussion this morning regarding license templatization a question came up regarding the exact purpose of templatization. This question was not answered satisfactory so hopefully the full

Hi Peter, Bumping this up a bit conceptually. I do agree that the timing and sophistication of tooling to support SPDX deserves additional discussion. The comments below speak a bit more to the

<tom.incorvia@...> wrote: I like the goal but i don't see how standardizing a license normalization algorithm designed to remove non-material variations advances this goal. I think

minor point to whomever is current keeper of license list: identifier GFDL-1.2 appears twice in http://spdx.org/system/files/spdx_licenselist_v1.6.xls cell B70 should instead be GFDL-1.1 Bill

I am updating the SPDX Tools source code to use the Apache 2.0 License. In addition to a NOTICE and LICENSE file, I plan on including the following text in all source files. Since we are not

You can disregard my last request – I found the correct template below: Copyright [yyyy] [name of copyright owner] Licensed under the Apache License, Version 2.0 (the "License");

Agenda Legal WorkStream 23-March-2011 (1) Re-Report SPDX Tools License Conclusion - Apache 2.0 (2) Revised Section 5.3 into Beta Spec. (3) SPDX Metadata StrawMan: (a) - Need for SPDX Metadata

I think it is going in the right direction. You should look at the way Ninka normalizes test for in-file licenses (BSD, MIT, etc). For the BSD and MIT variants the problems are not only spelling,