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
>>
>>
>
>
