[llvm-foundation] On Subprojects and the boundaries of authority (was: Voting)

[Robinson, Paul via llvm-foundation]

> -----Original Message-----
> From: llvm-foundation [mailto:llvm-foundation-bounces at 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 at lists.llvm.org
> Subject: Re: [llvm-foundation] Voting
> 
> 
> > On Jun 30, 2016, at 1:51 AM, David Chisnall via llvm-foundation <llvm-
> foundation at lists.llvm.org> wrote:
> > ... 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.

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