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-tech mailing list Spdx-tech@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-tech