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)

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.

| 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

Thank you very much for your quick answer and suggestions.

My goal is not only to standardize the legal text of our FOSS clauses. It
is also to
1) raise awareness about being able to provide the list of FOSS in a
proprietary product or in a big FOSS distribution (Linux, Open BSD,
Eclipse, Swing, ...)
2) Big companies are reluctant to provide you a FOSS list. They are more
or less in compliance but some of them provide you a URL on their web
site on which you find the list of their products and for each of them a
several megabyte ASCII File with the list of all licenses of FOSS on
their products. That's not usable at all. If one of their customer want
to resale their product in one of its products it has to read everything
and identify every action to comply "Ha yes this is apache1.1 so I have
to put some acknowledgement in my documentation!".
3) Liability clause/money damage. Big companies are not always accepting
it. I have been told by some of their lawyers: how can we guarantee that
we are not doing mistakes this is a too complex world. If you take a
Linux distribution with 6000 package and you look at packages, you can
find hundreds of various licenses in one package. Small companies accept
more easily these conditions, but they have not too much money. How do
you value the fact that you have to stop to distribute your product or
the potential issue to have to disclose your source code while it was not
planned and it is not your fault.
4) .... a lot of other issues

I would challenge the SPDX members to take a Linux standard distribution
and to provide me the SPDX file at file level (not at package level). Yes
open source is great but it is also really a Bazard 8-) and with maven
and cloud computing it will become worse.

So the effort is tremendous and cannot be done by one company, it should
be shared. And it is time to start.

So I will study the short terms options you propose. But for the long
term, I would to start to create a new mailing list of people who are
intereted in discussing FOSS governance standardization issues (to start:
FOSS clause in contracts, having a common Database under a king of
Wikipedia contribution system describing FOSS IP, having public tutorial
on FOSS issues, and perhaps things like lobbying to reduce the number of
FOSS licenses, ...); Martin, can we use the FOSS Bazaar infrastructure to
create the mailing list?

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 : Bradley M. Kuhn [mailto:bkuhn@...]
Envoyé : vendredi 15 juin 2012 19:49
À : RUFFIN, MICHEL (MICHEL)
Cc : spdx@...
Objet : FOSS clauses for contracts & fora for discussing it (was Re:
Clarification regarding "FSF legal network")

Michel,

I went back and read your previous posts from February on this topic,
(as I mentioned earlier in this thread, I don't follow SPDX closely. I
mostly joined this thread (Kibo-like) when the term "FSF" came up).

However, having gotten fully caught up on your posts, I think your idea
is a useful one. In my work doing GPL compliance, I have often had
situations where a downstream company has violated and they never
actually had clear clauses in their contract with upstream about what
would happen if a FLOSS license was violated. This has caused mass
confusion and made it more difficult to get the company into compliance.

In a few cases, there *were* clearly developed clauses like the ones you
mention, and it did indeed facilitate more easy work getting to compliance
on the product.

So, I'm thus supportive of your effort to
promulgate these standardized clauses regarding use of FLOSS in
upstream/downstream contracts. Meanwhile, I wish I had a better
suggestion for you of where to talk about the idea....

RUFFIN, MICHEL (MICHEL) wrote at 08:14 (EDT):

what is your suggestion for me to try to standardize these FOSS
clauses. What organization? I have tried SPDX, I have been advised to
go to FSFE legal network.

... as others have suggested, FOSS Bazaar might be a good place.

I have join the FSFE legal network and I tried to get a reaction
without success except "that's interesting"

It sounds like in addition to my objections to ftf-legal, that there
were other issues: your description seems to indicate ftf-legal wasn't
that interested in this giving useful feedback and collaboration on the
issue!

Any suggestion of organization that would have a look?

There was once a forum called "open-bar", which is at:
https://www.open-bar.org/discussion.html but it's mostly defunct AFAICT.
The mailing lists disappeared a while back. The last email from I have
in my archives for <discuss-general@...> was Tuesday 18 Mar
2008.

Meanwhile, as part of the FOSDEM 2012 Legal and Policy track I
coordinated along with Tom Marble, Richard Fontana, and Karen Sandler,
we had some very brief discussions about creating a forum for discussion
that was open and available to all about these issues (like open bar
was). However, it's unclear if, as a community, we're at a "build it
and they would come" moment, so none of us from the FOSDEM 2012 track
have put effort in.

Thus, at the moment, I think FOSS Bazaar is probably the best place to
host this sort of discussion venue, so I think if you want an immediate
discussion about your specific topic, that's probably the place to
start.

Also, as a medium-term suggestion, I strongly recommend you propose a
talk for (a) the FOSDEM 2013 Legal & Policy track, or (b) LinuxCon
(sadly, North America CFP just closed), or (c) at the 2013 Linux
Collaboration Summit Legal Track (which Richard Fontana & I will
co-chair) about the topic. Speaking about the topic at conferences is a
great way to get interest and feedback.

Long term, as a community, it'd be good to solve this general issue: the
fora that exist for Legal, Licensing and Policy issues in Free Software
are scattered across many different places, and some of the primary ones
are closed clubs. I've been witnessing the problem for years and I
don't have a good solution to propose to solve it.
--
-- bkuhn
_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx

[An] SPDX file consists almost exclusively of data collected from
original sources, and copyright law.... doesn't provide my copyright
protection at all for aggregation of otherwise available data. In
essence, an SPDX file may not adequately constitute a 'work of
authorship' that warrants copyright protection.

Hi Marc-Etienne,

There is a more recent version at http://spdx.org/content/tools This page
will become active once the new website is up and running. Let me know if
you have any trouble accessing the page.

The most recent checked in code is a bit in flux as we have not completely
nailed down the SPDX 1.1 changes. Once we finalize the 1.1 spec, I'll
compile and upload a 1.1 compliant version of the tools.

BTW - If you use an Eclipse development environment, there is project meta
data checked in which will allow the code to be compiled in the IDE.

On Fri Jun 15 14:40:49 2012, RUFFIN, MICHEL (MICHEL) wrote:

But the question is what was the purpose of this initially?

It is a excellent question. I have never understood this purpose of this
"feature" of SPDX so someone else will have to provide the answer.

But the question is what was the purpose of this initially?

I am not very happy that data must be made in public domain. For the
following reasons:

- ALU should not be responsible of the data if we export it. And I
understand that ther e is a clause that loow us to do exception (ALU
name not exported with the data, but it should be the other way around
by default any export file should not imply any responsibility from
exporting company).

- if by mischance there are some comments which we will not want to
share with the rest of the world. It should be protected by the
licensing conditions.

Long term, as a community, it'd be good to solve this general issue: the
fora that exist for Legal, Licensing and Policy issues in Free Software
are scattered across many different places, and some of the primary ones
are closed clubs. I've been witnessing the problem for years and I
don't have a good solution to propose to solve it.

what is your suggestion for me to try to standardize these FOSS
clauses. What organization? I have tried SPDX, I have been advised to
go to FSFE legal network.

I have join the FSFE legal network and I tried to get a reaction
without success except "that's interesting"

Any suggestion of organization that would have a look?