[Buildbot-devel] Discussion of the Fiscal Sponsorship Agreement with Conservancy (was Re: Offer of membership to Buildbot into Software Freedom Conservancy, Inc.)
Bradley M. Kuhn
bkuhn at sfconservancy.org
Tue Apr 9 18:01:26 UTC 2013
BuildBot Community,
I'm sorry for Conservancy's delay in replying to this thread. I've
combined a number of the questions you all raised in late March, and
hopefully have answered them adequately below. I'm happy to pick up the
conversation here with follow-up questions.
I realize that, because I've merged responses to so many different
questions, this response is rather long. Nevertheless, I hope you won't
TL;DR it, as it does discuss some finer points of what it means for a
project to join Conservancy, and the BuildBot community should think
carefully about these issues before joining.
Dustin Mitchell wrote on 20 March:
> [what does it] mean for an employee to sign the FSA if the work on
> Buildbot was done for hire? This is important for such employees to
> know how to have a conversation with their legal department...
We always ask for people to serve as both signatories and on Project
Leadership Committees (PLCs) in their *individual* capacity.
That said, we *have* seen many occasions where someone's employer has a
vested interest in the project -- so much so that we have seen
unfortunate situations such as:
(a) The company doesn't want the employee to be allowed to act in
their individual capacity in the project at all (i.e., the company
views the employee as merely their agent in all things related to
the project), and forbids the employee from signing the FSA, or
serving on the PLC, or
(b) The company allows the employee to act as an individual, but then
tries to influence the individual in their role on the PLC to get
something the company wants from the project.
With regard to (a), I think then it's best that the person not be
involved with the PLC at all (although note my additional discussion
about this below). The 501(c)(3) status of Conservancy cannot abide by
having for-profit companies have influence over the project.
With regard to (b), we know this happens, and it's difficult to predict
and/or prevent. In those cases, when an issue arises, we'd appreciate
private conversations between that individual and Conservancy's General
Counsel, Tony Sebro, if someone's employer attempts it. In communities
where we think this is highly likely to happen, we do encourage drafting
of a "only one person from any one employer" clause into your FSA.
Frankly, my views of the BuildBot community are that it doesn't suffer
from dangerous corporate politics very much like some other projects do,
but perhaps I'm wrong. :)
In addition, from a *community* perspective (as opposed to "charities
regulation" view), I can imagine that undue influence by *any* one
individual or entity -- regardless of the legal tax status of that
entity -- might be of concern to your community. That's an issue,
though, that Conservancy fully delegates to the community to regulate
for itself: as long as (0) we don't see private benefit going to an
individual or a for-profit company, and (1) everyone in the project,
(when acting in their role of the project) does so in a way to further a
charitable mission of advancing and improving Free Software, then we're
happy.
Dustin Mitchell wrote at 21:32 (EDT) on Thursday:
> it might be good to have a slightly expanded description of what it
> means for *anyone* to sign the FSA, and on that basis what it might
> mean if someone does not sign it.
The danger of someone "not signing" is admittedly more Conservancy's
danger than it is the individual's. For example, suppose this fully
hypothetical situation:
Dustin doesn't sign the FSA. Dustin is well-known as a key developer
and leader in the BuildBot community. Conservancy gets signatures
from others, and announces that BuildBot has joined. Conservancy
applies for the BuildBot trademark on BuildBot's behalf, and
otherwise starts collecting donations and revenue in BuildBot's name.
Dustin becomes furious. He sues Conservancy, saying that Conservancy
had no right to "take over" his BuildBot project because it was his,
and he never signed an agreement with Conservancy.
This potential outcome is why it's important from Conservancy's
perspective to make sure everyone who is involved with a project in a
serious way signs the FSA, and that at least those who are nominally
involved (or are previous heavy contributors) give an email "ok" to the
idea that BuildBot is joining Conservancy.
>From Conservancy's perspective, the biggest "what if" issue we face is
"what if there's a fork?". Conservancy would have the job of figuring
out who the "real BuildBot community is", since we're holding its assets
and liabilities and acting in its name. the Signatory/PLC structure is
designed to make sure there's an established and clear "chain of
custody" of "BuildBot as a project".
Thus, if there is a major contributor to BuildBot who feels
uncomfortable signing the FSA, Tony and I want to investigate why in
great detail. I can tell you vaguely that there *have* been projects
who wanted to join Conservancy, but we didn't take them ultimately
because some major contributor simply refused to sign the FSA (primarily
for reason (a) above). We couldn't sort out the issue, so the project
just didn't join.
Does that help clarify this issue? Feel free to ask follow up questions
if you have them.
Meanwhile, that issue does relate in some ways to another issue raised
in the thread:
William Deegan wrote on 18 March:
>> Is it possible to clarify what that means for consultants who consult
>> with clients on buildbot? (For example me?) Assuming there'd be no
>> issues stating that I provide BuildBot consulting?
Dustin Mitchell wrote on 18 March:
> as long as you're not representing yourself *as* Buildbot, that's
> absolutely fine. If your clients are OK with submitting your patches
> upstream, then those patches become a donation to Buildbot/Conservancy
> under the GPLv2, but the private arrangements that led to their
> creation are not important.
To put a finer point on this: Conservancy knows well that Open Source
and Free Software licenses treat commercial and non-commercial activity
equally. Conservancy concerns itself entirely with the non-commercial
activity of its projects, and basically "ignores" the commercial
activity. From Conservancy's perspective, when two parties take
software under the GPL and transact some business around it (e.g.,
funding a developer to do work on the codebase), when the patches land
upstream, from Conservancy's perspective, that's just a charitable
donation in the form of code (rather than dollars). That's great, and
we love to see it, but it has little no more to do with us than a nice
big check showing up in an envelope donated to the project that we
didn't even fundraise for: it's nice to see, but it's out of our hands
how that happens.
The place where such things require more diligence is if a developer
wants to be funded by Conservancy to do work. Conservancy does a lot of
this, by accepting donations from the public and using those funds to
employ developers on a contract basis to work on Conservancy projects.
In those cases, Conservancy needs to be involved every step of the way.
The rule of thumb I tell developers to use is to simply decide *up
front* before you begin some work if you want the funding of it to be
channeled through Conservancy or not. If you want Conservancy to handle
the funds and figure things out, then you need to be talking to
Conservancy from the start, before you solicit donors, pitch the idea
publicly, etc.
Meanwhile, if someone just wants to go out as a private consultant and
get paid to do work on the codebase, Conservancy doesn't care at all,
provided that you do all your work in compliance with the relevant Free
Software license, and, as Dustin says, you don't say you're doing it
officially on behalf of the BuildBot project. Upon joining Conservancy,
doing something "in the name of BuildBot" is the legal equivalent of
doing it "in the name of Conservancy", so you have to be coordinated
with Conservancy on such.
> 2. As a member of SFC, Buildbot will be a business entity. If you
> work for a company, that means the company can relate to Buildbot
> directly, rather than to a nebulous "community" or, worse for me, to
> some guy named Dustin.
Yes, that's correct, and relates to the point I was making above.
> 3. As a part of a charity, Buildbot can accept donations - financial
> and in-kind - from individuals and companies.
I'd also note that since specifically Conservancy is a 501(c)(3)
charity, upon joining, individuals (usually) will be able deduct
financial donations to BuildBot on their USA taxes, which is a big
benefit for individuals who itemize their deductions on 1040 Schedule A.
> * Get a draft of the agreement as discussed and review it. I don't
> have a source format, so I think that's in your court, too.
The source format is LaTeX; my original email had URLs for both the
PDF and LaTeX sources.
Dustin Mitchell wrote on 17 March:
> ... but we're looking at some alternate language that would transfer
> the assets elsewhere.
Anyway, Tony and I did some drafting on the one issue of your concern at
the PyCon meeting: the Termination without a Successor provision.
Here's our proposed text on that (as a diff against the default
template):
===================================================================
--- buildbot-sponsorship-agreement.tex (revision 8276)
+++ buildbot-sponsorship-agreement.tex (revision 8279)
@@ -311,6 +311,26 @@
any extension thereof, subject to the approval of any third parties
that may be required.
\item \textbf{Termination Without a Successor}. If no Successor is found,
+ Conservancy, the FIXME-SIGNATORIES and FIXME-LEADERSHIP-BODY-NAME all agree
+ that any remaining tangible assets in the Project Fund shall be donated to
+ the Python Software Foundation (``PSF''), a 501(c)(3) charity with USA
+ federal tax exempt identification number of 04-3594598. Conservancy agrees to
+ negotiate in good faith with the FIXME-LEADERSHIP-BODY-NAME regarding
+ disposal and potential donation to the PSF of any intangible assets
+ (including but not necessarily limited to) copyrights and trademarks.
+
+In the event that no Successor is found, and at that time:
+
+\begin{enumerate}[label=\roman*.,ref=\theenumi(\alph{enumii})(\roman*)]
+
+\item PSF is no longer tax-exempt under IRC Section 501(c)(3), or
+
+\item PSF is classified as a private foundation under IRC Section 509(a), or
+
+\item PSF's 501(c)(3) tax-exempt charity status is, for any other reason, not
+ in good standing with the USA Internal Revenue Service,
+\end{enumerate}
+then
Conservancy may dispose of Project assets and liabilities
in any manner consistent with applicable tax and charitable trust
laws.
===================================================================
Does that address the concern that you were raising at the meeting at
PyCon?
The main drafting action, though, is to write the Representation
section. Tony would be glad to make a first draft, or you can make it
if you prefer that. Which do you prefer?
> * Begin the process of gathering signatures.
> * Call for nominations for the PLC.
Actually, I'd prefer these sorted the other way around: i.e., it would
be ideal if the initial PLC is known at the time of signing the FSA.
However, that's not mandatory if there's a good reason to figure out who
the signatories should be, and then finalize the PLC after the FSA is
signed.
Jared Grubb wrote on 17 March:
>>> The only option that seems completely wrong for buildbot ...
Just a brief comment on this: please definitely don't treat the texts in
the template as "options". They are really just potential examples,
based on texts used by other Conservancy projects. If you'd like
something completely new, that's possible too. The goal here is to fit
the "natural leadership structure" of the project as much as is
possible.
I've attached the current LaTeX version of the FSA, for which the only
current change from the template is the diff mentioned above.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: buildbot-sponsorship-agreement.tex
Type: text/x-tex
Size: 19736 bytes
Desc: not available
URL: <http://buildbot.net/pipermail/devel/attachments/20130409/b33a1f9c/attachment.bin>
-------------- next part --------------
--
Bradley M. Kuhn, Executive Director, Software Freedom Conservancy
More information about the devel
mailing list