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

Difference between revisions of "Legal Team/Minutes/2012-07-25"

From SPDX Wiki
Jump to: navigation, search
(Convert to MediaWiki syntax)
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
−
<p><strong>Attendees:</strong>
+
== Attendees ==
−
<ul>
+
−
<li> </li>
+
−
</ul>
+
−
</p>
+
−
<p><strong>Agenda:</strong></p>
+
  
−
<p>1) New License Request for GNU Affero General Public License v3.0 or later (AGPL-3.0+) from Tom Incorvia</p>
+
* Karen Copenhaver
 +
* Peter Williams
 +
* Tom Incorvia
 +
* Jason Buttara
 +
* Michael Herzog
 +
* ??
  
−
<p>2) Discuss concept of SPDX Lite - pros and cons</p>
+
== Agenda ==
  
−
<p>3) Additional Licenses from FSF List. Paul did a first pass on this and Jilayne also added notes and checked against the Fedora list. Legal team needs to go through the licenses highlighted in blue text on the spreadsheet included below and decide which ones should be added.  
+
1) New License Request for GNU Affero General Public License v3.0 or later (AGPL-3.0+) from Tom Incorvia
−
<ul>
+
 
−
<li>this process raises the question as to: should checking various other lists as part of the license addition process? And if so, which other lists (besides Fedora)?</li>
+
Unanimous agreement – with thanks to Tom for identifying the problem.
 +
 
 +
2) Discuss concept of SPDX Lite - pros and cons
 +
 
 +
* No one wanted to create anything by the name SPDX Lite. Unanimously agreed that we should “kill” the use of that name.
 +
* We all agreed that there needed to be a way to start an SPDX for a large project and be able to crowd source or permit the SPDX to evolve toward completion.
 +
* We all agreed that there would be SPDX’s that were more or less incomplete early in the adoption cycle.
 +
* We all agreed that we need to provide tools/instructions that avoid the impression that anyone must individually type or cut and paste the same entry over and over into many different boxes in order to prepare something that is called an SPDX.
 +
* We all agree that the SPDX specification should be consistent with the full set of information that reasonable, knowledgeable lawyers would want to have access to in order to provide advice to their clients regarding the software that is represented in the SPDX. And we agree that “mandatory fields” is the best way to communicate what we consider to be the full set. “Optional” communicates that this additional level of information is only required by companies that are going overboard.
 +
* It is not clear to us that it will be possible to provide all of the information in the “mandatory fields” early in the adoption cycle and we do not want it to be an overly painful process to complete the fields for which there is no information. We think there is more discussion/education/explanation required with respect to what the default should be in a field that is not completed (blank and stays blank, blank but cannot stay blank, or some equivalent of “no assertion”). [We know that there was a lot of thought given to the permissible entries in the various fields. We wonder whether we were focused on a future time where fully vetted SPDX’s for most projects are readily available and did not take into consideration this early adoption period where incomplete information will still be the norm.]
 +
* We should also look at the definition/explanation provided for the word or phrase that is selected to communicate that there has been no work performed in a field. “No assertion” may mean that a lot of work has been done to determine that there is no information available or it might mean that there has been no work to determine whether the information is available. To focus work on the areas where no efforts to identify the correct information have been made, you need to be able to distinguish between the two.
 +
* We wondered whether there could eventually be a way to indicate that the code and SPDX came directly from the originating project and are unchanged.
 +
* We agree that we should take other steps to communicate to projects the importance of putting licensing information in every file.
 +
 
 +
[[Category:Legal|Minutes]]
 +
[[Category:Minutes]]

Latest revision as of 17:41, 5 March 2013

Attendees

  • Karen Copenhaver
  • Peter Williams
  • Tom Incorvia
  • Jason Buttara
  • Michael Herzog
  •  ??

Agenda

1) New License Request for GNU Affero General Public License v3.0 or later (AGPL-3.0+) from Tom Incorvia

Unanimous agreement – with thanks to Tom for identifying the problem.

2) Discuss concept of SPDX Lite - pros and cons

  • No one wanted to create anything by the name SPDX Lite. Unanimously agreed that we should “kill” the use of that name.
  • We all agreed that there needed to be a way to start an SPDX for a large project and be able to crowd source or permit the SPDX to evolve toward completion.
  • We all agreed that there would be SPDX’s that were more or less incomplete early in the adoption cycle.
  • We all agreed that we need to provide tools/instructions that avoid the impression that anyone must individually type or cut and paste the same entry over and over into many different boxes in order to prepare something that is called an SPDX.
  • We all agree that the SPDX specification should be consistent with the full set of information that reasonable, knowledgeable lawyers would want to have access to in order to provide advice to their clients regarding the software that is represented in the SPDX. And we agree that “mandatory fields” is the best way to communicate what we consider to be the full set. “Optional” communicates that this additional level of information is only required by companies that are going overboard.
  • It is not clear to us that it will be possible to provide all of the information in the “mandatory fields” early in the adoption cycle and we do not want it to be an overly painful process to complete the fields for which there is no information. We think there is more discussion/education/explanation required with respect to what the default should be in a field that is not completed (blank and stays blank, blank but cannot stay blank, or some equivalent of “no assertion”). [We know that there was a lot of thought given to the permissible entries in the various fields. We wonder whether we were focused on a future time where fully vetted SPDX’s for most projects are readily available and did not take into consideration this early adoption period where incomplete information will still be the norm.]
  • We should also look at the definition/explanation provided for the word or phrase that is selected to communicate that there has been no work performed in a field. “No assertion” may mean that a lot of work has been done to determine that there is no information available or it might mean that there has been no work to determine whether the information is available. To focus work on the areas where no efforts to identify the correct information have been made, you need to be able to distinguish between the two.
  • We wondered whether there could eventually be a way to indicate that the code and SPDX came directly from the originating project and are unchanged.
  • We agree that we should take other steps to communicate to projects the importance of putting licensing information in every file.
Retrieved from "https://wiki.spdx.org/index.php?title=Legal_Team/Minutes/2012-07-25&oldid=2054"