Date   

License Meeting Minutes from today are available

Kim Weins <kim.weins@...>
 

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 temporarily CLOSE adding of new licenses.  We need to focus on getting the license repo in place and getting license data loaded and reviewed.  Once that is done, we will define and document the process for adding new licenses to the list and re-open the list.  If you see any egregious items missing from the license list, please let us know ASAP.  Everything else will need to wait for the license repo to get in place — we’re estimating that will be about 8 weeks away.

License List on wiki
http://www.spdx.org/wiki/license-list

Minutes
http://www.spdx.org/wiki/license-subteam-minutes-20101203

Kim

Kim Weins | Senior Vice President, Marketing
kim.weins@...
Follow me on Twitter @KimAtOpenLogic

650 279 0410 | cell
www.openlogic.com
Follow OpenLogic on Twitter @OpenLogic

OpenLogic, Inc.
Headquarters, Broomfield, Colorado





Minimizing discrepancies with Debian's DEP-5

Kate Stewart <kate.stewart@...>
 

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 at: http://dep.debian.net/deps/dep5/

The DEP5 team is tracking the differences with SPDX that they care about
in the following WIKI: http://wiki.debian.org/Proposals/CopyrightFormat
In particular there are some namings of the key licenses that they would
like to harmonize.

Esteban - can you please add looking at the license naming issues to the
agenda of the next legal call?

Thanks, Kate


For today's SPDX Legal Workstream Meeting ...

Esteban Rockett <mgia3940@...>
 

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 these minutes.

- Adding (1) Agenda for 12-Jan-2011 meeting, (2) International Dial-in Numbers, and (3) Proposed Minutes from Last Meeting:


(1) -- 12-Jan-2011 -- Proposed Agenda

(A) Last Meeting Minutes Posted; Additional Week to Review

(B) Update on "Create Process/Method to Add Licenses"

(C) Update on SPDX Metadata License Discussion with Bradley and SPDX Core Team

(D) Continue/Conclude Discussion on Use of SPDX Standard License Acronyms

(E) Issue raised from Tech Workstream on the need for a Legal Policy on "SPDX Not Validating License Recited"

(F) Any New Topics


(2) -- International Dial-in Numbers --

Conference PIN: 0376146

Country

Toll free number

AUSTRALIA

1800003691

AUSTRIA

0800292117

BELGIUM

080077968

CANADA

8772832663

CHINA Netcom (CNC)*

10 800 712 3245
10 800 714 0551

CHINA Telecom (CT)*

10 800 120 3245

DENMARK

80703158

FINLAND

0800770232

FRANCE

0800941694

GERMANY

08001014510

GREECE

0080016122038641

HONG KONG

800967971

HUNGARY

0680015286

INDIA (Bharti) **

000 800 001 2005

INDIA (Reliance)

000195

INDIA (VSNL)

0008001005009

INDIA (ALL OTHER CARRIERS) **

000 800 100 6006

INDONESIA

008800105490 (mobile excluded)

INDONESIA Alternate

0018030113665 (mobile excluded)

IRELAND

1800944115

ISRAEL

1809458641

ITALY

800781687

JAPAN

00531160347

LUXEMBOURG

80023984

MALAYSIA

1 800 802 411

MONACO

80093182

NETHERLANDS

08002658218

NEW ZEALAND

0800447808

NORWAY

80057408

PHILIPPINES

180011100676

POLAND

008001114561

PORTUGAL

800819894

RUSSIA

81080022521012

SINGAPORE

800 120 0250

SOUTH AFRICA

0800990934

SOUTH KOREA

00308140426

SPAIN

900971504

SWEDEN

0201400558

SWITZERLAND

0800563963

TAIWAN, THE REPUBLIC OF CHINA

00801126569

THAILAND

0018001562038641

UNITED KINGDOM

08006920816

UNITED STATES

8772832663


Licensing/Legal Issues for Beta

Kim Weins <kim.weins@...>
 

For the Beta program, there are two additional legal issues I want to raise for the legal team to discuss.

  1. What will be the OSS license for the SPDX tools we are providing?  (ccing Gary since he wrote them)
  2. Will we need some type of NDA or Beta agreement with our Beta sites that would cover privacy?  For example, if Beta participants are discussing stuff with Beta support team, they may not want that shared.

Can we add these to agenda for next legal call.

Thanks
Kim


Re: Licensing/Legal Issues for Beta

Gary O'Neall
 

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

 

From: Kim Weins [mailto:kim.weins@...]
Sent: Thursday, January 20, 2011 9:02 AM
To: spdx-legal@...
Cc: Gary O'Neall
Subject: Licensing/Legal Issues for Beta

 

For the Beta program, there are two additional legal issues I want to raise for the legal team to discuss.

  1. What will be the OSS license for the SPDX tools we are providing?  (ccing Gary since he wrote them)
  2. Will we need some type of NDA or Beta agreement with our Beta sites that would cover privacy?  For example, if Beta participants are discussing stuff with Beta support team, they may not want that shared.


Can we add these to agenda for next legal call.

Thanks
Kim


Re: Licensing/Legal Issues for Beta

Kim Weins <kim.weins@...>
 

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:

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.


Re: Licensing/Legal Issues for Beta

Gary O'Neall
 

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

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:

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.


Re: Purpose of licensing info

Philip Odence
 

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, precisely I think, because it was unambiguous. I frankly am not sure of the limitations on Tag (or how Tag is used) but I would be in favor of "LicenseInformationinFile" or "LicenseInfoinFile".


L. Philip Odence
Vice President of Business Development
Black Duck Software, inc.
265 Winter Street, Waltham, MA 02451
Phone: 781.810.1819, Mobile: 781.258.9502

On Feb 8, 2011, at 5:44 PM, Peter Williams wrote:

On Tue, Feb 8, 2011 at 10:41 AM,  <kate.stewart@...> wrote:
  Can I suggest LicenseSeen  rather than LicenseInformation,  as
the name for that field?   Information could get us back into those
ambiguous name discussions for someone seeing this for the first
time - using Seen might make it a bit more explicit that this is what
was seen in the file for those not doing a detailed reading of the
spec.  ;)

I don't love "LicenseSeen" but i agree that "LicenseInformation" a bit
too ambiguous.

  In the case when there is a fragement or some non-standardized
license,  the references in the non-standard-license should be
made with the same syntax, specifically "LICENSE"-N,

We should either stick to one format or not specific the format of
these ids at all.  I lean toward just saying licenses have an id
string and leaving it to the implementations to decide what those ids
look like.  It is likely that specifying the shape of license ids will
make it more difficult to implement rdf/xml (or any other rdf format)
file generators.

Peter
openlogic.com
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx


Re: Purpose of licensing info

kate.stewart@...
 

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

Kate


--- On Tue, 2/8/11, Philip Odence <podence@...> wrote:

From: Philip Odence <podence@...>
Subject: Re: Purpose of licensing info
To: "Peter Williams" <peter.williams@...>
Cc: "Kate Stewart" <kate.stewart@...>, "spdx-legal@..." <spdx-legal@...>, "spdx@..." <spdx@...>, "Esteban Rockett" <mgia3940@...>
Date: Tuesday, February 8, 2011, 5:05 PM

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, precisely I think, because it was unambiguous. I frankly am not sure of the limitations on Tag (or how Tag is used) but I would be in favor of "LicenseInformationinFile" or "LicenseInfoinFile".


L. Philip Odence
Vice President of Business Development
Black Duck Software, inc.
265 Winter Street, Waltham, MA 02451
Phone: 781.810.1819, Mobile: 781.258.9502

On Feb 8, 2011, at 5:44 PM, Peter Williams wrote:

On Tue, Feb 8, 2011 at 10:41 AM,  <kate.stewart@...> wrote:
  Can I suggest LicenseSeen  rather than LicenseInformation,  as
the name for that field?   Information could get us back into those
ambiguous name discussions for someone seeing this for the first
time - using Seen might make it a bit more explicit that this is what
was seen in the file for those not doing a detailed reading of the
spec.  ;)

I don't love "LicenseSeen" but i agree that "LicenseInformation" a bit
too ambiguous.

  In the case when there is a fragement or some non-standardized
license,  the references in the non-standard-license should be
made with the same syntax, specifically "LICENSE"-N,

We should either stick to one format or not specific the format of
these ids at all.  I lean toward just saying licenses have an id
string and leaving it to the implementations to decide what those ids
look like.  It is likely that specifying the shape of license ids will
make it more difficult to implement rdf/xml (or any other rdf format)
file generators.

Peter
openlogic.com
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx


-----Inline Attachment Follows-----

_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx


License text formatting

Peter Williams <peter.williams@...>
 

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 the
exception based licenses, for instance).

I think the license registry should use formatting as similar to
original author's representation as possible. I suggest we start with
extracts from the original source pages (including the html markup
used there). Some of these texts may require some minor
modifications/cleanup in order to integrate into our registries web
pages. To support those changes we can place these texts (with
embedded html markup for formatting) under revision control.

The license registry builder will use both the spread sheet and the
html formatted license html files to produce the full registry pages.

Does that sound reasonable to everyone? If so i'll request another
git repository from the linux foundation to house this data and the
associated tools.

Peter
openlogic.com


Python Licensing and SPDX License List

Tom Incorvia
 

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

 



This message has been scanned for viruses by MailController.


Python Licensing and SPDX License List

Tom Incorvia
 

(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

 



This message has been scanned for viruses by MailController.


Purpose of license templatization

Peter Williams <peter.williams@...>
 

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 legal
group can answer it.

The use cases we have so far can be categorized as either ignoring
inconsequential variations (eg, white space differences, alternate
spellings, minor grammatical differences) or ignoring very common, and
well understood, material variations (eg, changes in the name of the
copyright holder).

Support for specifying acceptable material changes seems necessary.
Without it several of the standardized licenses will be effectively
useless because they have organization names, etc embedded in them.
The bsd license is a prime example.

Standardizing approaches for ignoring inconsequential variations has
much lower value. It will be extremely difficult to do well and tools
can handle this problem without a standard. In fact, most tools
already have sophisticated techniques for recognizing licenses while
ignoring trivial variations. Those techniques are probably superior
to the rather basic normalization mechanisms we are going to be able
to specify. Tools are unlikely to adopt any approach suggested in the
spec because that would reduce the quality of their results.

Designing, testing and documenting even a relatively simple minded
english language normalization algorithm is non-trivial. (If we need
to support any other languages that will, of course, add to the level
of effort.) Much of the effort required to design and implement such
a normalization scheme will fall on people who are already critical
resources for the beta release of the spec.

We should seriously consider if a license normalization algorithm is
worth the cost. (Particularly with an eye to the opportunity costs.)
I don't think specifying how tools/people should deal with
inconsequential variations in license text is worth the effort. Tools
will quickly evolve, or more likely have already have evolved,
techniques equivalent or superior to anything we will specify.

If it does turn out that a standardized normalization mechanism is
required, it would be just as easy to implement post beta or in
version 2 as it is to implement it now.

Peter
openlogic.com


Re: Purpose of license templatization

Tom Incorvia
 

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

 

-----Original Message-----
From: spdx-legal-bounces@... [mailto:spdx-legal-bounces@...] On Behalf Of Peter Williams
Sent: Wednesday, March 02, 2011 10:20 PM
To: spdx-legal@...
Subject: Purpose of license templatization

 

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 legal

group can answer it.

 

The use cases we have so far can be categorized as either ignoring

inconsequential variations (eg, white space differences, alternate

spellings, minor grammatical differences) or ignoring very common, and

well understood, material variations (eg, changes in the name of the

copyright holder).

 

Support for specifying acceptable material changes seems necessary.

Without it several of the standardized licenses will be effectively

useless because they have organization names, etc embedded in them.

The bsd license is a prime example.

 

Standardizing approaches for ignoring inconsequential variations has

much lower value.  It will be extremely difficult to do well and tools

can handle this problem without a standard.  In fact, most tools

already have sophisticated techniques for recognizing licenses while

ignoring trivial variations.  Those techniques are probably superior

to the rather basic normalization mechanisms we are going to be able

to specify.  Tools are unlikely to adopt any approach suggested in the

spec because that would reduce the quality of their results.

 

Designing, testing and documenting even a relatively simple minded

english language normalization algorithm is non-trivial.  (If we need

to support any other languages that will, of course, add to the level

of effort.)  Much of the effort required to design and implement such

a normalization scheme will fall on people who are already critical

resources for the beta release of the spec.

 

We should seriously consider if a license normalization algorithm is

worth the cost.  (Particularly with an eye to the opportunity costs.)

I don't think specifying how tools/people should deal with

inconsequential variations in license text is worth the effort.  Tools

will quickly evolve, or more likely have already have evolved,

techniques equivalent or superior to anything we will specify.

 

If it does turn out that a standardized normalization mechanism is

required, it would be just as easy to implement post beta or in

version 2 as it is to implement it now.

 

Peter

openlogic.com

_______________________________________________

Spdx-legal mailing list

Spdx-legal@...

https://fossbazaar.org/mailman/listinfo/spdx-legal

 

 

This message has been scanned for viruses by MailController - www.MailController.altohiway.com


Re: Purpose of license templatization

Peter Williams <peter.williams@...>
 

On Thu, Mar 3, 2011 at 5:31 AM, Tom Incorvia
<tom.incorvia@...> wrote:

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.
I like the goal but i don't see how standardizing a license
normalization algorithm designed to remove non-material variations
advances this goal.

In prior discussions regarding template licenses like BSD, there has always
been an intent to parse out items such as organization names.
I think everyone agrees we need to handle this case.

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.
Having a registry of licenses with standardized text (particularly
good, well formatted, cut-and-pastable text) may increase the use of
those licenses. However, i don't think we can assume that license
variations will ever be reduced to point that users will be able to do
without sophisticated matching. Even it that does happen someday, it
is not the world we live in today.

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.
Maybe. Personally, i doubt we will ever see the day when there are
few license variation than there are now.

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.
If we did this, what would a non-match due to a non-material variation
mean? (Say some "a"s where switched to "an"s.)

Could i, as a human, look at it and decide that it is clearly one of
the standard licenses and so produce an spdx file in when the licenses
in file and concluded licenses both reference the standard license?
Or would i be forced to use a non-standard license (even though is is
clearly one of the standard licenses)?


Peter
openlogic.com


typo: identifier GFDL-1.2 appears twice in spdx_licenselist_v1.6.xls

Bill Schineller <bschineller@...>
 

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 Schineller
Knowledge Base Manager
Black Duck Software Inc.
T: +1.781.810.1829
F: +1.781.891.5145
E: bschineller@...
http://www.blackducksoftware.com


Review of Apache license notice included in source files

Gary O'Neall
 

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.

 

 


FW: Review of Apache license notice included in source files

Gary O'Neall
 

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.

 

 

From: Gary O'Neall [mailto:gary@...]
Sent: Sunday, March 13, 2011 3:39 PM
To: 'spdx-legal@...'
Subject: Review of Apache license notice included in source files

 

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.

 

 


Today's Agenda Legal WorkStream

Esteban Rockett <mgia3940@...>
 

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 Author/Creator??? -- (additional fields permissible)
(b) - Confidentiality Statement (also see "author comments field" or notion of a metadata license field) ???
(c) - Copyright in Comments (author and review) (if non-confidential; free; non-attributable???)


(4) Review and Discuss --- Guidelines for "Templatizing" licenses



Re: Today's Agenda Legal WorkStream

dmg
 



On Wed, Mar 23, 2011 at 7:40 AM, Esteban Rockett <mgia3940@...> wrote:
Agenda Legal WorkStream

(4) Review and Discuss --- Guidelines for "Templatizing" licenses



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, but in some cases, variants in grammar: past vs present
tense, use of word "software", "product", "program", "library" in the same place.



--dmg

 

_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx




--
--dmg

---
Daniel M. German
http://turingmachine.org

1 - 20 of 3280