[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Constitutional Amendment GR: Handling assets for the project

On Mon, Aug 14, 2006 at 01:08:11AM -0500, Manoj Srivastava wrote:
>         What I think we would need to have happen is this:
>  a) If a new organization is added to the set of organizations that
>     can accept and hold assets for Debian, this needs to be
>     publicized.

...and debated, and whatever. Completely happy for that process to be
detailed in the constitution; it should be rare, and it's a new procedure
that we can start doing right from now anyway.

>  b) There should be an annual report from each organization that holds
>     assets, so we can have at least an annual big picture of where we
>     stand fiscally, etc
>  c) While the DPL should be able to spend money, all such expenditures
>     should be communicated to the membership on a mailing list they
>     can read.

100% agree to these in principle, but I'm worried that since we've never
actually managed to handle them in practice in the past, that putting
them in the constitution now will be a problem.

That said I'd be _very_ appreciative if someone's willing to volunteer to
spend the time tracking these things for some or all of the organisations
that hold money for us. So far no one's bitten though.

>         I would also like there to be some way of saying that if a
>  significant expenditure is to be made (I don't quite know how to
>  define significant), I would like to know it a priori, as opposed to
>  a posteriori.


>         Like, if I become DPL, and buy this 100GB drive for Debian
>  from my brother in law for $100k,  perhaps I should have sent it
>  before the membership ahead of time.

At the moment, you have to rely on (a) the DPL being more reliable than
that, and (b) the organisations actually holding the money acting as
a check on such things. Those have worked pretty well so far, and I'd
expect them to continue doing so.

> > Just generalising the current text/situation might be better:
> >   4. The Developers by way of General Resolution or election
> >     4.1. Powers
> >      Together, the Developers may:
> >       6. Instruct organisations holding property in trust for
> >          purposes related to Debian on how those assets should be
> >          used. (See ?9.1.)
> > Hrm. I don't think the "Together with the Project Leader" is a good
> > idea in that cause -- if people go to the trouble of a GR, why
> > should the DPL need to be involved?
>         In section 4.1.6, I don't think we are necessarily talking
>  about a GR, are we? Can't a subset of us get together witht eh DPL
>  and do stuff, without a formal GR? If  we are talking about a GR,
>  then this whole clause is redundant, no?

Huh? "4" is all about General Resolutions, no? That's what it's title

If they get together with the DPL, that's just the DPL's authority
being exercised.

> >   5. Project Leader
> >     5.1. Powers
> >      The Project Leader may:
> >      10. Instruct organisations holding property in trust for
> >          purposes related to Debian on how those assets should be
> >          used. (See ?9.)
> > Is "instruct" too strong? The idea is that the DPL should just tell
> > them what to do in the normal case, but not that those organisations
> > shouldn't have some sort of oversight -- eg, if there's a problem
> > with charitable purposes, or if they think there's embezzling going
> > on and want to mail -private and give developers a chance to revoke
> > the decision by GR before the money disappears or whatever.
>         I am not sure I like "make decisions about" -> instruct; the
>  former clearly retains the decision over Debian's money with Debian's
>  officers and membership; merely instructing a third party and letting
>  the third party have oversight over Debian is ceding altogether too
>  much power to these as yet unnamed external entities. Or am I being
>  too paranoid?  I am not sure I want third parties to _have_
>  oversight.

So, at the moment we *need* them to have oversight, because we don't have
procedures in place for Debian as a whole to have that oversight. IMO,

And technically, they have to have some level of oversight, because
they'll be saying "no" if we ask them to do something they're legally
forbidden to do (eg "Please donate $x from Debian's funds to Joe Bloggs
campaign for president").

[Why isn't Debian incorporated]
>         I am not sure that is accurate either.  I think the reason for
>  not being incorporated is more of who goes through the paperwork and
>  tedium, not to minimize government control.

Well, we've gone through the paperwork and tedium already -- in setting
up SPI in the first place. We could, relatively easily, make SPI be
Debian's legal entity right now if we wanted, and have the constitution
become the rules of order for an SPI sub-project, under the SPI by laws.

I don't think we want to do that, or should do that for a few
reasons. Most notably, SPI is incorporated in the US, and that makes it
illegal for SPI to be involved in activities related to Cuba; if Debian
were an SPI sub-project, Debian would likewise be restricted from that
involvement, which would impact the Debian Latinamerica folks, who're
trying to improve Debian for all of Latin America, which includes Cuba.

We'd have similar problems if Debian were incorporated *anywhere*,
which, IMO, is why we shouldn't incorporate anywhere. That doesn't
mean we *can't*, or even that we're not already an entity with rights
or obligations under various laws, it just means we choose not to
incorporate, not to take advantage of those rights directly, and more
importantly not to be encumbered by some of the obligations.

> >       Therefore, money and other assets intended to be used for
> >       Debian's mission must be held in trust by other organisations,
> >       as detailed below.
>         I think we are beginning to split hairs.  While in some
>  jurisdiction perhaps Debian is a legal entity, but still, in order to
>  own assets, I am pretty sure work needs to be done , papers filed,
>  taxes assessed, or dispensatoion obtained -- which is a lot of work
>  which has not been done. For a global project, this is ibviously
>  untenable: 

I don't think that's true either -- certainly in setting up LCA 2002,
all we needed to do in order to establish a bank account was provide
some minutes of a meeting we'd had to the bank, and proof of identity
for the people we wanted to be able to sign cheques.

>         "In most jurisdictions around the world, the Debian project is
>         not in a position to directly hold funds or other
>         property. Therefore ....."

So, I don't think this is true either -- we could fill out the paperwork
in all those jurisdictions fairly easily, because generally we do that
anyway whether for SPI or Debconf or whatever else. If we're going to
offer a reason, I'd really rather that be our underlying motivation
rather than pretending it's too hard.

> > How about we just require a GR if the DPL and secretary can't come
> > to an agreement? Seems much more sensible to me, especially if SPI
> > continues expanding its membership to include other projects.
>         I'll be happy with that.  Decision by the membership as the
>  decision body of last resort. 

How about:

    "If the Project Leader and the current Project Secretary cannot agree
     on a new appointment, they must ask the Developers by way of General
     Resolution to appoint a Secretary."


Also, any thoughts on changing:

4. The Developers by way of General Resolution or election
  4.1. Powers
   Together, the Developers may:
    3. Override any decision by the Project Leader or a Delegate.
    4. Override any decision by the Technical Committee, provided they
       agree with a 2:1 majority.


   Together, the Developers may:
    3. Make or override any decision authorised by the powers of the Project 
       Leader or a Delegate.
    4. Make or override any decision authorised by the powers of the Technical 
       Committee, provided they agree with a 2:1 majority.

I think something like that matches what we expect developers to be able
to do, but makes it clearer that developers can just do it, and that
the DPL (eg) can't block an issue by choosing not to make a decision
and thus not giving the developers anything to override.

> >       9.3 Trusted organisations
> >       Debian maintains a public List of Trusted Organisations that
> >       accept donations and hold assets in trust for Debian
> >       (including both tangible property and intellectual property)
> >       that includes the commitments those organisations have made as
> >       to how those assets will be handled.
> > I guess "The ability to edit the List of Trusted Organisations"
> > should then be one of the powers of the DPL (or their delegates, or
> > the developers by GR).
> > I figure that way we can see that SPI have made a commitment to
> > publish their financials publically and provide receipts for tax
> > purposes, while some other random organisation has made weaker
> > commitments, and therefore it's better to donate to SPI; but we
> > don't make it impossible to donate to Debian if we can't find an
> > organisation that's as on top of things as we'd like.
>         This one I am not so sure about.  I think that we ought to be
>  going for tighter controls than SPI has exercised in the past, and
>  not weaker ones: surely an annual accounting of funds is not too much
>  to ask for an organization that holds other people's money?

I would have thought the same, but it's not something we've managed
yet, so I'd like to preserve the flexibility of muddling on without it,
while we work on getting it right.

The other issue is that "accounting for assets" in general is hard --
we haven't done very well accounting for bank balances so far; but if we
expect organisations to account for servers, trademarks or copyrights
they hold on Debian's behalf too, we're probably asking for more than
they can actually manage, even if it's not an unreasonable thing to ask.

Again, if someone wants to volunteer to help get this right, please
stick your hand up.


Attachment: signature.asc
Description: Digital signature

Reply to: