24 proposals (which is good), in line with the last 2 years.
Currently ranking proposals.
Many differences in program compared to previous years, including:
not just students anymore
only beginners to open source can participate
Makes it harder for candidates to match the criteria. Many past participants would not qualify this year.
This also means people can only participate once in the program.
Outreachy Updates
One Outreachy project - 2 candidates. Candidates didn’t make a “functional” change to the project which was expected by the mentor. It would be good to fix this in the future so we can accept more applicants.
Maybe have something at the next dev meeting to “advertise” to potential new mentors
EuroLLVM
150 registrants - full. There is also a waiting list.
○ One speaker may not get a visa - looking into having them speak remotely.
Starting to plan EuroLLVM 2023 - looking at potential venues in Paris. Looking atthe last 2 weeks in April or last week in March - trying to avoid Easter breaks.
US LLVM Dev Mtg
COVID-19 policies
Hard to predict what the COVID situation will be at the time.
We will at least follow local government rules.
We may need to decide to set a more strict policy if the COVID situation changes.
Sponsorship Changes
Rising costs may require changes to sponsorship levels.
We’ll use a sponsorship meeting to hear feedback from sponsors.
Has there been any progress on the 4b clause problem of the Apache license? Recall, this clause states that:
(4) You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:
…
(b) You must cause any modified files to carry prominent notices stating that You changed the files; and
The result of this clause is that everybody who pushes a branch to GitHub and doesn’t add such a comment in the source itself is arguably violating the license. At the very least, they seem to be entering unsafe legal territory. This is the interpretation of AMD’s lawyers, and while I don’t like this conclusion I can’t really find a fault in their logic.
This in turn is a blocker against ever using GitHub PRs for development, at least given the current plan as I understand it. As a project, we really shouldn’t set up a workflow in which we tell developers that in order to contribute to the project, they must violate its license!
Can the LLVM Foundation help put us on a path that offers legal certainty here?
(Other licenses do require that if you distribute a modified version you clearly mark it as such, but don’t require this to be stated in the source files themselves. For those licenses, the Git history should be sufficient. The Apache license is really an unfortunate outlier in its wording. That doesn’t necessarily mean that we have to change the license, other options, like an explicit waiver or exception could be considered as well.)
Not a legal argument, but there are many projects under the Apache license that use github PRs, not least many (most?) of the official Apache projects themselves. Perhaps the Apache Software Foundation can be asked for comment…?
That would indeed be interesting. Perhaps it matters that the ASF uses Contributor License Agreements, but obviously I’m just speculating as a non-lawyer here. In any case, this feels like precisely the sort of thing that the LLVM Foundation should look into.
I should think the clause applies to proper downstream modifications, rather than the mechanics of making a contribution to the project–which, once it’s accepted, no longer requires any prominent notice, because it’s part of the project. But lawyers do like to make things more complicated than they should be.
The LLVM Foundation does not believe this is a problem. We have consulted legal counsel and it can be best explained as follows:
The person making the change is actually the project, not the contributor. There is no risk to the contributor. The contributor is only suggesting a contribution (the pull request).
The “you” here is the licensee, not the licensor. The “you” is only a downstream user. (Downstream users usually leave a comment in the source code if they make changes.)
The GIT metadata is a prominent written notice. It shows exactly what changes were made, when, and by whom. It has supplanted comment notes. This license was written prior to the industry’s move to GIT.
Unfortunately I just have vague information. Timeframe late April or early May. Looking at a ton of locations as inflation has caused us issues finding a venue that is affordable and available.