2025-06-10 Blender Admins Meeting

Meetings
1

Attendees

  • Bastien Montagne
  • Campbell Barton
  • Jacques Lucke
  • Philipp Oeser

AI written pull requests / patch descriptions

  • How to deal with AI written code or the suspicion that code has been written with AI?
  • Should docs / info when creating a pull request be more explicit on this?

Conclusion: Bottom line would be that using these tools is fine, as long as the reporter does the work to analyze and present it in an understandable way. Do not just create a report or PR with the raw outcome of the AI tool. Ultimately, similar to using other analysis tools like sanitizer, static analyzer, etc.
Regarding AI generated code:

  • The author should be able to respond to requests to cleanup to make up for the shortfalls from the tools they use.
  • Inability to respond to follow up requests - if the author is not capable of managing this, we should not invest too much time into this - up to the judgement of the reviewer.

License Header for code Templates

  • Campbell noticed that some recent new templates (for OSL cameras) have been added with a SPDX header (copyright to the Blender Foundation, Apache-2.0 license).
  • The undocumented practice so far was to have no license info at all for these templates (implicit ā€˜public domainā€™ release).
  • This allows everyone to use them as base, without any form of constraints.
  • However, having no copyright and no explicit license is not a good thing, as this does not provide any legal validity under many jurisdictions.

Proposal:

Conclusion: Meeting agrees with the proposal. This does not apply to the code examples in the documentation.

Styleguides regarding some C++ features (templates, lambdas, auto)

  • Bastien raises concerns about relying too much on ā€˜advanced implicitnessā€™ in our code (type deduction, generic parameters capture in lambdas, and so on). Especially in non-trivial usages.
  • Inlining of comlex lambdas into function calls can also be a concern for readability.
  • Jacques adds the auto usages to the list.

Conclusion:

  • Meeting agrees in general with the concerns.
  • How exactly to define what is allowed or not remains a work in progress.
  • Bastien will create a devtalk thread to:
    • Have a clear and concrete proposal.
    • Gather more feedback from the whole development team.

New dependency: Jpeg XL

  • During the last Pipeline & I/O module meeting, Jesse suggested that we may want to add support for Jpeg XL in Blender 5.0. This implies adding the libjxl library to our dependencies, and rebuilding OpenImageIO.
  • libjxl has itself a significant number of dependencies.
  • OpenImageIO itself is still pending some improvements of its jxl integration, expected with this summerā€™s release.

Conclusion: Meeting has no strong opinion. Itā€™s not clear if itā€™s really a widely used format yet. Probably not a hard target for now, it can also make it to a later release.

Namespace Naming Proposal

  • Nothing really conclusive came out of the discussions on the proposal, expressed opinions are fairly divergent. This remains work in progress.
3 Likes
2

Note this was fixed last week.

Is there any motivation for why these templates need a license? We also donā€™t have license for the code examples in our API docs. To me it seems unnecessary.

4

AFAIK, code examples from the documentation are covered by the documentation license?

The templates on the other end do not have any licensing info when added e.g. to the Blender text editor. One could then assume e.g. that they have the Blender distribution license (ā€œGNU GPL Version 3 or laterā€)ā€¦

Explicitly using the ā€˜public domain-likeā€™ MIT-0 license makes things clear. And makes licensing legally valid.

On a side note, having SPDX license info in templates is also a nice way to hint devs using them to do care about this topic and make informed decision on the license they want to use.

5

Most templates and API example code is trivial enough that there is no copyright. So for me it is a bit misleading for us to even claim copyright.

In my opinion having the copyright and license header there raises more questions than it helps. Developers might reasonably assume that they need to preserve these headers as they do with other code they encounter. But in this case we want people to remove them. We do not want ā€œBlender Authorsā€ copyright on an add-on that was not developed by the Blender project.

Other software and their docs generally donā€™t seem to add these kinds of headers to their code examples either.

Developers understanding licenses is important, but Iā€™m not sure adding SPDX headers to our examples will teach much.

6

To me having code or templates for which the license/copyright is not mentioned explicitly is not any better situation. Some of the code in the templates we provide has questionable triviality.

Other software and their docs generally donā€™t seem to add these kinds of headers to their code examples either.

Other projects have license or ToS which cover explicitly the license of docs and examples.

Developers understanding licenses is important, but Iā€™m not sure adding SPDX headers to our examples will teach much.

To me it is not so much about teaching, but making things clear. Like if you use some of the examples to develop shader or some Python code, what are you allowed to do with it? Can you put the code into your non-GPL software like a game? Do you need to give attribution?

While i can see the concern about Blender Authors copyright, I do not think having files free of license header or other note (anywhere, not necessarily in the templates themselves, files could have a link to a page on blender.org that explains what is possible to do with the code) is good.

7

If we are concerned about the legal aspect, I thinking adding a LICENSE.txt in the template directories would be enough, even if most users never go look for it.

If we need something in the template itself, indeed it would be better to have something a bit more explanatory than SPDX. But in my opinion itā€™s not needed.

8

Do we then ā€œlinkā€ to this LICESNE.txt from the template?

9

Personally I wouldnā€™t, itā€™s not clear to me who this helps.

10

The licenses seem like visual noise in this context, while an extreme case, we end up with templates like this:

/* SPDX-FileCopyrightText: 2012-2025 Blender Authors
 *
 * SPDX-License-Identifier: MIT-0 */

shader name()
{

}

The user probably doesnā€™t know what SPDX or MIT-0 areā€¦ or if they should care.

Personally Iā€™d opt for something less intrusive (a license file in the directory - using MIT-0), as well as a note in the user manual that templates are licensed MIT-0. This seems good enough for code-examples in the manual, so we could consider it acceptable for templates too.

An alternative solution could be to include license headers in the source files but strip the headers so weā€™re not displayed to users.
This means anyone looking around in our source files has licenses on all files, but weā€™re not bothering users with these details.

1 Like