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
