"Scope" of licenses to be covered by SPDX
|
Jilayne Lovejoy <jilayne.lovejoy@...>
Great, Bradley. When I find someone who will *do* that work, we will
toggle quoted message
Show quoted text
definitely ask for you input! - Jilayne On 6/28/12 12:02 PM, "Bradley M. Kuhn" <bkuhn@...> wrote:
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 |
|
|
|
Peter A. Bigot
On Fri, Jun 29, 2012 at 10:19 AM, Peter Williams
<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 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 |
|
|
|
Peter Williams <peter.williams@...>
On Fri Jun 29 07:04:27 2012, Philip Odence wrote:
Polite request:Is that really the best choice? This issue seems to be cross functional 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. Peter openlogic.com |
|
|
|
Philip Odence
Polite request:
Could we shift this discussion off of the General Meeting list and onto the Legal Team list only? TThis is GREAT discussion for the legal team.
This is not a big problem, but I want to respect the norms we established when we formed the Legal, Business and Tech teams. Part of splitting up the lists was to keep the traffic on the General Meeting list light so as not to burden folks who are only
looking to monitor goings across the teams and at a high level. Real work (and this is real work) is supposed to be done on the team lists.
So, if anyone responds to this (or other emails in the thread) please remove spdx@... from the CC.
Note: anyone not on the legal list and wanting to follow the discussion can sign up at http://lists.spdx.org/mailman/listinfo/spdx-legal
Thanks,
Phil
From: Tom Incorvia <tom.incorvia@...>
Date: Thu, 28 Jun 2012 14:14:32 -0500 To: Bob Gobeille <bob.gobeille@...>, "Bradley M. Kuhn" <bkuhn@...> Cc: SPDX-legal <spdx-legal@...>, <spdx@...> Subject: RE: "Scope" of licenses to be covered by SPDX As long as the licenses are
- Carefully named and vetted for exact license text
- Somewhat broadly applicable (“somewhat broadly” is fuzzy, but we do want the list to grow starting with very common and moving to less common – it is a way to get more value with our limited bandwidth to vet the licenses)
Then more is better.
SPDX is looking for volunteers to submit additional licenses that meet the above criteria.
To nominate a license, provide this info: http://spdx.org/wiki/spdx-license-list-process-requesting-new-licenses-be-added.
Legal team: I can help with the reviews of proposed licenses, although I am not available until the end of July.
Tom
Tom Incorvia Direct: (512) 340-1336
-----Original Message-----
From: spdx-legal-bounces@... [mailto:spdx-legal-bounces@...] On Behalf Of Bob Gobeille Sent: Thursday, June 28, 2012 1:50 PM To: Bradley M. Kuhn Cc: SPDX-legal; spdx@... Subject: Re: "Scope" of licenses to be covered by SPDX
On Jun 28, 2012, at 12:02 PM, Bradley M. Kuhn wrote:
> 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.
FWIW, 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 _______________________________________________ Spdx-legal mailing list https://lists.spdx.org/mailman/listinfo/spdx-legal
This message has been scanned by MailController - portal1.mailcontroller.co.uk This message has been scanned by MailController. _______________________________________________ Spdx mailing list Spdx@... https://lists.spdx.org/mailman/listinfo/spdx |
|
|
|
Philip Odence
Bradley,
toggle quoted message
Show quoted text
See spec http://www.spdx.org/system/files/spdx-1.0.pdf on pages 23-24. There's a section in an SPDX file called Other Licensing Information Detected to handle licenses not on the standard list. The person creating SPDX file creates an extension to the standard list that is local to the particular SPDX file with similar short names. So, if you find the Bradley Kuhn License you could designate it at BMKL-1.0, say, and then could use that identifier throughout that SPDX file to reference that license. The Other Licensing Information Detected section would map BMLK-1.0 to the specific text of the license. Hope that increases your comfort that the SPDX standard can handle-non standard licenses. And, as others have pointed out, you could also submit the BMKL to the SPDX legal team for future inclusion on the standard list. Best, Phil Jilayne, I am not yet on the legal list, so please forward. On 6/28/12 2:10 PM, "Bradley M. Kuhn" <bkuhn@...> wrote:
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 |
|
|
|
Tom Incorvia
As long as the licenses are
- Carefully named and vetted for exact license text
- Somewhat broadly applicable (“somewhat broadly” is fuzzy, but we do want the list to grow starting with very common and moving to less common – it is a way to get more value with our limited bandwidth to vet the licenses)
Then more is better.
SPDX is looking for volunteers to submit additional licenses that meet the above criteria.
To nominate a license, provide this info: http://spdx.org/wiki/spdx-license-list-process-requesting-new-licenses-be-added.
Legal team: I can help with the reviews of proposed licenses, although I am not available until the end of July.
Tom
Tom Incorvia tom.incorvia@... Direct: (512) 340-1336
-----Original Message-----
On Jun 28, 2012, at 12:02 PM, Bradley M. Kuhn wrote:
> 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.
FWIW, 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 _______________________________________________ Spdx-legal mailing list https://lists.spdx.org/mailman/listinfo/spdx-legal
This message has been scanned by MailController - portal1.mailcontroller.co.uk This message has been scanned by MailController.
|
|
|
|
Kevin P. Fleming <kpfleming@...>
On 06/28/2012 01:10 PM, Bradley M. Kuhn wrote:
Other license lists aren't designed to allow for cataloging the detailsSPDX files don't require that the licenses they refer to be present in the "SPDX License List". The license that you find in a source file can be represented on its own in the SPDX file. The primary purpose of the license list is to provide consistent names for the commonly used licenses, provide standard texts and (eventually) provide a mechanism for automated matching of license text gathered from source files against these standard licenses. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@... | SIP: kpfleming@... | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org |
|
|
|
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@... |
|
|
|
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 |
|
|
|
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 |
|
|
|
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
|
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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
|
|
|
|
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”.
|
|
|
|
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
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
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 |
|
|