Academy Software Foundation Technical Advisory Council (TAC) Meeting - April 1, 2026

Join the meeting at https://zoom-lfx.platform.linuxfoundation.org/meetings/aswf?view=list&projects=aswf

Voting Representative Attendees

Premier Member Representatives

Project Representatives

Carol Payne - OpenColorIO Representative
Cary Phillips - OpenEXR Representative
Chris Kulla - Open Shading Language Representative
Daniel Greenstein - OpenImageIO Representative
Diego Tavares Da Silva - OpenCue Representative
Jonathan Stone - MaterialX Representative
Karen Ruggles - Diversity & Inclusion Working Group Representative
Ken Museth - OpenVDB Representative
Nick Porcino - Universal Scene Description Working Group Representative

Industry Representatives

Jean-Francois Panisset - Visual Effects Society

Non-Voting Attendees

Non-Voting Project and Working Group Representatives

LF Staff

David Morin - Individual - No Account
Emily Olin - Academy Software Foundation
John Mertic - The Linux Foundation
Yarille Ortiz - The Linux Foundation

Other Attendees

Doug Walker - Autodesk / OCIO
Jim Helman - MovieLabs
JT Nelson - Pasadena Open Source consortium / SoCal Blender group
Lee Kerley - Apple
Lorna Dumba - Framestore
Olga Avramenko - Sony Imageworks / Dailies Notes Assistant project
Sam Richards - ORI

Antitrust Policy Notice

Linux Foundation meetings involve participation by industry competitors, and it is the intention of the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws.

Examples of types of actions that are prohibited at Linux Foundation meetings and in connection with Linux Foundation activities are described in the Linux Foundation Antitrust Policy available at linuxfoundation.org/antitrust-policy. If you have questions about these matters, please contact your company counsel, or if you are a member of the Linux Foundation, feel free to contact Andrew Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to the Linux Foundation.

Agenda

General Updates
- TAC Industry Representative Election #1291
- ORI follow up on Incubation #1167
- Dev Days 2026 #1288
- AGENDA TOPIC: AI code assistant policy #1195
- AGENDA TOPIC SLP 2026 #1306

Notes

General Updates
- TAC Industry Representative Election #1291
  - Carol: if anyone is interested, haven’t had volunteers come forward, if we are interested in that. Any TAC members who are non voting members? If no volunteers, we could just not have it, or ask someone to do it? John: a mechanism for the TAC to give a voting seat to someone out there, can have up to 3. Up to the TAC to decide. In the past JF had been since the beginning (for VES), do you see individuals out there that you would want to have a voting seat. Don’t have to pick anybody either.
  - JF: what about people who have multiple qualification for a voting seat? Larry: you still get just one vote. Carol: we can overlap responsibilities, in my case I have the OCIO vote and Karen has the D&I vote. For company member reps who are also TSC chairs, it gets a bit greyer. John: projects can pick a different TAC rep than their TSC chair. But someone cannot vote twice.
  - Larry: is “industry representative” is different than “at large”? John: it’s effectively the same thing, it’s the terminology. General members don’t have a seat to elect into TAC, just the Board. Larry: industry representative does not have work for the “general member” companies? John: could be anybody, TAC can set the qualifications. Carol: we’ve had JF in that role, now he has a vote through CI WG (as a long term WG). We have opportunities to add people to the TAC within that role, so we can talk about it again.
- Dev Days 2026 #1288
  - Olga: 6 weeks until Dev Days, on May 14th. Please update your GitHub and Confluence docs, methods of communication, build process, link to Slack, how to claim an issue. Check Clotributor for your project to make sure your “Good First Issues” are showing up, contact John if not. Assign a Dev Days project lead who can be the point person, message me if you aren’t in the Slack channel for dev days. Make sure to tell people in your company, get them to take part.
  - Olga: starting a small student pilot program with some UBC students, we have 5 who signed up, will assign them to projects. Let me know if you don’t want a student volunteer assigned. Volunteer will be doing a build of the project and helping to update the documentation / file issues against the documentation. Larry: throwing them into the deep end! Olga: yes, but before Dev Days. Carol: let me know before you assign someone, I need to update OCIO docs. Olga: I’ll make sure to reach out to projects before assigning someone. Not sure if they get to chose, or if we assign.
  - Larry: if a student wants to be involved with a project, they should be assigned to that project? Olga: of course, but don’t want them to all go on one project.
- SLP 2026 #1306
  - Carol (Karen can’t make it today). Applications for learners and volunteers are happen. Please share with your companies that we are looking for volunteers, template for that email is on Confluence. Also volunteer itself! Deadline coming up end of April, expect emails / Slack DMs.
ORI follow up on Incubation #1167
- Erik: Follow up on their last annual review. ORI structure a bit unique inside ASWF, early on we were experimenting on how we wanted to organize teams and projects. Evolved into different alignment on projects and ownerships. Projects are doing well, making good progress, but we are an outlier. After deliberations and talking to many stakeholders, we put together a historical document (how did we get here), with recommendations as to directions to take, and as a follow on, Carol joined us at recent TSC, we think we want to move ORI as long term WG, and turn OpenRV and xStudio as their own projects with own structures, outside of ORI entity. Wrote an action plan around that, need to make choices on where documentation goes, what to do about Encoding and RPA projects, but the team is well aligned with this outcome.
- Allows OpenRV / xStudio to have their own annual review cadence, as well as their own release cadence.
- Historical Context
- Action Plan
- Would need to move some reps to the ORI LTWG
- xStudio folks are in the UK, makes this timeslot more complicated. They may have someone in LA who would be on better timezone.
- OTIO schema for cross product review, still chasing additional projects from the community, WDA working on something they would like to contribute which would be a good addition to the suite of offerings. LTWG allows us to engage with the community, but we can stagger reviews of the main projects. Also fits better with the way ASWF is structured.
- Carol: a great summary. What we are asking for is 3 votes:
  - Converting ORI to LTWG, would not longer be a “project”
  - Adding OpenRV as a project, at what level? Sandbox?
  - Adding xStudio as a project, at what level? Sandbox?
- Erik: yes, at the current level, then we can schedule review to “upgrade” status, especially for OpenRV. And there’s been a lot of recent activity on xStudio.
- John: we’ve alreday done background work for xStudio / OpenRV. We’ll work in the background to get the governance setup. When the timing is good for the other two projects, we can do that. Erik: for encoding guidelines, it sits in an interesting status. It is meant to be a reference guide, has code to generate test suites, but it doesn’t expect a lot of contributions. Could just live as part of the WG. If RPA (Review Plugin Architecture) evolves, it may need to become its own project. Carol: let’s get the clear cut ones done. No rush for the other projects. Would like to discuss Encoding Guidelines could interact with the Color Interop forum, so could be a wide discussion.
- Larry: this is great, I’m 100% behind the plan put together by ORI, nothing controversial. If you look at our projects, we have a complicated web of projects being dependencies on other projects, but we don’t have projects that are purely a dependency for another project. For projects that will be used by a few different projects, should we have small projects being independent? Or should they be together?
- Erik: RPA is interesting, outcome we’d like to see is a community of contributed plugins shared between OpeNRV / xStudio (and others). RPA acts as framework to generate those plugins, could be a standalone project. But there’s a high barrier to contributing to the big review packages, so this is a way to be able to on-board new contributors, as well as drive interop.
- Erik: are the LTWG mechanisms of incubating / spawning projects the objective? What happens if the TAC isn’t interested in a proposal? People coming together in those environments are our direct or indirect customers of those projects. How do we promote something coming out of a WG? Before investing a lot of effort, make sure it aligns with expectations. Carol: ML WG has 2 projects, both did presentations to the TAC. We’re skipping that a bit with OpenRV and xStudio since we know them well. If the TAC wants them to present officially, we could? When a project is ready to become a sandbox / incubating project, they should present to the TAC. I don’t have a problem with a WG doing something, even if the end result is that ASWF may not be the home for it. Can still use ORI LTWG to talk about it, similar to USD WG. Erik: was thinking about newer projects. Is there some way that as projects are starting in WGs, how do we give guidance to community members on whether to keep going since it makes sense to ASWF? How can the TAC provide membership? Carol: something interesting to think about. Put items on TAC agenda, don’t wait for annual review, anyone can create a TAC agenda item and we can get it scheduled. But would put that responsibility on LTWG leads to bubble up to TAC.
- Gordon: how do we characterize state of OpenRV and xStudio projects today? Autodesk has already given OpenRV to ASWF, I understand the structure has changed, but do we have to have another vote? Does it get “kicked back out”, even after we’ve changed all the copyright / IP? Larry: we’ve been representing it as an ASWF project for years, so we don’t want to call it into question? John: its a recharacterization, they’ve been considered as projects, but this is more “cleaning things up” . Carol: so the ask is acknowledging the change of org? Gordon: aren’t they already sandbox? Erik: I’m trying to get the organization clearer. Just positioning them the way the other projects are. Gordon: so maybe it’s a single vote for restructure, we end up with a LTWG, and two separate groups. Otherwise it gets weird if one project passes and the other doesn’t? We should just vote on a restructuring. Carol: we do need to vote on version of ORI to LTWG. John: we can do it as a single vote. Carol: let’s do this, vote to move ORI to LTWG, with “side effect” of moving OpenRV and xStudio to project status.
- Carol: thank you for all the work ORI TSC has done, hopefully this will put us in a good place. Erik: happy to do it, wants projects to have more access to TAC, so far there’s been an “abstraction layer” between projects and TAC. We can still maintain the continuity for the team.
AI code assistant policy #1195
- Carol: a follow up on previous discussion.
- Document to be discussed
- Starts with what it’s not. None of these concepts are new, just being more heavily scrutinized and needed to be put into writing because of the use of agentic workflows. Open to other ways to structure this. Sent it to Larry for review.
- Want to make sure that every ASWF project has a comment about tooling which was used. Larry: want to be able to go back and do various kinds of reviews. What tools are people getting benefit from. Maybe a retrospective talk next summer about how well those tools worked.
- Michael: there’s a lot of frenetic activity around CA-942 and European laws, depending on what the software does, may need more formal discussions, lots of legalities popping up. Carol: this is just for code authoring, not generating imagery. Michael: we may need to adhere to these standards, even indirectly.
- Larry: easy to get carried away. We should assume at this point that any development will use these tools. There’s nothing that will be “pure” going forward. Most of those regulations are more about generative workflows on the “consumer” side? Michael: there may be some responsibility that tools have to pass on the provenance, even though the code doesn’t generate anything, but plugins may? We don’t need to worry about legalities of code generation, but does work on images / videos require considerations about round-tripping provenance information?
- John McCarten: at RMTC TSC, icon generation, test asset generation may use generative tooling, so it’s not just code we’re putting into our code. So we may want better definitions: auto complete, code generation… Generative workflows can apply to non code assets we generate.
- Larry: at last OSL TSC meeting we discussed code assistance policy, we decided to be explicit in our policy about just code. We wanted to call out that other ASWF projects may have assets like artwork, logos, but what about materials / models / … ? We’ve explicitly excluded these from our guidance for now. John M: I found it useful in your OIIO guidance to list what is not covered. We’ll comment on the Google doc from Carol. Facilities are keen to look at these policies for their own work.
- Larry: this is all subject for revision. We’re learning as we go. Carol: I wrote this specifically around code generation in our projects. If we need to expand and talk about other aspects of our projects, that’s important.
- Matthew: DPEL falls in “misaligned” category. We’re following the same policy in an “abstract way”, anyone contributing asset to DPEL must have the right to contribute it. If you are signing the contribution docs, you are acknowledging you have the right to contribute that asset. We have an asset coming up that has an asset which represents a known consumer product, we’re telling the contributor that if they don’t have that right, that’s an issue. Guidelines current go a long way even with AI.
- John M: a lot more complexity with assets. Carol: are you familiar with DPEL? John M: a bit. Carol: DPEL is all assets, they have a specific license, could be worth taking a look at it. There is a lot of crossover. When someone signs a CLA, that has to be legally binding. Matthew: what we’ve discussed so far doesn’t seem to trigger any of the new laws, but may want LF legal review? Larry: also there are the sensitivities of the audience? The producers / consumers of code may be more comfortable with this tech, someone working in a CG pipeline may not. Matthew: we have different perspectives between different contributors, for instance ASC vs Netflix Animation.
- Carol: action item: please read the doc, comment on it, this is a first draft only. Will post link in #tac channel.

Next Meeting Agenda

General Updates
- 2026 Security Reviews #1137
2026 TAC Priorities #1208
Linux Workstations in VFX - Wayland #1317