Trac -> Software Freedom Conservancy?

[Ethan Jucovy]

Hi,

I wanted to ask the community's thoughts on submitting a proposal for Trac to become a member of the Software Freedom Conservancy. [0]

After hearing WANdisco's concerns about sponsoring code contributions without a foundation's guarantees, and Christian's hesitations about changing Trac's established ways in order to become an Apache project, I started to research other open source foundations like the Apache Foundation.  I wanted to see if any reputable foundation existed that could hold Trac's copyright without imposing any changes on Trac's existing license, development infrastructure, and governance.

Of the foundations I researched (which also included the Apache Foundation, the Eclipse Foundation, and the Free Software Foundation) -- the Software Freedom Conservancy looks most promising for Trac:

• I believe the SFC would accept Trac's existing 3-Clause BSD License without modifications. [1]
• I believe the SFC would accept Trac's existing informal governance structure and procedures without modifications. [2]
• I believe the SFC would accept Trac's existing development practices (occurring in the Edgewall Subversion repository with issues tracked in the Edgewall Trac Trac) without modifications. [3]
• Entering into a relationship with the SFC would not need to be permanent.  The Trac project would be free to leave the SFC in the future. [4]
• The SFC does seem to be very reputable.  Its current Member Projects include very prominent project, for example Git, Mercurial, PyPy, Inkscape, jQuery, Selenium, Twisted, and Wine. [5]  And its Board of Directors includes Bradley Kuhn[6] (formerly of the Free Software Foundation) and Stormy Peters[7], Head of Developer Engagement at Mozilla. [8]
• The SFC would also be able to accept and distribute donations earmarked for Trac development which would be tax-deductible in the United States. [9]  It also seems to do some fundraising support on behalf of its member projects if they are interested. [10]

So, I wanted to see what people thought about the idea.  Applications for new projects are accepted twice per year.  The next application deadline is February 1.

Importantly, submitting an application does not imply any obligation to accept membership if it is offered: the SFC FAQ says "Don't worry about “wasting our time” [...] If membership in Conservancy is currently a legitimate consideration for your project, we encourage you to apply.  We'd rather that you apply and turn down an offer for membership than fail to apply and have to wait until the next application round when you're sure." [11] 

The canonical Application Form is not published officially, but it is not secret either, and member projects have published theirs.  Here is an example: [12]

Before agreeing to join the SFC, I imagine it would be best to be sure of a few things -- including how Trac's core developers and "core developers emeritus" felt about it; how the broader Trac community felt about it; whether Trac's membership in the SFC would make WANdisco's executives more comfortable with the idea of sponsoring code contributions; and whether the Apache Foundation's formal guidelines and informal procedures would allow for a healthy relationship between Apache Bloodhound and an upstream BSD-licensed Trac sponsored by the SFC.  Also of course we should make sure that my above statements (that SFC membership would not change Trac's license, governance or infrastructures) are correct.  I'd be happy to take the lead on communicating and researching any or all (or none) of these questions.

For now, since the next application deadline is February 1 -- and because that application would be non-binding -- I thought it was worthwhile to hear people's thoughts on this ASAP, and also to offer to (try to) put together an application in time for the deadline.  I would be happy to do the work to collect and write up the necessary information and submit an application (with the core developers' review of course) on behalf of the Trac team and community.  Let me know what you think.

Thanks, and happy New Year,

Ethan

[0] http://sfconservancy.org/overview/

[1] "All software of the project should be licensed under a license that is listed both as a Free Software license by the Free Software Foundation and as an Open Source license by the Open Source Initiative. All software documentation for the project should be licensed under a license on the preceding lists, or under Creative Commons' CC-By-SA or CC-By or CC-0."  http://sfconservancy.org/members/apply/ -- under "What are the key criteria our project must meet to join?"

[2]  "Substantively, member projects continue to operate in the same way as they did before joining the Conservancy. So long as the project remains devoted to software freedom and operates consistently with the Conservancy's tax-exempt status, the Conservancy does not intervene in the project's development other than to provide administrative assistance. For example, the Conservancy keeps and maintains books and records for the project and assists with the logistics of receiving donations, but does not involve itself with technical or artistic decision making. Projects are asked, however, to keep the Conservancy up to date on their activities." http://sfconservancy.org/members/apply/ -- under "If my project joins the Conservancy, how will it change?"

[3] "Conservancy always avoids making any technical recommendations. [...] Conservancy, for its part, doesn't have a recommended version control system, nor a recommended hosting site, nor anything else like that." http://sfconservancy.org/blog/2011/nov/28/what-npo-for/

[4] "All agreements between member projects and the Conservancy stipulate clearly that the member project can leave the Conservancy with a few months' notice. Federal tax exemption law, though, states that projects must transfer their assets from the Conservancy in a way that is consistent with the Conservancy's not-for-profit tax status — meaning the assets cannot be transferred to an individual or a for-profit entity. Generally, a project would either find another fiscal sponsor or form their own independent tax-exempt non-profit." http://sfconservancy.org/members/apply/

[5] http://sfconservancy.org/members/current/

[6] http://en.wikipedia.org/wiki/Bradley_Kuhn

[7] http://en.wikipedia.org/wiki/Stormy_Peters

[8] http://sfconservancy.org/about/board/

[9] http://sfconservancy.org/members/services/ -- under "Tax-Deductible, Earmarked Donations"

[10] http://sfconservancy.org/news/2011/nov/11/support/

[11] http://sfconservancy.org/members/apply/ -- under "Is our project required to accept membership if offered?"

[12] http://wiki.openqa.org/display/WTR/Joining+the+Software+Freedom+Conservancy

[Leo Simons]

Hey hey,

Thought I'd answer this little bit:

On Sun, Jan 8, 2012 at 2:44 PM, Ethan Jucovy <ethan....@gmail.com> wrote:
<snip/>

> whether the
> Apache Foundation's formal guidelines and informal procedures would allow
> for a healthy relationship between Apache Bloodhound and an upstream
> BSD-licensed Trac sponsored by the SFC

<snip/>

There wouldn't be any issue from an apache guideline/procedure
perspective with that.

If the bloodhound contributors were to decide they will just work
on/within trac directly if it's an SFC project, then maybe having
bloodhound exist at all would stop making sense. Of course I can't
decide that for them. But, I can say that from an apache
guideline/procedure perspective that also wouldn't be an issue.

cheers,

Leo

[Greg Troxel]

I wanted to ask the community's thoughts on submitting a proposal for Trac
to become a member of the Software Freedom Conservancy. [0]

(I'm only a user, list lurker, occasional ranter, and very occasional
provider of plugin patches, but,)

I think trac joining SFC would be a good thing. SFC indeed has a good
reputation, and exists to provide umbrella 501(c)3 benefits to member
projects without imposing significant constraints on how the project
operates beyond insisting that it's actually a free software project.

In particular, SFC won't insist on a particular license, a particular
version-control tool, particular hosting, CLAs, etc.

But, one item is perhaps confusing:

I wanted to see if any reputable foundation existed that could hold
Trac's copyright without imposing any changes on Trac's existing
license, development infrastructure, and governance.

There are basically 3 approaches here:

custodian organization holds copyright, with formal assignment
(e.g. emacs in FSF)

custodian organization has a formal CLA, and while
individuals/companies that produce code retain copyright, there is a
formal grant of permission to license

inbound=outbound: there is no formal CLA but there's a policy, perhaps
formal, that states that all code contributions are made under the
existing license.

I have the impression trac operates in the third mode, but it's not
clear.

That said, edgewall could assign any copyrights it does hold to SFC.

[Ethan Jucovy]

On Sun, Jan 8, 2012 at 11:36 AM, Greg Troxel <g...@ir.bbn.com> wrote:

 inbound=outbound: there is no formal CLA but there's a policy, perhaps

 formal, that states that all code contributions are made under the
 existing license.

I have the impression trac operates in the third mode, but it's not
clear.

That said, edgewall could assign any copyrights it does hold to SFC.

Thanks.  I hadn't realized that Trac's copyright works this way.

Just to clarify, do you know if this would be a problem for SFC sponsorship?  It looks like Mercurial uses the same distributed copyright model (http://mercurial.selenic.com/wiki/License#Who_holds_the_Mercurial_copyright.3F) and is an SFC member project, so it looks like that wouldn't be an issue?

-Ethan

[Greg Troxel]

Ethan Jucovy <ethan....@gmail.com> writes:

I am quite sure the non-assigned non-CLA inbound=outbound approach is
fine with SFC, from having listened to Bradley rant on his Software
Freedom Law Show and Free as in Freedom podcasts.

[Christian Boos]

On 1/8/2012 2:44 PM, Ethan Jucovy wrote:
> Hi,
>
> I wanted to ask the community's thoughts on submitting a proposal for
> Trac to become a member of the Software Freedom Conservancy. [0]
>

Great idea! I'm all for it, and ...

> [...] I'd be happy to take the lead on

> communicating and researching any or all (or none) of these questions.
>

... I think you would be doing this just fine, many thanks for the
undertaking!

-- Christian

[Jonas Borgström]

On 2012-01-11 04:25 , Ethan Jucovy wrote:
> On Sun, Jan 8, 2012 at 11:36 AM, Greg Troxel <g...@ir.bbn.com> wrote:
>
> > inbound=outbound: there is no formal CLA but there's a policy, perhaps
> > formal, that states that all code contributions are made under the
> > existing license.
> >
> > I have the impression trac operates in the third mode, but it's not
> > clear.
>

> Thanks. I hadn't realized that Trac's copyright works this way.

Hi Ethan and all,

Yes that's correct, there's no formal CLA or any formal policy
describing how code contributions are handled.
What we do have is that all source files have a
"Copyright XXXX-YYYY Edgewall Software" line in the license header. In
addition to that many files also have similar lines for individual
developers.

I'm not a lawyer so I don't really know if this means that Edgewall
Software holds full or partial copyright of the source code.

> > That said, edgewall could assign any copyrights it does hold to SFC.

Even though I think Edgewall Software has served the project well so
far. I think from my perspective the most interesting part of the SFC
proposal would be to find a way for it to replace Edgewall Software as
copyright holder and legal entity.
Hopefully that will be enough to remove future concerns when it comes to
external sponsoring and code contributions.

Cheers,
Jonas

[Hyrum K Wright]

2012/1/12 Jonas Borgström <jo...@borgstrom.se>:
...

> Yes that's correct, there's no formal CLA or any formal policy describing
> how code contributions are handled.
> What we do have is that all source files have a
> "Copyright XXXX-YYYY Edgewall Software" line in the license header. In
> addition to that many files also have similar lines for individual
> developers.
>
> I'm not a lawyer so I don't really know if this means that Edgewall Software
> holds full or partial copyright of the source code.

In most jurisdictions, unless contributors have expresses granted
copyright of their contributions to Edgewall, they still hold
copyright over the code, and that header is inaccurate. Edgewall (or
the SFC, or $FOO) may still have copyright over an entire
distribution, but the individual contributions remain the property of
their authors.

In theory, these contributions could even have separate licenses,
which opens up a whole other set of issues. Clearing up such
ambiguity is one fo the primary purposes of having a CLA. In practice
though, it is understood that contributions to a file have been made
under the license that file is under. (With the GPL, this is
required, and is explicitly in the license. With the BSD and friends,
not so much.)

I'm not a lawyer either, btw, but have been through this before with
other projects.

-Hyrum

[osimons]

That seems to be in line with my understanding too.

1) There has been an implicit understanding in the project among
contributors and anyone helping out with tickets and patches, that the
result will be BSD licensed. AFAIK there has never been a complaint or
discussion about that to suggest otherwise. Anything known to have
other licenses, such as the Mercurial plugin, has been kept external
to the main Trac code. We have certainly never accepted any
contribution that has explicitly claimed a different license. I think
it is fair assumption to claim that all of the Trac source code is BSD
licensed, and I don't see that anyone will challenge that.

2) I have touched many files in my work with Trac, but other than
adding my name to the AUTHORS file I have never bothered to "claim"
any copyright in individual files. But, as Hyrum correctly states, I
still hold the copyright of my changes even though my name does not
appear in files. I have no reason or incentive to hold such a
copyright to a body of work built as part of a team building software
for public availability, and as such I have 'implicitly' transferred
my copyright to Edgewall all along. However, I will have no problem
making an explicit grant of transfer - for past, present and future -
to whatever organisation deemed appropriate to manage the Trac project
intellectual property (IP).

3) Jonas, I suppose if we transferred the IP elsewhere we should also
handle the other Trac dependencies/dependents at the same time -
Genshi, Babel, Bitten in particular. It widens the scope a little, but
should still be quite manageable.

:::simon

https://www.coderesort.com
http://trac-hacks.org/wiki/osimons

[Jonas Borgström]

On 2012-01-12 14:53 , osimons wrote:
>
> 3) Jonas, I suppose if we transferred the IP elsewhere we should also
> handle the other Trac dependencies/dependents at the same time -
> Genshi, Babel, Bitten in particular. It widens the scope a little, but
> should still be quite manageable.

Agreed, it makes no sense to leave them behind.

/ Jonas

[Christian Boos]

What if in the future we'd like to add another "toplevel"
project? Or if we'd like to cover some of the other plugins
(Mercurial plugin, SpamFilter plugin... though as they're already
part of the Trac repos and maintained at t.e.o, one could
consider they're part of the Trac project itself, as optional
components).

So it would be nice if we could be a kind of general agreement,
like all code produced at edgewall.org is "covered" by the SFC,
for some meaning of "covered".

-- Christian

[Ethan Jucovy]

Quick (non-)update:

Last Wednesday (a week ago) I emailed ap...@sfconservancy.org with descriptions of Trac, Babel, Genshi and Bitten, and requesting the application materials.  I still hadn't heard back this morning, so I pinged them again.  Hopefully they'll respond in time to get the application in by the February 1 deadline -- I suppose I'll pester them again next week if I still haven't heard back.

The next time applications can be considered will be in six months, so if they don't get back to me in time for this application period, I suppose I'll just have a much more leisurely time putting in an application for the next period. ;)

Per Christian's comment below, I'll inquire about the different permutations of memberships/applications that are possible (one application for all current Edgewall projects; four distinct applications for Babel/Bitten/Trac/Genshi; one application for Edgewall Software in general covering current and future projects; etc) when they get back to me.

-Ethan