Date   

Re: FOSS clauses for contracts & fora for discussing it (was Re: Clarification regarding "FSF legal network")

RUFFIN MICHEL
 

First I Would like enlighten that when I speak on the SPDX or FSFE mailing list I speak for the Alcatel-Lucent company; I check before with our FOSS executive committee that I can say things (in most of the cases 8-). But I am not a lawyer and I know this might be tricky discussions in term of company and what you have said. So What I say is not officially the Company stamped decision in term of legal (except if stamped) but it is the rough direction of the company, However it reflects the company policy. Barry Freedman is the official guy to accept or not what I am saying. I guess it is important to notice this.

So Barry and myself are more or less co-directing the Alcatel-lucent internal Executive committee since 2007. He is the lawyer, I am the technical guy with a bit of paralegal training (we have 8 or 10 other members in this committee).

So today our points are the following

1) SPDX standard. After discussing with Marc-Etienne who is trying to align our FOSS DB on the SPDX standard we will have to add SHA-1 checksums to our DB. Since we have not that we will look to partners to provide us the data. But in any case we will not have them for all/old entries, so the SPDX standard needs to cope with this kind of situation.

1 bis) what modification we need to do to SDPX standard when we are not able to provide it and to be able to export information.

1 ter) we have issue with the licensing issues of data when coming from SPDX standard: data are public domain with some restriction, but it is not clear

2)Alcatel-Lucent FOSS clauses in suppliers contracts. What group I should contact for standardization of these clauses?

3) Alcatel-lucent is willing to "open source" its FOSS DB Who is interested and how to make this things works

4) Alcatel-Lucent has a lot of tutorials on open source; It is a tremendous work to maintain them, they have been registered on webinar, we are now thinking to update everything and to translate them in foreign languages such as Chinese. Perhaps we can share this effort

Should we create a FOSS governance task force? If SPDX is not the good place, If SFSE legal network is not the good place, tell me where!

Alcatel-lucent is committed to respect the open source licences philosophies (not only the legal part of it) but we need help because this is far to be clear.

That's my Friday evening email, Please think about this, we need to put our forces together.

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


Re: Compilation of SPDX tools

Gary O'Neall
 

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.

Gary

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


Re: FOSS clauses for contracts & fora for discussing it (was Re: Clarification regarding "FSF legal network")

Kevin P. Fleming <kpfleming@...>
 

On 06/15/2012 12:49 PM, Bradley M. Kuhn wrote:
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.
For what it's worth, you are not alone in wanting to find a solution to this problem :-) The lack of knowledge sharing in the Free Software legal community is disappointing, although the SPDX effort is one step to help with part of that problem.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@... | SIP: kpfleming@... | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org


FOSS clauses for contracts & fora for discussing it (was Re: Clarification regarding "FSF legal network")

Bradley M. Kuhn <bkuhn@...>
 

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


TR: SPDX standard: files are placed in public domain

RUFFIN MICHEL
 

Dear all, once again on a different topic within our current effort in implementing the SPDX standard.

 

Here it is a licensing issue.

 

I am not very comfortable with the licensing issue for the data when using the standard. See the quick Analysis of Barry below our Senior attorney on IP issues and I have a quick chat today with him on that subject.

 

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.

 

Legally speaking implementing a format that implies some obligation on the data is unclear.

 

So my question is what is the rational for these licensing conditions and can we alleviate them a bit?

 

Michel.Ruffin@..., PhD
Software Coordination Manager, Bell Labs, Corporate CTO Dpt
Distinguished Membe
r of Technical Staff
Tel +33 (0) 6 75 25 21 94
Alcatel-Lucent International, Centre de Villarceaux

Route De Villejust, 91620 Nozay, France


De : Freedman, Barry H (Barry)
Envoyé : mercredi 13 juin 2012 23:12
Objet : RE: SPDX standard: files are placed in public domain

 

Michel and all:  I have looked at the Open Data Commons Public Domain Dedication and License 1.0 (“PDDL-1.0”), which is the license for SPDX 1.0, and also

Creative Commons CC0 1.0 Universal license, which is the license for SPDX1.1.  They are both essentially the same, in that they place the SPDX file itself in the public domain, meaning that we have no further copyright rights therein.  But, both versions also make it clear that we can temporarily or permanently limit, by a separate and independent agreement, recipients from (i) distribution of a specific aggregation (collection) of SPDX files to others or (ii) disclosing ALU  as the source and/or creator of any specific SPDX file(s).

 

So, we need to be comfortable that the SPDX file itself (including comments in the file) does not contain anything that we do not want to dedicate.  Perhaps we can discuss this further at the next FOSS EC meeting.

 

Let me know if there are questions.  Thx. Barry

Corporate-sig-logo

 

Barry H. Freedman
Senior Intellectual Property Attorney

Intellectual Property and Standards
IP Law Services Group
600-700 Mountain Avenue
Room 3A-239
Murray Hill, New Jersey 07974
Office: 908-582-4060

Cell:  908-692-6773
e-mail freedman@...

CONFIDENTIALITY NOTICE
This email may contain confidential or privileged information.  If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, then please notify us by return e-mail immediately.  If you have received this e-mail in error, do not copy this e-mail for any purpose nor disclose its contents to any other person.


Compilation of SPDX tools

Marc-Etienne Vargenau
 

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


Re: Clarification regarding "FSF legal network" (was Re: Import and export function of SPDX)

RUFFIN MICHEL
 

So Bradley, 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?

It took us a lot of manpower to define FOSs clause which are widely accepted and tremendous effort to negotiate them with various suppliers before reaching this state. And if not standardize we can expect again more efforts

That's important because we are trying to standardize as much as we can of our FOSS governance process (for instance having an "open source" database describing iPR issues so the effort done by each company today will be shared and copyright owners can have their own word for correcting information interpretation. I think this will be the benefit of everybody: copyright owners, open source communities, proprietary software vendors, FOSS distributor companies.

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


Re: Clarification regarding "FSF legal network" (was Re: Import and export function of SPDX)

Bradley M. Kuhn <bkuhn@...>
 

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


Re: Clarification regarding "FSF legal network" (was Re: Import and export function of SPDX)

RUFFIN MICHEL
 

You are right it is FTFE legal network.
If I provided our FOSS clause to SPDX it was illustrate the use case, I know that the discussion on this subject should be in FTFE mailing list.

By the way with the discussion in SPDX, I am now convinced that we need to add these two fields to our database. However to cope with legacy the import/export function might provide a solution when these field are blank

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


Thursday SPDX General Meeting Reminder

Philip Odence
 

I am on vacation. Kate will fill in for me. 

Meeting Time: June14, 8am PST / 10 am CST / 11am EST / 15:00 UTC. http://www.timeanddate.com/worldclock/converter.html

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

 
Administrative Agenda
Attendance
Approve minutes: 

Technical Team Report - Kate
Legal Team Report - Jilayne
Business Team Report – Jack Manbeck/Scott Lamons

Cross Functional Issues
Website Update – Steve Cropper


Re: Clarification regarding "FSF legal network" (was Re: Import and export function of SPDX)

Bradley M. Kuhn <bkuhn@...>
 

On 06/13/2012 10:06 PM, Bradley M. Kuhn wrote:
I am quite sure FTFE-legal [sic: should be FTF-legal]
has no affiliation with FSF whatsoever.
Armijn Hemel replied:
There is no such thing as "FTFE-legal".
I'm sorry; you're right; I inadvertently added an "E". I was thinking of
FTF-legal, which does exist: https://mail.fsfeurope.org/mailman/listinfo/ftf-legal

Indeed, I should have remembered there's no 'E', as I've submitted many
(declined) subscription requests there!

Jilayne Lovejoy also replied:
That was a function of sloppy and quick typing on my part
and should have really referred to it as the European
Legal Network (facilitated by FSFE)
No problem! As you see, I did something similar (above) myself!
It's problematic that there are a lot of very similar names here for
very different things. :)

Anyway, to my knowledge, neither the European Legal Network, nor ftf-legal
are affiliated with, nor endorsed by, the FSF.

I just want to clarify that because some of the publications made under
that group's auspices contradict some of FSF's positions on the GPL.

[ Full disclosure: in addition to my various other roles in Free Software,
I serve as a volunteer on the Board of Directors of the FSF:
http://www.fsf.org/about/board . ]

-- bkuhn


Re: Clarification regarding "FSF legal network" (was Re: Import and export function of SPDX)

Jilayne Lovejoy <jilayne.lovejoy@...>
 

You are indeed correct, Bradley. That was a function of sloppy and quick
typing on my part and should have really referred to it as the European
Legal Network (facilitated by FSFE) to be perfectly accurate. See
http://wiki.fsfe.org/EuropeanLegalNetwork for more information for anyone
I have thusly confused.

Cheers,
Jilayne

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


Re: Clarification regarding "FSF legal network" (was Re: Import and export function of SPDX)

Armijn Hemel <armijn@...>
 

On 06/13/2012 10:06 PM, Bradley M. Kuhn wrote:
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.
There is no such thing as "FTFE-legal". You might be referring to the European Legal Network. Information about it can be found here:

http://fsfe.org/projects/ftf/network.en.html

armijn

--
------------------------------------------------------------------------
armijn@... || http://www.gpl-violations.org/
------------------------------------------------------------------------


Clarification regarding "FSF legal network" (was Re: Import and export function of SPDX)

Bradley M. Kuhn <bkuhn@...>
 

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


Re: Import and export function of SPDX

Gary O'Neall
 

Thanks Michel. This does describe the use case. I think this is an
excellent discussion on which use cases require which fields.

For the use case
http://spdx.org/wiki/provide-sufficient-data-allow-consumer-comply-licenses-
redistribution, there may really be two different use cases. The first is
receiving the open source information (import) and the second is providing
the information to downstream consumers (export).

In my opinion, there would be value in capturing the archive file and
verification information on the import and passing it through if available -
you may want to consider adding this to your process going forward (this is
something I recommend to my clients). Even with an open source database of
a million+ packages, there will be specific versions missing where having
the checksums would speed up any verification process.

That being said, for any legacy information where this was not already
collected and a few other common circumstances, I believe it would not be
practical to capture these fields.

Following are two situations I have run across in helping other commercial
entities setup an open source inventory management and review process:
- Legacy open source where the original downloaded source files were not
saved and the origin website for download is no longer available.
- Code copied from website postings where there is no "file" to checksum.
This is the case for some JavaScript open source.

I don't have any hard data to back up this claim, but I believe if we
require the export to contain the verification code and archive file name
for all open source code which is embedded in the product, very few larger
commercial companies of any size would be able to comply. We have some good
representation of large commercial companies redistributing open source
software participating in SPDX, so I will defer to their opinions on this
topic.

I have a couple ideas on how we can implement an "SPDX-Lite" mechanism which
may help in this situation. Once I get a bit more time, I'll write up a
proposal in Bugzilla.

Gary

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


Re: Import and export function of SPDX

Kevin P. Fleming <kpfleming@...>
 

On 06/13/2012 10:51 AM, RUFFIN, MICHEL (MICHEL) wrote:
Well, today we solve more or less this issue by requesting the URL where the FOSs can be downloaded, so URL + name + version number determine the FOSS used. It is not perfect but I never manage a good solution to identify uniquely an open source.

Even the URL is not enough, when our foss evaluators received a URL to study a FOSS, they have first to check that it is the good one. For instance people are providing the URL on Sourceforge or on a mirror site, while this is not the home page for the software. So our internal recommendation is to use the home page of the copyright owner whenever possible.

Not that the URL and version number are the only mandatory fields in our database
Right, and this is what the package checksum was intended to solve. If you have that, then no matter where you go the source archive, you can confirm (with nearly 100% confidence) that it has the some contents as were used by the person who constructed the SPDX file.

In other words, the problem you've been struggling with has been addressed as part of SPDX, but you aren't in a position to be able to take advantage of it, which is somewhat unfortunate.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@... | SIP: kpfleming@... | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org


Re: Import and export function of SPDX

Soeren_Rabenstein@...
 

Dear Michel

I find your idea utmost interesting and would like to discuss it in further (sorry that I did not react earlier. Due to my recent transfer to EU with major expansion of job responsibilities, I hardly find time to read mails from this list anymore :()

But I think a better forum for this project would be the FSFE legal network.


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



-----Ursprüngliche Nachricht-----
Von: spdx-bounces@... [mailto:spdx-bounces@...] Im Auftrag von RUFFIN, MICHEL (MICHEL)
Gesendet: Mittwoch, 13. Juni 2012 14:45
An: Gary O'Neall; 'Peter Williams'
Cc: spdx-tech@...; spdx@...
Betreff: 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


Re: Import and export function of SPDX

RUFFIN MICHEL
 

Well, today we solve more or less this issue by requesting the URL where the FOSs can be downloaded, so URL + name + version number determine the FOSS used. It is not perfect but I never manage a good solution to identify uniquely an open source.

Even the URL is not enough, when our foss evaluators received a URL to study a FOSS, they have first to check that it is the good one. For instance people are providing the URL on Sourceforge or on a mirror site, while this is not the home page for the software. So our internal recommendation is to use the home page of the copyright owner whenever possible.

Not that the URL and version number are the only mandatory fields in our database

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 Kevin P. Fleming
Envoyé : mercredi 13 juin 2012 16:57
À : spdx@...
Objet : Re: Import and export function of SPDX

On 06/13/2012 06:50 AM, RUFFIN, MICHEL (MICHEL) wrote:
We are currently in the process of revisiting all our entries in the
database to increase consistency and remove confidential information in
order to be able to provide the content of our database to some external
partner companies such as Blackduck (and there are others). The goal is
to increase the quality and completeness of their database (we have 200
FOSS experts feeding our DB for 5000 entries, Blackduck has a DB of
around 500 000 entries, Antelink has a DB of 1 000 000 entries, I do not
know for Palamida, Protecode and NextB but it should be similar in range.).
I'm curious how you see this working. As I posted on the other SPDX list
yesterday, I find the package-level metadata to be mandatory in order to
have a high degree of trust in the rest of the information present in
the SPDX file.

As an example of why, let's assume that a company has received a binary
distribution of some software from a vendor, and the software is
nominally licensed under the GPLv2. The vendor supplies the company with
a source archive that purportedly is the original source used to produce
that binary code, and also provides an SPDX file that claims to be a
valid and accurate representation of the license information present in
the files in the source archive. The company wants to use this
information to ensure that they are in compliance with the stated
license obligations when they further distribute this binary.

However, the SPDX file does not contain the source archive
name/version/etc. nor its checksum. All it contains is file names and
their checksums. How can the receiving company be sure that the SPDX
file correctly represents the source archive they have received? If the
source archive contains additional source files not represented in the
SPDX file, there is no way for the receiving company to know this other
than to audit the source archive contents again, thus partially
defeating the purpose of having received an SPDX file in the first
place. In my own case, if I did this audit and found that the source
archive contained source files that were *not* represented in the SPDX
file, then I'd probably just throw away the SPDX file and act as if I
had not received it in the first place.

I understand that there are probably many situations where the source
archive is not available, or will not be distributed, and in such
situations making these fields mandatory in SPDX seems burdensome.
However, in any case where the source archive is available and will be
distributed, I think these fields are as important as any other
top-level metadata in the SPDX file.

Could we construct the SPDX 2.0 XML in such a way that there was an
attribute indicating that the source archive is 'unavailable or
unknown', and if this attribute it set, then (and only then) these other
fields become optional? Doing this would mean that if the
producer/distributor of an SPDX file makes the claim that the source
archive is unavailable/unknown (and thus does not provide these
additional pieces of information), but in fact the source archive is
available, the receiver of the SPDX file could then choose whether to
audit the source archive or trust the SPDX file.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@... | SIP: kpfleming@... | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx


Re: Import and export function of SPDX

RUFFIN MICHEL
 

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.

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


Re: Import and export function of SPDX

Kevin P. Fleming <kpfleming@...>
 

On 06/12/2012 06:08 PM, Peter Williams wrote:
Even if you choose not to accept an incomplete file verbatim, having it
might still be advantageous. If nothing else it gives you a place to
start your investigation. For example, if i receive an SPDX file w/o a
packageVerificationCode, i might decide i need to do my own analysis of
the package i am using because i cannot verify that is exactly the one
described by the SPDX file. Fortunately, the licensing of software
packages rarely change dramatically between versions so i could use the
untrusted SPDX data as a starting point. Such a head start would be
likely to save a great deal of time and effort. This would be about the
same process needed if i received an SPDX file with a
packageVerificationCode that did not match my package.
Agreed, and this is pretty much what I just posted in another reply before having read yours :-)

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@... | SIP: kpfleming@... | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

941 - 960 of 1592