Date   

Re: Import and export function of SPDX

Soeren_Rabenstein@...
 

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

 

 

 

Von: spdx-bounces@... [mailto:spdx-bounces@...] Im Auftrag von RUFFIN, MICHEL (MICHEL)
Gesendet: Freitag, 22. Juni 2012 13:23
An: Jilayne Lovejoy; Gary O'Neall; Peter Williams
Cc: spdx-tech@...; spdx@...
Betreff: RE: Import and export function of SPDX

 

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, 91620 Nozay, 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, 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

>> 

>> 

 

 


Re: TR: SPDX standard: files are placed in public domain

RUFFIN MICHEL
 

As you say (I like the expression) my concern about this license is more like getting an eye brow raised; What does this license implies?

If I want to export data from our DB, I will not make it public but aim a specific company/group to do it. If this is partner or a non profit organization, the data will be provided without any liability from ALU that it is correct (we can do mistake) the goal is to help the partner, non profit organization. If it is a customer we will probably take a little more commitment and we will add a clause such as "to the best of our knowledge this data is accurate" or something like this. But in any case we will not provide this data with the name of our company as public domain our lawyers will not accept that. The subject is so complex that there is necessary mistakes.

Now a disclaimer of warranty and liability is not enough. If I publish a list of software in which I say this software is LGPL, while in fact it is GPL I can be sued for GPL infringement.

In addition our DB is not SPDX compliant is the way that there are some field which interpret FOSS license according to ALU policy, special deals done with copyright owners to interpret license differently or have special permissions, consideration regarding patents (ALu or external), ... We are doing currently a cleaning to separate this information from what we can export, but with 200 people feeding independently and continually our database we cannot guarantee that some confidential information will not be in the export file. So public domain is out of question.

That's for the use case. Now on the legal side. If I generate an export file and I write "Alcatel-Lucent proprietary data - confidential" This is in contradiction with the license saying data must be in public domain. What does the judge decide in this case? I asked the question to our lawyers and they say it is unclear but they are not sure that presenting proprietary data according to a standard might impose a license on the data.

I will be happy to participate to a conf call on the subject, this need clarification and can jeopardize the success of SPDX. But one of our lawyers (Barry) should be present to understand and explain the implication of this license.

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 Jilayne Lovejoy
Envoyé : vendredi 22 juin 2012 03:03
À : Kevin P. Fleming; spdx@...
Cc : SPDX-legal
Objet : Re: TR: SPDX standard: files are placed in public domain

In response to Michel's initial question about CC-0 (and subsequent
responses):

Here's some of the back story:
This was an issue that the legal work group spent a vast amount of time
discussing. Initially we had decided on the PddL license, but got some
pretty severe push-back for that license during LinuxCon North America and
1.0 release last August. So, it was back to the drawing board. Due to
the many meetings spent discussing this (which may be captured to varying
degrees in the meeting minutes around that time...), Mark Gisi (thanks
Mark!) posted a summary of the reason for having a license and then the
pros and cons of the various license options discussed on its own page
(see http://spdx.org/wiki/spdx-metadata-license-rationale-cc0) for easy
reference, transparency, and historical purposes. Once we decided on CC-0,
we reached out to various community members (including those specifically
who had expressed discomfort with PddL) to make sure the new decision was
amenable.

That is a very short summary of the process. The webpage referenced above
provides a good overview, but naturally does not capture the nuances and
details of the concerns, rationale, and so forth raised during those
discussions.

Michel - from, your previous email, it sounds like you've got an eye brow
raised, but are still formulating exactly what the exact concern is. (I do
think that the goal of using an open, permissive license, if one at all,
was to facilitate free exchange, which appears to be part of your
concern.) In any case, perhaps the above information will help a bit and
if you have further concerns, I might suggest either asking for an agenda
item on one of the legal calls or I can simply set up a call with some of
the key people who were involved in the above process - which ever is
more appropriate.

Consequently, I have now included this email on the SPDX Legal group list
as well, as others may be able to weigh in. The relevant bits from the
various emails are cut and pasted below (separated by a dotted line) for
reference for those who missed this on the general SPDX mailing list.

Incidentally - Kevin and Bradley both had good points in regards to the
potential legal analysis. The other piece of that puzzle concerns the
reality that E.U. law does allow database protection (of facts, that would
otherwise not be considered protectable under, U.S. law, for example). If
anyone is interested in learning more about this, there is an excellent
article here: http://www.ifosslr.org/ifosslr/article/view/62
(but don't go learning too much about this law stuff, as you might put us
out of work ;)

Cheers,
Jilayne

Jilayne Lovejoy | Corporate Counsel
OpenLogic, Inc.

jlovejoy@... | 720 240 4545




------------

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


---------------

What I want is freedom, to exchange information between companies without
constraints. If we need constraints, we put it in the contract. It is not
to SPDX to put the constraints.

Let us time to think about consequences/consraints, ... before addressing
the issue. But the question is what was the purpose of this initially?

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


----------------

On 6/15/12 3:05 PM, "Kevin P. Fleming" <kpfleming@...> wrote:

On 06/15/2012 03:53 PM, Peter Williams wrote:
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.
I suspect that it may be at least partially based on the fact that the
SPDX file consists almost exclusively of data collected from original
sources, and copyright law (at least as I've been told, I'm no lawyer)
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,
and thus there really wouldn't be a legitimate way to control its
distribution via licensing.

This is just a mildly educated guess late on a Friday afternoon, though.
I could be 1000% off base :-)

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

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


Re: Import and export function of SPDX

RUFFIN MICHEL
 

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, 91620 Nozay, 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, 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

>> 

>> 

 

 


Re: TR: SPDX standard: files are placed in public domain

Jilayne Lovejoy <jilayne.lovejoy@...>
 

In response to Michel's initial question about CC-0 (and subsequent
responses):

Here's some of the back story:
This was an issue that the legal work group spent a vast amount of time
discussing. Initially we had decided on the PddL license, but got some
pretty severe push-back for that license during LinuxCon North America and
1.0 release last August. So, it was back to the drawing board. Due to
the many meetings spent discussing this (which may be captured to varying
degrees in the meeting minutes around that time...), Mark Gisi (thanks
Mark!) posted a summary of the reason for having a license and then the
pros and cons of the various license options discussed on its own page
(see http://spdx.org/wiki/spdx-metadata-license-rationale-cc0) for easy
reference, transparency, and historical purposes. Once we decided on CC-0,
we reached out to various community members (including those specifically
who had expressed discomfort with PddL) to make sure the new decision was
amenable.

That is a very short summary of the process. The webpage referenced above
provides a good overview, but naturally does not capture the nuances and
details of the concerns, rationale, and so forth raised during those
discussions.

Michel - from, your previous email, it sounds like you've got an eye brow
raised, but are still formulating exactly what the exact concern is. (I do
think that the goal of using an open, permissive license, if one at all,
was to facilitate free exchange, which appears to be part of your
concern.) In any case, perhaps the above information will help a bit and
if you have further concerns, I might suggest either asking for an agenda
item on one of the legal calls or I can simply set up a call with some of
the key people who were involved in the above process - which ever is
more appropriate.

Consequently, I have now included this email on the SPDX Legal group list
as well, as others may be able to weigh in. The relevant bits from the
various emails are cut and pasted below (separated by a dotted line) for
reference for those who missed this on the general SPDX mailing list.

Incidentally - Kevin and Bradley both had good points in regards to the
potential legal analysis. The other piece of that puzzle concerns the
reality that E.U. law does allow database protection (of facts, that would
otherwise not be considered protectable under, U.S. law, for example). If
anyone is interested in learning more about this, there is an excellent
article here: http://www.ifosslr.org/ifosslr/article/view/62
(but don't go learning too much about this law stuff, as you might put us
out of work ;)

Cheers,
Jilayne

Jilayne Lovejoy | Corporate Counsel
OpenLogic, Inc.

jlovejoy@... | 720 240 4545




------------

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


---------------

What I want is freedom, to exchange information between companies without
constraints. If we need constraints, we put it in the contract. It is not
to SPDX to put the constraints.

Let us time to think about consequences/consraints, ... before addressing
the issue. But the question is what was the purpose of this initially?

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


----------------

On 6/15/12 3:05 PM, "Kevin P. Fleming" <kpfleming@...> wrote:

On 06/15/2012 03:53 PM, Peter Williams wrote:
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.
I suspect that it may be at least partially based on the fact that the
SPDX file consists almost exclusively of data collected from original
sources, and copyright law (at least as I've been told, I'm no lawyer)
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,
and thus there really wouldn't be a legitimate way to control its
distribution via licensing.

This is just a mildly educated guess late on a Friday afternoon, though.
I could be 1000% off base :-)

--
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: Clarification regarding "FSF legal network" (was Re: Import and export function of SPDX)

Jilayne Lovejoy <jilayne.lovejoy@...>
 

Responses inline below and to this email, since Bradley hit upon several
salient issues :)

On 6/14/12 8:39 AM, "Bradley M. Kuhn" <bkuhn@...> wrote:

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.
Would agree to the extent that, considering that what Michel is proposing
doesn't (yet) seem to have a directly on-point mailing list, discussing it
across multiple platforms (and multiple times, in order to finally get a
response ;) seems about right!

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.
I feel like I need to at least suggest an alternative view for
balance-sakes, especially since, as a member, I have greatly benefited
from the discussions on that list-serve. The network is made up of mostly
lawyers and from all different kinds of organizations and, due to the
Chatham House Rule, provides a space for open conversation among members
without fear of being quoted/attributed outside the network. Given the
reluctance most lawyers have in terms of making public statements, etc,
this is a pretty valuable forum, as it provides a chance to discuss things
that just may not be ready to take public or that a lawyer cannot risk
having attributed or implied to the company he or she works for.

In so far as what Michel is suggesting here re: the license clauses, I can
imagine quite a few companies being quite resistant/hesitant about sharing
this information initially. This is where some discussion that is limited
in its exposure can be helpful to begin to break down that barrier.

Just like scanning, multiple methods of attacking the problem leads to the
best results?? (bad analogy, but seemed fitting ;)


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 :).
Lurking is completely fine for whomever. More involvement means more
opportunity to shape the process, so it's up to each participant to
determine their level of participation (just reiterating something said at
the SPDX Forum, for benefit of all).


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.)
I'm not sure it's the role of SPDX to address this problem (at least
directly - the goal/mission in terms of license compliance has been more
of facilitation, than doing the job of compliance itself). In any case -
we all have limited resources/time/energy, but I do think that the various
efforts (yours, SPDX, Yocto, and so forth...) come together at the common
goal of making the use, proliferation, health, compliance with licenses...
of open source software easier for all!



(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).
But all the tools coming out of the SPDX working groups are open source!
http://spdx.org/wiki/sandbox-tools (I think there are more than this, but
I'm not the one to appropriately answer that question).
To be fair, of course the companies who have commercial scanning tools are
going to include the ability to generate SPDX files as a feature - because
their customers are asking for it. So, there's both - that can't be all
bad ;)

Jilayne


Re: Import and export function of SPDX

Jilayne Lovejoy <jilayne.lovejoy@...>
 

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


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

Philip Odence
 

Michel,
Your idea about standard FOSS clauses might fit into the charter of the
Linux Foundation Open Compliance Program.
http://www.linuxfoundation.org/programs/legal/compliance (To head off the
question, the program is for open source compliance in general, not
limited to Linux.)
I am cc'ing Ibrahim who coordinates that for the LF with hopes that he
will weigh in. (I believe, he's out of the office this week, so he may not
respond immediately.)
Phil

On 6/18/12 9:30 AM, "RUFFIN, MICHEL (MICHEL)"
<michel.ruffin@...> wrote:

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


FW: License List Matching Guidelines - update

Philip Odence
 

To SPDX General List Members,
The legal team is putting final touches on matching guidelines. In case you have not been following, this is your chance to speak up if you see any show-stoppers. The legal team has been regularly reporting progress on this work, so I don't expect it to be a surprise for anyone, but I want to err on the side of over-communication as these guidelines will have ongoing technical implications.
Best,
Phil

From: Jilayne Lovejoy <jilayne.lovejoy@...>
Date: Thu, 14 Jun 2012 05:08:49 +0000
To: SPDX-legal <spdx-legal@...>
Cc: Phil Odence <podence@...>
Subject: License List Matching Guidelines - update

Hi All, 

We are aiming to finish (at least the first draft of) the SPDX License List Matching Guidelines by the end of June.  To this end, we made some progress on today's legal work stream call, but decided to schedule an additional, off-week call to help facilitate this goal.  

1) please review the updated matching guidelines here:  http://spdx.org/wiki/spdx-license-list-match-guidelines
In particular, note the decision to use {{ }} to indicate text that can be ignored for matching purposes, this applies in particular to the BSD and old Apache licenses.  I have made a first pass at these, but since you won't be able to see them until the new license list is posted, I'm attaching the relevant text files to this email for review/feedback.

2) if you have any additional thoughts or suggestions, please add a comment to that page at the bottom (note there are some comments already posted).  Please comment by end-of-business, next Wednesday, 20 June.

3) attend the special call to discuss all the posted comments and any other outstanding issues: 
Thursday, 21 June at 9am PT / noon ET (immediately after the business team call)
Dial-in: 1.866.740.1260
access: 2404545

4) if we don't complete everything on that call, we will finish up on the regular legal  call on 6/27 (but I hope to wrap up on next Thursday!!)

Let me know if you have any questions.

Cheers,

Jilayne Lovejoy |  Corporate Counsel
OpenLogic, Inc.
jlovejoy@...   720 240 4545


Re: Package Verification Code (section 4.7)

Gary O'Neall
 

Hi Marc-Etienne,

Responses inline below....

An example implementation of the 1.1 verification code can be found at
http://git.spdx.org/?p=spdx-tools.git;a=blob;f=src/org/spdx/rdfparser/Verifi
cationCodeGenerator.java;h=3c15b8b420fa1a5d5c5ed72d548c0cb43330d28c;hb=HEAD

Gary

-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...] On
Behalf Of Marc-Etienne Vargenau
Sent: Tuesday, June 19, 2012 7:33 AM
To: spdx@...
Subject: Package Verification Code (section 4.7)

Hello,

The text of Package Verification Code (section 4.7) has been changed from
SPDX 1.0 to SPDX 1.1 draft.

1) Does that mean that the algorithm changed or is it just described better?
[Gary] See bug 968 (https://bugs.linuxfoundation.org/show_bug.cgi?id=968)
for a description of the problems and fixes in the Package Verification code
algorithm.

2) After sorting, the CR/LF must be removed before applying SHA1?
[Gary] Correct

3) The text in SPDX 1.1 draft refers to "normalized_filename"
but this is no longer defined.
[Gary] This is probably a bug in the spec - if you don't mind, go ahead and
add a bug for this. BTW - the normalized filename was more critical in the
previous algorithms since it included the filename in the checksum
calculation. A fix for the documentation may just be removing the
referenced and calling it just a filename.

Best regards,

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: Compilation of SPDX tools

Gary O'Neall
 

Hi Marc-Etienne,

I am expecting to have the tools posted for the 1.1 spec by July 9th. We
still have a few more items to close on for the spec, so the schedule is
subject to change.

I'll post a note to the spdx tech list once the tools have been published.

Gary

-----Original Message-----
From: Marc-Etienne Vargenau
[mailto:Marc-Etienne.Vargenau@...]
Sent: Monday, June 18, 2012 2:33 AM
To: Gary O'Neall
Cc: spdx@...
Subject: Re: Compilation of SPDX tools

Le 15/06/2012 20:47, Gary O'Neall a écrit :
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.
Hi Gary,

Thanks, I could download the tools from this 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.
When is the final SPDX 1.1 expected?

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.
I do not, but I will try that.

Best regards,

Marc-Etienne

--
Marc-Etienne Vargenau
Alcatel-Lucent France, Route de Villejust, 91620 NOZAY, FRANCE
+33 (0)1 30 77 28 33, Marc-Etienne.Vargenau@...


Package Verification Code (section 4.7)

Marc-Etienne Vargenau
 

Hello,

The text of Package Verification Code (section 4.7) has been
changed from SPDX 1.0 to SPDX 1.1 draft.

1) Does that mean that the algorithm changed or is it just
described better?

2) After sorting, the CR/LF must be removed before applying SHA1?

3) The text in SPDX 1.1 draft refers to "normalized_filename"
but this is no longer defined.

Best regards,

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: TR: SPDX standard: files are placed in public domain

Bradley M. Kuhn <bkuhn@...>
 

Kevin Fleming wrote at 17:05 (EDT) on Friday:
[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.
I'd suspect strongly that there *is* an arrangement copyright on the
arrangement someone makes. I hope SPDX has done something to deal with
this fact.

Arrangement copyrights are usually pretty thin, but I do think that
arranging data into an SPDX file is a creative expression. It's clear
from reading the spec that there's different ways to arrange the same
data into an SPDX file.
--
-- bkuhn


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

RUFFIN MICHEL
 

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


Re: Compilation of SPDX tools

Marc-Etienne Vargenau
 

Le 15/06/2012 20:47, Gary O'Neall a écrit :
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.
Hi Gary,

Thanks, I could download the tools from this 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.
When is the final SPDX 1.1 expected?

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.
I do not, but I will try that.

Best regards,

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: TR: SPDX standard: files are placed in public domain

RUFFIN MICHEL
 

It is not a definite answer, but discussing with our people implementing the spec (marc-Etienne in cc)it seems that the checksums would be usefull to compare package between companies, but I do not see a need for the package tar name

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é : vendredi 15 juin 2012 23:06
À : spdx@...
Objet : Re: TR: SPDX standard: files are placed in public domain

On 06/15/2012 03:53 PM, Peter Williams wrote:
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.
I suspect that it may be at least partially based on the fact that the
SPDX file consists almost exclusively of data collected from original
sources, and copyright law (at least as I've been told, I'm no lawyer)
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,
and thus there really wouldn't be a legitimate way to control its
distribution via licensing.

This is just a mildly educated guess late on a Friday afternoon, though.
I could be 1000% off base :-)

--
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: TR: SPDX standard: files are placed in public domain

Kevin P. Fleming <kpfleming@...>
 

On 06/15/2012 03:53 PM, Peter Williams wrote:
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.
I suspect that it may be at least partially based on the fact that the SPDX file consists almost exclusively of data collected from original sources, and copyright law (at least as I've been told, I'm no lawyer) 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, and thus there really wouldn't be a legitimate way to control its distribution via licensing.

This is just a mildly educated guess late on a Friday afternoon, though. I could be 1000% off base :-)

--
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: TR: SPDX standard: files are placed in public domain

Peter Williams <peter.williams@...>
 

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.

Peter


Re: TR: SPDX standard: files are placed in public domain

RUFFIN MICHEL
 

I need to think a little bit about it with our lawyers on the potential consequences before answering you.

What I want is freedom, to exchange information between companies without constraints. If we need constraints, we put it in the contract. It is not to SPDX to put the constraints.

Let us time to think about consequences/consraints, ... before addressing the issue. But the question is what was the purpose of this initially?

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


Re: TR: SPDX standard: files are placed in public domain

Peter Williams <peter.williams@...>
 

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


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

921 - 940 of 1591