-----Message d'origine-----
De : Peter Williams [mailto:peter.williams@...]
Envoyé : vendredi 15 juin 2012 22:25
À : RUFFIN, MICHEL (MICHEL)
Cc : Freedman, Barry H (Barry); spdx@...
Objet : Re: TR: SPDX standard: files are placed in public domain

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

Just 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

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

-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...] On
Behalf Of Marc-Etienne Vargenau
Sent: Friday, June 15, 2012 7:44 AM
To: spdx@...
Subject: Compilation of SPDX tools

Hello,

The compiled version et the Java tools in this page:
http://www.spdx.org/tools
is rather old compared to the source code found in
http://git.spdx.org/?p=spdx-tools.git;a=summary

Can someone please compile the latest source code and upload the result to
the tools page?

I tried to compile it myself but did not succeed.
The Gem from my Ubuntu seems to be incompatible.

Thank for yor help.

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

-----Message d'origine-----
De : spdx-bounces@... [mailto:spdx-bounces@...] De la part de Bradley M. Kuhn
Envoyé : jeudi 14 juin 2012 16:39
À : spdx@...
Cc : spdx-tech@...
Objet : Re: Clarification regarding "FSF legal network" (was Re: Import and export function of SPDX)

RUFFIN, MICHEL (MICHEL) wrote today:

I know that the discussion on this subject should be in FTFE mailing
list.

Actually, I caution against being too quick to move discussion to
ftf-legal mailing list, even if a topic seems off-topic for similar,
public lists.

ftf-legal is an invite-only mailing list, and thus it's probably not a
good choice for discussion of topics where the Free Software community can
help, since most of the Free Software community can't access ftf-legal.
The list organizers said publicly at LinuxCon Europe 2011 that the
criteria for subscription to ftf-legal are secret, so no one outside of
existing list members actually know what they need to do to qualify for
participation. After my three-year-long Kafkaesque experience of
attempting to subscribe to ftf-legal, I eventually just gave up.

Thus, I'd hate for (even tangentially) relevant discussions to SPDX to
fall into the black hole of private discussion on ftf-legal. As most
subscribers to *this* list know, I've been occasionally critical of SPDX
for various reasons, but I have *no* criticisms about the inclusiveness
and openness of SPDX's process, which are top-notch. Indeed, Martin
invited me to the SPDX list when he chartered it as "FOSS Bazaar Package
Facts". I've lurked on the list since its inception, and I've always been
welcomed to participate (sometimes even by pleading private phone calls
begging me to get more involved in SPDX :).

In April 2012 at the Linux Foundation Collaboration Summit legal track
that I chaired, I explained the reasons that I don't regularly participate
in SPDX. For those who weren't present for that event, the two primary
reasons why I don't actively participate in SPDX are:

(a) SPDX currently has no plans nor mechanism to address the key and
most common FLOSS license compliance problem -- namely, inadequate
and/or missing "scripts to control compilation and installation of the
executable" for GPL'd and/or LGPL'd software. Given my limited time and
wide range of duties, I need to focus any time spent on new
compliance-assistance projects on solutions that will solve that primary
compliance problem before focusing on the (valuable but minor) ones that
SPDX seeks to address. (And many of you know, I've given my endorsement
to the Yocto project, as I think it's a good tool to help address the
key issue of FLOSS compliance. I also encouraged the Yocto project to
work more directly with SPDX, which I understand is now happening.)

(b) I strongly object to the fact that most of the software being written
by SPDX committee participants utilizing the SPDX format is proprietary
software. I find this not only offensive but also ironic (i.e.,
developing and marketing *proprietary* software to help people better
utilize *Free* Software).

I should have posted these concerns sooner to this mailing list, but I
hadn't thought to do so since I'd already explained the concerns privately
to so many of you before.

-- bkuhn
_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx

-----Message d'origine-----
De : spdx-bounces@... [mailto:spdx-bounces@...] De la part de Bradley M. Kuhn
Envoyé : mercredi 13 juin 2012 22:07
À : Jilayne Lovejoy
Cc : spdx-tech@...; spdx@...
Objet : Clarification regarding "FSF legal network" (was Re: Import and export function of SPDX)

Jilayne Lovejoy wrote:

In regards to your posting...to... the FSF legal network

Just for clarification: the FSF doesn't have a legal network, to my
knowledge.

I believe you are likely referring to the highly secretive entity called
FTFE-legal, which appears to have some (albeit unclear) affiliation with a
different organization called FSF Europe. While I am indeed unclear on what
FTFE-legal's relationship to FSF Europe is, I am quite sure FTFE-legal has no
affiliation with FSF whatsoever.

Nevertheless, please do feel free to correct me if I have any of those facts
wrong. That's my understanding, having discussed this issue extensively with
FSF leadership.

-- bkuhn
_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx

On 6/13/12 2:06 PM, "Bradley M. Kuhn" <bkuhn@...> wrote:

Jilayne Lovejoy wrote:

In regards to your posting...to... the FSF legal network

Just for clarification: the FSF doesn't have a legal network, to my
knowledge.

I believe you are likely referring to the highly secretive entity called
FTFE-legal, which appears to have some (albeit unclear) affiliation with a
different organization called FSF Europe. While I am indeed unclear on
what
FTFE-legal's relationship to FSF Europe is, I am quite sure FTFE-legal
has no
affiliation with FSF whatsoever.

Nevertheless, please do feel free to correct me if I have any of those
facts
wrong. That's my understanding, having discussed this issue extensively
with
FSF leadership.

-- bkuhn

-----Original Message-----
From: RUFFIN, MICHEL (MICHEL) [mailto:michel.ruffin@...]
Sent: Wednesday, June 13, 2012 5:45 AM
To: Gary O'Neall; 'Peter Williams'
Cc: spdx-tech@...; spdx@...
Subject: RE: Import and export function of SPDX

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

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