On Tue, Oct 29, 2013 at 3:22 PM, Philippe Ombredanne wrote: >>> As a component consumer, I may want to treat these upstream obligations at >>> a >>> more coarse level, and treat larger things possibly as big as a Linux >>> distro >>> or a JBoss as one aggregate component, and may or may not care about finer- >>> grained details passed to me from upstream.
Coarse level compliance is an interesting term. It suggests a level of compliance quality where one chooses to comply with some applicable licenses but not others. For example, saying the Android platform is available under just the Apache-2.0 license, when in fact the GPL, LGPL, BSD and various other licenses are also relevant to an Android distributor creates a problem. Although I struggle with the suggestion that coarse level compliance is an acceptable approach, I do understand why this approach has been taken. For years open source consumers have struggle to obtain high quality license information. For years many they have been force to pursue coarse level compliance because that was the only level achievable with reasonable efforts. Actually, this was not true in the *earliest of days* when the Big 4 (FSF, Apache Foundation, Eclipse, Kernel.org) supplied the lion share of open source software. The quality of license information for their respected packages was (and still is) very high. The Big 4 achieve this by exercising good discipline with respect to managing licensing information in their code base (e.g., including a license notice in every file). The problem stems from many other projects demonstrating considerable less discipline with respect to managing licensing info. SPDX is fueling a paradigm shift with respect to the compliance quality level one can achieve with reasonable efforts. The current version, SPDX 1.2, does two important things: 1) delivers much higher quality license information (e.g., at the file level) and 2) sheds light on how good or poorly licensing information has been managed by a project or initiative. When better licensing information is available, coarse level compliance is not an approach I would recommend. On Tue, Oct 29, 2013 at 3:22 PM, Philippe Ombredanne wrote: >>> IMHO, you guys are coming from two different points of view but >>> are talking the same language. I agree. I chose a bottom up approach where Michel chose a more traditional top down approach. In the end I find Michel's position to be more than reasonable when faced with less than perfect information. I wanted to build on Michel's example to highlight how we can all do better than coarse level compliance. Many organizations actually want to do more. Before SPDX it was not feasible to achieve with reasonable efforts. The advent of SPDX has fundamentally changed this. I will follow up next with a proposal on how SPDX data can be leveraged to solve the JBoss coarse level compliance problem. - Mark Mark Gisi | Wind River | Senior Intellectual Property Manager Tel (510) 749-2016 | Fax (510) 749-4552 -----Original Message----- From: spdx-legal-boun...@lists.spdx.org [mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Philippe Ombredanne Sent: Tuesday, October 29, 2013 3:22 PM Cc: spdx-tech@lists.spdx.org; SPDX-legal Subject: Re: Revisiting the SPDX license representation syntax (Package vs. Program license) On Tue, Oct 29, 2013 at 5:39 PM, RUFFIN, MICHEL (MICHEL) <michel.ruf...@alcatel-lucent.com> wrote: > I just want to point out that we are mostly dealing with package level > system If I take the example of JBoss in our FOSS DB you get the > following (see below) So the concluded license is just LGPL-2.1 AND(+) > a lot of dependencies Michel: My 2 cents, I would possibly express this either: * as lplg-2.1+ {mit bsd-3-clause and a long list of licenses .... } using my 'little language' OR * I would create a new license internally which I would call the something like the JBossAS-4.2.1 license. This would be a 'composite' of all the licenses contained in this large component, abstracting the details. AFAIK, there is nothing in SPDX that would prohibit you from creating your own licenses for this purpose. You could even provide both the long list of SPDX ids AND the composite text. >> On lundi 28 octobre 2013 23:23 Gisi, Mark [mailto:mark.g...@windriver.com] >> wrote: >> All in all, Boolean expressions provide an effective way to describe >> licensing of programs, libraries and source files (linkable distributable >> components). >> Package licensing is an ill defined concept. Often a package can be >> viewed as a box containing a collection of components each >> *potentially* subject to different licensing terms. We will need to >> address these differences in the upcoming licensing breakout session. Mark and Michel: IMHO, you guys are coming from two different points of view but are talking the same language. As a Linux distro vendor (or a JBoss distro provider) I may want to express the obligations of the packages I distribute (be they mine or from upstream) at a finer level of granularity, which would be possible unit of discrete consumption. This would then be helpful to downstream consumers such they could make informed decisions when they consume, use, build or link with components I provide in my distro. As a component consumer, I may want to treat these upstream obligations at a more coarse level, and treat larger things possibly as big as a Linux distro or a JBoss as one aggregate component, and may or may not care about finer-grained details passed to me from upstream. Because in the end, somehow, your product (that you may see as several fine-grained components) may be one of the many components for my own product or application and I may see as just one single component. I think that SPDX does and should in spirit and letter support both approaches. -- Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.com DejaCode Enterprise at http://www.dejacode.com nexB Inc. at http://www.nexb.com _______________________________________________ Spdx-legal mailing list spdx-le...@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal _______________________________________________ Spdx-tech mailing list Spdx-tech@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-tech
