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 the text from the notice from Jenna – an open source component used by the pretty printer. 

Once I add the worksheet functionality, I will be adding another component – Apache POI – which is licensed under the Apache 2.0 License.

Let me know if you would like any modifications to the licensing or notices.

Thanks,
Gary

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 answer.  Here are the compromise recommendations gleaned from the details below:

========== Summary  =====================

1.       We work with Van Lindberg to remove the CNRI Python License listed on opensource.org

2.       SPDX removes the CNRI Python license and link from the SPDX Rev-1 list

3.       SPDX deals ONLY with the stack of 4 licenses applicable to Python 2.0.1 through 3.2, and uses the following naming conventions:

-          License Identifier: “Python-2.0”

-          Full Name: “Python Software Foundation License v2”

-          “Official” license text is obtained from: http://www.opensource.org/licenses/PythonSoftFoundation

=================== =====================

Details:

Based on discussions with Van Lindberg (thanks for the referral Kate Stewart), we have confirmed that the various Python releases are licensed as follows:

a.       Python 0.9.0 through 1.2: Licensed solely via the:

                     i.             CWI License Agreement for Python (“CWI License”)

b.      Python 1.3 through 1.6.0 (assuming that you have licensed Python 1.6.0 but NOT licensed 1.6.1 or anything beyond 1.6.1): Licensed via the 2-license stack consisting of the

                     i.            CWI License, AND the

                   ii.            CNRI License Agreement for Python with Virginia choice of law (“CNRI License Virginia”)

c.       Python 1.3 through 1.6.1: (assuming that you HAVE licensed Python 1.6.1): Licensed via the 2-license stack consisting of the 2-license stack consisting of the

                     i.            CWI License, AND the

                   ii.            CNRI License with the “limited” Virginia choice of law (“CNRI License Limited-Virginia”)

d.      Python 2.0: Licensed by the 3-license stack consisting of the

                     i.            CWI License, AND the

                   ii.            CNRI License Limited-Virginia AND the

                  iii.            BeOPEN.COM license Agreement for Python (“BeOPEN License”)

e.      Python 2.0.1 thru 3.2: Licensed by the 4-license stack consisting of the

                     i.            CWI License, AND the

                   ii.            CNRI License Limited-Virginia, AND the

                  iii.            BeOpen license, AND the

                 iv.            Python Software Foundation License (“PSF License”)

Also, we determined that the CNRI Python License listed on opensource.org is out of date and should be removed.  Van Lindberg will make the arrangements for the removal of this license.  

As such, I recommend that we remove the CNRI Python license and link from the SPDX Rev-1 list – its applicability is very limited (Python 0.9.0 through 1.2, which are not available on the Python site other than a single release, 0.9.1 that is described as “a historical relic”).

I do not believe that we have dealt previously with a “License Stack” in a context like a. through e. above.  There are issues with older versions of this license stack (for instance, different legal terms for certain versions of Python depending on whether you have or have not licensed a follow-on version).  These issues make licensing for older versions of Python difficult to ascertain without knowing the full history of versions that were obtained. 

Also, the naming, even of the initial license in the Python stack, is not consistent.  Opensource.org names the initial license “PYTHON SOFTWARE FOUNDATION LICENSE VERSION 2”; the Python site, however, generally suffixes the initial license with the version of Python – but not always.  The use of “Version 2” by opensource.org probably was based on the assumption that Python 2 and above are licensed via the full stack.  However, the initial release of Python 2.0 is licensed under a three-license stack rather than the four-license stack that includes the PSF License.  Also, very small changes have been made to the text of the various licenses depending on the version of Python that was released. 

For all the reasons above, I recommend that we compromise as follows:

For the initial SPDX license list release, I recommend that we only deal with the stack of 4 licenses applicable to Python 2.0.1 through 3.2, and use the following naming conventions:

License Identifier: “Python-2.0”

Full Name: “Python Software Foundation License v2”

“Official” License text is obtained from: http://www.opensource.org/licenses/PythonSoftFoundation

This will cover us in the vast majority of cases.

Tom

Tom Incorvia

tom.incorvia@...

Direct:  (512) 340-1336

Mobile: (408) 499 6850

(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, and a long discussion is below. There is not a single logical answer.  Here are the compromise recommendations gleaned from the details below:

========== Summary  =====================

1.       We work with Van Lindberg to remove the CNRI Python License listed on opensource.org

2.       SPDX removes the CNRI Python license and link from the SPDX Rev-1 list

3.       SPDX deals ONLY with the stack of 4 licenses applicable to Python 2.0.1 through 3.2, and uses the following naming conventions:

-          License Identifier: “Python-2.0”

-          Full Name: “Python Software Foundation License v2”

-          “Official” license text is obtained from: http://www.opensource.org/licenses/PythonSoftFoundation

=================== =====================

Details:

Based on discussions with Van Lindberg (thanks for the referral Kate Stewart), we have confirmed that the various Python releases are licensed as follows:

a.       Python 0.9.0 through 1.2: Licensed solely via the:

                     i.             CWI License Agreement for Python (“CWI License”)

b.      Python 1.3 through 1.6.0 (assuming that you have licensed Python 1.6.0 but NOT licensed 1.6.1 or anything beyond 1.6.1): Licensed via the 2-license stack consisting of the

                     i.            CWI License, AND the

                   ii.            CNRI License Agreement for Python with Virginia choice of law (“CNRI License Virginia”)

c.       Python 1.3 through 1.6.1: (assuming that you HAVE licensed Python 1.6.1): Licensed via the 2-license stack consisting of the 2-license stack consisting of the

                     i.            CWI License, AND the

                   ii.            CNRI License with the “limited” Virginia choice of law (“CNRI License Limited-Virginia”)

d.      Python 2.0: Licensed by the 3-license stack consisting of the

                     i.            CWI License, AND the

                   ii.            CNRI License Limited-Virginia AND the

                  iii.            BeOPEN.COM license Agreement for Python (“BeOPEN License”)

e.      Python 2.0.1 thru 3.2: Licensed by the 4-license stack consisting of the

                     i.            CWI License, AND the

                   ii.            CNRI License Limited-Virginia, AND the

                  iii.            BeOpen license, AND the

                 iv.            Python Software Foundation License (“PSF License”)

Also, we determined that the CNRI Python License listed on opensource.org is out of date and should be removed.  Van Lindberg will make the arrangements for the removal of this license.  

As such, I recommend that we remove the CNRI Python license and link from the SPDX Rev-1 list – its applicability is very limited (Python 0.9.0 through 1.2, which are not available on the Python site other than a single release, 0.9.1 that is described as “a historical relic”).

I do not believe that we have dealt previously with a “License Stack” in a context like a. through e. above.  There are issues with older versions of this license stack (for instance, different legal terms for certain versions of Python depending on whether you have or have not licensed a follow-on version).  These issues make licensing for older versions of Python difficult to ascertain without knowing the full history of versions that were obtained. 

Also, the naming, even of the initial license in the Python stack, is not consistent.  Opensource.org names the initial license “PYTHON SOFTWARE FOUNDATION LICENSE VERSION 2”; the Python site, however, generally suffixes the initial license with the version of Python – but not always.  The use of “Version 2” by opensource.org probably was based on the assumption that Python 2 and above are licensed via the full stack.  However, the initial release of Python 2.0 is licensed under a three-license stack rather than the four-license stack that includes the PSF License.  Also, very small changes have been made to the text of the various licenses depending on the version of Python that was released. 

For all the reasons above, I recommend that we compromise as follows:

For the initial SPDX license list release, I recommend that we only deal with the stack of 4 licenses applicable to Python 2.0.1 through 3.2, and use the following naming conventions:

License Identifier: “Python-2.0”

Full Name: “Python Software Foundation License v2”

“Official” License text is obtained from: http://www.opensource.org/licenses/PythonSoftFoundation

This will cover us in the vast majority of cases.

Tom

Tom Incorvia

tom.incorvia@...

Direct:  (512) 340-1336

Mobile: (408) 499 6850

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 intent, so hopefully we will get additional discussion on this topic.   

One of the intents of normalization is to move the open source community to more standard licenses with less non-material reorganization of words, single-word changes, etc. 

In prior discussions regarding template licenses like BSD, there has always been an intent to parse out items such as organization names.  Other items, like the BSD tendency to swap copyright “Holder” vs. “Owner” and other small but potentially material items would likely be dealt with by an agreement with our legal representatives and the broader SPDX community regarding what the “standard” license is (or should be), and having other variants be bumped to “non-standard” in a package and being required to list the full text.

The expectation is that by standardizing the licenses that will move people in the direction of using the standard rather than the small variants.  Over time, the requirements for tool sophistication with regards to license identification will be reduced – there would essentially be a requirement for an exact match other than agreed upon template items.  Companies that participate in SPDX or want to take advantage of SPDX will benefit by moving towards the standard.

Our “bail out” has consistently been that if the match is insufficient, the entire license text is listed.  We can get a lot of mileage out of a straightforward approach that starts with exact match minus white space, capitalization etc., and then progressing to removal agreed upon template items, and then optionally progressing to small, agreed upon word changes such as single v plural, British use of Z rather than S, etc.  But we only do this with the full agreement of the legal team and possibly some extension in to the SPDX group and open source community – the approach is conservative, with anomalies kicked out into the full text being required.

The net is that the reasonable alternative to tool sophistication is the progressive standardization of the licenses which should occur over time if we get the adoption that we are aiming for.

That aside, the declared license field (the field where the preparer states their interpretation of the license given the relevant facts) is an opportunity to state the license based on broader interpretations that include a more sophisticated tool, access to a particular resource individual such as the author or open source projects attorneys, etc.

My thought is that we start with a basic approach (exact match minus white space and caps, and grow from there) .  If we do this for the beta, that will give us an opportunity to pilot the approach with “friends and family” and have ongoing discussions in our group regarding the viability of the approach, and make necessary adjustments.   

Tom

Tom Incorvia

tom.incorvia@...

Direct:  (512) 340-1336

Mobile: (408) 499 6850

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 contributing the code to the Apache Software Foundation, I cannot use the standard template.

Could the legal team review the text and let me know if this is OK or if you would recommend and changes. 

Thanks,

Gary O’Neall

Proposed Text:

/**

* Copyright (c) ${year} Source Auditor Inc.

* Licensed under the Apache 2.0 License (the "License").

* See the NOTICE file distributed with this work for additional

 * information regarding copyright ownership. you may not use this

 * file except in compliance with the License.  You may obtain a

 * copy of the License at

*

*       http://www.apache.org/licenses/LICENSE-2.0

*

* Unless required by applicable law or agreed to in writing,

* software distributed under the License is distributed on an

* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY

* KIND, either express or implied.  See the License for the

* specific language governing permissions and limitations

* under the License.

*/

Recommended text from the Apache Software Foundation for your reference (http://www.apache.org/legal/src-headers.html#headers):

1.  Licensed to the Apache Software Foundation (ASF) under one

2.         or more contributor license agreements.  See the NOTICE file

3.         distributed with this work for additional information

4.         regarding copyright ownership.  The ASF licenses this file

5.         to you under the Apache License, Version 2.0 (the

6.         "License"); you may not use this file except in compliance

7.         with the License.  You may obtain a copy of the License at

8.   

9.           http://www.apache.org/licenses/LICENSE-2.0

10. 

11.       Unless required by applicable law or agreed to in writing,

12.       software distributed under the License is distributed on an

13.       "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY

14.       KIND, either express or implied.  See the License for the

15.       specific language governing permissions and limitations

16.       under the License.

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");

   you may not use this file except in compliance with the License.

   You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software

   distributed under the License is distributed on an "AS IS" BASIS,

   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

   See the License for the specific language governing permissions and

   limitations under the License.