Offer of membership to LLVM into the Software Freedom Conservancy, Inc.

"Bradley M. Kuhn" <bkuhn@sfconservancy.org> writes:

I'm sorry for the intrusion of a project policy discussion onto the
developer list, but there may be many here who may have thoughts, input,
or question regarding Conservancy's offer for LLVM's membership,
discussed below. If you're not interested in that topic, please feel
free to ignore this message.

I am interested but I must have missed some messages. Chris and Tanya,
can you explain what the goal is here? Is LLVM lookinmg for funding,
copyright enforcement or something else?

Thanks!

                                  -Dave

I responded on the other email more generally, but to answer these specific questions:

Yes, we would like to make it easier for companies and individuals to donate money, but also we need a way to be able to spend it. The University of Illinois is our current solution - they are capable of accepting money and keep it in an ear-marked account, but our requests to actually spend it (e.g. for student travel) are outstripping their time resources, particularly because the University folks that end up having to do this aren't used to dealing with open source projects.

We are not interested in copyright enforcement at all. In personal discussions with Bradley, he mentioned that they may be able to help us move the codebase to the MIT license, which would clarify that issue as well as resolve the current issues around runtime libraries.

-Chris

I'd like to follow up on Chris' message with a few details about how
Conservancy works. Specifically, Conservancy has generally always offered
our services "a la carte", in the sense that while we have a very
extensive service plan ( http://sfconservancy.org/members/services/ ), I
don't think there's a single one of our projects that takes advantage of
all the services we offer; they pick and chose.

One of the reasons for this is that we have a wide diversity of projects (
http://sfconservancy.org/members/current/ ), from copylefted projects like
BusyBox to permissively licensed ones like Boost. We've got
end-user applications like Evergreen and Mifos, and also programming
language infrastructure projects like PyPy.

With that level of diversity, usually each project needs very different
things. We tailor our work with them to fit what the project's community
needs. We'd do the same for LLVM if you decide to accept the offer of
membership.

Meanwhile, I'm really glad that LLVM is looking at all its options for
non-profit existence. Each solution to this problem has its own tweaks
and trade-offs, and it ultimately is a question of good cultural fit. Thus,
I'd like to begin a conversation so the LLVM community as a whole can find
out all it wants to know about Conservancy as an option, so you can easily
compare it to your other options. As a 501(c)(3) charity, Conservancy's
first and foremost charge is to serve the public good, and that public
includes both users of the software under our auspices and the individual
developers who contribute to it. We thus want to hear all we can from any
stakeholder about what they want regarding a potential non-profit existence
for LLVM before finalizing anything.

Finally, Conservancy's mission isn't just to get projects to join: our mission
includs helping Free Software projects find the *right* non-profit home
for the project. It's not uncommon that projects are offered membership
in Conservancy and go with another fiscal sponsor in the end. We think
that's a great outcome, because we want to help projects make the right
choice.

I hope those interested in learning more will read the Fiscal Sponsorship
Agreement template and ask any questions you have.

Chris Lattner <clattner@apple.com> writes:

Yes, we would like to make it easier for companies and individuals to
donate money, but also we need a way to be able to spend it. The
University of Illinois is our current solution - they are capable of
accepting money and keep it in an ear-marked account, but our requests
to actually spend it (e.g. for student travel) are outstripping their
time resources, particularly because the University folks that end up
having to do this aren't used to dealing with open source projects.

Ah, makes perfect sense.

We are not interested in copyright enforcement at all. In personal
discussions with Bradley, he mentioned that they may be able to help
us move the codebase to the MIT license, which would clarify that
issue as well as resolve the current issues around runtime libraries.

Thanks for clarifying, this is helpful. What's the motivation for
moving to the MIT license? Something more than general familiarity?

What's the issue with runtime libraries?

Thanks!

                           -David

I Am Not A Lawyer, etc….

My understanding is that the issue is about the "advertising" clause in the UIUC license, similar to old-style BSD licenses. It generally isn't much of a problem to reproduce the copyright header in the documentation for a compiler that is based on LLVM. However, it's not an appropriate clause for a runtime library that will be linked into applications compiled *by* LLVM. We don't want to force our users to have an LLVM copyright header included with their binaries just because we linked them against compiler-rt. That is why compiler-rt is dual licensed with the MIT license today.

This, then, creates the issue that we have LLVM sub-projects that do not have the same license as the main project, which in turn means we can't free move code between the various sub-projects and the main project. I know that the Address Sanitizer guys have had issues with this when developing their runtime library.

--Owen

> Chris Lattner <clattner@apple.com> writes:
>> We are not interested in copyright enforcement at all. In personal
>> discussions with Bradley, he mentioned that they may be able to
>> help us move the codebase to the MIT license, which would clarify
>> that issue as well as resolve the current issues around runtime
>> libraries.
>
> Thanks for clarifying, this is helpful. What's the motivation for
> moving to the MIT license? Something more than general familiarity?
>
> What's the issue with runtime libraries?

I Am Not A Lawyer, etc….

My understanding is that the issue is about the "advertising" clause
in the UIUC license, similar to old-style BSD licenses. It generally
isn't much of a problem to reproduce the copyright header in the
documentation for a compiler that is based on LLVM. However, it's
not an appropriate clause for a runtime library that will be linked
into applications compiled *by* LLVM. We don't want to force our
users to have an LLVM copyright header included with their binaries
just because we linked them against compiler-rt. That is why
compiler-rt is dual licensed with the MIT license today.

I am supportive of a licensing change. The MIT license contains the
"substantial portions" qualifier, which seems fairly ambiguous, and
does not specify whether 'copies ... of the software' includes
binaries, etc. I think that the Boost license is better in this
regard.

-Hal

Chris Lattner <clattner@apple.com> writes:

We are not interested in copyright enforcement at all. In personal
discussions with Bradley, he mentioned that they may be able to help
us move the codebase to the MIT license, which would clarify that
issue as well as resolve the current issues around runtime libraries.

Thanks for clarifying, this is helpful. What's the motivation for
moving to the MIT license? Something more than general familiarity?

What's the issue with runtime libraries?

I Am Not A Lawyer, etc….

My understanding is that the issue is about the "advertising" clause in the UIUC license, similar to old-style BSD licenses.

Disclaimer: I Am Not A Lawyer.

Maybe I'm missing something, but the UIUC license does not have the infamous advertising clause. The infamous BSD advertising clause required any *advertisements* to note the names of contributors; that gets problematic when you have lots of contributors. LLVM has never had this problem as we made sure to avoid it from the very beginning.

It generally isn't much of a problem to reproduce the copyright header in the documentation for a compiler that is based on LLVM.

Correct. Furthermore, I think it's a desirable feature of the license.

   However, it's not an appropriate clause for a runtime library that will be linked into applications compiled *by* LLVM. We don't want to force our users to have an LLVM copyright header included with their binaries just because we linked them against compiler-rt. That is why compiler-rt is dual licensed with the MIT license today.

It sounds like your concern is with the clause that requires binary distributions of the code to contain the copyright notice and other legal stuff. Just to be picky, that's not the infamous BSD advertising clause; you're talking about another (completely valid but different) problem.

That said, it sounds like compiler-rt is already dual licensed, so it seems like the problem is solved. Is there another problem with the UIUC license on core LLVM?

-- John T.

[snip]

This, then, creates the issue that we have LLVM sub-projects that do not have the same license as the main project, which in turn means we can't free move code between the various sub-projects and the main project. I know that the Address Sanitizer guys have had issues with this when developing their runtime library.

Sorry. Missed reading this last part.

So the problem is being able to move code from the core compiler (which requires the license with binary distributions) to runtime libraries (for which binary license redistribution is a bad thing). Correct?

Hrm. I am not a lawyer, but I don't think the MIT license gets you around the problem either. Both require copies or significant portions to carry the copyright notice; link in enough of the library, and one may be technically required to include the license.

-- John T.

Just to clarify, we're not actually proposing a license change at this point, so there is no need to discuss the pros and cons of various options. If we went with the SFC, they'd presumably be fine with whatever license the community chose.

-Chris

Hi John,

This is discussed here:
http://llvm.org/docs/DeveloperPolicy.html#copyright-license-and-patents

There are two different "advertising" clauses in the BSD license, depending on which version you're talking about. The UIUC license has just the "binary" attribution clause, but that is still problematic for runtime libraries.

-Chris