THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx

Difference between revisions of "Legal Team/Minutes/2010-12-03"

From SPDX Wiki
Jump to: navigation, search
(Convert to MediaWiki syntax)
 
Line 1: Line 1:
−
<p>The meeting was attended by:</p><ul><li>Jilayne Lovejoy (OpenLogic)</li><li>Kate Stewart (Canonical)</li><li>Tom Incorvia (Microfocus)</li><li>Esteban Rockett (Motorola)</li><li>Kim Weins (OpenLogic)</li></ul><p><strong>Discussion</strong></p><p>Python</p><ul><li>We revisited the issue of the Python license.&nbsp; Tom had done some additional tracking down of licensing info on the Python website (see attached jpg).&nbsp; Based on that, the new proposal is that we have 2 Python licenses in the list</li></ul><blockquote><ol><li>Python License Stack<ol><li>This consists of the entire stack of licenses that are needed for the Python language. The last language in the stack is Python Software Foundation license, which applies to the newer portions of Python.&nbsp; Other licenses in the stack apply to earlier poritions of the code.&nbsp; We noted that this "license stack" is referred to by the OSI as the Python Software Foundation (PSF) License.&nbsp; This is not entirely correct, since the PSF license is one element of the license stack.</li></ol></li><li>Python Software Foundation License<ul><li>This will encompass only the PSF license.&nbsp; We are separating this out since other projects may use the PSF license without the rest of the Python License Stack</li></ul></li></ol></blockquote><ul><li>As a follow up, Tom volunteered to validate this approach with the legal person at the PSF (a contact Kate will provide).&nbsp; He will also find out why the OSI also lists the Python CNRI License (ONE of the licenses in the Pthon License Stack) as a separate license on the list.&nbsp;</li></ul><p>Older licenses</p><ul><li>Jilayne had pointed out that in some cases we had older versions of a license on our list, but were missing the earlier versions.&nbsp; Examples included EUPL v1.0, MPL v1.0, NPL v1.0, other OSL versions, AFL, etc.&nbsp;&nbsp; We decided to add those earlier versions to the list as well, unless we got into a situation where they were too numerous.</li></ul><p>zlib/libpng license</p><ul><li>The OSI site lists a zlib/libpng license.&nbsp; However the text listed by OSI is the zlib license.&nbsp; There is a separate libpng license as well with different terms.&nbsp; We believe that these should be separate licenses in our list.&nbsp; Jilayne is going to do further research, including reaching out to zlib developers and OSI to try and determine why they are together.&nbsp; Once we get that info, back we will determine how to handle.</li></ul><p>GPL exceptions</p><ul><li>Jilayne has added several standard exceptions to the GPLv2 and GPLv3 listings.&nbsp; If anyone knows of additional exceptions, they can provide these to Jilayne along with a link to the "canonical source" for the license on the web.</li></ul><p>GPLv3 Section 7</p><ul><li>Mark Radcliffe had brought up the issue of GPLv3 section 7 on the mailing list.&nbsp; That section allows for other specific variations to be added to GPLv3.&nbsp; The primary goal of this clause was to allow compatibility with other licenses, such as Apache.&nbsp; However, theoretically someone could simply add these variations to the GPLv3.&nbsp; No one on the call had ever seen these variations in the real world yet, so the proposal is to simply list GPLv3 for now.&nbsp; Any variations would be handled as a "non standard license".&nbsp; If we begin to see these licenses appearing in the real world, we can then determine how to handle them.&nbsp; Jilayne will circulate this proposal to the mailing list for further comment.</li></ul><p>Finalizing the license list</p><ul><li>Prior to release of SPDX 1.0 Release Candidate (RC), we will need to get all of the licenses from this list into the license repository.&nbsp; Here are the tasks<br /><ol><li>Technical team to finalize the techncial design of that repo.&nbsp;</li><li>Set up and Implement the blank repo (technical team?)</li><li>Load (automated hopefully) of the data from the license list into the repo</li><li>Add any manual data (such as license template info or notes).</li><li>Validation and verification of all data in the repo (at least 2 different people)</li><li>Ready to go live</li><li>Define and document update processes for adding new licenses</li><li>Open process for addition of new licenses</li></ol></li><li>Aside from the remaining items listed here, we are planning to close off addition of any new licenses to the list until after the license repo is up, unless we find an egregious item that is missing.&nbsp; Once the repo is up with this base list, we can then open the process for adding new items.</li></ul><p>Going forward</p><ul><li>The remaining items associated with the list will now roll into the legal workstream and be handled in the legal meetings.</li></ul>
+
== Attendees ==
 +
 
 +
* Jilayne Lovejoy (OpenLogic)
 +
* Kate Stewart (Canonical)
 +
* Tom Incorvia (Microfocus)
 +
* Esteban Rockett (Motorola)
 +
* Kim Weins (OpenLogic)
 +
 
 +
== Python ==
 +
 
 +
We revisited the issue of the Python license. Tom had done some additional tracking down of licensing info on the Python website (see attached jpg). Based on that, the new proposal is that we have 2 Python licenses in the list
 +
 
 +
# Python License Stack
 +
#* This consists of the entire stack of licenses that are needed for the Python language. The last language in the stack is Python Software Foundation license, which applies to the newer portions of Python. Other licenses in the stack apply to earlier poritions of the code. We noted that this "license stack" is referred to by the OSI as the Python Software Foundation (PSF) License. This is not entirely correct, since the PSF license is one element of the license stack.
 +
# Python Software Foundation License
 +
#* This will encompass only the PSF license. We are separating this out since other projects may use the PSF license without the rest of the Python License Stack
 +
 
 +
As a follow up, Tom volunteered to validate this approach with the legal person at the PSF (a contact Kate will provide). He will also find out why the OSI also lists the Python CNRI License (ONE of the licenses in the Pthon License Stack) as a separate license on the list.
 +
 
 +
== Older licenses ==
 +
 
 +
* Jilayne had pointed out that in some cases we had older versions of a license on our list, but were missing the earlier versions. Examples included EUPL v1.0, MPL v1.0, NPL v1.0, other OSL versions, AFL, etc. We decided to add those earlier versions to the list as well, unless we got into a situation where they were too numerous.
 +
 
 +
== zlib/libpng license ==
 +
 
 +
* The OSI site lists a zlib/libpng license. However the text listed by OSI is the zlib license. There is a separate libpng license as well with different terms. We believe that these should be separate licenses in our list. Jilayne is going to do further research, including reaching out to zlib developers and OSI to try and determine why they are together. Once we get that info, back we will determine how to handle.
 +
 
 +
== GPL exceptions ==
 +
 
 +
* Jilayne has added several standard exceptions to the GPLv2 and GPLv3 listings. If anyone knows of additional exceptions, they can provide these to Jilayne along with a link to the "canonical source" for the license on the web.
 +
 
 +
== GPLv3 Section 7 ==
 +
 
 +
* Mark Radcliffe had brought up the issue of GPLv3 section 7 on the mailing list. That section allows for other specific variations to be added to GPLv3. The primary goal of this clause was to allow compatibility with other licenses, such as Apache. However, theoretically someone could simply add these variations to the GPLv3. No one on the call had ever seen these variations in the real world yet, so the proposal is to simply list GPLv3 for now. Any variations would be handled as a "non standard license". If we begin to see these licenses appearing in the real world, we can then determine how to handle them. Jilayne will circulate this proposal to the mailing list for further comment.
 +
 
 +
== Finalizing the license list ==
 +
 
 +
* Prior to release of SPDX 1.0 Release Candidate (RC), we will need to get all of the licenses from this list into the license repository. Here are the tasks
 +
*# Technical team to finalize the techncial design of that repo.
 +
*# Set up and Implement the blank repo (technical team?)
 +
*# Load (automated hopefully) of the data from the license list into the repo
 +
*# Add any manual data (such as license template info or notes).
 +
*# Validation and verification of all data in the repo (at least 2 different people)
 +
*# Ready to go live
 +
*# Define and document update processes for adding new licenses
 +
*# Open process for addition of new licenses
 +
* Aside from the remaining items listed here, we are planning to close off addition of any new licenses to the list until after the license repo is up, unless we find an egregious item that is missing. Once the repo is up with this base list, we can then open the process for adding new items.
 +
 
 +
== Going forward ==
 +
 
 +
* The remaining items associated with the list will now roll into the legal workstream and be handled in the legal meetings.
 +
 
 +
[[Category:Legal|Minutes]]
 +
[[Category:Minutes]]

Latest revision as of 18:47, 5 March 2013

Attendees

  • Jilayne Lovejoy (OpenLogic)
  • Kate Stewart (Canonical)
  • Tom Incorvia (Microfocus)
  • Esteban Rockett (Motorola)
  • Kim Weins (OpenLogic)

Python

We revisited the issue of the Python license. Tom had done some additional tracking down of licensing info on the Python website (see attached jpg). Based on that, the new proposal is that we have 2 Python licenses in the list

  1. Python License Stack
    • This consists of the entire stack of licenses that are needed for the Python language. The last language in the stack is Python Software Foundation license, which applies to the newer portions of Python. Other licenses in the stack apply to earlier poritions of the code. We noted that this "license stack" is referred to by the OSI as the Python Software Foundation (PSF) License. This is not entirely correct, since the PSF license is one element of the license stack.
  2. Python Software Foundation License
    • This will encompass only the PSF license. We are separating this out since other projects may use the PSF license without the rest of the Python License Stack

As a follow up, Tom volunteered to validate this approach with the legal person at the PSF (a contact Kate will provide). He will also find out why the OSI also lists the Python CNRI License (ONE of the licenses in the Pthon License Stack) as a separate license on the list.

Older licenses

  • Jilayne had pointed out that in some cases we had older versions of a license on our list, but were missing the earlier versions. Examples included EUPL v1.0, MPL v1.0, NPL v1.0, other OSL versions, AFL, etc. We decided to add those earlier versions to the list as well, unless we got into a situation where they were too numerous.

zlib/libpng license

  • The OSI site lists a zlib/libpng license. However the text listed by OSI is the zlib license. There is a separate libpng license as well with different terms. We believe that these should be separate licenses in our list. Jilayne is going to do further research, including reaching out to zlib developers and OSI to try and determine why they are together. Once we get that info, back we will determine how to handle.

GPL exceptions

  • Jilayne has added several standard exceptions to the GPLv2 and GPLv3 listings. If anyone knows of additional exceptions, they can provide these to Jilayne along with a link to the "canonical source" for the license on the web.

GPLv3 Section 7

  • Mark Radcliffe had brought up the issue of GPLv3 section 7 on the mailing list. That section allows for other specific variations to be added to GPLv3. The primary goal of this clause was to allow compatibility with other licenses, such as Apache. However, theoretically someone could simply add these variations to the GPLv3. No one on the call had ever seen these variations in the real world yet, so the proposal is to simply list GPLv3 for now. Any variations would be handled as a "non standard license". If we begin to see these licenses appearing in the real world, we can then determine how to handle them. Jilayne will circulate this proposal to the mailing list for further comment.

Finalizing the license list

  • Prior to release of SPDX 1.0 Release Candidate (RC), we will need to get all of the licenses from this list into the license repository. Here are the tasks
    1. Technical team to finalize the techncial design of that repo.
    2. Set up and Implement the blank repo (technical team?)
    3. Load (automated hopefully) of the data from the license list into the repo
    4. Add any manual data (such as license template info or notes).
    5. Validation and verification of all data in the repo (at least 2 different people)
    6. Ready to go live
    7. Define and document update processes for adding new licenses
    8. Open process for addition of new licenses
  • Aside from the remaining items listed here, we are planning to close off addition of any new licenses to the list until after the license repo is up, unless we find an egregious item that is missing. Once the repo is up with this base list, we can then open the process for adding new items.

Going forward

  • The remaining items associated with the list will now roll into the legal workstream and be handled in the legal meetings.
Retrieved from "https://wiki.spdx.org/index.php?title=Legal_Team/Minutes/2010-12-03&oldid=811"