[prev in list] [next in list] [prev in thread] [next in thread] 

List:       amarok-devel
Subject:    Re: Report from incorporation research committee
From:       "Ian Monroe" <ian.monroe () gmail ! com>
Date:       2009-01-07 23:09:00
Message-ID: f680fec50901071509s3bb12104j85ad3b6a5f7dfe10 () mail ! gmail ! com
[Download RAW message or body]

On Wed, Jan 7, 2009 at 4:42 PM, Leo Franchi <lfranchi@kde.org> wrote:
> Hi everyone,
>
> As discussed in the IRC meeting a while ago, the 4 of us (Leo, Mark,
> Lydia, Jeff) have been investigating and discussing options for Amarok
> to create a more formal governing structure for the disbursement of
> funds and legal organization. We wish to re-iterate once again that
> this structure is NOT to have any power to make technical decisions
> --- this is an open source project and all technical decisions will
> remain with the community at large.  We have always had a consensus
> system for this, and it has worked fairly well so far...we see no
> reason to change it.
>
> However, some sort of legal structure is useful in the efficient and
> fair distribution of funds (which may be increasing if we partner with
> music stores for example) as well as in the ability to allow tax-
> deductible donations for potential donors. What follows is a summary
> of our findings, including what we think is reasonable and what we
> recommend as a good governing structure for the project.
>
> We recommend that the board be small (but odd-numbered). 5 seems to be
> a good number as that forces a split as well as allows inclusion of a
> broad array of opinions. The board will have to have at least a
> president, a treasurer, and a secretary to take official minutes.
>
> First, the legal options. Then, possible voting structures for the
> Amarok project itself to adopt.
>
> Note that in both of these cases, foreign citizens to the home
> organization could be on the board.  Furthermore, it is possible that
> we could do both U.S. and non-U.S. entities, but we may not want to
> split donations up if we cannot easily transfer them back and forth.
>
> US Options
> ======
> Becoming a non-profit entity in the United States is not a terribly
> complicated procedure, but it may take a little bit of time and a non-
> significant amount of funds.
>
> Furthermore, we have been in contact with the SFLC (Software Freedom
> Law Center, http://www.softwarefreedom.org/) and we basically have two
> options.  Both provide tax-deductible donations from donors in the
> U.S.; they may or may not be tax-deductible for other countries (note
> that our current music stores that we either work with or that want to
> work with us have U.S. presences):
>
> 1) Go under the umbrella of an organization (Software Freedom
> Conservancy [http://conservancy.softwarefreedom.org/] or Software in
> the Public Interest [http://www.spi-inc.org/].  The details of the SFC
> are below:
>     * We lose direct access to our funds. People donate to them with
> our name.
>     * They can provide for us a special paypal button which will
> redirect the funds to them in our name.
>     * They cut checks to us (basically) when give them receipts. 2-4
> week turnaround time.
>     * We make our own decisions about our money.  They interfere only
> if they believe that a request is either illegal or threatens their
> status as a charity organization.
>     * Multiple contacts can be authorized to make requests (which
> provides some redundancy in the case of unforeseen problems).
>     * No setup, instantly available, some (minimal) charges possible.
> VERY convenient.
>     * 5% recommended donations.
>     * NO HASSLE. Free tax-deductible public charity status. Immense
> amount of hours saved on our end.
>
> 2) Do it ourselves, become a registered 501(c)(3) organization (public
> charity).
>     * Manage our own money, donations, expenses, etc.
>     * Much more work on our end, especially to set up, and need to
> file paperwork yearly.
>     * Potentially register trademarks in our name (not sure, needs
> more research).
>     * We need to choose a state to incorporate in, in which at least
> 1 of our members resides ideally.
>     * Cost is $750 if we think we will be receiving more than $10,000.
>     * Yearly filing requirements, certain laws to be aware of when
> distributing money.
>     * Very specific requirements as far as what the funding sources
> can be, what distribution they can have, etc.
>
> German options
> ==========
> Registering to become a German e.V. is not that complicated, it just
> requires a few things:
>     * 7 members to found.
>     * Members voting for by-laws and elect first board at mandatory
> first meeting.
>     * Registration at court.
>     * Costs ~100 EUR.
>     * Yearly meeting required (think e.V. general assembly at Akademy).
>
> This can be done relatively easily it seems, and non-germans can be on
> the board (so would be easy to get everyone involved).
>
> ============
> Recommendation
> ============
>
> As both Tradebit and Magnatune (to take two examples) are incorporated
> in the United States, and given the relative size of the United States
> to Germany, if all other things are equal it would make more sense to
> allow tax-deductible donations from individuals or corporations from
> the United States. This would open us up to more potential funding. It
> seems that if we go with the SFC we basically have a very easy way to
> get these donations, while at the same time not impinging on our
> rights to decide what to do with our funds. Furthermore, this fits
> well with our plans to create a board as outlined above --- the board
> would simply be required to decide how to allocate funding, then the
> predetermined SFC contact (on the board) would request a reimbursement
> for the necessary amount.
>
> It is our preliminary recommendation that the Amarok project choose
> the SFC for managing its funds, while considering an additional
> second, German-based entity.
>
> ===========
> Voting Structure
> ===========
>
> We need a formal system for deciding who can vote, and how the Amarok
> project as a whole elects board members. Currently, we are proposing
> something like this:
>
>     * Voters are contributors to the Amarok project who have shown
> continued commitment to Amarok as a whole. This means very new
> contributors do not have a vote until they have been around for a bit.
>     * Body of voters approves new members to get voting privileges.
>     * Voters vote on board members, resolutions, etc.
>
> Of course, before you can vote on new members you need a way to
> determine who the "initial" membership is going to be. In order to try
> to keep things clear and fair, a simple set of guidelines is in order:
>
>     * People who have been active contributors for over 1 year and
> are still around (just means not disappeared).
>     * People who have been active contributors for less than 1 year,
> but have been continuously actively and engaged in the community since
> then (e.g. some SoC students).
>
> That said, here is a preliminary list of voters that we feel confident
> about immediately including:
>
> Bart Cerneels
> Casey Link
> Dan Meltzer
> Greg Meyer
> Ian Monroe
> Jeff Mitchell
> Leinir Jensen
> Leo Franchi
> Lydia Pintscher
> Mark Kretschmann
> Maximilian Kossick
> Nikolaj Hald Nielsen
> Seb Ruiz
> Sven Krohlas
>
> Once we form the initial group, we will have an immediate voting round
> to include further members who are on the edge of our guidelines.
>
> We are currently discussing options for allocating voting power to
> voters. We do not wish to hold back debate on all of the things
> mentioned above, so we will continue to work out a recommendation
> privately while allowing for a group discussion of all of these
> various options.
>
> ========
> What is next
> ========
>
> Lydia is waiting on a response from the KDE e.V. board, regarding
> possible legal help and various other contributions that could help us
> in creating an e.V. in Germany.
> Jeff will talk to the SFC more about possibilities for having both a
> US-based entity and a German one. What are the possibilities regarding
> the transfer of money between them? Is that totally OK with the whole
> public charity thing?
>
> As we hear back from these pending questions, we will revise our
> recommendation to provide a more up-to-date solution. Specifically,
> once we hear back from the e.V. board we will be able to more clearly
> explain our options with regard to Germany.
>
> If there are disagreements about our proposed voting system, please
> bring them up.
>
> If there are no disagreements, or once we have reached the end of our
> discussion, we propose to move forward like so:
>
> 1) 1 week: Nomination phase: Voters and non-voters alike can nominate
> (5) people to the board
> 2) 2 weeks: Voting phase: All voters can vote for (5) people. At the
> end of 2 weeks, 5 people with most votes are the new board.

I like the voting structure. We can go ahead and do this nowish right?
Maybe we can ask Thiago to run the vote (it should be secret ballot
IMO)?

> All comments and criticisms are very welcome, we are opening this up
> to the community for further input and discussion. Remember, to state
> once again for the record, this board exists solely to deal with
> administrative and financial decisions, and NOT to decide on the
> technical aspects of the Amarok project. This board has no
> jurisdiction over the development path that the Amarok team chooses.
> It will remain in the community and the decision process will proceed
> as it always has.

The primary concern with the SFC is both the reimbursement time (the
SFLC is their day job, they do this on the side I think) and the fact
that we'd no longer be able to loan money prior to the person spending
it. Perhaps a German e.V. would give us some flexibility there. This
issue and how important US non-profit status is to us should be what
we think about.

Anyways I'm glad that the committee narrowed things down to these two
options basically. Great job folks!

Ian
_______________________________________________
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel
[prev in list] [next in list] [prev in thread] [next in thread]