On Mon, Apr 20, 2020 at 6:04 PM Gary O'Neall <[email protected]> wrote:
> Hi Tony, > > > > Great to hear you are utilizing the SPDX license ID’s. Happy to help > support the effort. > > > > In terms of your licensing question below, my interpretation is the same > as yours – no need for attribution when using, transforming, or > distributing the SPDX license list data. Note – IANL (I am not a lawyer), > just a technical contributor to the tools generating the data. Our intent > is to make the license list data easy to use with minimal requirements – > especially for build tools like Bazel. > That is what I expected. Thanks for the confirmation. > > > I haven’t had a chance to review the Google doc in much detail, but I will > echo Alexios comment on supporting the full license expressions. We found > this to be important at a package level and even when describing licenses > at a file level. > > > > The full license expression definition can be found in the spec Appendix > IV <https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60>. > Yes. We are starting with AND only for now, because we can fully wrap our heads around how that can be used for automated compliance checking and audit. The expectation is that when importing a third party package, a human examines the license terms and picks the applicable one for their code base in the case of a choice. I am looking forward to the day when the project achieves enough usage such that supporting more complex declarations is a needed use case. > Let us know if you have any other questions. > We could turn to the use of LicenseA OR LicenseB. What are your expectations for how that applies to a final application that must comply with notice or other requirements? Notice is the easy case, since we just have to bundle the author provided license text with the code, let's say an iOS app. As the publisher of the app, surely we want to pick one, rather than say either LicenseA or LicenseB. That would leave things too ambiguous to the consumer. Then, where do we make the choice of what license. We could leave it to the app developer, but they are not lawyers, so each team using the code with an OR license would have to pick it. This would result in a legal review per app rather than once at import. We could have automatic tooling pick the "best" one for any app. I think anything that ends up with a solver for the set of licenses is going to be complex, and thus harder to get lawyers to buy in on. I understand the need to capture the reality of some interesting license terms in the wild. What I am looking for is how we can mechanically answer if a particular application is compliant with the terms of all its dependencies. > > > Cheers, > Gary > > > > *From:* [email protected] <[email protected]> *On Behalf Of > *Alexios Zavras > *Sent:* Monday, April 20, 2020 4:52 AM > *To:* [email protected] > *Cc:* [email protected] > *Subject:* Re: [spdx-tech] Support for SPDX in Bazel > > > > Hi Tony; delighted to see Bazel’s interest in SPDX. > > > > Please keep in mind that actual licenses of software components are **license > expressions**, not single licenses; a typical example might be “MPL-2.0 > OR EPL-2.0”. As such, in your design, the license field might not have a > direct correspondence to a single license_kind. The GDoc you shared seems > to only mention that a license can be a “concatenation” of license texts, > which is effectively an AND expression. > > > -- zvr > > > > *From:* [email protected] <[email protected]> *On Behalf Of > *Tony Aiuto via lists.spdx.org > *Sent:* Friday, 17 April, 2020 21:12 > *To:* [email protected] > *Subject:* [spdx-tech] Support for SPDX in Bazel > > > > Hello all: > > > > I have a question, but first let me give you some background so I can > pinpoint in. > > > > I work on Bazel, Google's OSS version of their build tool. > https://bazel.build/. > > > > I've been leading a project to replace the license compatibility checking > baked into our internal tool 10+ years ago with a system that allows more > flexibility. The new design is OSS friendly and we have just released the > first preview of it at https://github.com/bazelbuild/rules_license. > > > > More about the project: License Checking with Bazel > <https://docs.google.com/document/d/1uwBuhAoBNrw8tmFs-NxlssI6VRolidGYdYqagLqHWt8/edit> > > > > I am sure you will agree that for OSS license declarations to work, all > projects that call something, say, Apache-2.0 use the same identifier for > Apache-2.0. I do not want to invent a new namespace of identifiers for the > Bazel community, so I am planning to recommend that Bazel users use the > SPDX identifier space. > > > > Towards that end, I am about to add placeholder declarations to our > project that effectively encourage people to align with the SPDX names. You > can see the details in https://github.com/bazelbuild/rules_license/pull/3. > The important part is that we add a file licenses/spdx/BUILD (attached) > that contains many stanza of the form > > > > license_kind( > > name = "0BSD", > > conditions = [], > > url = "https://spdx.org/licenses/0BSD.html";, > > ) > > > > This is mechanically built from the SPDX JSON data file > <https://github.com/spdx/license-list-data/raw/master/json/licenses.json>. > > > > So, now the questions. > > - The input file is under CC0-1.0 (according to your docs) > - That is input to a tool of mine, which produces this BUILD file. > - From my understanding, CC0 implies that I need no attribution > alongside the generated file. That seems to be the rationale as described > in https://wiki.spdx.org/images/SPDX-TR-2014-1.v1.1.pdf > - Is that right? > > My objective is to encourage Bazel users to use SPDX identifiers whenever > possible, but I also must ensure that any use of our tool does not add new > license compliance issues to their products. In general, this is not an > issue, as Bazel is never linked into anyone's project. It is merely used to > orchestrate the build. But, since this is all about licenses, it can't > hurt to double check. > > > > Cheers, > > Tony > > Intel Deutschland GmbH > Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany > Tel: +49 89 99 8853-0, www.intel.de > Managing Directors: Christin Eisenschmid, Gary Kershaw > Chairperson of the Supervisory Board: Nicole Lau > Registered Office: Munich > Commercial Register: Amtsgericht Muenchen HRB 186928 > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3865): https://lists.spdx.org/g/Spdx-tech/message/3865 Mute This Topic: https://lists.spdx.org/mt/73090505/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
