Ongoing discussions to narrow down the general criteris for a formal criteria of a Debian Trusted Org
Update: See https://wiki.debian.org/Teams/DPL/TrustedOrganizationCriteria for final resolution of discussion.
- "Implement" the Constitution requirements to have an authorative list of Trusted Organizations?
- To aid current and Future DPLs in making decisions about inclusion of new Trusted Organizations?
- Clarify what is expected from current and future Trusted Organizations?
- Increase the understanding of the Debian "ecosystem" in the general public?
- This discussion is a work in progress, and is happening on a number of mailing lists, including for now "dpl-helpers".
Section 9 of the constitution deals with Assets and Trusted Organizations http://www.debian.org/devel/constitution#item-9
9. Assets held in trust for Debian
- In most jurisdictions around the world, the Debian project is not in a position to directly hold funds or other property. Therefore, property has to be owned by any of a number of organisations as detailed in §9.2. Traditionally, SPI was the sole organisation authorized to hold property and monies for the Debian Project. SPI was created in the U.S. to hold money in trust there. SPI and Debian are separate organisations who share some goals. Debian is grateful for the legal support framework offered by SPI.
9.1. Relationship with Associated Organizations
- Debian Developers do not become agents or employees of organisations holding assets in trust for Debian, or of each other, or of persons in authority in the Debian Project, solely by the virtue of being Debian Developers. A person acting as a Developer does so as an individual, on their own behalf. Such organisations may, of their own accord, establish relationships with individuals who are also Debian developers.
- An organisation holding assets for Debian has no authority regarding Debian's technical or nontechnical decisions, except that no decision by Debian with respect to any property held by the organisation shall require it to act outside its legal authority. Debian claims no authority over an organisation that holds assets for Debian other than that over the use of property held in trust for Debian.
9.3. Trusted organisations
- Any donations for the Debian Project must be made to any one of a set of organisations designated by the Project leader (or a delegate) to be authorized to handle assets to be used for the Debian Project. Organisations holding assets in trust for Debian should undertake reasonable obligations for the handling of such assets. 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.
bgupta's original proposal
- Organization is incorporated as a non-profit and can legally hold assets in the organization's name
- The leadership structure of organization must have at least three Debian Project Members
- At least 50% of the leadership structure of the organization must be Debian Project Members
- The organization is willing to hold assets on behalf of Debian
- The organization is willing to sign a contract agreeing to only transfer, spend, or use those assets on authorization of the Debian Project Leader or a designated delegate. (Not sure if we want DPL only, or leave DPL flexibility to delegate signatory rights on certain assets. If we do, the delegation almost certainly must be revocable. Perhaps better to leave DPL only.)
- Organization must be willing and capable of providing detailed reports of asset transfers and balance sheets on a quarterly basis
- Mission of organization should be in support of Free Software
- Even if all other criteria are met, it will be at the final Discretion of the DPL to decide if they are to be authorized as a TO.
- Can the designation be revoked? (I'd think yes, if they aren't meeting the criteria of being a TO, or DPL otherwise feels needed, if for some reason the affiliation is no longer beneficial to Debian.)
- Anything about mission of organization? Perhaps something about Free Software? IE: I can't think of great examples, but if there were a non-profit run by Debian Project Members, but it was say, an educational organization would it be suitable?
lucas's counterproposal (with zack's comments/responses as sub-bullets)
Debian Trusted Organizations (TO) are organizations that hold and manage assets on behalf of the Debian project. The list of TOs is maintained by the Debian Project Leader (following Debian Constitution 5.1.11 and 9).
- Trusted Organizations share Debian's general visions and support Debian's general goals
- Trusted Organizations have a legal structure that enables them to accept donations and/or hold assets in trust for Debian, and provide Debian with guarantees that those assets will only be managed according to the Debian Project Leader (or delegates) decisions.
- zack: For the same reason as above I'd rather conclude this paragraph with "according to the Debian Project decision" (*who* actually takes the decision should be a detail for the reader, and it's well documented elsewhere anyhow).
- (continued) For example, the leadership structure of the organization could always have a minimum number, and/or a majority of Debian Developers, or the decision making processes of the organization could explicitely delegate decisions to the Debian Project Leader.
- zack: Is this actually interesting to mention? To me it seems that either we want to make something like this mandatory to approve a TO (and in that case we drop the "For example" incipit), or it is not mandatory and as such this whole paragraph can be dropped, no?
- Trusted Organizations provide accountability on assets held in trust (for example, through detailed and regular reports of assets transfers and balance sheets).
- zack: s/for example/usually/ maybe ? or even "are expected to" if we want to make clear that this is something we really really want to happen.
- The constitution already contains quite a lot on this topic, we should only defer to it to avoid adding conflicting processes.
- I don't think that we should be too specific on the implementation details.
- They might differ a lot between different countries.
- I prefer to use "Debian Developers" rather than "Debian Project Members". That matches the working of the constitution.
- zack: AFAICT this is actually a common gotcha. The constitution uses as *synonyms* the terms "[debian] project member" and "debian developer". This is the actual constitutional basis we have used for renaming in various important project processes, including NM. So I'd rather to as Brian suggested, using "Debian Project Members", and I think that's totally fine with the Constitution wording.