Jilayne Lovejoy wrote at 20:01 (EDT) on Thursday:

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!

I agree that trying everywhere makes sense for what Michel is trying to
do, since, as others have pointed out, there's no clear venue for the
discussion at the moment.

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

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.

I think you're responding to a point I didn't raise. I didn't
claim ftf-legal isn't useful -- indeed, I've applied and been denied
membership in ftf-legal many times myself. I wouldn't have done so if I
didn't think there were likely useful discussions going on there.

due to the Chatham House Rule,

I don't object to ftf-legal's use of CHR per se, but I'm still confused
about how the CHR applies to a meeting that never ends, since CHR is
designed for timeboxed meetings. Does ftf-legal has some tutorial on
their odd application of CHR?

Anyway, the issue I was raising was not about the traffic on ftf-legal
itself, but the meta-issue of how the list membership is constructed. It is a
self-selected group that arbitrarily refuses applicants based on secret
criteria. Your response didn't seem to address that problem.

The network is made up of mostly lawyers

I have confirmation there are many, many non-lawyers on the list. I
don't know the percentage numbers, obviously, since the data I have is
from self-disclosure.

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

I'm not sure it's the role of SPDX to address this problem

Indeed, I'm sure you're right on that point. However, that also means
that SPDX is focused on addressing minor problems and ignoring the
largest and most common FLOSS license compliance problem in the world in
favor of minor ones. That's the center of my criticism (a) above.

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

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

These don't appear to me, based on the URL given above, to be flourishing
Free Software projects. The git log seems a bit sparse, and there's not a
lot of "there there". It seems three contributors are occasionally committing
stuff. I'm glad they're doing this work, but it doesn't seem they're getting
lots of support and contributions from most of the companies benefiting
from SPDX, are they?

Is your argument here that these tools are the more advanced, usable and
feature-ful than the proprietary tools available that utilize SPDX? What
it looks to me upon first analysis is that the Free Software tools are limping
along without adequate funding, while the proprietary solutions flourish.
Am I wrong about that?

BTW, I know developers who'd be ready to help work on Free Software
SPDX tools, but funding is a serious problem. If folks have thoughts about
that, please do contact me off list.

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.

I'm completely amazed to learn that customers *want* proprietary
software. I've never seen someone say: "Please, don't give me the
source code or the right to modify it for the software you're selling
me." Do your customers actually say: "I really hope you'll take my
software freedom away when you sell me your products!"?

I don't sell proprietary software licenses for a living like many people
on this list do, so I admit I have no first-hand experience in this
area. But I'm nevertheless surprised that customers are *asking* to
have software that doesn't give them software freedom. I'd bet it's
more like they're helplessly begging their vendor to add features
because they're locked-in in the usual proprietary way that the software
freedom movement fights against.


Anyway, what I think is happening in the SPDX project is that SPDX is
primarily used as a marketing tool to sell proprietary software
"compliance" solutions that won't solve the primary compliance problems
of our day. Indeed, most of the SPDX process is being driven by
companies that produce proprietary software, of the type I described in
(b) above.

Even if I were to get involved to attempt to fight this proprietary
marketing push from within SPDX, these well-funded organizations bent on
building more proprietary software and taking away software freedom from
their users would overpower any advocacy or work that I did in SPDX
against that idea. This is why I stopped participating in SPDX -- I realized
there was nothing I could do to make SPDX good for software freedom.
--
-- bkuhn