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
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
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.
Legal Affairs Center
Harkortstr. 21-23, 40880 Ratingen
Tel.: (+49) 2102 5609 317
Fax.: (+49) 2102 5609 309
soeren_rabenstein@...
____________________________________________________________
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.
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, 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
>>Spdx-tech@...
>>https://lists.spdx.org/mailman/listinfo/spdx-tech
>>
>>
>
>
