On 9/30/10 11:57 AM, dmg wrote:

Thanks Peter for your clarifications.

I think this shows, that the ones creating the files will be _making_
decisions.

I completely agree. I think anyone that has actual tried to analyze a package for copyright/license info knows that a lot of judgment calls are required.

In this case, several have been made:

1. Files without a license share the license of the project
2. If a file A specifies that its license is in B, then license(A) == license(B)

I would say that as license(A) = license-specified-by(B). For example, the text of GPL v3, <http://www.gnu.org/licenses/gpl.html>, is licensed under terms quite different from GPL. So if license(A) -> B where B is a file containing just the text of the GPL then license(A) = GPL but license(B) = "Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed."

3. Even thought there is no perfect textual comparison of the license
(aside from whitespace) the licenses have been considered to be
equivalent.

This is the only sane thing to do. Unfortunately, there are situations in which reasonable people could disagree about whether two license texts are really the same license or not.

These are very good reasons why standardizing text of licenses by
inclusion seems to me like a bad idea.

Here i disagree. I think standardizing some license texts is a Good Thing. No one will be force to reference those standard licenses. If you find a license that you believe is materially different from the all the texts in the public repo that license can be included in the spdx file as a non-standard license. Having a set of licenses with standardized names allows much more efficient communication and greater interoperability.

The standard should be updated to allow the license text to be included in all situations. Even for standard licenses. That way an spdx producer could include the variations found, even if the producer considers them materially the same.

Peter

---dmg

On Thu, Sep 30, 2010 at 9:06 AM, Peter Williams
<peter.williams@...> wrote:

On 9/29/10 2:32 PM, dmg wrote:

This is good. It can start some discussion on the standard.

First, one question:

I scanned the file for zlib and I found some issues with it, but I
think are worth discussing:

1. Some files do not contain a license, yet they are marked as one:

We assume any that file that does not contain explicit license info and does
not match any of the open source in our database is licensed under the
declared license of the project. In this case the Zlib license.

2. Some files refer to zlib.h as the file with a license. Now, if the
SHA1 of the file does not change, I would presume (as a user) that I
don't need to scan it again, which is good. But what if zlib.h
changes? Would it be useful in the SPDX to
use a "reference" field to denote such a thing?

I think this is outside the scope of the spdx proper. Many of the decisions
about what licenses govern a file will be made on criteria other than an
explicit license declaration, direct or indirect. For example, some part of
a file might be matched against a database of open source and that open
source file might have a license associated with it.

In the short term this could be handled as comment on the file object. It
might be an interesting follow on project to create an extension to allow
expressing the decision criteria for why a particular license was chosen.

3. Is it the same to include a license than to refer to a license?

We treat those the same. This is a policy issue to be worked out between
the producer and the consumers of the spdx file. I think the spec should
avoid specify the copyright/license analysis process. Spdx should just
provide a way to express the results of such an analysis.

4. In some files the zlib iicense varies slightly:


This software is provided 'as-is', without any express or implied
warranty. In no event will the author be held liable for any damages
arising from the use of this software.

and in others

This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.

This also feels like a policy issue to me. We treat those as the same.

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

Thanks Peter for your clarifications.

I think this shows, that the ones creating the files will be _making_
decisions. In this case, several have been made:

1. Files without a license share the license of the project
2. If a file A specifies that its license is in B, then license(A) == license(B)
3. Even thought there is no perfect textual comparison of the license
(aside from whitespace) the licenses have been considered to be
equivalent.

These are very good reasons why standardizing text of licenses by
inclusion seems to me like a bad idea.

---dmg

On Thu, Sep 30, 2010 at 9:06 AM, Peter Williams
<peter.williams@...> wrote:

On 9/29/10 2:32 PM, dmg wrote:

This is good. It can start some discussion on the standard.

First, one question:

I scanned the file for zlib and I found some issues with it, but I
think are worth discussing:

1.  Some files do not contain a license, yet they are marked as one:

We assume any that file that does not contain explicit license info and does
not match any of the open source in our database is licensed under the
declared license of the project.  In this case the Zlib license.

2. Some files refer to zlib.h as the file with a license. Now, if the
SHA1 of the file does not change, I would presume (as a user) that I
don't need to scan it again, which is good. But what if zlib.h
changes? Would it be useful in the SPDX to
use a "reference" field to denote such a thing?

I think this is outside the scope of the spdx proper.  Many of the decisions
about what licenses govern a file will be made on criteria other than an
explicit license declaration, direct or indirect.  For example, some part of
a file might be matched against a database of open source and that open
source file might have a license associated with it.

In the short term this could be handled as comment on the file object. It
might be an interesting follow on project to create an extension to allow
expressing the decision criteria for why a particular license was chosen.

3. Is it the same to include a license than to refer to a license?

We treat those the same.  This is a policy issue to be worked out between
the producer and the consumers of the spdx file.  I think the spec should
avoid specify the copyright/license analysis process.  Spdx should just
provide a way to express the results of such an analysis.

4. In some files the zlib iicense varies slightly:


  This software is provided 'as-is', without any express or implied
  warranty.  In no event will the author be held liable for any damages
  arising from the use of this software.

and in others

  This software is provided 'as-is', without any express or implied
  warranty.  In no event will the authors be held liable for any damages
  arising from the use of this software.

This also feels like a policy issue to me.  We treat those as the same.

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

--
--dmg

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

In <https://fossbazaar.org/pipermail/spdx/2010-September/000116.html> dmg brought up and interesting question regarding how similar two license texts need to be before they can be considered the same license.  This got me thinking about the proposed license templates.

I am increasing uncomfortable with the idea of spdx specify a mechanism intended to support recognition of licenses.  That very idea seems fraught with peril, both technically and legally. 

What constitutes similar enough to treat as a single license is a policy decision.  Risk averse organizations with a high profile might choose a relatively high bar for sameness, while less risk averse organizations will probably prefer a lower bar.  I think setting these policies should be left to the producers and consumers of spdx files.  These parties are the only ones with enough information to do it effectively.

There are a few situations where a light weight template syntax in the license text field itself would be useful.  Such a syntax would allow a way to demarcate really obvious and uncontentious replaceable parts of the license.  Square brackets around a description of the replaceable element would probably sufficient.  For example, the 3 clause bsd license text would look like this

Copyright (c) [YEAR], [OWNER]
All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

• Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
• Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
• Neither the name of the [ORGANIZATION] nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

This would allow spdx to provide canonical forms of licenses without trying to specify policy issues.

Peter Williams
<http://openlogic.com>

On 9/29/10 2:32 PM, dmg wrote:

This is good. It can start some discussion on the standard.

First, one question:

I scanned the file for zlib and I found some issues with it, but I
think are worth discussing:

1. Some files do not contain a license, yet they are marked as one:

We assume any that file that does not contain explicit license info and does not match any of the open source in our database is licensed under the declared license of the project. In this case the Zlib license.

2. Some files refer to zlib.h as the file with a license. Now, if the
SHA1 of the file does not change, I would presume (as a user) that I
don't need to scan it again, which is good. But what if zlib.h
changes? Would it be useful in the SPDX to
use a "reference" field to denote such a thing?

I think this is outside the scope of the spdx proper. Many of the decisions about what licenses govern a file will be made on criteria other than an explicit license declaration, direct or indirect. For example, some part of a file might be matched against a database of open source and that open source file might have a license associated with it.

In the short term this could be handled as comment on the file object. It might be an interesting follow on project to create an extension to allow expressing the decision criteria for why a particular license was chosen.

3. Is it the same to include a license than to refer to a license?

We treat those the same. This is a policy issue to be worked out between the producer and the consumers of the spdx file. I think the spec should avoid specify the copyright/license analysis process. Spdx should just provide a way to express the results of such an analysis.

4. In some files the zlib iicense varies slightly:


This software is provided 'as-is', without any express or implied
warranty. In no event will the author be held liable for any damages
arising from the use of this software.

and in others

This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.

This also feels like a policy issue to me. We treat those as the same.

Peter Williams
<http://openlogic.com>

Done

As per the discussion during Friday's License call, I typed up a
guideline/description of what should/should not be included in the
License Notes field on the License List:


License Notes field guidelines
- For the purpose of describing what kinds of information
should or can be included in this field and what kinds of information
should not be included here with examples of both.

The information included in the License Notes field should consist of
factual information only. Opinions or interpretations of the license
should not be included here. Factual information may include such
information as the dates of a revision or new version if that
information is not already included in the license itself or a note
stating that the license has been deprecated by the author. For
example, the BSD license might have a Note stating that the original
advertising clause was deleted as of July 22, 1999. (see "Historical
Note" here for full example:
http://opensource.org/licenses/bsd-license.php) This field may also be
used to communicate updates to the license due to typographical errors
or other data entry alterations (that are not changes to the license by
the license's author).

Information that in any way interprets the license or draws conclusions
as to what the license requires is not appropriate. For example, links
to interpretations of the license, even if written by the license's
author, should not be included here. Much external information exists
on license interpretation and we do not want to favor one over the
other. Likewise, statements that the license is a dedication to the
public domain should not be included. This is a determination for the
recipient of the license to make, not the SPDX creator.

A name change would be an improvement.

I see your point about not complicating navigation for existing participants. However, having a top level page that basically free of content, as the participation page is now, is a waste.

Would moving the minutes and spec development links to the top of the partcipation page and then adding a "Getting Started" section below those links work? It would make the navigation links for on going participation even easier to get to than they are now. And it would be really obvious for potential participants how to go about getting started.

Peter

Peter,

Does anyone object to moving the content of <http://www.spdx.org/wiki/spdx/participation-guidelines> to the main participation page, <http://www.spdx.org/node/2240>? A page named "guidelines" seems more like a code of conduct than a page containing the details of how one would go about participating. And the extra click seem unnecessary.

Peter

This is good. It can start some discussion on the standard.

First, one question:

I scanned the file for zlib and I found some issues with it, but I
think are worth discussing:

1. Some files do not contain a license, yet they are marked as one:

dmg@i:/tmp/zlib-1.2.5$ more contrib/minizip/zip.c
/* zip.c -- IO on .zip files using zlib
Version 1.1, February 14h, 2010
part of the MiniZip project - (
http://www.winimage.com/zLibDll/minizip.html )

Copyright (C) 1998-2010 Gilles Vollant (minizip) (
http://www.winimage.com/zLibDll/minizip.html )

Modifications for Zip64 support
Copyright (C) 2009-2010 Mathias Svensson ( http://result42.com )

For more info read MiniZip_info.txt

Changes
Oct-2009 - Mathias Svensson - Remove old C style function prototypes
Oct-2009 - Mathias Svensson - Added Zip64 Support when creating new
file archives
Oct-2009 - Mathias Svensson - Did some code cleanup and refactoring
to get better overview of some functions.
Oct-2009 - Mathias Svensson - Added zipRemoveExtraInfoBlock to
strip extra field data from its ZIP64 data
It is used when recreting zip archive
with RAW when deleting items from a zip.
ZIP64 data is automaticly added to
items that needs it, and existing ZIP64 data need to be removed.
Oct-2009 - Mathias Svensson - Added support for BZIP2 as
compression mode (bzip2 lib is required)
Jan-2010 - back to unzip and minizip 1.0 name scheme, with
compatibility layer

*/


------------
2. Some files refer to zlib.h as the file with a license. Now, if the
SHA1 of the file does not change, I would presume (as a user) that I
don't need to scan it again, which is good. But what if zlib.h
changes? Would it be useful in the SPDX to
use a "reference" field to denote such a thing?

---------
3. Is it the same to include a license than to refer to a license?

---
4. In some files the zlib iicense varies slightly:


This software is provided 'as-is', without any express or implied
warranty. In no event will the author be held liable for any damages
arising from the use of this software.

and in others

This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.

--dmg


On Wed, Sep 29, 2010 at 12:52 PM, Philip Odence
<podence@...> wrote:

I moved it to
Home » Wiki » Software Package Data Exchange (SPDX) » Spec
Development » Sandbox For Sharing Examples, Ideas, Etc.
Not sure if it way my knowledge or permissions or both, but anyway, it's
there.
Good stuff, Peter.



On Sep 29, 2010, at 3:45 PM, Peter Williams wrote:

Hi all,

I have posted some examples, along with some notes about them at
<http://spdx.org/wiki/openlogic-spdx-10-beta-examples>.  The examples
are intended to conform to the 1.0 beta version of the spec except that
we used sha-256 checksums -- rather than sha-1 -- to identify the files.

I was not able to figure out how to add that page to the examples
sandbox.  (Perhaps i do not permission to do that? )   Would someone
with more knowledge of (or permissions with) the wiki do that for me?

Comments and feedback are welcome.

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


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

--
--dmg

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

On Wed, 2010-09-29 at 16:24 -0400, Philip Odence wrote:

Now that you have appeared in the NY Times with a Boston Red Sox hat
http://www.nytimes.com/2010/09/26/business/26ping.html?src=busln, I
feel I must respond quickly.

Actually I was replying to Peter's question. I guess that your mail
client might not have shown that it was a reply.

But, to actually make it a question: is there an archive available of
the period before August 10?

armijn

--
---------------------------------------------------------------------------
armijn@... || http://www.gpl-violations.org/
---------------------------------------------------------------------------

On 9/29/10 2:16 PM, Armijn Hemel wrote:

https://fossbazaar.org/pipermail/spdx/

Sweet, thanks. I added a link to the participation guidelines page in the wiki. Hopefully one more link will make google pick it up.

Peter

On Wed, 2010-09-29 at 14:04 -0600, Peter Williams wrote:

Is the spdx mailing list archived anywhere? I was looking to read up
on
the past debate around a particular part of the spec and I was unable
to
locate an archive of the mailing list.

https://fossbazaar.org/pipermail/spdx/

armijn

--
---------------------------------------------------------------------------
armijn@... || http://www.gpl-violations.org/
---------------------------------------------------------------------------

Is the spdx mailing list archived anywhere? I was looking to read up on the past debate around a particular part of the spec and I was unable to locate an archive of the mailing list.

It is crucial that the forum in which so many of the decisions regarding SPDX are made be archived and made available on the web. The lack of an archive on the web make our work quite opaque to anyone who is not currently subscribed. It also hides this effort from people who might be interested because none of it shows up in search engines.

It is possible to turn on an archiving feature in our list server?

Peter Williams
<http://openlogic.com>

Hi all,

I have posted some examples, along with some notes about them at <http://spdx.org/wiki/openlogic-spdx-10-beta-examples>. The examples are intended to conform to the 1.0 beta version of the spec except that we used sha-256 checksums -- rather than sha-1 -- to identify the files.

I was not able to figure out how to add that page to the examples sandbox. (Perhaps i do not permission to do that? ) Would someone with more knowledge of (or permissions with) the wiki do that for me?

Comments and feedback are welcome.

Peter Williams
<http://openlogic.com>

Colleagues,
Sorry for sending out the call-in details late.
The call will be at the usual Tuesday time the RDF subgroup has been
meeting the last 3 weeks.
We'll be discussing mechanism for representing the machine-readable
ontology within a single XHTML document. Perhaps Peter can demonstrate
online?


SPDX RDF Sub-group Mtg 4
(TODAY) Tuesday Sept 28, 11AM eastern time

Toll-free dial-in number (U.S. and Canada): (877) 435-0230
International dial-in number: (253) 336-6732
Conference code: 7833942033

URL to join meeting:
http://blackducksoftware.na6.acrobat.com/r70154570/


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

Kate is doing her best to fix it up asap.