On Subprojects and the boundaries of authority (was: Voting)

I think the LLVM Foundation is still figuring out what are the correct
boundaries for its authority. This is not a surprise.

The discussion of the llgo sub-project in particular was a mix of
technical and non-technical aspects. There may be some difference of
opinion about what is a "technical" aspect so I will spend some time
laying out my opinion here. The 25 Nov 2014 minutes say:

    We want to encourage new sub-projects, but have specific guidelines
    such as: following the LLVM Developer Policy, code structured similar
    to other LLVM projects, licenses should follow the UIUC/MIT licenses
    as appropriate to the project. Exceptions to these rules will be
    considered on a case by case basis by the board.

I think it's entirely appropriate for the Foundation to state copyright,
licensing and patent requirements for software sub-projects hosted with
equipment/services provided by the Foundation. This is legal stuff that
clearly falls under the Foundation's purview.

But, it's equally *not* appropriate for the Foundation to impose technical
requirements, and I include the following as "technical" points.
- Code structure is a technical point, to be decided by the community.
- Adhering to Developer Policy (besides the legal stuff) is a technical
  point, ditto.

I should be clear that I think all these requirements are appropriate,
just that it's absolutely not the Foundation's job to impose them.
Although, as David suggests, exactly the same people participating on the
Dev lists (instead of a Foundation board meeting) absolutely should make
sure these requirements were imposed. Understanding how these roles are
(and should be) separate is a bit of a learning curve.

If the community decides a new software sub-project is appropriate, and
the new subproject adheres to the Foundation's legal requirements, then
it should Just Happen; the community should not have to go to the
Foundation to get *approval* for the new sub-project. The Foundation
provides equipment/services to support the software deemed appropriate
by the community; having the Foundation approve new sub-projects would
be putting the cart before the horse. Nobody's IT department decides
what products to produce.

Conversely, if the Foundation wants to host non-software subprojects
using the same equipment/services (to support workshops, conferences,
other educational services) that's entirely up to the Foundation, of
course. And for those subprojects, there is no reason for the Foundation
to go to the *community* for approval.

Given that essentially all of the LLVM Foundation board members are
people who are used to writing software, it's no real surprise that
it's hard to correctly separate the legal/operational policy concerns
that are properly in the domain of the Foundation from the technical
policy concerns that are properly the domain of the community. Yes
they are all "policy" but no, they are not all Foundation concerns.

HTH,
--paulr

From: llvm-foundation [mailto:llvm-foundation-bounces@lists.llvm.org] On
Behalf Of Tanya Lattner via llvm-foundation
Sent: Thursday, June 30, 2016 10:28 AM
To: David Chisnall
Cc: llvm-foundation@lists.llvm.org
Subject: Re: [llvm-foundation] Voting

… describing FreeBSD Foundation …
It’s worth noting that, while certain individuals are on both Core and

the Foundation Board, their responsibilities are very different in these
two capacities. The Foundation has a lot more flexibility, because it is
decoupled from the project and not directly responsible, whereas the Core
Team has far greater authority within the project as a result of their
elected status. The relationship between the FreeBSD Foundation and the
FreeBSD Project is very carefully managed. By spending money on things,
the Foundation can direct development to a degree (though no more than any
other company that is investing in FreeBSD - a dozen or so companies
routinely spend more on FreeBSD development than the Foundation), but its
role must be (and must be seen to be) supporting and facilitating, not
driving.

The LLVM Foundation is currently in a place somewhere between these.

Some of the minutes from the early LLVM Foundation meetings discussed
technical issues (inclusion of subprojects) that should be LLVM-the-
project decisions, not Foundation issues (though the same people would
likely have been making the decisions in both cases). It’s still not
clear within the LLVM project (or from outside) where the LLVM
Foundation’s authority starts and ends. There is no equivalent of an
elected Core Team that serves as an obvious project-side balance for the
Foundation.

Regarding sub projects, it was discussed as to what criteria would be used
to accept sub projects from the perspective of supporting the sub-project
with resources paid for and administered by the LLVM Foundation. In
addition to hosting and infrastructure support, I see the LLVM Foundation
supporting official sub-projects in educational services realm as well
(workshops, conferences, etc). I do not feel this is a technical issue but
an administrative and legal issue. Obviously projects are proposed on the
list first (like the parallel-libs project).

As I have said many times before we are supporting the LLVM Project
through legal, financial, administrative, and infrastructure. We don’t
control the LLVM project in any technical way. We have code owners to
handle technical decisions.

-Tanya

I think the LLVM Foundation is still figuring out what are the correct
boundaries for its authority. This is not a surprise.

The discussion of the llgo sub-project in particular was a mix of
technical and non-technical aspects. There may be some difference of
opinion about what is a “technical” aspect so I will spend some time
laying out my opinion here. The 25 Nov 2014 minutes say:

We want to encourage new sub-projects, but have specific guidelines
such as: following the LLVM Developer Policy, code structured similar
to other LLVM projects, licenses should follow the UIUC/MIT licenses
as appropriate to the project. Exceptions to these rules will be
considered on a case by case basis by the board.

I think it’s entirely appropriate for the Foundation to state copyright,
licensing and patent requirements for software sub-projects hosted with
equipment/services provided by the Foundation. This is legal stuff that
clearly falls under the Foundation’s purview.

But, it’s equally not appropriate for the Foundation to impose technical
requirements, and I include the following as “technical” points.

  • Code structure is a technical point, to be decided by the community.
  • Adhering to Developer Policy (besides the legal stuff) is a technical
    point, ditto.

Paul,

We aren’t defining anything new. This is already stated in the Developer Policy:
http://llvm.org/docs/DeveloperPolicy.html

First paragraph “… This policy covers all llvm.org subprojects, including Clang, LLDB, libc++, etc.”

Anyone who gets commit access to the llvm repository has access to everything, so thats why one policy is used. I don’t disagree that the Developer Policy does include technical points such as code structure, but its not something new.

I should be clear that I think all these requirements are appropriate,
just that it’s absolutely not the Foundation’s job to impose them.
Although, as David suggests, exactly the same people participating on the
Dev lists (instead of a Foundation board meeting) absolutely should make
sure these requirements were imposed. Understanding how these roles are
(and should be) separate is a bit of a learning curve.

If the community decides a new software sub-project is appropriate, and
the new subproject adheres to the Foundation’s legal requirements, then
it should Just Happen; the community should not have to go to the
Foundation to get approval for the new sub-project. The Foundation
provides equipment/services to support the software deemed appropriate
by the community; having the Foundation approve new sub-projects would
be putting the cart before the horse. Nobody’s IT department decides
what products to produce.

The Foundation is only approving a project in the sense of providing it resources (hosting, mailing lists, svn) if it meets the requirements. Everything else is already in the developer policy. I think it could be made more clear though which is why it says a policy would be written.

Conversely, if the Foundation wants to host non-software subprojects
using the same equipment/services (to support workshops, conferences,
other educational services) that’s entirely up to the Foundation, of
course. And for those subprojects, there is no reason for the Foundation
to go to the community for approval.

Given that essentially all of the LLVM Foundation board members are
people who are used to writing software, it’s no real surprise that
it’s hard to correctly separate the legal/operational policy concerns
that are properly in the domain of the Foundation from the technical
policy concerns that are properly the domain of the community. Yes
they are all “policy” but no, they are not all Foundation concerns.

I feel like there is a lot of concern over what might happen versus whats actually happening. We haven’t told any project they couldn’t be created. We haven’t imposed any new technical decisions. Has the LLVM Foundation done something actively harmful to the community? If so, then lets talk about the specifics of those decisions and work to a better solution.

-Tanya

Hi Tanya!

This is not a concern about what happened but how it happened, as evidenced by how it was reported in the minutes. Achieving a good outcome from a poor process still leaves you with a poor process, and I want the interaction of the Foundation with the community at large to be the result of good process.

My main point is that the Foundation’s only concern w.r.t. new projects should be whether they comply with the Foundation’s legal requirements (which are stated in the Developer Policy). It is up to the community to make sure new projects comply with the technical requirements (which are also stated in the Developer Policy). It’s unfortunate that these things are described in the same document and don’t clearly reflect the distinction between which entity owns which parts.

Now, if the problem is merely poor reporting in the minutes (which could have better reflected that the “approval” was based on the agreed-upon compliance with legal requirements, and nothing else) then we’re all good. As you said, the policy document could stand some updating, to clarify the distinction that we have now.

I have other procedural quibbles with the Foundation but they should wait for another time.

Thanks,

–paulr