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