SPI resolution 2012.09.13.bg.1, TideSDK as associated project

[Jimmy Kaplowitz]

Hi Bdale,

The only "showstopper" issue for me with regard to TideSDK is ensuring that the
old TiStudio/Appcelerator licensing issues are either resolved or sufficiently
on their way to resolution, since that affects the freeness of the software.
I'm optimistic on that point but want more certainty before proceeding. The
other issues are real in terms of the resolution text but probably not
"showstopper" enough to keep me from voting yes.

That said:

On Mon, Sep 10, 2012 at 10:41:49PM -0600, Bdale Garbee wrote:
> The point of this clause is to allow those who are defined members of a
> particular team at some arbitrary point in the future to be able to make
> a decision and communicate it to SPI.  We don't try to cache a list of
> who's on the Debian keyring with power to elect the DPL, for example, so
> I'm not sure why caching a copy of the current membership of the TideSDK
> Team makes any more sense? 

Indeed we don't, though in the case of Debian, the project Constitution itself
and the people and roles acting according to the Constitution are deemed
authoritative, not whoever a website or keyring lists at a given point in time.
We already asked the Debian Project Secretary to let us know if any
SPI-relevant GRs or DPL identity disputes happen, and asked the DDs "and
others" to basically act as a failsafe for those two, including disputes about
their identities.

http://www.spi-inc.org/corporate/resolutions/2007/2007-02-28.iwj.1.jrk.1/

I was too verbose there as I often am, but at the same time, the situation in
Debian is complex enough that we had to capture some real complexity when
documenting the SPI-Debian relationship which already existed. Most of our
subsequent projects were small enough to have a more autocratic structure, and
several of them fixed some of these governance/authority issues when we pointed
them out earlier in the process than we are now. I guess we're evolving back
toward larger projects, which is fine but makes these issues tougher again.

> I think if we recall that the decision making in question is in the
> context of telling SPI what to do with project assets, and not some
> arbitrarily large possible decision space in the project, the current
> terminology works adequately.

Based on what Ian Jackson has recently said, as the person who invented the
terminology, the decision making indeed is the overall control of the project,
and the liaison itself is the role who instructs SPI with respect to the
project. That's certainly how I've always thought about it myself, even when I
paid less close attention to these issues in deciding on some past resolutions.

It's quite true that this last issue, and to some extent both of these wording
issues, isn't specific to TideSDK, and we may want to address it more generally
outside of specific decision processes on association applications.

- Jimmy Kaplowitz
jimmy at spi-inc.org