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

Please add this resolution to our September meeting agenda.

TideSDK is used to create multi-platform desktop apps using HTML5, CSS3
and JavaScript. It is the current, community-based incarnation of the
former Titanium Desktop. The code is all licensed Apache v2.0, and
based on my conversations with the project leader David Pratt, there
appear to be no unusual issues or needs. The project is gaining
momentum and needs a destination for pending corporate donations.

Bdale

SPI resolution 2012-09-13.bg.1

WHEREAS

1. TideSDK is a substantial and significant Free Software project.

2. The TideSDK developers would like SPI's support and assistance, including
taking donations, and holding trademarks and domain names.

THE SPI BOARD RESOLVES THAT

3. TideSDK is formally invited to become an SPI Associated Project, according
to the SPI Framework for Associated Projects, SPI Resolution
1998-11-16.iwj.1-amended-2004-08-10.iwj.1, a copy of which can be found at
http://www.spi-inc.org/corporate/resolutions/2004/2004-08-10.iwj.1/

4. David Pratt is recognised by SPI as the authoritative decision maker
and SPI liaison for TideSDK. Successors will be appointed by concensus
of the TideSDK Team as defined on the tidesdk.org web site.

5. This invitation will lapse, if not accepted, 60 days after it is approved by
the SPI Board.

On Thu, Aug 25, 2011 at 02:07:57PM -0600, Bdale Garbee wrote:
> TideSDK is used to create multi-platform desktop apps using HTML5, CSS3
> and JavaScript. It is the current, community-based incarnation of the
> former Titanium Desktop. The code is all licensed Apache v2.0, and
> based on my conversations with the project leader David Pratt, there
> appear to be no unusual issues or needs. The project is gaining
> momentum and needs a destination for pending corporate donations.

In a web search, I found this Google Groups thread mentioning a licensing issue to resolve related to the old TiStudio license from Appcelerator:

https://groups.google.com/forum/#!topic/titanium-desktop-transition/L3BhEgSjb4c

My understanding from reading that thread and the TideSDK blog is that
Appcelerator was interested in resolving the issue, which is great. However
before I can vote yes I do need to understand the current state of that
resolution, and if it's not fully resolved, what the plan is. SPI can certainly
leverage its legal entity status to accept copyright assignment or sign some
contract to solve the issue if needed, but TideSDK should be past the stage of
substantive negotiations before associating with SPI.

The rest of what I mention in this mail will not interefere with me voting yes.

One typo fix:

> 4. David Pratt is recognised by SPI as the authoritative decision maker
> and SPI liaison for TideSDK. Successors will be appointed by concensus
> of the TideSDK Team as defined on the tidesdk.org web site.

s/concensus/consensus/

The same issue exists as in the OBF resolution - we should probably archive a
copy of the relevant part of the TideSDK website and ask David, or failing that
the TideSDK Team, to notify us when David's role or the Team membership
changes.

Interesting also that the authoritative decision maker and the body which can
choose another authoritative decision maker are distinct.... I'm increasingly
agreeing with Ian that we should figure out a better phrase than "authoritative
decision maker" and revise all of our project relationships, with consent of
course, before any of our projects have a divisive succession battle.

- Jimmy Kaplowitz
jimmy(at)spi-inc(dot)org

Jimmy Kaplowitz <jimmy(at)spi-inc(dot)org> writes:

> The same issue exists as in the OBF resolution - we should probably archive a
> copy of the relevant part of the TideSDK website and ask David, or
> failing that the TideSDK Team, to notify us when David's role or the
> Team membership changes.

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?

> Interesting also that the authoritative decision maker and the body which can
> choose another authoritative decision maker are distinct.... I'm increasingly
> agreeing with Ian that we should figure out a better phrase than
> "authoritative decision maker" and revise all of our project
> relationships, with consent of course, before any of our projects have
> a divisive succession battle.

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.

Bdale

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(dot)org

Jimmy Kaplowitz <jimmy(at)spi-inc(dot)org> writes:

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

Right. The frequency with which this or similar discussion has occurred
on recent association resolutions suggests that a refresh of both the
template and related instructions in the associated projects howto might
be called for. That's a great task for us to undertake outside the
scope of any specific association resolution.

Bdale