On Fri, Sep 15, 2017 at 06:02:00AM +0000, Gisi, Mark wrote: > How does one define “accurate and complete” when a package’s “top > level” license does not represent all the files contained within the > package (think license diversity). Although there was no standard > agreement on what “accurate and complete” meant, I got the strong > impression looking at the customer’s spreadsheet that a package’s > top level license was not enough.
If you're going to look through the package an conclude licenses for each file (a good idea when you need this level of detail), then you'll have declared/concluded licenses for each file (or parts of files, if you use snippets). Once you've collected that, an “accurate and complete” license for the package would be the AND-ed combination of all the file/snippet licenses. However, in many cases there will be content in those packages that is not ending up in the final device (e.g. documentation, some license files, project management and policy information, …) that someone shipping a device does not care about. Those file/snippet licenses won't matter to them (unless they are interested in pushing doc patches back upstream, or some such). So I'd recommend just providing those customers with file/snippet granularity and find a workflow that does not bother with “package licenses”. If they can't support that level of granularity, ask them to provide you with a list of files/snippets they care about and only AND their licenses to conclude a selected-project-subset license. If they can't provide a list of files/snippets they care about and can only accept conclusions at the package level, then they're going to get things like “GPL-3.0 AND Verbatim” for a package that includes GPL-3.0 code and the text of the GPL 3.0. But the Verbatim license contains no onerous conditions for someone shipping devices, so they probably won't mind. > There are obviously other types of open source users who do not > share the same compliance challenges as Stakeholder #1. Consider > businesses that provides Software as a Service (SaaS) where the lion > share of the open source runs in the data center as opposed to being > distributed on millions of devices. Think of Facebook, Netflix, > Airbnb, and Lyft. For SaaS provider’s software distribution is > typically not a consideration (except perhaps for the apps you > download onto your phone). The license compliance complexity and > risk profile for a SaaS provider is very low compared to device > makers, their need for SPDX file level licensing information tends > to very low, if at all. Maybe the risk is lower, but they have the same issue. For example, the AGPL-3.0 has explicit requriments for this use case [1]. Where detailed licensing is expensive, SaaS providers end up cutting corners. But if everyone was doing things right, SaaS providers would have the same audit-trail robustness that you attribute to device shippers. > Many of the products you use (or drive) are created by Stakeholder > #1. If they lack sufficient file level licensing information… And nobody is arguing for removing file/snippet granularity (just like nobody is arguing for removing LicenseRef [2]). So what problems does SPDX not address for either of these use cases? Cheers, Trevor [1]: https://github.com/spdx/license-list-XML/blob/f1522b5cc61bde64d9b38af05204fdb93c02eef8/src/AGPL-3.0.xml#L480-L494 [2]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002184.html Subject: Re: GPLv2 - Github example Date: Tue, 12 Sep 2017 09:45:38 -0700 Message-ID: <20170912164538.gg30...@valgrind.tremily.us> -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
