[Buildbot-devel] Discussion of the Fiscal Sponsorship Agreement with Conservancy (was Re: Offer of membership to Buildbot into Software Freedom Conservancy, Inc.)
Pierre Tardy
tardyp at gmail.com
Wed Apr 10 12:44:20 UTC 2013
FWIW,
I took the time to read the TL;DR, and this helped a lot to clarify.
This looks like really good stuff for the viability and the seriousness of
the project.
Thanks to dustin for taking care of it!
>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.
OK from me then.
Regards,
Pierre
On Tue, Apr 9, 2013 at 8:01 PM, Bradley M. Kuhn <bkuhn at sfconservancy.org>wrote:
> 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.
>
>
> --
> Bradley M. Kuhn, Executive Director, Software Freedom Conservancy
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Buildbot-devel mailing list
> Buildbot-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/buildbot-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20130410/dccfcdd9/attachment.html>
More information about the devel
mailing list