Re: "Scope" of licenses to be covered by SPDX
Peter Bigot <bigotp@...>
On Fri, Jun 29, 2012 at 10:19 AM, Peter Williams
<peter.williams@...> wrote:
license list approach does not meet the needs of Linux distributions
(in the case I raised, OpenEmbedded) because it does not have the
flexibility to succinctly and accurately represent the current
licenses of many GPL packages like gcc and its libraries.
Missing a "BMKL" is one thing. Missing GPL-2.0+-with-GCC-exception
and other GPL variants in common use, and/or requiring all such
variants to be listed explicitly in the spec or named arbitrarily at
the discretion of independent compilers of SPDX files, seems to be a
more fundamental weakness in the technical description of licenses.
Resolution of this is likely to require fairly wide familiarity with
what packages should have supported license descriptions in
combination with legal insight on how to express their licenses.
Adding spdx-tech (which I've just done, and joined) and dropping
general (which I have not done), might make sense, recognizing that
this sort of fragmentation does make it more likely that issues will
not be discovered and resolved in a timely fashion.
Peter
_______________________________________________
Spdx-tech mailing list
Spdx-tech@...
https://lists.spdx.org/mailman/listinfo/spdx-tech
<peter.williams@...> wrote:
On Fri Jun 29 07:04:27 2012, Philip Odence wrote:Agreed. In this general forum we've heard that the existing SPDXIs that really the best choice? This issue seems to be cross functional
Polite request:
Could we shift this discussion off of the General Meeting list and
onto the Legal Team list only?
issue in that it concerns both the license list and the technical details of
representing license data in SPDX files (and in the license list itself). I
think both the legal and tech teams need to collaborate to solve this
problem. Relegating it into any single functional area list will, i fear,
hinder progress to a solution quite significantly.
license list approach does not meet the needs of Linux distributions
(in the case I raised, OpenEmbedded) because it does not have the
flexibility to succinctly and accurately represent the current
licenses of many GPL packages like gcc and its libraries.
Missing a "BMKL" is one thing. Missing GPL-2.0+-with-GCC-exception
and other GPL variants in common use, and/or requiring all such
variants to be listed explicitly in the spec or named arbitrarily at
the discretion of independent compilers of SPDX files, seems to be a
more fundamental weakness in the technical description of licenses.
Resolution of this is likely to require fairly wide familiarity with
what packages should have supported license descriptions in
combination with legal insight on how to express their licenses.
Adding spdx-tech (which I've just done, and joined) and dropping
general (which I have not done), might make sense, recognizing that
this sort of fragmentation does make it more likely that issues will
not be discovered and resolved in a timely fashion.
Peter
_______________________________________________
Spdx-tech mailing list
Spdx-tech@...
https://lists.spdx.org/mailman/listinfo/spdx-tech