|
SPDX Data License Selection Rationale -- RE: TR: SPDX standard: files are placed in public domain
Mark Gisi
Attached is a document that explains the rationale behind why the Creative Commons Zero license was selected by the SPDX legal working group. The core requirements for consideration were:
toggle quoted message
Show quoted text
o does not imply that SPDX data is intellectual property; o in jurisdictions that permit data to be intellectual property - prevents others from claiming controlling ownership over the data contained in a SPDX file; o will not hinder adoption of the SPDX format by the open source community; o minimizes further license proliferation in the open source community; o permits the exchange of SPDX files under confidentiality terms (potentially temporarily) for special situations that may require it. For the details on the pros and cons of different license options please see the attached document. - Mark Mark Gisi | Wind River | Senior Intellectual Property Manager Tel (510) 749-2016 | Fax (510) 749-4552 -----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of RUFFIN, MICHEL (MICHEL) Sent: Friday, June 22, 2012 5:44 AM To: Jilayne Lovejoy; Kevin P. Fleming; spdx@... Cc: Freedman, Barry H (Barry); SPDX-legal Subject: RE: TR: SPDX standard: files are placed in public domain As you say (I like the expression) my concern about this license is more like getting an eye brow raised; What does this license implies? If I want to export data from our DB, I will not make it public but aim a specific company/group to do it. If this is partner or a non profit organization, the data will be provided without any liability from ALU that it is correct (we can do mistake) the goal is to help the partner, non profit organization. If it is a customer we will probably take a little more commitment and we will add a clause such as "to the best of our knowledge this data is accurate" or something like this. But in any case we will not provide this data with the name of our company as public domain our lawyers will not accept that. The subject is so complex that there is necessary mistakes. Now a disclaimer of warranty and liability is not enough. If I publish a list of software in which I say this software is LGPL, while in fact it is GPL I can be sued for GPL infringement. In addition our DB is not SPDX compliant is the way that there are some field which interpret FOSS license according to ALU policy, special deals done with copyright owners to interpret license differently or have special permissions, consideration regarding patents (ALu or external), ... We are doing currently a cleaning to separate this information from what we can export, but with 200 people feeding independently and continually our database we cannot guarantee that some confidential information will not be in the export file. So public domain is out of question. That's for the use case. Now on the legal side. If I generate an export file and I write "Alcatel-Lucent proprietary data - confidential" This is in contradiction with the license saying data must be in public domain. What does the judge decide in this case? I asked the question to our lawyers and they say it is unclear but they are not sure that presenting proprietary data according to a standard might impose a license on the data. I will be happy to participate to a conf call on the subject, this need clarification and can jeopardize the success of SPDX. But one of our lawyers (Barry) should be present to understand and explain the implication of this license. Michel Michel.Ruffin@..., PhD Software Coordination Manager, Bell Labs, Corporate CTO Dpt Distinguished Member of Technical Staff Tel +33 (0) 6 75 25 21 94 Alcatel-Lucent International, Centre de Villarceaux Route De Villejust, 91620 Nozay, France -----Message d'origine----- De : spdx-bounces@... [mailto:spdx-bounces@...] De la part de Jilayne Lovejoy Envoyé : vendredi 22 juin 2012 03:03 À : Kevin P. Fleming; spdx@... Cc : SPDX-legal Objet : Re: TR: SPDX standard: files are placed in public domain In response to Michel's initial question about CC-0 (and subsequent responses): Here's some of the back story: This was an issue that the legal work group spent a vast amount of time discussing. Initially we had decided on the PddL license, but got some pretty severe push-back for that license during LinuxCon North America and 1.0 release last August. So, it was back to the drawing board. Due to the many meetings spent discussing this (which may be captured to varying degrees in the meeting minutes around that time...), Mark Gisi (thanks Mark!) posted a summary of the reason for having a license and then the pros and cons of the various license options discussed on its own page (see http://spdx.org/wiki/spdx-metadata-license-rationale-cc0) for easy reference, transparency, and historical purposes. Once we decided on CC-0, we reached out to various community members (including those specifically who had expressed discomfort with PddL) to make sure the new decision was amenable. That is a very short summary of the process. The webpage referenced above provides a good overview, but naturally does not capture the nuances and details of the concerns, rationale, and so forth raised during those discussions. Michel - from, your previous email, it sounds like you've got an eye brow raised, but are still formulating exactly what the exact concern is. (I do think that the goal of using an open, permissive license, if one at all, was to facilitate free exchange, which appears to be part of your concern.) In any case, perhaps the above information will help a bit and if you have further concerns, I might suggest either asking for an agenda item on one of the legal calls or I can simply set up a call with some of the key people who were involved in the above process - which ever is more appropriate. Consequently, I have now included this email on the SPDX Legal group list as well, as others may be able to weigh in. The relevant bits from the various emails are cut and pasted below (separated by a dotted line) for reference for those who missed this on the general SPDX mailing list. Incidentally - Kevin and Bradley both had good points in regards to the potential legal analysis. The other piece of that puzzle concerns the reality that E.U. law does allow database protection (of facts, that would otherwise not be considered protectable under, U.S. law, for example). If anyone is interested in learning more about this, there is an excellent article here: http://www.ifosslr.org/ifosslr/article/view/62 (but don't go learning too much about this law stuff, as you might put us out of work ;) Cheers, Jilayne Jilayne Lovejoy | Corporate Counsel OpenLogic, Inc. jlovejoy@... | 720 240 4545 ------------ On Fri Jun 15 09:37:17 2012, RUFFIN, MICHEL (MICHEL) wrote: I am not very happy that data must be made in public domain. For theJust to clarify, is it your desire to be allowed to license SPDX files that you produce under terms of your choice? Or are you suggesting that we change the required licensing of SPDX to include a disclaimer of some sort? Regarding the second bullet, can you provide examples of scenarios where confidentiality agreements (which until now have been the proposed solution to this problem) between you and your partners would be insufficient? Thanks in advance, Peter --------------- What I want is freedom, to exchange information between companies without constraints. If we need constraints, we put it in the contract. It is not to SPDX to put the constraints. Let us time to think about consequences/consraints, ... before addressing the issue. But the question is what was the purpose of this initially? Michel.Ruffin@..., PhD Software Coordination Manager, Bell Labs, Corporate CTO Dpt Distinguished Member of Technical Staff Tel +33 (0) 6 75 25 21 94 Alcatel-Lucent International, Centre de Villarceaux Route De Villejust, 91620 Nozay, France ---------------- On 6/15/12 3:05 PM, "Kevin P. Fleming" <kpfleming@...> wrote: On 06/15/2012 03:53 PM, Peter Williams wrote:On Fri Jun 15 14:40:49 2012, RUFFIN, MICHEL (MICHEL) wrote:I suspect that it may be at least partially based on the fact that theBut the question is what was the purpose of this initially?It is a excellent question. I have never understood this purpose of this _______________________________________________ Spdx mailing list Spdx@... https://lists.spdx.org/mailman/listinfo/spdx _______________________________________________ Spdx mailing list Spdx@... https://lists.spdx.org/mailman/listinfo/spdx |
|
|
|
Re: "Scope" of licenses to be covered by SPDX
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”.
|
|
|
|
Re: "Scope" of licenses to be covered by SPDX
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”.
|
|
|
|
Re: "Scope" of licenses to be covered by SPDX
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”.
|
|
|
|
Re: "Scope" of licenses to be covered by SPDX
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:
|
|
|
|
Re: "Scope" of licenses to be covered by SPDX
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:
|
|
|
|
"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:
|
|
|
|
Re: SPDX Mailing Lists
Michael J Herzog <mjherzog@...>
Gentlemen,
I think that some of the confusion about email lists is due to the fact that we "deprecated" spdx@... some time past and switched to using list-name@... format. I don't recall the date of the change, but you should be able sign up for any or all of these existing lists from the SPDX Participation pages at http://spdx.org/wiki/spdx/participation-guidelines. There are four current email lists: General - spdx@... Business - spdx-biz@... Legal - spdx-legal@... Technical - spdx-tech@... These mailing lists were defined by "team" not by topic, but we do have many cross-team topics like governance so this may be a good time to consider additional mailing lists for some key topics since we are often posting items to three or four lists at a time. I will raise this point at our next General conference call on Thursday June 28 (8AM Pacfiic). The call-in details are: Conf call dial-in: Conference code: 7812589502 Toll-free dial-in number (U.S. and Canada): (877) 435-0230 International dial-in number: (253) 336-6732 For those dialing in from other regions, a list of toll free numbers can be found: https://www.intercallonline.com/portlets/scheduling/viewNumbers/viewNumber.do?ownerNumber=6053870&audioType=RP&viewGa=false&ga=OFF 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. |
|
|
|
FOSS clauses in contracts between companies
RUFFIN MICHEL
I agree for this particular topic (but it seems I am not part of this mailing list). But I am more ambitious, I have other initiatives in the pockets: having an open source DB describing the foss IP issues, having public tutorials on open source governance, having some standard way to package products with FOSS obligations, … So perhaps we should have a more general “governance process” mailing list.
I have change the subject 8-)
Michel.Ruffin@..., PhD De : Steve Cropper
(stcroppe) [mailto:stcroppe@...]
Feels like this should go to spdx-legal@... and the Subject line should change to indicate the change of subject ?
Steve
From: <RUFFIN>,
"MICHEL (MICHEL)" <michel.ruffin@...>
Before answering this, we need to determine in which group/mailing list we need to discuss this subject, I do not want to bother people not interested by this. Can we continue with SPDX list should we create a different list? I would prefer this second option. Martin would it be possible to create a “FOSS governance process” mailing list in the framework of FOSSBazaar which I think would be the best solution
Now if you look at the ALU definition of FOSS your definition cover only a part of the i) definition, there are a lot of software coming with an open source like license which is not OSI compliant, for instance beerware license How do you cope with theses? The ii) (EULA licenses): Sun/oracle binary license, Oracle OTN licenses, google licenses, adobe licenses, … are a huge set of licenses. In a contractual context they need to be treated the same way. Please note we are not discussing here what is an open source (I know there are two major definitions, the FSF one with 4 freedoms and the OSI one with 10 criteria) but what we should put in contracts.
Michel Michel.Ruffin@...,
PhD De : Soeren_Rabenstein@...
[mailto:Soeren_Rabenstein@...]
Hello Michel and others
In our standard FOSS contract clauses (which I am willing to share too, once we determined that this (or ftf, or any other network) is the appropriate forum for it) the FOSS-definition is also rather broad, but exemplarily refers to the OSI approved licenses. The definition reads as follows:
“Free Open Source Software” or “FOSS” shall mean a copyrighted work that is licensed under any of the licenses listed under www.opensource.org/licenses or any similar open source, free software or community license (“FOSS License”).
Btw: It seems I have been dropped from the list of persons allowed to post here (so not sure if this mail will even make it the mailing list). Can someone help on this?
Mit freundlichen Grüßen / Kind regards
Sören Rabenstein
____________________________________________________________
ASUS Computer GmbH
Sören Rabenstein,
LL.M.
Von: spdx-bounces@...
[mailto:spdx-bounces@...]
Im Auftrag von RUFFIN, MICHEL
(MICHEL)
For the definition of FOSS (free and/or open source software (free is for free of cost here)) that we provide it is of course in the context of a contract negotiation. It is everything that do not go through a procurement department, i.e. coming with an implicit license: a click to accept EULA, an OSI compliant license or similar, + shareware and of course public domain. This definition is now accepted without discussion by most of our suppliers because it is quite clear (we had a lot of revisions before coming to this definition). Note that we use this definition internally in ALU for our FOSS governance process.
A comment on licenses, what I find confusing in the SPDX standard is the numbering of BSD licenses for instance the BSD 4 clause is in fact the original BSD license and I would have call it BSD1. But that’s not very important. What is important is to stabilize this taxonomy because we cannot change every year the content of our FOSS database, our internal FOSs governance process documents (around 80 pages), our internal tutorials (170 slides), our requests to suppliers, an update of the knowledge of our FOSs experts, etc.
Michel.Ruffin@..., PhD Software Coordination Manager, Bell Labs, Corporate CTO Dpt Distinguished Member of Technical Staff Tel +33 (0) 6 75 25 21 94 Alcatel-Lucent International, Centre de Villarceaux Route De Villejust, 91620Nozay, France
-----Message d'origine-----
De : Jilayne Lovejoy [mailto:jilayne.lovejoy@...] Envoyé : vendredi 22 juin 2012 01:33 À : RUFFIN, MICHEL (MICHEL); Gary O'Neall; Peter Williams Cc : spdx-tech@...; spdx@... Objet : Re: Import and export function of SPDX
(Apologies for falling off this exchange - had some other things come up and am now getting caught up with various responses - lots of great discussion, though!)
On 6/13/12 9:34 AM, "RUFFIN, MICHEL (MICHEL)" <michel.ruffin@...> wrote:
>So far our FOSS clauses are not aligned on the SPDX standard (we are >already happy when suppliers can comply to our requirements without too >much discussion so we did not formalize things too much)
One thing I noticed immediately about your clauses is the definition of FOSS - which is quite broad. While I can understand why it might make sense to use a broad definition for contracts, it includes some categories of software (e.g. (ii) and (iii) in your definition) that other people/parties might not consider "FOSS." In terms of the SPDX License List, for example, I believe (if memory serves) that we discussed to what "kinds" of licenses should be included on the list and an argument against including, what I would refer to as "freeware" licenses (usually under some kind of click-through EULA that more resembles a more traditional, restrictive IP license, than open source) should not be on the list. I don't know if this definition's breadth would necessarily create a conflict in practical reality or not, but thought I'd at least point it out...
> >What we request is the name of FOSS, the name of the license if it is OSI >compliant, or a copy of the license if it is not, the nature of the FOSS: >is it a library, a standalone software, an interpreter, ... in order to >determine if there is some potential contamination as with GPL. > >Now we have already aligned our database on the SPDX taxonomy for naming >licenses, we will soon ask our suppliers to align on this taxonomy. I >have already prepared a document (in copy) to distribute to our suppliers >and partners on SPDX.
Thanks for sharing this. Really great to hear that you have adopted the SPDX License List already. I'm not sure if you or anyone from your team is on the legal work group mailing list, but that may be helpful to stay on top of issues/updates/discussion there. (for example, a new version of the license list was just uploaded this week :)
Jilayne
Jilayne Lovejoy | Corporate Counsel OpenLogic, Inc.
<applewebdata://EAA1F861-B11E-4827-976F-55756901A796/jlovejoy@... > | 720 240 4545
> > >-----Message d'origine----- >De : Jilayne Lovejoy [mailto:jilayne.lovejoy@...] >Envoyé : mercredi 13 juin 2012 16:08 >À : RUFFIN, MICHEL (MICHEL); Gary O'Neall; Peter Williams >Cc : spdx-tech@...; spdx@... >Objet : Re: Import and export function of SPDX > >Hi Michel, > >Thanks again for sharing your information. In regards to your posting (to >both this group and the FSF legal network) about the legal clauses, I have >noticed this and apologize as well for not responding sooner (it's still >in my inbox as a to-do item, sadly). In any case, a couple thoughts. It >is my understanding from your previous email(s), that you'd like to see >some kind of FOSS-related legal clause resource, is that correct? At the >moment, this is not within the scope of SPDX (albeit a great idea >generally!). This is probably something that could be discussed further >in terms of something to consider tackling in the longer-term road map. > >More specifically, your "list of FOSS" clause (a)(ii), you require the >name of the license, license text, and whether it is OSI certified or not. > This is all information capture in the SPDX License List. Do you have an >internal list as well? If so, it would be great to discuss aligning any >licenses on your list for potential inclusion on the SPDX License List, if >not already included there and otherwise coordinating. > >Cheers, > >Jilayne Lovejoy | Corporate Counsel >jlovejoy@... | 720 240 4545 >Twitter @jilaynelovejoy > >OpenLogic, Inc. >10910 W 120th Ave, Suite 450 >Broomfield, Colorado 80021 >Twitter @openlogic @cloudswing > > > > >On 6/13/12 6:45 AM, "RUFFIN, MICHEL (MICHEL)" ><michel.ruffin@...> wrote: > >>Gary, I think in my previous mail I expressed our use case: >>1) getting information from our suppliers on FOSS included in their >>products in order to respect license obligations and to provide this to >>our customers >>2) automate the work of ALU for accepting this FOSS in our products >>3) being able to provide the same information to our customers. >> >>I think it is covered by actual use cases, if not I can do a new one. >> >>Now I would like to attract your attention on a document that I sent few >>months ago to this mailing list and also to the FSF legal network group. >>Which are the clauses that we put in the contracts with our suppliers and >>their rationnal. The goal is to standardize these clauses and I receive >>no feedback from anybody on this. >> >>This should illustrate the use case. And I understand that I should use >>the FSF legal network to discuss this. But I am very surprised that there >>is no reaction/interest in this. It has been a huge ALU effort to shape >>these conditions in order to reach acceptance to these conditions by most >>companies. >> >>Michel.Ruffin@..., PhD >>Software Coordination Manager, Bell Labs, Corporate CTO Dpt >>Distinguished Member of Technical Staff >>Tel +33 (0) 6 75 25 21 94 >>Alcatel-Lucent International, Centre de Villarceaux >>Route De Villejust, 91620Nozay, France >> >> >>-----Message d'origine----- >>De : Gary O'Neall [mailto:gary@...] >>Envoyé : mardi 12 juin 2012 19:29 >>À : 'Peter Williams'; RUFFIN, MICHEL (MICHEL) >>Cc : spdx-tech@...; spdx@... >>Objet : RE: Import and export function of SPDX >> >>I believe the current SPDX tools will treat both RDF and Tag/Value in the >>same manner - the documents will be readable by the tools but it will >>fail a >>validation (missing required field). For the command line tools, the >>conversions or pretty printing will still work but you will get warning. >> >>In terms of making the fields optional - I can see this as a valuable >>change >>for some of the use cases where that information is not available. There >>is >>need to make sure the components described in the SPDX file match the >>actual >>file artifacts, but that need can be filled by the per-file information. >> >>Michel - Which use case best describes your use of SPDX >>(http://spdx.org/wiki/spdx-20-use-cases). If there isn't a good >>representation of your use case(s), could you provide a brief >>description? >>I want to make sure we cover this when working on SPDX 2.0. >> >>Thanks, >>Gary >> >>-----Original Message----- >>From:spdx-tech-bounces@... >>[mailto:spdx-tech-bounces@...] On Behalf Of Peter Williams >>Sent: Tuesday, June 12, 2012 9:27 AM >>To: RUFFIN, MICHEL (MICHEL) >>Cc: spdx-tech@...; spdx@... >>Subject: Re: Import and export function of SPDX >> >>On Tue Jun 12 06:02:03 2012, RUFFIN, MICHEL (MICHEL) wrote: >>> We have an issue with 2 fields that do not exist in our database.: the >>> name of the archive file and the checksum. In the SPDX standard they >>> are mandatory and I do not see why would it be possibly to make them >>> optional? >> >>I think making those fields optional would be advantageous. Would you >>mind >>filing a bug[1] so that we don't forget to look into the issue for the >>next >>version. >> >>As for your immediate issues of not having data for those fields, if you >>are >>using RDF i'd just skip them altogether in the SPDX file. While your file >>will technically be invalid all reasonable SPDX consumers will not have a >>problem with that information being absent unless they need it to >>accomplish >>their goal. (In which case they cannot use your SPDX files, anyway.) If >>you >>are using the tag-value format skipping the fields altogether will, i >>think, >>prove problematic due to that format's stricter syntactic constraints. >>(Kate >>or Gary, can you confirm this?) >> >>[1]: >>https://bugs.linuxfoundation.org/enter_bug.cgi?product=SPDX&component=Spe >>c >> >>Peter >> >>PS: I am cc-ing the technical working group because it's participants are >>best suited to answer these sorts of issues. >> >>_______________________________________________ >>Spdx-tech mailing list >>https://lists.spdx.org/mailman/listinfo/spdx-tech >> >> > >
|
|
|
|
Re: Import and export function of SPDX
Steve Cropper (stcroppe) <stcroppe@...>
Feels like this should go to spdx-legal@... and the Subject line should change to indicate the change of subject ?
Steve
From: <RUFFIN>, "MICHEL (MICHEL)" <michel.ruffin@...>
Date: Friday, June 22, 2012 6:42 AM To: "Soeren_Rabenstein@..." <Soeren_Rabenstein@...>, "jilayne.lovejoy@..." <jilayne.lovejoy@...>, "gary@..." <gary@...>, "peter.williams@..." <peter.williams@...> Cc: "spdx-tech@..." <spdx-tech@...>, "spdx@..." <spdx@...> Subject: RE: Import and export function of SPDX Before answering this, we need to determine in which group/mailing list we need to discuss this subject, I do not want to bother people not interested by this. Can we continue with SPDX list should we create a different list? I would prefer this second option. Martin would it be possible to create a “FOSS governance process” mailing list in the framework of FOSSBazaar which I think would be the best solution
Now if you look at the ALU definition of FOSS your definition cover only a part of the i) definition, there are a lot of software coming with an open source like license which is not OSI compliant, for instance beerware license How do you cope with theses? The ii) (EULA licenses): Sun/oracle binary license, Oracle OTN licenses, google licenses, adobe licenses, … are a huge set of licenses. In a contractual context they need to be treated the same way. Please note we are not discussing here what is an open source (I know there are two major definitions, the FSF one with 4 freedoms and the OSI one with 10 criteria) but what we should put in contracts.
Michel Michel.Ruffin@..., PhD De :
Soeren_Rabenstein@... [mailto:Soeren_Rabenstein@...]
Hello Michel and others
In our standard FOSS contract clauses (which I am willing to share too, once we determined that this (or ftf, or any other network) is the appropriate forum for it) the FOSS-definition is also rather broad, but exemplarily refers to the OSI approved licenses. The definition reads as follows:
“Free Open Source Software” or “FOSS” shall mean a copyrighted work that is licensed under any of the licenses listed under www.opensource.org/licenses or any similar open source, free software or community license (“FOSS License”).
Btw: It seems I have been dropped from the list of persons allowed to post here (so not sure if this mail will even make it the mailing list). Can someone help on this?
Mit freundlichen Grüßen / Kind regards
Sören Rabenstein
____________________________________________________________
ASUS Computer GmbH
Sören Rabenstein, LL.M.
Von:
spdx-bounces@... [mailto:spdx-bounces@...]
Im Auftrag von RUFFIN, MICHEL (MICHEL)
For the definition of FOSS (free and/or open source software (free is for free of cost here)) that we provide it is of course in the context of a contract negotiation. It is everything that do not go through a procurement department, i.e. coming with an implicit license: a click to accept EULA, an OSI compliant license or similar, + shareware and of course public domain. This definition is now accepted without discussion by most of our suppliers because it is quite clear (we had a lot of revisions before coming to this definition). Note that we use this definition internally in ALU for our FOSS governance process.
A comment on licenses, what I find confusing in the SPDX standard is the numbering of BSD licenses for instance the BSD 4 clause is in fact the original BSD license and I would have call it BSD1. But that’s not very important. What is important is to stabilize this taxonomy because we cannot change every year the content of our FOSS database, our internal FOSs governance process documents (around 80 pages), our internal tutorials (170 slides), our requests to suppliers, an update of the knowledge of our FOSs experts, etc.
Michel.Ruffin@..., PhD Software Coordination Manager, Bell Labs, Corporate CTO Dpt Distinguished Member of Technical Staff Tel +33 (0) 6 75 25 21 94 Alcatel-Lucent International, Centre de Villarceaux Route De Villejust, 91620Nozay, France
-----Message d'origine-----
De : Jilayne Lovejoy [mailto:jilayne.lovejoy@...] Envoyé : vendredi 22 juin 2012 01:33 À : RUFFIN, MICHEL (MICHEL); Gary O'Neall; Peter Williams Cc : spdx-tech@...; spdx@... Objet : Re: Import and export function of SPDX
(Apologies for falling off this exchange - had some other things come up and am now getting caught up with various responses - lots of great discussion, though!)
On 6/13/12 9:34 AM, "RUFFIN, MICHEL (MICHEL)" <michel.ruffin@...> wrote:
>So far our FOSS clauses are not aligned on the SPDX standard (we are >already happy when suppliers can comply to our requirements without too >much discussion so we did not formalize things too much)
One thing I noticed immediately about your clauses is the definition of FOSS - which is quite broad. While I can understand why it might make sense to use a broad definition for contracts, it includes some categories of software (e.g. (ii) and (iii) in your definition) that other people/parties might not consider "FOSS." In terms of the SPDX License List, for example, I believe (if memory serves) that we discussed to what "kinds" of licenses should be included on the list and an argument against including, what I would refer to as "freeware" licenses (usually under some kind of click-through EULA that more resembles a more traditional, restrictive IP license, than open source) should not be on the list. I don't know if this definition's breadth would necessarily create a conflict in practical reality or not, but thought I'd at least point it out...
> >What we request is the name of FOSS, the name of the license if it is OSI >compliant, or a copy of the license if it is not, the nature of the FOSS: >is it a library, a standalone software, an interpreter, ... in order to >determine if there is some potential contamination as with GPL. > >Now we have already aligned our database on the SPDX taxonomy for naming >licenses, we will soon ask our suppliers to align on this taxonomy. I >have already prepared a document (in copy) to distribute to our suppliers >and partners on SPDX.
Thanks for sharing this. Really great to hear that you have adopted the SPDX License List already. I'm not sure if you or anyone from your team is on the legal work group mailing list, but that may be helpful to stay on top of issues/updates/discussion there. (for example, a new version of the license list was just uploaded this week :)
Jilayne
Jilayne Lovejoy | Corporate Counsel OpenLogic, Inc.
<applewebdata://EAA1F861-B11E-4827-976F-55756901A796/jlovejoy@... > | 720 240 4545
> > >-----Message d'origine----- >De : Jilayne Lovejoy [mailto:jilayne.lovejoy@...] >Envoyé : mercredi 13 juin 2012 16:08 >À : RUFFIN, MICHEL (MICHEL); Gary O'Neall; Peter Williams >Cc : spdx-tech@...; spdx@... >Objet : Re: Import and export function of SPDX > >Hi Michel, > >Thanks again for sharing your information. In regards to your posting (to >both this group and the FSF legal network) about the legal clauses, I have >noticed this and apologize as well for not responding sooner (it's still >in my inbox as a to-do item, sadly). In any case, a couple thoughts. It >is my understanding from your previous email(s), that you'd like to see >some kind of FOSS-related legal clause resource, is that correct? At the >moment, this is not within the scope of SPDX (albeit a great idea >generally!). This is probably something that could be discussed further >in terms of something to consider tackling in the longer-term road map. > >More specifically, your "list of FOSS" clause (a)(ii), you require the >name of the license, license text, and whether it is OSI certified or not. > This is all information capture in the SPDX License List. Do you have an >internal list as well? If so, it would be great to discuss aligning any >licenses on your list for potential inclusion on the SPDX License List, if >not already included there and otherwise coordinating. > >Cheers, > >Jilayne Lovejoy | Corporate Counsel >jlovejoy@... | 720 240 4545 >Twitter @jilaynelovejoy > >OpenLogic, Inc. >10910 W 120th Ave, Suite 450 >Broomfield, Colorado 80021 >Twitter @openlogic @cloudswing > > > > >On 6/13/12 6:45 AM, "RUFFIN, MICHEL (MICHEL)" ><michel.ruffin@...> wrote: > >>Gary, I think in my previous mail I expressed our use case: >>1) getting information from our suppliers on FOSS included in their >>products in order to respect license obligations and to provide this to >>our customers >>2) automate the work of ALU for accepting this FOSS in our products >>3) being able to provide the same information to our customers. >> >>I think it is covered by actual use cases, if not I can do a new one. >> >>Now I would like to attract your attention on a document that I sent few >>months ago to this mailing list and also to the FSF legal network group. >>Which are the clauses that we put in the contracts with our suppliers and >>their rationnal. The goal is to standardize these clauses and I receive >>no feedback from anybody on this. >> >>This should illustrate the use case. And I understand that I should use >>the FSF legal network to discuss this. But I am very surprised that there >>is no reaction/interest in this. It has been a huge ALU effort to shape >>these conditions in order to reach acceptance to these conditions by most >>companies. >> >>Michel.Ruffin@..., PhD >>Software Coordination Manager, Bell Labs, Corporate CTO Dpt >>Distinguished Member of Technical Staff >>Tel +33 (0) 6 75 25 21 94 >>Alcatel-Lucent International, Centre de Villarceaux >>Route De Villejust, 91620Nozay, France >> >> >>-----Message d'origine----- >>De : Gary O'Neall [mailto:gary@...] >>Envoyé : mardi 12 juin 2012 19:29 >>À : 'Peter Williams'; RUFFIN, MICHEL (MICHEL) >>Cc : spdx-tech@...; spdx@... >>Objet : RE: Import and export function of SPDX >> >>I believe the current SPDX tools will treat both RDF and Tag/Value in the >>same manner - the documents will be readable by the tools but it will >>fail a >>validation (missing required field). For the command line tools, the >>conversions or pretty printing will still work but you will get warning. >> >>In terms of making the fields optional - I can see this as a valuable >>change >>for some of the use cases where that information is not available. There >>is >>need to make sure the components described in the SPDX file match the >>actual >>file artifacts, but that need can be filled by the per-file information. >> >>Michel - Which use case best describes your use of SPDX >>(http://spdx.org/wiki/spdx-20-use-cases). If there isn't a good >>representation of your use case(s), could you provide a brief >>description? >>I want to make sure we cover this when working on SPDX 2.0. >> >>Thanks, >>Gary >> >>-----Original Message----- >>From:spdx-tech-bounces@... >>[mailto:spdx-tech-bounces@...] On Behalf Of Peter Williams >>Sent: Tuesday, June 12, 2012 9:27 AM >>To: RUFFIN, MICHEL (MICHEL) >>Cc: spdx-tech@...; spdx@... >>Subject: Re: Import and export function of SPDX >> >>On Tue Jun 12 06:02:03 2012, RUFFIN, MICHEL (MICHEL) wrote: >>> We have an issue with 2 fields that do not exist in our database.: the >>> name of the archive file and the checksum. In the SPDX standard they >>> are mandatory and I do not see why would it be possibly to make them >>> optional? >> >>I think making those fields optional would be advantageous. Would you >>mind >>filing a bug[1] so that we don't forget to look into the issue for the >>next >>version. >> >>As for your immediate issues of not having data for those fields, if you >>are >>using RDF i'd just skip them altogether in the SPDX file. While your file >>will technically be invalid all reasonable SPDX consumers will not have a >>problem with that information being absent unless they need it to >>accomplish >>their goal. (In which case they cannot use your SPDX files, anyway.) If >>you >>are using the tag-value format skipping the fields altogether will, i >>think, >>prove problematic due to that format's stricter syntactic constraints. >>(Kate >>or Gary, can you confirm this?) >> >>[1]: >>https://bugs.linuxfoundation.org/enter_bug.cgi?product=SPDX&component=Spe >>c >> >>Peter >> >>PS: I am cc-ing the technical working group because it's participants are >>best suited to answer these sorts of issues. >> >>_______________________________________________ >>Spdx-tech mailing list >>https://lists.spdx.org/mailman/listinfo/spdx-tech >> >> > >
|
|
|
|
Re: Import and export function of SPDX
RUFFIN MICHEL
Before answering this, we need to determine in which group/mailing list we need to discuss this subject, I do not want to bother people not interested by this. Can we continue with SPDX list should we create a different list? I would prefer this second option. Martin would it be possible to create a “FOSS governance process” mailing list in the framework of FOSSBazaar which I think would be the best solution
Now if you look at the ALU definition of FOSS your definition cover only a part of the i) definition, there are a lot of software coming with an open source like license which is not OSI compliant, for instance beerware license How do you cope with theses? The ii) (EULA licenses): Sun/oracle binary license, Oracle OTN licenses, google licenses, adobe licenses, … are a huge set of licenses. In a contractual context they need to be treated the same way. Please note we are not discussing here what is an open source (I know there are two major definitions, the FSF one with 4 freedoms and the OSI one with 10 criteria) but what we should put in contracts.
Michel Michel.Ruffin@..., PhD De : Soeren_Rabenstein@...
[mailto:Soeren_Rabenstein@...]
Hello Michel and others
In our standard FOSS contract clauses (which I am willing to share too, once we determined that this (or ftf, or any other network) is the appropriate forum for it) the FOSS-definition is also rather broad, but exemplarily refers to the OSI approved licenses. The definition reads as follows:
“Free Open Source Software” or “FOSS” shall mean a copyrighted work that is licensed under any of the licenses listed under www.opensource.org/licenses or any similar open source, free software or community license (“FOSS License”).
Btw: It seems I have been dropped from the list of persons allowed to post here (so not sure if this mail will even make it the mailing list). Can someone help on this?
Mit freundlichen Grüßen / Kind regards
Sören Rabenstein
____________________________________________________________
ASUS Computer GmbH
Sören Rabenstein,
LL.M.
Von:
spdx-bounces@... [mailto:spdx-bounces@...] Im Auftrag von RUFFIN, MICHEL (MICHEL)
For the definition of FOSS (free and/or open source software (free is for free of cost here)) that we provide it is of course in the context of a contract negotiation. It is everything that do not go through a procurement department, i.e. coming with an implicit license: a click to accept EULA, an OSI compliant license or similar, + shareware and of course public domain. This definition is now accepted without discussion by most of our suppliers because it is quite clear (we had a lot of revisions before coming to this definition). Note that we use this definition internally in ALU for our FOSS governance process.
A comment on licenses, what I find confusing in the SPDX standard is the numbering of BSD licenses for instance the BSD 4 clause is in fact the original BSD license and I would have call it BSD1. But that’s not very important. What is important is to stabilize this taxonomy because we cannot change every year the content of our FOSS database, our internal FOSs governance process documents (around 80 pages), our internal tutorials (170 slides), our requests to suppliers, an update of the knowledge of our FOSs experts, etc.
Michel.Ruffin@..., PhD Software Coordination Manager, Bell Labs, Corporate CTO Dpt Distinguished Member of Technical Staff Tel +33 (0) 6 75 25 21 94 Alcatel-Lucent International, Centre de Villarceaux Route De Villejust, 91620 Nozay, France
-----Message d'origine-----
De : Jilayne Lovejoy [mailto:jilayne.lovejoy@...] Envoyé : vendredi 22 juin 2012 01:33 À : RUFFIN, MICHEL (MICHEL); Gary O'Neall; Peter Williams Cc : spdx-tech@...; spdx@... Objet : Re: Import and export function of SPDX
(Apologies for falling off this exchange - had some other things come up and am now getting caught up with various responses - lots of great discussion, though!)
On 6/13/12 9:34 AM, "RUFFIN, MICHEL (MICHEL)" <michel.ruffin@...> wrote:
>So far our FOSS clauses are not aligned on the SPDX standard (we are >already happy when suppliers can comply to our requirements without too >much discussion so we did not formalize things too much)
One thing I noticed immediately about your clauses is the definition of FOSS - which is quite broad. While I can understand why it might make sense to use a broad definition for contracts, it includes some categories of software (e.g. (ii) and (iii) in your definition) that other people/parties might not consider "FOSS." In terms of the SPDX License List, for example, I believe (if memory serves) that we discussed to what "kinds" of licenses should be included on the list and an argument against including, what I would refer to as "freeware" licenses (usually under some kind of click-through EULA that more resembles a more traditional, restrictive IP license, than open source) should not be on the list. I don't know if this definition's breadth would necessarily create a conflict in practical reality or not, but thought I'd at least point it out...
> >What we request is the name of FOSS, the name of the license if it is OSI >compliant, or a copy of the license if it is not, the nature of the FOSS: >is it a library, a standalone software, an interpreter, ... in order to >determine if there is some potential contamination as with GPL. > >Now we have already aligned our database on the SPDX taxonomy for naming >licenses, we will soon ask our suppliers to align on this taxonomy. I >have already prepared a document (in copy) to distribute to our suppliers >and partners on SPDX.
Thanks for sharing this. Really great to hear that you have adopted the SPDX License List already. I'm not sure if you or anyone from your team is on the legal work group mailing list, but that may be helpful to stay on top of issues/updates/discussion there. (for example, a new version of the license list was just uploaded this week :)
Jilayne
Jilayne Lovejoy | Corporate Counsel OpenLogic, Inc.
<applewebdata://EAA1F861-B11E-4827-976F-55756901A796/jlovejoy@... > | 720 240 4545
> > >-----Message d'origine----- >De : Jilayne Lovejoy [mailto:jilayne.lovejoy@...] >Envoyé : mercredi 13 juin 2012 16:08 >À : RUFFIN, MICHEL (MICHEL); Gary O'Neall; Peter Williams >Cc : spdx-tech@...; spdx@... >Objet : Re: Import and export function of SPDX > >Hi Michel, > >Thanks again for sharing your information. In regards to your posting (to >both this group and the FSF legal network) about the legal clauses, I have >noticed this and apologize as well for not responding sooner (it's still >in my inbox as a to-do item, sadly). In any case, a couple thoughts. It >is my understanding from your previous email(s), that you'd like to see >some kind of FOSS-related legal clause resource, is that correct? At the >moment, this is not within the scope of SPDX (albeit a great idea >generally!). This is probably something that could be discussed further >in terms of something to consider tackling in the longer-term road map. > >More specifically, your "list of FOSS" clause (a)(ii), you require the >name of the license, license text, and whether it is OSI certified or not. > This is all information capture in the SPDX License List. Do you have an >internal list as well? If so, it would be great to discuss aligning any >licenses on your list for potential inclusion on the SPDX License List, if >not already included there and otherwise coordinating. > >Cheers, > >Jilayne Lovejoy | Corporate Counsel >jlovejoy@... | 720 240 4545 >Twitter @jilaynelovejoy > >OpenLogic, Inc. >10910 W 120th Ave, Suite 450 >Broomfield, Colorado 80021 >Twitter @openlogic @cloudswing > > > > >On 6/13/12 6:45 AM, "RUFFIN, MICHEL (MICHEL)" ><michel.ruffin@...> wrote: > >>Gary, I think in my previous mail I expressed our use case: >>1) getting information from our suppliers on FOSS included in their >>products in order to respect license obligations and to provide this to >>our customers >>2) automate the work of ALU for accepting this FOSS in our products >>3) being able to provide the same information to our customers. >> >>I think it is covered by actual use cases, if not I can do a new one. >> >>Now I would like to attract your attention on a document that I sent few >>months ago to this mailing list and also to the FSF legal network group. >>Which are the clauses that we put in the contracts with our suppliers and >>their rationnal. The goal is to standardize these clauses and I receive >>no feedback from anybody on this. >> >>This should illustrate the use case. And I understand that I should use >>the FSF legal network to discuss this. But I am very surprised that there >>is no reaction/interest in this. It has been a huge ALU effort to shape >>these conditions in order to reach acceptance to these conditions by most >>companies. >> >>Michel.Ruffin@..., PhD >>Software Coordination Manager, Bell Labs, Corporate CTO Dpt >>Distinguished Member of Technical Staff >>Tel +33 (0) 6 75 25 21 94 >>Alcatel-Lucent International, Centre de Villarceaux >>Route De Villejust, 91620 Nozay, France >> >> >>-----Message d'origine----- >>De : Gary O'Neall [mailto:gary@...] >>Envoyé : mardi 12 juin 2012 19:29 >>À : 'Peter Williams'; RUFFIN, MICHEL (MICHEL) >>Cc : spdx-tech@...; spdx@... >>Objet : RE: Import and export function of SPDX >> >>I believe the current SPDX tools will treat both RDF and Tag/Value in the >>same manner - the documents will be readable by the tools but it will >>fail a >>validation (missing required field). For the command line tools, the >>conversions or pretty printing will still work but you will get warning. >> >>In terms of making the fields optional - I can see this as a valuable >>change >>for some of the use cases where that information is not available. There >>is >>need to make sure the components described in the SPDX file match the >>actual >>file artifacts, but that need can be filled by the per-file information. >> >>Michel - Which use case best describes your use of SPDX >>(http://spdx.org/wiki/spdx-20-use-cases). If there isn't a good >>representation of your use case(s), could you provide a brief >>description? >>I want to make sure we cover this when working on SPDX 2.0. >> >>Thanks, >>Gary >> >>-----Original Message----- >>From: spdx-tech-bounces@... >>[mailto:spdx-tech-bounces@...] On Behalf Of Peter Williams >>Sent: Tuesday, June 12, 2012 9:27 AM >>To: RUFFIN, MICHEL (MICHEL) >>Cc: spdx-tech@...; spdx@... >>Subject: Re: Import and export function of SPDX >> >>On Tue Jun 12 06:02:03 2012, RUFFIN, MICHEL (MICHEL) wrote: >>> We have an issue with 2 fields that do not exist in our database.: the >>> name of the archive file and the checksum. In the SPDX standard they >>> are mandatory and I do not see why would it be possibly to make them >>> optional? >> >>I think making those fields optional would be advantageous. Would you >>mind >>filing a bug[1] so that we don't forget to look into the issue for the >>next >>version. >> >>As for your immediate issues of not having data for those fields, if you >>are >>using RDF i'd just skip them altogether in the SPDX file. While your file >>will technically be invalid all reasonable SPDX consumers will not have a >>problem with that information being absent unless they need it to >>accomplish >>their goal. (In which case they cannot use your SPDX files, anyway.) If >>you >>are using the tag-value format skipping the fields altogether will, i >>think, >>prove problematic due to that format's stricter syntactic constraints. >>(Kate >>or Gary, can you confirm this?) >> >>[1]: >>https://bugs.linuxfoundation.org/enter_bug.cgi?product=SPDX&component=Spe >>c >> >>Peter >> >>PS: I am cc-ing the technical working group because it's participants are >>best suited to answer these sorts of issues. >> >>_______________________________________________ >>Spdx-tech mailing list >>https://lists.spdx.org/mailman/listinfo/spdx-tech >> >> > >
|
|
|
|
Re: Import and export function of SPDX
Soeren_Rabenstein@...
Hello Michel and others
In our standard FOSS contract clauses (which I am willing to share too, once we determined that this (or ftf, or any other network) is the appropriate forum for it) the FOSS-definition is also rather broad, but exemplarily refers to the OSI approved licenses. The definition reads as follows:
“Free Open Source Software” or “FOSS” shall mean a copyrighted work that is licensed under any of the licenses listed under www.opensource.org/licenses or any similar open source, free software or community license (“FOSS License”).
Btw: It seems I have been dropped from the list of persons allowed to post here (so not sure if this mail will even make it the mailing list). Can someone help on this?
Mit freundlichen Grüßen / Kind regards
Sören Rabenstein
____________________________________________________________
ASUS Computer GmbH
Sören Rabenstein, LL.M.
Von: spdx-bounces@... [mailto:spdx-bounces@...]
Im Auftrag von RUFFIN, MICHEL (MICHEL)
For the definition of FOSS (free and/or open source software (free is for free of cost here)) that we provide it is of course in the context of a contract negotiation. It is everything that do not go through a procurement department, i.e. coming with an implicit license: a click to accept EULA, an OSI compliant license or similar, + shareware and of course public domain. This definition is now accepted without discussion by most of our suppliers because it is quite clear (we had a lot of revisions before coming to this definition). Note that we use this definition internally in ALU for our FOSS governance process.
A comment on licenses, what I find confusing in the SPDX standard is the numbering of BSD licenses for instance the BSD 4 clause is in fact the original BSD license and I would have call it BSD1. But that’s not very important. What is important is to stabilize this taxonomy because we cannot change every year the content of our FOSS database, our internal FOSs governance process documents (around 80 pages), our internal tutorials (170 slides), our requests to suppliers, an update of the knowledge of our FOSs experts, etc.
Michel.Ruffin@..., PhD Software Coordination Manager, Bell Labs, Corporate CTO Dpt Distinguished Member of Technical Staff Tel +33 (0) 6 75 25 21 94 Alcatel-Lucent International, Centre de Villarceaux Route De Villejust, 91620 Nozay, France
-----Message d'origine-----
De : Jilayne Lovejoy [mailto:jilayne.lovejoy@...] Envoyé : vendredi 22 juin 2012 01:33 À : RUFFIN, MICHEL (MICHEL); Gary O'Neall; Peter Williams Cc : spdx-tech@...; spdx@... Objet : Re: Import and export function of SPDX
(Apologies for falling off this exchange - had some other things come up and am now getting caught up with various responses - lots of great discussion, though!)
On 6/13/12 9:34 AM, "RUFFIN, MICHEL (MICHEL)" <michel.ruffin@...> wrote:
>So far our FOSS clauses are not aligned on the SPDX standard (we are >already happy when suppliers can comply to our requirements without too >much discussion so we did not formalize things too much)
One thing I noticed immediately about your clauses is the definition of FOSS - which is quite broad. While I can understand why it might make sense to use a broad definition for contracts, it includes some categories of software (e.g. (ii) and (iii) in your definition) that other people/parties might not consider "FOSS." In terms of the SPDX License List, for example, I believe (if memory serves) that we discussed to what "kinds" of licenses should be included on the list and an argument against including, what I would refer to as "freeware" licenses (usually under some kind of click-through EULA that more resembles a more traditional, restrictive IP license, than open source) should not be on the list. I don't know if this definition's breadth would necessarily create a conflict in practical reality or not, but thought I'd at least point it out...
> >What we request is the name of FOSS, the name of the license if it is OSI >compliant, or a copy of the license if it is not, the nature of the FOSS: >is it a library, a standalone software, an interpreter, ... in order to >determine if there is some potential contamination as with GPL. > >Now we have already aligned our database on the SPDX taxonomy for naming >licenses, we will soon ask our suppliers to align on this taxonomy. I >have already prepared a document (in copy) to distribute to our suppliers >and partners on SPDX.
Thanks for sharing this. Really great to hear that you have adopted the SPDX License List already. I'm not sure if you or anyone from your team is on the legal work group mailing list, but that may be helpful to stay on top of issues/updates/discussion there. (for example, a new version of the license list was just uploaded this week :)
Jilayne
Jilayne Lovejoy | Corporate Counsel OpenLogic, Inc.
<applewebdata://EAA1F861-B11E-4827-976F-55756901A796/jlovejoy@... > | 720 240 4545
> > >-----Message d'origine----- >De : Jilayne Lovejoy [mailto:jilayne.lovejoy@...] >Envoyé : mercredi 13 juin 2012 16:08 >À : RUFFIN, MICHEL (MICHEL); Gary O'Neall; Peter Williams >Cc : spdx-tech@...; spdx@... >Objet : Re: Import and export function of SPDX > >Hi Michel, > >Thanks again for sharing your information. In regards to your posting (to >both this group and the FSF legal network) about the legal clauses, I have >noticed this and apologize as well for not responding sooner (it's still >in my inbox as a to-do item, sadly). In any case, a couple thoughts. It >is my understanding from your previous email(s), that you'd like to see >some kind of FOSS-related legal clause resource, is that correct? At the >moment, this is not within the scope of SPDX (albeit a great idea >generally!). This is probably something that could be discussed further >in terms of something to consider tackling in the longer-term road map. > >More specifically, your "list of FOSS" clause (a)(ii), you require the >name of the license, license text, and whether it is OSI certified or not. > This is all information capture in the SPDX License List. Do you have an >internal list as well? If so, it would be great to discuss aligning any >licenses on your list for potential inclusion on the SPDX License List, if >not already included there and otherwise coordinating. > >Cheers, > >Jilayne Lovejoy | Corporate Counsel >jlovejoy@... | 720 240 4545 >Twitter @jilaynelovejoy > >OpenLogic, Inc. >10910 W 120th Ave, Suite 450 >Broomfield, Colorado 80021 >Twitter @openlogic @cloudswing > > > > >On 6/13/12 6:45 AM, "RUFFIN, MICHEL (MICHEL)" ><michel.ruffin@...> wrote: > >>Gary, I think in my previous mail I expressed our use case: >>1) getting information from our suppliers on FOSS included in their >>products in order to respect license obligations and to provide this to >>our customers >>2) automate the work of ALU for accepting this FOSS in our products >>3) being able to provide the same information to our customers. >> >>I think it is covered by actual use cases, if not I can do a new one. >> >>Now I would like to attract your attention on a document that I sent few >>months ago to this mailing list and also to the FSF legal network group. >>Which are the clauses that we put in the contracts with our suppliers and >>their rationnal. The goal is to standardize these clauses and I receive >>no feedback from anybody on this. >> >>This should illustrate the use case. And I understand that I should use >>the FSF legal network to discuss this. But I am very surprised that there >>is no reaction/interest in this. It has been a huge ALU effort to shape >>these conditions in order to reach acceptance to these conditions by most >>companies. >> >>Michel.Ruffin@..., PhD >>Software Coordination Manager, Bell Labs, Corporate CTO Dpt >>Distinguished Member of Technical Staff >>Tel +33 (0) 6 75 25 21 94 >>Alcatel-Lucent International, Centre de Villarceaux >>Route De Villejust, 91620 Nozay, France >> >> >>-----Message d'origine----- >>De : Gary O'Neall [mailto:gary@...] >>Envoyé : mardi 12 juin 2012 19:29 >>À : 'Peter Williams'; RUFFIN, MICHEL (MICHEL) >>Cc : spdx-tech@...; spdx@... >>Objet : RE: Import and export function of SPDX >> >>I believe the current SPDX tools will treat both RDF and Tag/Value in the >>same manner - the documents will be readable by the tools but it will >>fail a >>validation (missing required field). For the command line tools, the >>conversions or pretty printing will still work but you will get warning. >> >>In terms of making the fields optional - I can see this as a valuable >>change >>for some of the use cases where that information is not available. There >>is >>need to make sure the components described in the SPDX file match the >>actual >>file artifacts, but that need can be filled by the per-file information. >> >>Michel - Which use case best describes your use of SPDX >>(http://spdx.org/wiki/spdx-20-use-cases). If there isn't a good >>representation of your use case(s), could you provide a brief >>description? >>I want to make sure we cover this when working on SPDX 2.0. >> >>Thanks, >>Gary >> >>-----Original Message----- >>From: spdx-tech-bounces@... >>[mailto:spdx-tech-bounces@...] On Behalf Of Peter Williams >>Sent: Tuesday, June 12, 2012 9:27 AM >>To: RUFFIN, MICHEL (MICHEL) >>Cc: spdx-tech@...; spdx@... >>Subject: Re: Import and export function of SPDX >> >>On Tue Jun 12 06:02:03 2012, RUFFIN, MICHEL (MICHEL) wrote: >>> We have an issue with 2 fields that do not exist in our database.: the >>> name of the archive file and the checksum. In the SPDX standard they >>> are mandatory and I do not see why would it be possibly to make them >>> optional? >> >>I think making those fields optional would be advantageous. Would you >>mind >>filing a bug[1] so that we don't forget to look into the issue for the >>next >>version. >> >>As for your immediate issues of not having data for those fields, if you >>are >>using RDF i'd just skip them altogether in the SPDX file. While your file >>will technically be invalid all reasonable SPDX consumers will not have a >>problem with that information being absent unless they need it to >>accomplish >>their goal. (In which case they cannot use your SPDX files, anyway.) If >>you >>are using the tag-value format skipping the fields altogether will, i >>think, >>prove problematic due to that format's stricter syntactic constraints. >>(Kate >>or Gary, can you confirm this?) >> >>[1]: >>https://bugs.linuxfoundation.org/enter_bug.cgi?product=SPDX&component=Spe >>c >> >>Peter >> >>PS: I am cc-ing the technical working group because it's participants are >>best suited to answer these sorts of issues. >> >>_______________________________________________ >>Spdx-tech mailing list >>https://lists.spdx.org/mailman/listinfo/spdx-tech >> >> > >
|
|
|
|
Re: TR: SPDX standard: files are placed in public domain
RUFFIN MICHEL
As you say (I like the expression) my concern about this license is more like getting an eye brow raised; What does this license implies?
toggle quoted message
Show quoted text
If I want to export data from our DB, I will not make it public but aim a specific company/group to do it. If this is partner or a non profit organization, the data will be provided without any liability from ALU that it is correct (we can do mistake) the goal is to help the partner, non profit organization. If it is a customer we will probably take a little more commitment and we will add a clause such as "to the best of our knowledge this data is accurate" or something like this. But in any case we will not provide this data with the name of our company as public domain our lawyers will not accept that. The subject is so complex that there is necessary mistakes. Now a disclaimer of warranty and liability is not enough. If I publish a list of software in which I say this software is LGPL, while in fact it is GPL I can be sued for GPL infringement. In addition our DB is not SPDX compliant is the way that there are some field which interpret FOSS license according to ALU policy, special deals done with copyright owners to interpret license differently or have special permissions, consideration regarding patents (ALu or external), ... We are doing currently a cleaning to separate this information from what we can export, but with 200 people feeding independently and continually our database we cannot guarantee that some confidential information will not be in the export file. So public domain is out of question. That's for the use case. Now on the legal side. If I generate an export file and I write "Alcatel-Lucent proprietary data - confidential" This is in contradiction with the license saying data must be in public domain. What does the judge decide in this case? I asked the question to our lawyers and they say it is unclear but they are not sure that presenting proprietary data according to a standard might impose a license on the data. I will be happy to participate to a conf call on the subject, this need clarification and can jeopardize the success of SPDX. But one of our lawyers (Barry) should be present to understand and explain the implication of this license. Michel Michel.Ruffin@..., PhD Software Coordination Manager, Bell Labs, Corporate CTO Dpt Distinguished Member of Technical Staff Tel +33 (0) 6 75 25 21 94 Alcatel-Lucent International, Centre de Villarceaux Route De Villejust, 91620 Nozay, France -----Message d'origine-----
De : spdx-bounces@... [mailto:spdx-bounces@...] De la part de Jilayne Lovejoy Envoyé : vendredi 22 juin 2012 03:03 À : Kevin P. Fleming; spdx@... Cc : SPDX-legal Objet : Re: TR: SPDX standard: files are placed in public domain In response to Michel's initial question about CC-0 (and subsequent responses): Here's some of the back story: This was an issue that the legal work group spent a vast amount of time discussing. Initially we had decided on the PddL license, but got some pretty severe push-back for that license during LinuxCon North America and 1.0 release last August. So, it was back to the drawing board. Due to the many meetings spent discussing this (which may be captured to varying degrees in the meeting minutes around that time...), Mark Gisi (thanks Mark!) posted a summary of the reason for having a license and then the pros and cons of the various license options discussed on its own page (see http://spdx.org/wiki/spdx-metadata-license-rationale-cc0) for easy reference, transparency, and historical purposes. Once we decided on CC-0, we reached out to various community members (including those specifically who had expressed discomfort with PddL) to make sure the new decision was amenable. That is a very short summary of the process. The webpage referenced above provides a good overview, but naturally does not capture the nuances and details of the concerns, rationale, and so forth raised during those discussions. Michel - from, your previous email, it sounds like you've got an eye brow raised, but are still formulating exactly what the exact concern is. (I do think that the goal of using an open, permissive license, if one at all, was to facilitate free exchange, which appears to be part of your concern.) In any case, perhaps the above information will help a bit and if you have further concerns, I might suggest either asking for an agenda item on one of the legal calls or I can simply set up a call with some of the key people who were involved in the above process - which ever is more appropriate. Consequently, I have now included this email on the SPDX Legal group list as well, as others may be able to weigh in. The relevant bits from the various emails are cut and pasted below (separated by a dotted line) for reference for those who missed this on the general SPDX mailing list. Incidentally - Kevin and Bradley both had good points in regards to the potential legal analysis. The other piece of that puzzle concerns the reality that E.U. law does allow database protection (of facts, that would otherwise not be considered protectable under, U.S. law, for example). If anyone is interested in learning more about this, there is an excellent article here: http://www.ifosslr.org/ifosslr/article/view/62 (but don't go learning too much about this law stuff, as you might put us out of work ;) Cheers, Jilayne Jilayne Lovejoy | Corporate Counsel OpenLogic, Inc. jlovejoy@... | 720 240 4545 ------------ On Fri Jun 15 09:37:17 2012, RUFFIN, MICHEL (MICHEL) wrote: I am not very happy that data must be made in public domain. For theJust to clarify, is it your desire to be allowed to license SPDX files that you produce under terms of your choice? Or are you suggesting that we change the required licensing of SPDX to include a disclaimer of some sort? Regarding the second bullet, can you provide examples of scenarios where confidentiality agreements (which until now have been the proposed solution to this problem) between you and your partners would be insufficient? Thanks in advance, Peter --------------- What I want is freedom, to exchange information between companies without constraints. If we need constraints, we put it in the contract. It is not to SPDX to put the constraints. Let us time to think about consequences/consraints, ... before addressing the issue. But the question is what was the purpose of this initially? Michel.Ruffin@..., PhD Software Coordination Manager, Bell Labs, Corporate CTO Dpt Distinguished Member of Technical Staff Tel +33 (0) 6 75 25 21 94 Alcatel-Lucent International, Centre de Villarceaux Route De Villejust, 91620 Nozay, France ---------------- On 6/15/12 3:05 PM, "Kevin P. Fleming" <kpfleming@...> wrote: On 06/15/2012 03:53 PM, Peter Williams wrote:On Fri Jun 15 14:40:49 2012, RUFFIN, MICHEL (MICHEL) wrote:I suspect that it may be at least partially based on the fact that theBut the question is what was the purpose of this initially?It is a excellent question. I have never understood this purpose of this _______________________________________________ Spdx mailing list Spdx@... https://lists.spdx.org/mailman/listinfo/spdx |
|
|
|
Re: Import and export function of SPDX
RUFFIN MICHEL
For the definition of FOSS (free and/or open source software (free is for free of cost here)) that we provide it is of course in the context of a contract negotiation. It is everything that do not go through a procurement department, i.e. coming with an implicit license: a click to accept EULA, an OSI compliant license or similar, + shareware and of course public domain. This definition is now accepted without discussion by most of our suppliers because it is quite clear (we had a lot of revisions before coming to this definition). Note that we use this definition internally in ALU for our FOSS governance process.
A comment on licenses, what I find confusing in the SPDX standard is the numbering of BSD licenses for instance the BSD 4 clause is in fact the original BSD license and I would have call it BSD1. But that’s not very important. What is important is to stabilize this taxonomy because we cannot change every year the content of our FOSS database, our internal FOSs governance process documents (around 80 pages), our internal tutorials (170 slides), our requests to suppliers, an update of the knowledge of our FOSs experts, etc.
Michel.Ruffin@..., PhD Software Coordination Manager, Bell Labs, Corporate CTO Dpt Distinguished Member of Technical Staff Tel +33 (0) 6 75 25 21 94 Alcatel-Lucent International, Centre de Villarceaux Route De Villejust, 91620 Nozay, France
-----Message d'origine-----
De : Jilayne Lovejoy [mailto:jilayne.lovejoy@...] Envoyé : vendredi 22 juin 2012 01:33 À : RUFFIN, MICHEL (MICHEL); Gary O'Neall; Peter Williams Cc : spdx-tech@...; spdx@... Objet : Re: Import and export function of SPDX
(Apologies for falling off this exchange - had some other things come up and am now getting caught up with various responses - lots of great discussion, though!)
On 6/13/12 9:34 AM, "RUFFIN, MICHEL (MICHEL)" <michel.ruffin@...> wrote:
>So far our FOSS clauses are not aligned on the SPDX standard (we are >already happy when suppliers can comply to our requirements without too >much discussion so we did not formalize things too much)
One thing I noticed immediately about your clauses is the definition of FOSS - which is quite broad. While I can understand why it might make sense to use a broad definition for contracts, it includes some categories of software (e.g. (ii) and (iii) in your definition) that other people/parties might not consider "FOSS." In terms of the SPDX License List, for example, I believe (if memory serves) that we discussed to what "kinds" of licenses should be included on the list and an argument against including, what I would refer to as "freeware" licenses (usually under some kind of click-through EULA that more resembles a more traditional, restrictive IP license, than open source) should not be on the list. I don't know if this definition's breadth would necessarily create a conflict in practical reality or not, but thought I'd at least point it out...
> >What we request is the name of FOSS, the name of the license if it is OSI >compliant, or a copy of the license if it is not, the nature of the FOSS: >is it a library, a standalone software, an interpreter, ... in order to >determine if there is some potential contamination as with GPL. > >Now we have already aligned our database on the SPDX taxonomy for naming >licenses, we will soon ask our suppliers to align on this taxonomy. I >have already prepared a document (in copy) to distribute to our suppliers >and partners on SPDX.
Thanks for sharing this. Really great to hear that you have adopted the SPDX License List already. I'm not sure if you or anyone from your team is on the legal work group mailing list, but that may be helpful to stay on top of issues/updates/discussion there. (for example, a new version of the license list was just uploaded this week :)
Jilayne
Jilayne Lovejoy | Corporate Counsel OpenLogic, Inc.
jlovejoy@... <applewebdata://EAA1F861-B11E-4827-976F-55756901A796/jlovejoy@... > | 720 240 4545
> > >-----Message d'origine----- >De : Jilayne Lovejoy [mailto:jilayne.lovejoy@...] >Envoyé : mercredi 13 juin 2012 16:08 >À : RUFFIN, MICHEL (MICHEL); Gary O'Neall; Peter Williams >Cc : spdx-tech@...; spdx@... >Objet : Re: Import and export function of SPDX > >Hi Michel, > >Thanks again for sharing your information. In regards to your posting (to >both this group and the FSF legal network) about the legal clauses, I have >noticed this and apologize as well for not responding sooner (it's still >in my inbox as a to-do item, sadly). In any case, a couple thoughts. It >is my understanding from your previous email(s), that you'd like to see >some kind of FOSS-related legal clause resource, is that correct? At the >moment, this is not within the scope of SPDX (albeit a great idea >generally!). This is probably something that could be discussed further >in terms of something to consider tackling in the longer-term road map. > >More specifically, your "list of FOSS" clause (a)(ii), you require the >name of the license, license text, and whether it is OSI certified or not. > This is all information capture in the SPDX License List. Do you have an >internal list as well? If so, it would be great to discuss aligning any >licenses on your list for potential inclusion on the SPDX License List, if >not already included there and otherwise coordinating. > >Cheers, > >Jilayne Lovejoy | Corporate Counsel >jlovejoy@... | 720 240 4545 >Twitter @jilaynelovejoy > >OpenLogic, Inc. >10910 W 120th Ave, Suite 450 >Broomfield, Colorado 80021 >www.openlogic.com >Twitter @openlogic @cloudswing > > > > >On 6/13/12 6:45 AM, "RUFFIN, MICHEL (MICHEL)" ><michel.ruffin@...> wrote: > >>Gary, I think in my previous mail I expressed our use case: >>1) getting information from our suppliers on FOSS included in their >>products in order to respect license obligations and to provide this to >>our customers >>2) automate the work of ALU for accepting this FOSS in our products >>3) being able to provide the same information to our customers. >> >>I think it is covered by actual use cases, if not I can do a new one. >> >>Now I would like to attract your attention on a document that I sent few >>months ago to this mailing list and also to the FSF legal network group. >>Which are the clauses that we put in the contracts with our suppliers and >>their rationnal. The goal is to standardize these clauses and I receive >>no feedback from anybody on this. >> >>This should illustrate the use case. And I understand that I should use >>the FSF legal network to discuss this. But I am very surprised that there >>is no reaction/interest in this. It has been a huge ALU effort to shape >>these conditions in order to reach acceptance to these conditions by most >>companies. >> >>Michel.Ruffin@..., PhD >>Software Coordination Manager, Bell Labs, Corporate CTO Dpt >>Distinguished Member of Technical Staff >>Tel +33 (0) 6 75 25 21 94 >>Alcatel-Lucent International, Centre de Villarceaux >>Route De Villejust, 91620 Nozay, France >> >> >>-----Message d'origine----- >>De : Gary O'Neall [mailto:gary@...] >>Envoyé : mardi 12 juin 2012 19:29 >>À : 'Peter Williams'; RUFFIN, MICHEL (MICHEL) >>Cc : spdx-tech@...; spdx@... >>Objet : RE: Import and export function of SPDX >> >>I believe the current SPDX tools will treat both RDF and Tag/Value in the >>same manner - the documents will be readable by the tools but it will >>fail a >>validation (missing required field). For the command line tools, the >>conversions or pretty printing will still work but you will get warning. >> >>In terms of making the fields optional - I can see this as a valuable >>change >>for some of the use cases where that information is not available. There >>is >>need to make sure the components described in the SPDX file match the >>actual >>file artifacts, but that need can be filled by the per-file information. >> >>Michel - Which use case best describes your use of SPDX >>(http://spdx.org/wiki/spdx-20-use-cases). If there isn't a good >>representation of your use case(s), could you provide a brief >>description? >>I want to make sure we cover this when working on SPDX 2.0. >> >>Thanks, >>Gary >> >>-----Original Message----- >>From: spdx-tech-bounces@... >>[mailto:spdx-tech-bounces@...] On Behalf Of Peter Williams >>Sent: Tuesday, June 12, 2012 9:27 AM >>To: RUFFIN, MICHEL (MICHEL) >>Cc: spdx-tech@...; spdx@... >>Subject: Re: Import and export function of SPDX >> >>On Tue Jun 12 06:02:03 2012, RUFFIN, MICHEL (MICHEL) wrote: >>> We have an issue with 2 fields that do not exist in our database.: the >>> name of the archive file and the checksum. In the SPDX standard they >>> are mandatory and I do not see why would it be possibly to make them >>> optional? >> >>I think making those fields optional would be advantageous. Would you >>mind >>filing a bug[1] so that we don't forget to look into the issue for the >>next >>version. >> >>As for your immediate issues of not having data for those fields, if you >>are >>using RDF i'd just skip them altogether in the SPDX file. While your file >>will technically be invalid all reasonable SPDX consumers will not have a >>problem with that information being absent unless they need it to >>accomplish >>their goal. (In which case they cannot use your SPDX files, anyway.) If >>you >>are using the tag-value format skipping the fields altogether will, i >>think, >>prove problematic due to that format's stricter syntactic constraints. >>(Kate >>or Gary, can you confirm this?) >> >>[1]: >>https://bugs.linuxfoundation.org/enter_bug.cgi?product=SPDX&component=Spe >>c >> >>Peter >> >>PS: I am cc-ing the technical working group because it's participants are >>best suited to answer these sorts of issues. >> >>_______________________________________________ >>Spdx-tech mailing list >>Spdx-tech@... >>https://lists.spdx.org/mailman/listinfo/spdx-tech >> >> > >
|
|
|
|
Re: TR: SPDX standard: files are placed in public domain
Jilayne Lovejoy <jilayne.lovejoy@...>
In response to Michel's initial question about CC-0 (and subsequent
responses): Here's some of the back story: This was an issue that the legal work group spent a vast amount of time discussing. Initially we had decided on the PddL license, but got some pretty severe push-back for that license during LinuxCon North America and 1.0 release last August. So, it was back to the drawing board. Due to the many meetings spent discussing this (which may be captured to varying degrees in the meeting minutes around that time...), Mark Gisi (thanks Mark!) posted a summary of the reason for having a license and then the pros and cons of the various license options discussed on its own page (see http://spdx.org/wiki/spdx-metadata-license-rationale-cc0) for easy reference, transparency, and historical purposes. Once we decided on CC-0, we reached out to various community members (including those specifically who had expressed discomfort with PddL) to make sure the new decision was amenable. That is a very short summary of the process. The webpage referenced above provides a good overview, but naturally does not capture the nuances and details of the concerns, rationale, and so forth raised during those discussions. Michel - from, your previous email, it sounds like you've got an eye brow raised, but are still formulating exactly what the exact concern is. (I do think that the goal of using an open, permissive license, if one at all, was to facilitate free exchange, which appears to be part of your concern.) In any case, perhaps the above information will help a bit and if you have further concerns, I might suggest either asking for an agenda item on one of the legal calls or I can simply set up a call with some of the key people who were involved in the above process - which ever is more appropriate. Consequently, I have now included this email on the SPDX Legal group list as well, as others may be able to weigh in. The relevant bits from the various emails are cut and pasted below (separated by a dotted line) for reference for those who missed this on the general SPDX mailing list. Incidentally - Kevin and Bradley both had good points in regards to the potential legal analysis. The other piece of that puzzle concerns the reality that E.U. law does allow database protection (of facts, that would otherwise not be considered protectable under, U.S. law, for example). If anyone is interested in learning more about this, there is an excellent article here: http://www.ifosslr.org/ifosslr/article/view/62 (but don't go learning too much about this law stuff, as you might put us out of work ;) Cheers, Jilayne Jilayne Lovejoy | Corporate Counsel OpenLogic, Inc. jlovejoy@... | 720 240 4545 ------------ On Fri Jun 15 09:37:17 2012, RUFFIN, MICHEL (MICHEL) wrote: I am not very happy that data must be made in public domain. For theJust to clarify, is it your desire to be allowed to license SPDX files that you produce under terms of your choice? Or are you suggesting that we change the required licensing of SPDX to include a disclaimer of some sort? Regarding the second bullet, can you provide examples of scenarios where confidentiality agreements (which until now have been the proposed solution to this problem) between you and your partners would be insufficient? Thanks in advance, Peter --------------- What I want is freedom, to exchange information between companies without constraints. If we need constraints, we put it in the contract. It is not to SPDX to put the constraints. Let us time to think about consequences/consraints, ... before addressing the issue. But the question is what was the purpose of this initially? Michel.Ruffin@..., PhD Software Coordination Manager, Bell Labs, Corporate CTO Dpt Distinguished Member of Technical Staff Tel +33 (0) 6 75 25 21 94 Alcatel-Lucent International, Centre de Villarceaux Route De Villejust, 91620 Nozay, France ---------------- On 6/15/12 3:05 PM, "Kevin P. Fleming" <kpfleming@...> wrote: On 06/15/2012 03:53 PM, Peter Williams wrote:On Fri Jun 15 14:40:49 2012, RUFFIN, MICHEL (MICHEL) wrote:I suspect that it may be at least partially based on the fact that theBut the question is what was the purpose of this initially?It is a excellent question. I have never understood this purpose of this |
|
|
|
Re: Clarification regarding "FSF legal network" (was Re: Import and export function of SPDX)
Jilayne Lovejoy <jilayne.lovejoy@...>
Responses inline below and to this email, since Bradley hit upon several
salient issues :) On 6/14/12 8:39 AM, "Bradley M. Kuhn" <bkuhn@...> wrote: RUFFIN, MICHEL (MICHEL) wrote today:Would agree to the extent that, considering that what Michel is proposingI know that the discussion on this subject should be in FTFE mailingActually, I caution against being too quick to move discussion to doesn't (yet) seem to have a directly on-point mailing list, discussing it across multiple platforms (and multiple times, in order to finally get a response ;) seems about right! I feel like I need to at least suggest an alternative view for balance-sakes, especially since, as a member, I have greatly benefited from the discussions on that list-serve. The network is made up of mostly lawyers and from all different kinds of organizations and, due to the Chatham House Rule, provides a space for open conversation among members without fear of being quoted/attributed outside the network. Given the reluctance most lawyers have in terms of making public statements, etc, this is a pretty valuable forum, as it provides a chance to discuss things that just may not be ready to take public or that a lawyer cannot risk having attributed or implied to the company he or she works for. In so far as what Michel is suggesting here re: the license clauses, I can imagine quite a few companies being quite resistant/hesitant about sharing this information initially. This is where some discussion that is limited in its exposure can be helpful to begin to break down that barrier. Just like scanning, multiple methods of attacking the problem leads to the best results?? (bad analogy, but seemed fitting ;) Lurking is completely fine for whomever. More involvement means more opportunity to shape the process, so it's up to each participant to determine their level of participation (just reiterating something said at the SPDX Forum, for benefit of all). I'm not sure it's the role of SPDX to address this problem (at least directly - the goal/mission in terms of license compliance has been more of facilitation, than doing the job of compliance itself). In any case - we all have limited resources/time/energy, but I do think that the various efforts (yours, SPDX, Yocto, and so forth...) come together at the common goal of making the use, proliferation, health, compliance with licenses... of open source software easier for all! But all the tools coming out of the SPDX working groups are open source! http://spdx.org/wiki/sandbox-tools (I think there are more than this, but I'm not the one to appropriately answer that question). To be fair, of course the companies who have commercial scanning tools are going to include the ability to generate SPDX files as a feature - because their customers are asking for it. So, there's both - that can't be all bad ;) Jilayne |
|
|
|
Re: Import and export function of SPDX
Jilayne Lovejoy <jilayne.lovejoy@...>
(Apologies for falling off this exchange - had some other things come up
and am now getting caught up with various responses - lots of great discussion, though!) On 6/13/12 9:34 AM, "RUFFIN, MICHEL (MICHEL)" <michel.ruffin@...> wrote: So far our FOSS clauses are not aligned on the SPDX standard (we areOne thing I noticed immediately about your clauses is the definition of FOSS - which is quite broad. While I can understand why it might make sense to use a broad definition for contracts, it includes some categories of software (e.g. (ii) and (iii) in your definition) that other people/parties might not consider "FOSS." In terms of the SPDX License List, for example, I believe (if memory serves) that we discussed to what "kinds" of licenses should be included on the list and an argument against including, what I would refer to as "freeware" licenses (usually under some kind of click-through EULA that more resembles a more traditional, restrictive IP license, than open source) should not be on the list. I don't know if this definition's breadth would necessarily create a conflict in practical reality or not, but thought I'd at least point it out... Thanks for sharing this. Really great to hear that you have adopted the SPDX License List already. I'm not sure if you or anyone from your team is on the legal work group mailing list, but that may be helpful to stay on top of issues/updates/discussion there. (for example, a new version of the license list was just uploaded this week :) Jilayne Jilayne Lovejoy | Corporate Counsel OpenLogic, Inc. jlovejoy@... <applewebdata://EAA1F861-B11E-4827-976F-55756901A796/jlovejoy@... | 720 240 4545
|
|
|
|
Re: FOSS clauses for contracts & fora for discussing it (was Re: Clarification regarding "FSF legal network")
Philip Odence
Michel,
Your idea about standard FOSS clauses might fit into the charter of the Linux Foundation Open Compliance Program. http://www.linuxfoundation.org/programs/legal/compliance (To head off the question, the program is for open source compliance in general, not limited to Linux.) I am cc'ing Ibrahim who coordinates that for the LF with hopes that he will weigh in. (I believe, he's out of the office this week, so he may not respond immediately.) Phil On 6/18/12 9:30 AM, "RUFFIN, MICHEL (MICHEL)" <michel.ruffin@...> wrote: Thank you very much for your quick answer and suggestions. |
|
|
|
FW: License List Matching Guidelines - update
Philip Odence
To SPDX General List Members,
The legal team is putting final touches on matching guidelines. In case you have not been following, this is your chance to speak up if you see any show-stoppers. The legal team has been regularly reporting progress on this work, so I don't expect it to
be a surprise for anyone, but I want to err on the side of over-communication as these guidelines will have ongoing technical implications.
Best,
Phil
From: Jilayne Lovejoy <jilayne.lovejoy@...>
Date: Thu, 14 Jun 2012 05:08:49 +0000 To: SPDX-legal <spdx-legal@...> Cc: Phil Odence <podence@...> Subject: License List Matching Guidelines - update Hi All,
We are aiming to finish (at least the first draft of) the SPDX License List Matching Guidelines by the end of June. To this end, we made some progress on today's legal work stream call, but decided to schedule an additional, off-week call to help facilitate
this goal.
1) please review the updated matching guidelines here: http://spdx.org/wiki/spdx-license-list-match-guidelines
In particular, note the decision to use {{ }} to indicate text that can be ignored for matching purposes, this applies in particular to the BSD and old Apache licenses. I have made a first pass at these, but since you won't be able to see them until the
new license list is posted, I'm attaching the relevant text files to this email for review/feedback.
2) if you have any additional thoughts or suggestions, please add a comment to that page at the bottom (note there are some comments already posted). Please comment by end-of-business, next Wednesday, 20 June.
3) attend the special call to discuss all the posted comments and any other outstanding issues:
Thursday, 21 June at 9am PT / noon ET (immediately after the business team call)
Dial-in: 1.866.740.1260
access: 2404545
4) if we don't complete everything on that call, we will finish up on the regular legal call on 6/27 (but I hope to wrap up on next Thursday!!)
Let me know if you have any questions.
Cheers,
Jilayne Lovejoy | Corporate Counsel
OpenLogic, Inc. jlovejoy@... | 720
240 4545
|
|
|
|
Re: Package Verification Code (section 4.7)
Gary O'Neall
Hi Marc-Etienne,
toggle quoted message
Show quoted text
Responses inline below.... An example implementation of the 1.1 verification code can be found at http://git.spdx.org/?p=spdx-tools.git;a=blob;f=src/org/spdx/rdfparser/Verifi cationCodeGenerator.java;h=3c15b8b420fa1a5d5c5ed72d548c0cb43330d28c;hb=HEAD Gary -----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of Marc-Etienne Vargenau Sent: Tuesday, June 19, 2012 7:33 AM To: spdx@... Subject: Package Verification Code (section 4.7) Hello, The text of Package Verification Code (section 4.7) has been changed from SPDX 1.0 to SPDX 1.1 draft. 1) Does that mean that the algorithm changed or is it just described better? [Gary] See bug 968 (https://bugs.linuxfoundation.org/show_bug.cgi?id=968) for a description of the problems and fixes in the Package Verification code algorithm. 2) After sorting, the CR/LF must be removed before applying SHA1? [Gary] Correct 3) The text in SPDX 1.1 draft refers to "normalized_filename" but this is no longer defined. [Gary] This is probably a bug in the spec - if you don't mind, go ahead and add a bug for this. BTW - the normalized filename was more critical in the previous algorithms since it included the filename in the checksum calculation. A fix for the documentation may just be removing the referenced and calling it just a filename. Best regards, Marc-Etienne -- Marc-Etienne Vargenau Alcatel-Lucent France, Route de Villejust, 91620 NOZAY, FRANCE +33 (0)1 30 77 28 33, Marc-Etienne.Vargenau@... _______________________________________________ Spdx mailing list Spdx@... https://lists.spdx.org/mailman/listinfo/spdx |
|
|