Date
1 - 2 of 2
Representing vs Interpreting Licenses
|
I am responding to the recent email threads discussing licenses for
object files and "license interaction":
Overall we need to remember that the mission of SPDX for the foreseeable future is be enable people to represent (assert) the license information for any kind of software, but it is not our role to interpret or validate in any way whether an asserted license in an SPDX file is correct or factual. The validity of the asserted information is beyond our scope because it will always require legal and technical interpretation which is best left to the supplier and customer. There may be some future role for an organization like SPDX to do the latter, but that would be the subject to a long business and legal discussion at some future time. The spec should, however, allow an SPDX producer to document the Supplier's basis for the asserting a particular license for a component, including potentially documenting that the effective license for a component is LGPL or GPL due to software interaction and linking. It seems reasonable to expect that when a supplier sends an SPDX file for a product that there will be cases where the supplier-asserted license is in fact based on the context of using that component in that product in a particular way (e.g. with libraries linked in a certain way for that product). There are many other common cases to consider such as how a Supplier decides to assert a license for a file that does not contain a specific license notice. I suspect that most of us who audit software for a living will have pretty similar guidelines for how we decide to assert the license for a set (directory?) of files where only some contain a license notice, but SPDX is not providing that guidance so the focus should be on reasonably documenting how the Supplier/SPDX-producer concluded what license applies. Rather than trying to squeeze too much information in a few fields, we probably need to take a step back and talk about how to enhance the SPDX spec to handle the real-world complexity of a Software BOM which is arbitrarily complex in depth and breadth. Showing the licenses from product-level down to components and the lowest-level sub-components will ultimately be the most accurate way to represent the data. There is actually a remarkably good Software BOM data standard that the Technical Team may want to consider as input for this area - it is called PDX (Product Data Exchange) and is pretty widely adopted in the electronics/discrete mfg industry (which is pretty much also our primary business domain). Two good links for PDX are: Overview: http://xml.coverpages.org/pdx.html (Note that many of the links within the text are "dead", but still a good intro)Regards, Michael -- Michael J. Herzog +1 650 380 0680 | mjherzog_at_nexB.com nexB [Open by Design] http://www.nexb.com CONFIDENTIALITY NOTICE: This e-mail (including attachments) may contain information that is proprietary or confidential. If you are not the intended recipient or a person responsible for its delivery to the intended recipient, do not copy or distribute it. Please permanently delete the e-mail and any attachments, and notify us immediately at (650) 380-0680. |
|
|
|
Peter Williams <peter.williams@...>
On Fri, Jan 7, 2011 at 1:09 PM, Michael J Herzog <mjherzog@...> wrote:
I am responding to the recent email threads discussing licenses for objectTotally agree. The spec should, however, allow an SPDX producer to document the Supplier'sDon't providing the licenses provide enough information for the consumer of the spdx to determine for themselves what their obligations are based on whatever legal theories they happen to hold? There is little reason to assume that spdx producers and consumers will agree on these legal issues. It seems safest to encourage full disclosure. Further, whether particular interactions and linking strategies actually change the licensing terms seems to be a legal opinion and often up for some debate. On the other side of things it seems like it would be rather difficult (read: impossible) to enumerate the different types of interactions which might have impacts. If i am wrong about the difficultly of this task i suppose i would not be opposed in principle. However, given our time line it seems imprudent to open yet another can of worms for this release. I think such capabilities could be added as an extension and/or future version of the spec. Rather than trying to squeeze too much information in a few fields, weWhat sort of information scenarios are are you thinking about that are not representable in spdx at the moment? (Anyone that can think of any of these should enter a bug so we do not forget it. I the one i could think of, <http://bugs.linux-foundation.org/show_bug.cgi?id=616>.) Showing the licenses fromI don't think i understand what you mean. There is |
|
|