"Scope" of licenses to be covered by SPDX
|
Michael J Herzog <mjherzog@...>
Michel and Soeren,
toggle quoted message
Show quoted text
The scope of SPDX is to convey information about any kind of software license: open source, "free proprietary" like Sun/Oracle BCL or Oracle OTN, and other proprietary/ commercial. You cannot provide a complete Bill of Materials for a software package or product without a way to report the license for every component (at some appropriate level of detail). The scope of the License List is, however, necessarily a subset of licenses for many reasons. The current focus of the License List is to identify the most common Open Source licenses and to develop techniques for dealing with close variants of BSD, MIT, Apache and similar licenses (the latter techniques are referred to as "templatization" in the current Legal Team discussions). I personally think that we should add the most common "free proprietary" licenses to the License List, but to the best of my knowledge that is an open item for future/continued discussion. Regards, Michael Michael J. Herzog +1 650 380 0680 | mjherzog_at_nexB.com DejaCode Enterprise http://www.dejacode.com nexB Inc. at http://www.nexb.com CONFIDENTIALITY NOTICE: This e-mail (including attachments) may contain information that is proprietary or confidential. If you are not the intended recipient or a person responsible for its delivery to the intended recipient, do not copy or distribute it. Please permanently delete the e-mail and any attachments, and notify us immediately at (650) 380-0680. On 6/22/2012 7:35 AM, Steve Cropper
(stcroppe) wrote:
|
|
|
|
RUFFIN MICHEL
Michael, for me it is not a subject of discussion
I am discussing with third party companies since 10 years on the subject and if you ignore open-source like license or “free proprietary” license, the discussion is void. OSI compliant licenses are a part of the pb and they are not too much a pb because we understand them other licenses are much more problems.
Michel.Ruffin@..., PhD De : Michael J Herzog [mailto:mjherzog@...]
Michel and Soeren, Michael J. Herzog +1 650 380 0680 | mjherzog_at_nexB.comDejaCode Enterprise http://www.dejacode.comnexB Inc. at http://www.nexb.com CONFIDENTIALITY NOTICE: This e-mail (including attachments) may contain information that is proprietary or confidential. If you are not the intended recipient or a person responsible for its delivery to the intended recipient, do not copy or distribute it. Please permanently delete the e-mail and any attachments, and notify us immediately at (650) 380-0680.
On 6/22/2012 7:35 AM, Steve Cropper (stcroppe) wrote:
|
|
|
|
Soeren_Rabenstein@...
Dear Michael
The topic we are having here (but will probably move to another forum, potentially the LF Open compliance Program) is to create industry wide accepted common contract clauses for supply contracts that involve FOSS. The purpose of such clauses are, amongst others, to clearly separate the proprietary licenses (which are often included in such supply contracts) from the FOSS licenses, have suppliers take responsibility for their own FOSS license compliance, and generally raise awareness for FOSS license compliance. Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”.
Cheers Sören
Von: RUFFIN, MICHEL (MICHEL) [mailto:michel.ruffin@...]
Michael, for me it is not a subject of discussion
I am discussing with third party companies since 10 years on the subject and if you ignore open-source like license or “free proprietary” license, the discussion is void. OSI compliant licenses are a part of the pb and they are not too much a pb because we understand them other licenses are much more problems.
Michel.Ruffin@..., PhD De : Michael J Herzog
[mailto:mjherzog@...]
Michel and Soeren, Michael J. Herzog
+1 650 380 0680 | mjherzog_at_nexB.com
DejaCode Enterprise http://www.dejacode.com
nexB Inc. at http://www.nexb.com
CONFIDENTIALITY NOTICE: This e-mail (including attachments) may contain information that is proprietary or confidential. If you are not the intended recipient or a person responsible for its delivery to the intended recipient, do not copy or distribute it. Please permanently delete the e-mail and any attachments, and notify us immediately at (650) 380-0680.
On 6/22/2012 7:35 AM, Steve Cropper (stcroppe) wrote:
|
|
|
|
Mike Milinkovich
Re: " Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”. "
The Free Software Foundation (FSF) and the Open Source Initiative (OSI) are the two organizations which, in my opinion, define what FOSS is. Any attempt to define FOSS which do not take into account the collective wisdom and process that went into their respective license lists [1][2] would be a big mistake.
FOSS = Free and Open Source Software, which is the union of software which meets the definition of Free Software[3] and Open Source Software[4].
I have seen attempts in the past to expand the definition of FOSS beyond licensing to include other parameters such as open development processes and the like. They've all been spectacularly unsuccessful. There be dragons.
In the interest of full disclosure, in addition to by day job at the Eclipse Foundation, I am also a Director of the OSI.
[1] http://www.gnu.org/licenses/license-list.html#SoftwareLicenses [2] http://opensource.org/licenses/alphabetical [3] http://www.gnu.org/philosophy/free-sw.html [4] http://opensource.org/docs/osd
Mike Milinkovich Executive Director Eclipse Foundation, Inc. Office: +1.613.224.9461 x228 Mobile: +1.613.220.3223 blog: http://dev.eclipse.org/blogs/mike/ twitter: @mmilinkov
Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”.
|
|
|
|
Philip Odence
I sometimes skirt the issue by broadly referring "software that is freely available on the web."
When one is talking about new projects, picking licenses, and the like, it makes sense to steer/limit to OSI approved licenses. When, on the other hand, the use case is documenting all the "junk" that may be found in a package and associated licenses (as
with SPDX), it makes sense to be expansive in order to be able to represent software under licenses outside the OSI definition.
So, the SPDX license list goes beyond the OSI list. Our goal has been to handle the bulk of license one might run into in a software package. And, the spec provides a mechanism for handling licenses not on the list, by essentially including the text of
the license. One of the benefits of the License List is that it keeps the size of the SPDX file down by not requiring the text to be included.
I don’t think we've come to grips with where we draw the line on the size of the license list. With the 150 or so license on there now, we certainly handle the vast majority of components, but for user convenience, more is better. I think when we get comfortable
with our understanding of the effort involved in maintaining the list and adding new licenses, we'll be in a better position to say how big we want the list to be.
From: Mike Milinkovich <mike.milinkovich@...>
Organization: Eclipse Foundation Reply-To: Mike Milinkovich <mike.milinkovich@...> Date: Fri, 22 Jun 2012 13:24:42 -0400 To: <Soeren_Rabenstein@...>, Michel Ruffin <Michel.Ruffin@...>, Michael Herzog <mjherzog@...>, <spdx@...> Subject: RE: "Scope" of licenses to be covered by SPDX Re: " Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”. "
The Free Software Foundation (FSF) and the Open Source Initiative (OSI) are the two organizations which, in my opinion, define what FOSS is. Any attempt to define FOSS which do not take into account the collective wisdom and process that went into their respective license lists [1][2] would be a big mistake.
FOSS = Free and Open Source Software, which is the union of software which meets the definition of Free Software[3] and Open Source Software[4].
I have seen attempts in the past to expand the definition of FOSS beyond licensing to include other parameters such as open development processes and the like. They've all been spectacularly unsuccessful. There be dragons.
In the interest of full disclosure, in addition to by day job at the Eclipse Foundation, I am also a Director of the OSI.
[1] http://www.gnu.org/licenses/license-list.html#SoftwareLicenses [2] http://opensource.org/licenses/alphabetical [3] http://www.gnu.org/philosophy/free-sw.html [4] http://opensource.org/docs/osd
Mike Milinkovich Executive Director Eclipse Foundation, Inc. Office: +1.613.224.9461 x228 Mobile: +1.613.220.3223 blog: http://dev.eclipse.org/blogs/mike/ twitter: @mmilinkov
Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”.
|
|
|
|
RUFFIN MICHEL
We do not discuss or put into question the FSF and OSI definitions of FOSS (I know them by heart, I understand the philosophy behind them and respect them). We try to make a definition of what should be the scope of software subject to the clause that we put in the contracts and it is broader than open source traditional definition. So perhaps the term “FOSS” is chocking you for that. But this is why we need to discuss and standardize. For me FOSS is not “Free and Open source Software” it is “Free and/or Open source software”; Now should we select another term in this context? I am totally open minded on this. Call it NPS (non-purchased software) or whatever, but even this wording will not fit with shareware for instance.
Michel Michel.Ruffin@..., PhD De : Mike Milinkovich [mailto:mike.milinkovich@...]
Re: " Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”. "
The Free Software Foundation (FSF) and the Open Source Initiative (OSI) are the two organizations which, in my opinion, define what FOSS is. Any attempt to define FOSS which do not take into account the collective wisdom and process that went into their respective license lists [1][2] would be a big mistake.
FOSS = Free and Open Source Software, which is the union of software which meets the definition of Free Software[3] and Open Source Software[4].
I have seen attempts in the past to expand the definition of FOSS beyond licensing to include other parameters such as open development processes and the like. They've all been spectacularly unsuccessful. There be dragons.
In the interest of full disclosure, in addition to by day job at the Eclipse Foundation, I am also a Director of the OSI.
[1] http://www.gnu.org/licenses/license-list.html#SoftwareLicenses [2] http://opensource.org/licenses/alphabetical [3] http://www.gnu.org/philosophy/free-sw.html [4] http://opensource.org/docs/osd
Mike Milinkovich Executive Director Eclipse Foundation, Inc. Office: +1.613.224.9461 x228 Mobile: +1.613.220.3223 blog: http://dev.eclipse.org/blogs/mike/ twitter: @mmilinkov
Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”.
|
|
|
|
Peter A. Bigot
With respect to the license list, an issue I happened to notice this
morning is that items on it appear to reflect a very flat concept of a license when there are options, e.g. GPL-2.0-with-GCC-exception and GPL-2.0+. The problem is that this approach limits the succinct representation of licenses. For example, if a package (e.g., libgcc) is GPL 2.0 or later version with runtime exception, there is no GPL-2.0+-with-GCC-exception. If a package also incorporates the GPL classpath exception, that isn't listed either. It's not obvious that this can be fixed by disjunction or conjunction of the listed licenses (wouldn't GPL-2.0+ AND GPL-2.0-with-GCC-exception be simple GPL-2.0?) In a future revision, perhaps the concept of a base license with a set of options (GPL-2.0, option for later revision, exception for runtime library, exception for classpath) would be more expressive. It could also cut down on the size of the list. Peter On Fri, Jun 22, 2012 at 12:48 PM, Philip Odence <podence@...> wrote: I sometimes skirt the issue by broadly referring "software that is freely |
|
|
|
RUFFIN MICHEL
Well I have not really through how this extend to the SPDX standard. But if you look at Blackduck protext tool there is probably 1500 to 2000 licenses described, Palamida is around 1500 (if I am not mistaking). The SPDX standard must cope with all these licenses, it should not limit itself to the 60 to 70 OSI certified licenses. It would be useless. Now if you have not a standard name for these licenses it is not a big issue but in fact they exist “Sun binary license”, “ Sun entitlement license”, “Oracle binary licence”, “ Oracle OTN license” (might also be “Oracle technology network” license) , “Alcatel-Lucent public license” …
Michel.Ruffin@..., PhD De : Philip Odence [mailto:podence@...]
I sometimes skirt the issue by broadly referring "software that is freely available on the web."
When one is talking about new projects, picking licenses, and the like, it makes sense to steer/limit to OSI approved licenses. When, on the other hand, the use case is documenting all the "junk" that may be found in a package and associated licenses (as with SPDX), it makes sense to be expansive in order to be able to represent software under licenses outside the OSI definition.
So, the SPDX license list goes beyond the OSI list. Our goal has been to handle the bulk of license one might run into in a software package. And, the spec provides a mechanism for handling licenses not on the list, by essentially including the text of the license. One of the benefits of the License List is that it keeps the size of the SPDX file down by not requiring the text to be included.
I don’t think we've come to grips with where we draw the line on the size of the license list. With the 150 or so license on there now, we certainly handle the vast majority of components, but for user convenience, more is better. I think when we get comfortable with our understanding of the effort involved in maintaining the list and adding new licenses, we'll be in a better position to say how big we want the list to be.
From: Mike Milinkovich <mike.milinkovich@...>
Re: " Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”. "
The Free Software Foundation (FSF) and the Open Source Initiative (OSI) are the two organizations which, in my opinion, define what FOSS is. Any attempt to define FOSS which do not take into account the collective wisdom and process that went into their respective license lists [1][2] would be a big mistake.
FOSS = Free and Open Source Software, which is the union of software which meets the definition of Free Software[3] and Open Source Software[4].
I have seen attempts in the past to expand the definition of FOSS beyond licensing to include other parameters such as open development processes and the like. They've all been spectacularly unsuccessful. There be dragons.
In the interest of full disclosure, in addition to by day job at the Eclipse Foundation, I am also a Director of the OSI.
[1] http://www.gnu.org/licenses/license-list.html#SoftwareLicenses [2] http://opensource.org/licenses/alphabetical [3] http://www.gnu.org/philosophy/free-sw.html [4] http://opensource.org/docs/osd
Mike Milinkovich Executive Director Eclipse Foundation, Inc. Office: +1.613.224.9461 x228 Mobile: +1.613.220.3223 blog: http://dev.eclipse.org/blogs/mike/ twitter: @mmilinkov
Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”.
_______________________________________________ Spdx mailing list Spdx@... https://lists.spdx.org/mailman/listinfo/spdx |
|
|
|
Mike Milinkovich
Re: "“Free and Open source Software” it is “Free and/or Open source software”; "
I understand that. Which is why I said it is the union, rather than the intersection.
In my highly simplified view, the FSF defines what free software is, and the OSI defines what open source software is. If you're going to include a bunch of other stuff that does not meet either of those definitions, then please (pretty please!) do not refer to your definition as FOSS or FLOSS. Find some other name, because that one's taken.
From: RUFFIN, MICHEL (MICHEL) [mailto:michel.ruffin@...]
Sent: June-22-12 1:55 PM To: mike.milinkovich@...; Soeren_Rabenstein@...; mjherzog@...; spdx@... Subject: RE: "Scope" of licenses to be covered by SPDX
We do not discuss or put into question the FSF and OSI definitions of FOSS (I know them by heart, I understand the philosophy behind them and respect them). We try to make a definition of what should be the scope of software subject to the clause that we put in the contracts and it is broader than open source traditional definition. So perhaps the term “FOSS” is chocking you for that. But this is why we need to discuss and standardize. For me FOSS is not “Free and Open source Software” it is “Free and/or Open source software”; Now should we select another term in this context? I am totally open minded on this. Call it NPS (non-purchased software) or whatever, but even this wording will not fit with shareware for instance.
Michel Michel.Ruffin@..., PhD De : Mike Milinkovich [mailto:mike.milinkovich@...]
Re: " Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”. "
The Free Software Foundation (FSF) and the Open Source Initiative (OSI) are the two organizations which, in my opinion, define what FOSS is. Any attempt to define FOSS which do not take into account the collective wisdom and process that went into their respective license lists [1][2] would be a big mistake.
FOSS = Free and Open Source Software, which is the union of software which meets the definition of Free Software[3] and Open Source Software[4].
I have seen attempts in the past to expand the definition of FOSS beyond licensing to include other parameters such as open development processes and the like. They've all been spectacularly unsuccessful. There be dragons.
In the interest of full disclosure, in addition to by day job at the Eclipse Foundation, I am also a Director of the OSI.
[1] http://www.gnu.org/licenses/license-list.html#SoftwareLicenses [2] http://opensource.org/licenses/alphabetical [3] http://www.gnu.org/philosophy/free-sw.html [4] http://opensource.org/docs/osd
Mike Milinkovich Executive Director Eclipse Foundation, Inc. Office: +1.613.224.9461 x228 Mobile: +1.613.220.3223 blog: http://dev.eclipse.org/blogs/mike/ twitter: @mmilinkov
Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”.
|
|
|
|
RUFFIN MICHEL
Ok now we have an understanding, any suggestion ?
Michel.Ruffin@..., PhD De : Mike Milinkovich [mailto:mike.milinkovich@...]
Re: "“Free and Open source Software” it is “Free and/or Open source software”; "
I understand that. Which is why I said it is the union, rather than the intersection.
In my highly simplified view, the FSF defines what free software is, and the OSI defines what open source software is. If you're going to include a bunch of other stuff that does not meet either of those definitions, then please (pretty please!) do not refer to your definition as FOSS or FLOSS. Find some other name, because that one's taken.
From: RUFFIN, MICHEL (MICHEL)
[mailto:michel.ruffin@...]
Sent: June-22-12 1:55 PM To: mike.milinkovich@...; Soeren_Rabenstein@...; mjherzog@...; spdx@... Subject: RE: "Scope" of licenses to be covered by SPDX
We do not discuss or put into question the FSF and OSI definitions of FOSS (I know them by heart, I understand the philosophy behind them and respect them). We try to make a definition of what should be the scope of software subject to the clause that we put in the contracts and it is broader than open source traditional definition. So perhaps the term “FOSS” is chocking you for that. But this is why we need to discuss and standardize. For me FOSS is not “Free and Open source Software” it is “Free and/or Open source software”; Now should we select another term in this context? I am totally open minded on this. Call it NPS (non-purchased software) or whatever, but even this wording will not fit with shareware for instance.
Michel Michel.Ruffin@...,
PhD De : Mike Milinkovich [mailto:mike.milinkovich@...]
Re: " Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”. "
The Free Software Foundation (FSF) and the Open Source Initiative (OSI) are the two organizations which, in my opinion, define what FOSS is. Any attempt to define FOSS which do not take into account the collective wisdom and process that went into their respective license lists [1][2] would be a big mistake.
FOSS = Free and Open Source Software, which is the union of software which meets the definition of Free Software[3] and Open Source Software[4].
I have seen attempts in the past to expand the definition of FOSS beyond licensing to include other parameters such as open development processes and the like. They've all been spectacularly unsuccessful. There be dragons.
In the interest of full disclosure, in addition to by day job at the Eclipse Foundation, I am also a Director of the OSI.
[1] http://www.gnu.org/licenses/license-list.html#SoftwareLicenses [2] http://opensource.org/licenses/alphabetical [3] http://www.gnu.org/philosophy/free-sw.html [4] http://opensource.org/docs/osd
Mike Milinkovich Executive Director Eclipse Foundation, Inc. Office: +1.613.224.9461 x228 Mobile: +1.613.220.3223 blog: http://dev.eclipse.org/blogs/mike/ twitter: @mmilinkov
Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”.
|
|
|
|
Mike Milinkovich
RMS - "Random May-be-free Stuff"?
Wait. That acronym's also taken. Darn!
<<Sorry, I just couldn't resist :) >>
More seriously: my apologies, but no good name or acronym immediately comes to mind.
From: RUFFIN, MICHEL (MICHEL) [mailto:michel.ruffin@...]
Sent: June-22-12 2:58 PM To: mike.milinkovich@...; Soeren_Rabenstein@...; mjherzog@...; spdx@... Subject: RE: "Scope" of licenses to be covered by SPDX
Ok now we have an understanding, any suggestion ?
Michel.Ruffin@..., PhD De : Mike Milinkovich [mailto:mike.milinkovich@...]
Re: "“Free and Open source Software” it is “Free and/or Open source software”; "
I understand that. Which is why I said it is the union, rather than the intersection.
In my highly simplified view, the FSF defines what free software is, and the OSI defines what open source software is. If you're going to include a bunch of other stuff that does not meet either of those definitions, then please (pretty please!) do not refer to your definition as FOSS or FLOSS. Find some other name, because that one's taken.
From: RUFFIN, MICHEL (MICHEL) [mailto:michel.ruffin@...]
We do not discuss or put into question the FSF and OSI definitions of FOSS (I know them by heart, I understand the philosophy behind them and respect them). We try to make a definition of what should be the scope of software subject to the clause that we put in the contracts and it is broader than open source traditional definition. So perhaps the term “FOSS” is chocking you for that. But this is why we need to discuss and standardize. For me FOSS is not “Free and Open source Software” it is “Free and/or Open source software”; Now should we select another term in this context? I am totally open minded on this. Call it NPS (non-purchased software) or whatever, but even this wording will not fit with shareware for instance.
Michel Michel.Ruffin@..., PhD De : Mike Milinkovich [mailto:mike.milinkovich@...]
Re: " Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”. "
The Free Software Foundation (FSF) and the Open Source Initiative (OSI) are the two organizations which, in my opinion, define what FOSS is. Any attempt to define FOSS which do not take into account the collective wisdom and process that went into their respective license lists [1][2] would be a big mistake.
FOSS = Free and Open Source Software, which is the union of software which meets the definition of Free Software[3] and Open Source Software[4].
I have seen attempts in the past to expand the definition of FOSS beyond licensing to include other parameters such as open development processes and the like. They've all been spectacularly unsuccessful. There be dragons.
In the interest of full disclosure, in addition to by day job at the Eclipse Foundation, I am also a Director of the OSI.
[1] http://www.gnu.org/licenses/license-list.html#SoftwareLicenses [2] http://opensource.org/licenses/alphabetical [3] http://www.gnu.org/philosophy/free-sw.html [4] http://opensource.org/docs/osd
Mike Milinkovich Executive Director Eclipse Foundation, Inc. Office: +1.613.224.9461 x228 Mobile: +1.613.220.3223 blog: http://dev.eclipse.org/blogs/mike/ twitter: @mmilinkov
Out of this topic we just discussed (in my understanding) what could be a proper definition of “FOSS”.
|
|
|
|
Jilayne Lovejoy <jilayne.lovejoy@...>
In so far as Phil and Michael's previous comment regarding the SPDX License List – it is correct to say that we have endeavored to include the most common open source licenses (not freeware, shareware,
various abominations of the above, proprietary, or what have you) as stated in the license list description at the top of the page found here: http://spdx.org/wiki/spdx-license-list The goal is not to try
to capture every license you might find, as that would be impossible, but the most commonly found. There are currently 168 licenses on the SPDX License List. We have been discussing coordinating with a few of the community groups to add licenses they may
have, that SPDX doesn't (e.g. Gentoo, Fedora, Debian), but haven't had enough people-power to get this task completed (yet).
When I responded earlier, I did not mention this as I could not remember accurately if we discussed the idea of adding other "free" (but not necessary source-code-is-provided licenses). In any
case, it's certainly something we could discuss, but I think there are some good reasons not to expand too far (which I will raise if and when we have that discussion, instead of rattling on unnecessarily here) That being said, there are probably other licenses
that are not "open source" per se, but commonly found and lumped into that broader category (the Sun/Oracle license come to mind) that perhaps should be added.
In any case, anyone can suggest adding a license via this process: http://spdx.org/wiki/spdx-license-list-process-requesting-new-licenses-be-added
We are largely "under-staffed" and "under-paid," so I would encourage anyone who wants to see the list expanded to get involved.
In regards to Michel's definition of "FOSS" for the purposes of contract negotiations and standardizing clauses – I don't have so much a problem with this name, per se. I
understand the reaction; "FOSS" has ideological underpinnings and is not thought of to include the second and third categories, so this is a bit uncomfortable. But, I guess when looking at it through
my attorney glasses, which is the lens for which these clauses are intended, I can compartmentalize and apply the definition as however it is presented for that particular contract. That is, after all, how contract definitions work. I have certainly
seen contract terms and definitions come across my desk, where I've thought, "well, that's not what I would have called that," but so long as I understand what that word
means in the context of that agreement, it really doesn't matter if it's called "Supercalifragilisticexpialidocious."
Just my two cents.
Jilayne
Jilayne Lovejoy | Corporate Counsel
OpenLogic, Inc. jlovejoy@... | 720
240 4545
From: <RUFFIN>, "MICHEL (MICHEL)" <michel.ruffin@...>
Date: Friday, June 22, 2012 12:57 PM To: "mike.milinkovich@..." <mike.milinkovich@...>, Soeren Rabenstein <Soeren_Rabenstein@...>, "mjherzog@..." <mjherzog@...>, SPDX-general <spdx@...> Subject: RE: "Scope" of licenses to be covered by SPDX
|
|
|
|
Ciaran Farrell
On Sat, 2012-06-23 at 00:23 +0000, Jilayne Lovejoy wrote:
In so far as Phil and Michael's previous comment regarding the SPDXTo chime in on this, at openSUSE we have exactly the problem described above - we'd like to adopt SPDX, but the license list does not provide anywhere need the coverage that we need. What we've done in the interim is create a spreadsheet on Google Docs where we add those licenses we need to track with a SUSE- prefix. We'd hope to push these (or substitutes for those) upstream to the SPDX license list. In response to another idea on this list, I also think it makes sense to use operators like + and - instead of basic strings for license shortnames. It is certainly not consistent that the list contains e.g. GPL-2.0-with-openssl-exception but not GPL-2.0+-with-openssl-exception. Rather than coming up with n- strings for all those licenses out there, surely using an operator would make more sense. In summary, the SPDX format (well, for us as a linux distribution, the SPDX shortnames) looks like it could help provide considerable consistency, but (and this is a huge but) it is currently unusable for linux distributions. Ciaran |
|
|
|
Bradley M. Kuhn <bkuhn@...>
Ciaran Farrell wrote at 15:45 (EDT) on Saturday:
at openSUSE .... we'd like to adopt SPDX, but the license list doesThis is interesting; I'd suspect this might be the case for other distributions, too. Debian, for example, basically has always kept a full text file (.../doc/copyright) to describe the exact licensing situation of its packages. Peter Bigot wrote on Friday: Indeed. I don't even *know* of any package in the world that's licensedWith respect to the license list, an issue I happened to notice this under "GPLv2-only along with any given 'GCC exception'". There is actually *no such thing* as a single "GPL-2.0-with-GCC-exception". The GPLv2'd versions of GCC actually have a patchwork of *different* exceptions that are all worded slightly differently and appear throughout various directories in the sources. When I helped lead the process of drafting the GPLv3 RTL exception, one of our primary goals was to encompass and rectify the differences in the various GPLv2 exceptions for GCC. Meanwhile, one of my proposals during the GPLv3 RTL exception drafting process -- which FSF now does -- is that all exceptions should be versioned. SPDX's license list doesn't account for this at all. SPDX will have to completely rework its monikers and details when new versions of exceptions are released [0]. Meanwhile, I note the obvious additional issue that Peter hinted at but didn't raise explicitly: I'm not aware of any program in the world that's GPLv3-only plus the GCC RTL exception 3.1. GCC itself is currently under "GPLv3-or-later with the GCC Runtime Library Exception 3.1". But even *that* isn't fully accurate as a generalization, because *parts* of GCC are under that license I just stated, but the majority of the code is straight GPLv3-or-later. Having not looked closely at the SPDX license list before, a first analysis shows that it's completely inadequate for representing even the most common licensing situations on some of the most widely used of programs. Indeed, it seems as SPDX's license list stands now, I basically couldn't represent the license of *any* version of GCC except versions from the very early 1990s, and even for those, I'd need to add a license exception or two. (Note, BTW -- and I bet this issue will be of particular interest to the Free Software licensing historians among us -- that the proto-GPL license such as the Emacs Public License, the GCC Public License, and the Nethack Public License aren't on SPDX's license list at all. To the extent that anyone wants to use SPDX's license list as a tool to represent historical versions of software, that's completely impossible, too. Notwithstanding that the Nethack Public License is actually still in active use AFAIK.) [0] Also, note there is, in fact, an RTL exception v3.0, although, I suspect it's not used by any package. It was only the default version "in the wild" for about 6 weeks, which is of course longer than GFDL 1.0's 4 day lifespan as the current version. (Those of you who, like me, were doing Free Software licensing work back in 2000 will remember that widespread confusion in early March 2000; I'm still apologizing for my role in that and various confusions about the GFDL. :) -- -- bkuhn |
|
|
|
Jilayne Lovejoy <jilayne.lovejoy@...>
(I have included the legal list on this response)
toggle quoted message
Show quoted text
This has been discussed a couple times and part of this issue is listed as a "to-do" on the legal page (http://spdx.org/wiki/legal-team-current-issues-last-updated-june-27), namely making sure the license list has capture all the common exceptions to begin with. The concept of having a base license with additive options was discussed (I can't seem to find it in the meeting minutes, but I only looked briefly at this year and it may even have been before that or touched upon tangentially) If memory serves, it wasn't a matter of consensus that this was a bad idea, but there has yet to be a fully thought-out proposal submitted for thorough consideration. So, if you have an idea as to how to implement this idea, while keeping in mind the overall goal of the LIcense List, etc. - that would be great!! Maybe someone else from the legal team can also weigh in here regarding the previous discussions on this topic. - Jilayne On 6/22/12 12:10 PM, "Peter Bigot" <bigotp@...> wrote:
With respect to the license list, an issue I happened to notice this |
|
|
|
Jilayne Lovejoy <jilayne.lovejoy@...>
Do you expect the SPDX License List to cover every license you find? DoesTo chime in on this, at openSUSE we have exactly the problem described any list? It would be great to align your list with the SPDX List (and make sure the short identifiers are consistent, as the intent it to not changes those, once they are published on the list) - please see the link above as to how to add a license or join a legal call so we can figure out how best to proceed. Just posted a response to the original response on this. What makes it "unusable" - I'm not sure I completely understand. - Jilayne |
|
|
|
Ciaran Farrell
On Wed, 2012-06-27 at 20:05 +0000, Jilayne Lovejoy wrote:
No, of course not. There are simply too many licenses which almostDo you expect the SPDX License List to cover every license you find? DoesTo chime in on this, at openSUSE we have exactly the problem described exactly correspond to existing, known licenses. It is the 'almost exactly' that raises the issue. If all of these were to be included in a list, the list would be very long indeed. It would be great to align your list with the SPDX List (and make sure thehttps://docs.google.com/spreadsheet/pub?key=0AqPp4y2wyQsbdGQ1V3pRRDg5NEpGVWpubzdRZ0tjUWc The left column is the SPDX shortname (with a proprietary SUSE- before it if the license is not on the SPDX list). If we are referring only to the shortnames (typically, this - or aJust posted a response to the original response on this. combination of these - would be what would be included in the spec file) then we would not get far if we limited ourselves only to packages with licenses on the spdx list. Our current workaround, as stated above, is to use a proprietary SUSE- prefix and to come up with a SPDX-like shortname. Ciaran
|
|
|
|
Bradley M. Kuhn <bkuhn@...>
Jilayne Lovejoy wrote at 16:02 (EDT) on Wednesday:
So, if you have an idea as to how to implement this idea, whileIMO, "implementing" is trivial. The tough part is careful cataloging to know *what* to add to the list. For example, obviously, no one did the work of cataloging the exceptions in GCC, which is why the license of GCC can't be represented by SPDX for any version of GCC (See my other post about that: http://lists.spdx.org/pipermail/spdx/2012-June/000704.html ) If someone wants to do the work of cataloging the exceptions in GCC, I'd be happy to advise, since I was involved with Brett Smith when he did the work during the 3.1 RTL exception drafting process. Cc me on any email threads that are working on this and I'll try to allocate time to help. But, note that exceptions are all over the place, in things like Classpath, autoconf, and plenty of other places. I wonder: has anyone taken a Fossology (the best scanning tool available as Free Software) run of Debian distribution and just made sure every license it finds has a moniker in SPDX? If not, why not? Seems like a necessary first step for SPDX to have any chance of being complete. -- -- bkuhn |
|
|
|
Bradley M. Kuhn <bkuhn@...>
Jilayne Lovejoy wrote at 16:05 (EDT) on Wednesday:
Do you expect the SPDX License List to cover every license you find?I'm not clear on what the value of SPDX's license list unless it's comprehensive. Can you explain how SPDX is still useful if the licenses for widely distributed and used central-infrastructure programs can't be listed with SPDX? Does any list?Other license lists aren't designed to allow for cataloging the details of a Free Software release, nor are they meant to be grokked by programs, so they don't need to be perfectly comprehensive. If a license is missing from SPDX's list, I can't write an accurate SPDX file for that package, right? Seems like a really big bug in SPDX to me. This is why I keep renewing my encouragement for the SPDX group to actually *write* some SPDX files and carry them upstream. Your problems with SPDX will start to shake out a lot faster if you do that. Indeed, my offer that I've been making for a year remains open: when I see that SPDX patch come across the BusyBox mailing list, I'll endorse it and encourage Denys to put it upstream.... but I still haven't seen the patch arrive, and when I suggest this to SPDX folks, they tell me "upstream should be responsible for doing this work". I get worried any time a bunch of proprietary software companies get together and start suggesting unfunded mandates for upstream Free Software projects. -- -- bkuhn |
|
|
|
Bob Gobeille
On Jun 28, 2012, at 12:02 PM, Bradley M. Kuhn wrote:
But, note that exceptions are all over the place, in things likeFWIW, one of our FOSSology contributors (thank you Camille) put together a spreadsheet (HarmonisationLicenseIDs.ods) highlighting the differences between the fossology license list and the SPDX license list: http://www.fossology.org/projects/fossology/wiki/MatchSPDXLicenceIDs We plan on using this to update fossology with the SPDX license short names and insure we have license signatures for all the SPDX licenses. Bob Gobeille bobg@... |
|
|