From: Aaron Bauman <bman@gentoo.org>
To: gentoo-nfp@lists.gentoo.org
Subject: Re: [gentoo-nfp] Trustee nomination: Aaron Bauman (bman)
Date: Wed, 18 Jul 2018 16:43:39 -0400 [thread overview]
Message-ID: <20180718204339.GB9075@monkey> (raw)
In-Reply-To: <CypSLRVhJ+E+AUrHBjcMke@j+id1ntEzMcetqibTSe/Q>
[-- Attachment #1: Type: text/plain, Size: 7016 bytes --]
On Wed, Jul 18, 2018 at 08:34:12PM +0100, Roy Bamford wrote:
> On 2018.07.17 19:18, Aaron Bauman wrote:
> > On Tue, Jul 17, 2018 at 07:01:18PM +0100, Roy Bamford wrote:
> > > On 2018.07.16 22:21, Aaron Bauman wrote:
>
> [snip stuff I'm not responding to]
>
> > > >
> > > > Another option which I have explored is beginning a new
> > incorporation
> > > > in
> > > > a different U.S. State (Indiana). This would allow us to gain a
> > > > not-for-profit status and proper IRS tax exemption. Upon forming
> > the
> > > > incorporation we would redirect all of Gentoo's contributions to
> > this
> > > > new organization. From there we would begin moving assets from
> > the
> > > > New
> > > > Mexico based foundation to the new. This would be in the form of
> > gifts
> > > > which allows a zero-sum transaction to occur given that the
> > > > organizations both address the same not-for-profit mission. This
> > would
> > > > require a significant amount of money (approximately $30-40k
> > dollars)
> > > > be
> > > > left in the NM foundation to deal with the IRS debt.
> > >
> > > That sounds risky for the trustees that vote to approve that. My
> > > understanding of NM law is that they would be personally liable for
> > > any shortfall as it could be seen as moving funds to avoid
> > liability.
> > >
> > > Also, we would need to operate two NFPs when at this election
> > > we only secured enough candidates to staff one ... if they are all
> > > ranked above _reopen_nominations in the poll.
> > >
> > > Its actually worse than that, as ideally, trustees and officers
> > should
> > > be separate individuals, except for the chairman of the board, who
> > > needs to be a board member.
> > >
> >
> > We are not attempting to avoid liability. The move is to ensure that
> > future contributions are properly protected while the old "non-profit"
> > is dissolved. Properly protected is meaning that they are indeed
> > non-taxable contributions to Gentoo vice continuing to bleed out.
> >
> > The sad state is, and don't take this personally, that operating even
> > one
> > should have been a simple task. Here we are though.
> >
> > The laws you speak of are the criterion such as "de facto merge",
> > "mere
> > continuation", etc. As stated though, this is not the case as we are
> > still properly dissolving the NM based non-profit.
> >
>
> I was trying to respond to the timing of the gifting to the new NFP.
> If its done before the tax liability is known, its risky.
>
> Spinning up a new NFP and directing future donations there seems
> OK. Moving the residue of assetts there after the tax liability is
> known is OK too. Thats the formal winding up
>
> I'm unclear as to how liabilities would be funded while both NFPs
> operate. The IRS will take o dim view of running down the assets
> of the old NFP while the new one grows if we end up with
> insufficient funds to cover our tax liability.
>
> I can see how the IRS might interpret moving money around in that
> that fashion as attempting to avoid liability.
>
Correct. The timing will be critical and must be deliberately planned.
e.g. Server X has been accounted for and depreciation values properly
calculated. We may make a transaction transferring this asset to the
new foundation. Proper paperwork and liability clauses included.
e.g. Domain X can be transferred now as there is no depreciation or
realized loss. Proper paperwork and liability clauses included.
>
> [snip]
>
> > > >
> > > > The council is and will remain the leadership within Gentoo. The
> > > > by-laws
> > > > will constrain the trustees to legally execute the direction in
> > which
> > > > the council votes. The few exceptions are any legally compromising
> > > > matters or financial. This also ensures that council members will
> > > > *not*
> > > > be forced to legally seek permission from their employers. It
> > will,
> > > > however, not remove the requirement that trustees are legally
> > > > obligated
> > > > to the foundation.
> > > >
> > > > e.g. The council votes that all developers will be supplied with a
> > > > Nitrokey to address 2FA concerns. The trustees will execute this
> > > > matter
> > > > legally and financially. There will be no choice as the
> > "technical
> > > > board" has voted and it is final.
> > >
> > > The technical board currently has no duty to ensure fhaf their
> > > decisions offer value for money. Which body would perform
> > > 'due dillegence'?
> > > To follow on your example, there are several competing 2FA
> > > solutions with differing feature sets. While Nitrokey may be
> > > selected for <reasons> the comparative value assesment still
> > > needs to be performed or the trustees would be neglecting their
> > > duty by rubber stamping council decisions.
> > >
> > > The council can do this today. I'm sure other groups/individuals
> > > already do this work before they submit funding requests.
> > >
> >
> > Yes, the intent of the example was not to "rubber stamp" anything and
> > as
> > mentioned those legal obligations still remain for the trustees. I
> > used
> > Nitrokey in the example unwittingly. The trustees would still be
> > required due diligence etc. The example would work though as Nitrokey
> > meets the foundation's mission statement (FOSS etc). Point taken
> > though. Other's would not even if cheaper due to proprietary
> > technology.
>
> Maybe I'm reading too much into this. In the past, the foundation
> has usually asked applicants for funding to do the due diligence.
> The foundation then checked it.
> There is no reason that cannot continue and be applied to the
> council too.
>
> Price is only one part of the value judgment, which is why I used
> the term value.
>
> As long as the trustees can continue to reject incomplete applications
> for funding, even from the council, there is no problem.
>
> [snip]
>
Of course, they would retain that ability. The only thing we are trying
to establish is a better relationship between the technical bodies
direction and the Foundation supporting them.
e.g.
Council: "We want some Yubikeys for our infra people"
Foundation: "Sorry, the Yubikey is proprietary and goes against our
social contract. Please choose another vendor who meets X requirements"
e.g.
Council: "We would like an HSM for our infra team to support crypto for
our end user. It costs $10k"
Foundation: "Sorry, this would not be a reasonable use of our money as
there are better options available such as end-user hardware tokens"
*note* none of this is meant to be technically sound or imply that the
council would ask such things.
> > --
> > Cheers,
> > Aaron
> >
>
> --
> Regards,
>
> Roy Bamford
> (Neddyseagoon) a member of
> arm64
> elections
> gentoo-ops
> forum-mods
--
Cheers,
Aaron
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2018-07-18 20:43 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-12 20:18 [gentoo-nfp] Trustee nomination: Aaron Bauman (bman) Michał Górny
2018-07-12 20:34 ` Aaron Bauman
2018-07-16 21:21 ` Aaron Bauman
2018-07-17 18:01 ` Roy Bamford
2018-07-17 18:18 ` Aaron Bauman
2018-07-18 19:34 ` Roy Bamford
2018-07-18 19:58 ` Rich Freeman
2018-07-18 20:25 ` Aaron Bauman
2018-07-18 20:43 ` Aaron Bauman [this message]
2018-07-17 18:21 ` Rich Freeman
2018-07-17 19:04 ` Aaron Bauman
2018-07-17 19:15 ` Rich Freeman
2018-07-17 19:29 ` Aaron Bauman
2018-07-17 20:43 ` Alec Warner
2018-07-17 20:59 ` Aaron Bauman
2018-07-17 21:16 ` Alec Warner
2018-07-17 21:42 ` Rich Freeman
2018-07-17 22:03 ` Aaron Bauman
2018-07-17 22:15 ` Alec Warner
2018-07-17 22:50 ` Aaron Bauman
2018-07-17 21:19 ` Rich Freeman
2018-07-17 22:08 ` Aaron Bauman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180718204339.GB9075@monkey \
--to=bman@gentoo.org \
--cc=gentoo-nfp@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox