Consider the situation where a supplier that wants to provide an
library as an object file and the headers and a purchaser would like
to get package and license information for that library in spdx
format. Or the situation where a developer downloads a binary
distribution of an open source project and would like get package and
license information for that library in spdx format for the
corporate/project governance processes.

Clearly there are not going to be copyright notices/license
declarations in most object files. However, object files have
significant licensing implications for their users. (For example, if
the source from which it is was built was gpl -- either intentionally,
or because it included some other gpl code.)

Should the spdx file for a "binary" package show the license
information of an object file as the union of the license information
for all the source file used to create the object file?

And do we
expect that the package license information for a "binary" package
would be the same as the license information for the "source" package
from which the binary is built?

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

I am starting to the that the interaction of licenses is too intricate
for use to support using multiple fields. It seems like you could
easily end up with conjunctions and disjunctions between the licenses
in the detect, declared and inferred licensing information.

Perhaps we should collapse those three fields in to a single field.
Doing so would allow the complete licensing information for a
file/package to be represented in a clear, precise and explicit way.

Is distinguishing the mechanism by which a license was discovered
required for spdx version 1? If so we could provide a way to describe
how licenses where discovered that is separate from the complete
license information. If not we could save ourselves the work at delay
that feature until version 2.

Peter
openlogic.com

On Thu, Jan 6, 2011 at 10:06 AM, Kate Stewart
<kate.stewart@...> wrote:

On Thu, 2011-01-06 at 09:25 -0700, Peter Williams wrote:

Consider the situation where a supplier that wants to provide an
library as an object file and the headers and a purchaser would like
to get package and license information for that library in spdx
format.  Or the situation where a developer downloads a binary
distribution of an open source project and would like get package and
license information for that library in spdx format for the
corporate/project governance processes.

Clearly there are not going to be copyright notices/license
declarations in most object files.  However, object files have
significant licensing implications for their users.  (For example, if
the source from which it is was built was gpl -- either intentionally,
or because it included some other gpl code.)

True.   There are some cases though where a scan of the binary reveals
the copyright/license in the comments (made so explicitly by the build
system) "od filename | grep" is your friend here.

Should the spdx file for a "binary" package show the license
information of an object file as the union of the license information
for all the source file used to create the object file?

Not necessarily - since sometimes the binary is build with the selection
of a specific license in mind.

Since a binary is one file, the use of the inferred license field we've
been talking about might be appropriate here as well.

And do we
expect that the package license information for a "binary" package
would be the same as the license information for the "source" package
from which the binary is built?

Likely to be the common case I would guess, but since source may be "or"
license based, and someone selects one license explicitly - if we have a
way to discover it, we should reflect it.   Example I'm thinking of is
dual licensed library GPL and BSD.  If statically bound, quite a
difference whether the library has been build with intention to be BSD
instead of GPL.

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

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

I completely agree that trying to interpret and represent the interaction
of licenses should be outside the scope of SPDX 1.0.  There are two
reasons for this:
1. It can be rather complex to represent the complete analysis since the
interaction may depend on the usage of a specific component and we have
already decided (early on) not to include usage information in SPDX 1.0
2. The license interaction analysis may require legal interpretation of
some of the license clauses

It still may make sense, however, to have a way of representing when there
is an explicit license declaration in a file.  We could go back to only
capturing explicit licenses and not including any inferred licenses, but
we would loose some analysis information which would be very nice to
convey.

BTW - when I think about the detected and inferred licenses, I am not
thinking as much about license interactions as much as capturing a clear
intent by the author to license a file under a particular license.  For
example, if an author (or copyright owner) has a file in a directory
stating all files in this directory are under a particular license and the
files within that directory have the same copyright and no conflicting
information.

On Fri, Jan 7, 2011 at 11:45 AM, Gary O'Neall <gary@...>

We are probably thinking a little differently on interaction. The use

I have in mind have to do with representing technical analysis on the
interaction between components that affect the license terms.

I usually think of spdx as a way to express the conclusions of a
technical analysis. Actually representing the analysis itself sounds
hard. :)

One requirement I think we should have on SPDX is any logic or judgment

by the auditor creating the SPDX document should be called out as a

(distinct from a fact). This would allow for independent verification

such judgments. If we were to apply this requirement to the licensing

package level (acknowledging that we have not discussed or agreed to

requirement), I think we would need to either include the "inferred"
information or not include the interaction based licensing information

the interaction analysis requires judgment.

I don't think non-facts have a place in spdx files. However, facts
can be established though the use of logic. If a file contains 100
contiguous lines that are identical to 100 contiguous lines in the
linux kernel and those lines where committed to the kernel before they
where committed to project of the package being analyzed then it is a
*fact* that the file must be licensed under gpl2. This is true
regardless of the licensing statements of the file, directory, or
project. It is important that spdx be able to represent this sort of
fact. It is also important that spdx be able to represent all the
licenses provided by the package regardless of how the fact of those
licenses was determined.

It would be nice to be able to represent the evidence for each license
in an spdx file. A model to record such evidence seems like it would
be non-trivial to develop. It also feels like an evidentiary model
could be implemented as an extension to a conclusions only spdx.
(Either as an separate standard or in a future version of spdx.) I'd
rather an evidentiary model be out of scope for v1 because spdx can
provide a lot of value without it and i think it will be straight
forward to add it later.

Agree with both of your comments in general - we don't want to try to build
a model to include all of the logic.  I do, however, think it is important
to capture where assumptions or judgment is being applied (even if we don't
capture the logic behind the judgment).  Having the inferred license type
would be sufficient for this.

Gary

-----Original Message-----
From: spdx-tech-bounces@...
[mailto:spdx-tech-bounces@...] On Behalf Of Kate Stewart
Sent: Friday, January 07, 2011 1:18 PM
To: Peter Williams
Cc: spdx-tech@...
Subject: Re: Licensing data for object files

On Fri, 2011-01-07 at 13:35 -0700, Peter Williams wrote:

On Fri, Jan 7, 2011 at 11:45 AM, Gary O'Neall <gary@...>

wrote:

We are probably thinking a little differently on interaction.  The use

cases

I have in mind have to do with representing technical analysis on the
interaction between components that affect the license terms.

I usually think of spdx as a way to express the conclusions of a
technical analysis.  Actually representing the analysis itself sounds
hard. :)

esp. for version 1.  :)

One requirement I think we should have on SPDX is any logic or judgment

used

by the auditor creating the SPDX document should be called out as a

judgment

(distinct from a fact).  This would allow for independent verification

of

such judgments.  If we were to apply this requirement to the licensing

at

package level (acknowledging that we have not discussed or agreed to

such a

requirement), I think we would need to either include the "inferred"
information or not include the interaction based licensing information

since

the interaction analysis requires judgment.

I don't think non-facts have a place in spdx files.  However, facts
can be established though the use of logic.  If a file contains 100
contiguous lines that are identical to 100 contiguous lines in the
linux kernel and those lines where committed to the kernel before they
where committed to project of the package being analyzed then it is a
*fact* that the file must be licensed under gpl2.  This is true
regardless of the licensing statements of the file, directory, or
project.  It is important that spdx be able to represent this sort of
fact.  It is also important that spdx be able to represent all the
licenses provided by the package regardless of how the fact of those
licenses was determined.

Inferred field proposal at file level should cover this I think.
Question in my mind is how many "reasons" for the inference do we want
to accept in version 1?   It takes a sophisticated tool and knowledge
base ;)  to generally detect code in other place matches code in
specific package.   Not everyone has this capability.  However if the
capability is there - marking it as "inferred" license - base on code
matching seems a good way of capturing the fact that there is evidence
that another license is in play, other than what may be declared.

It would be nice to be able to represent the evidence for each license
in an spdx file.  A model to record such evidence seems like it would
be non-trivial to develop.  It also feels like an evidentiary model
could be implemented as an extension to a conclusions only spdx.
(Either as an separate standard or in a future version of spdx.)  I'd
rather an evidentiary model be out of scope for v1 because spdx can
provide a lot of value without it and i think it will be straight
forward to add it later.

Agree.   I think for version 1, a set of known reasons on the inferred
license field is probably the most we should aim for, for right now.

Kate

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

Can you give some examples of the "assumptions or judgements" you have in
mind?

In the context of the license, I can think of 2 examples:

File containing copyleft code snippet:
  - Fact1: File A contains several lines of code
  - Fact2: A subset of the code in file A matches code in file B
  - Fact3: File A does not contain any license statement
  - Fact4: File B contains an explicit LGPL license statement
  - Fact5: File B does not exist in the package described by the SPDEX
document.
In this case, I would not call it a fact that file A is under the LGPL
license, but rather a judgement call by the person who identified those
lines as being copied.  Note - this example assumes that the author of
File A is not the person making the judgement.