Academy Software Foundation Technical Advisory Council (TAC) Meeting - October 1st, 2025

Join the meeting at https://zoom-lfx.platform.linuxfoundation.org/meeting/97880950229?password=81d2940e-c055-43b9-9b5a-6cd7d7090feb

Voting Representative Attendees

Premier Member Representatives

Project Representatives

Carol Payne - Diversity & Inclusion Working Group Representative, 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
Ken Museth - OpenVDB Representative
Nick Porcino - Universal Scene Description Working Group Representative
Rachel Rose - Diversity & Inclusion 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 - Academy Software Foundation
Emily Olin - Academy Software Foundation
John Mertic - The Linux Foundation
Yarille Ortiz - The Linux Foundation

Other Attendees

Cory Ormand, Walt Disney Studios
Doug Walker, Autodesk/OCIO
Bill Ballew, Dreamworks
JT Nelson, Pasadena Open Source consortium / SoCal Blender group
Jim Geduldick, SpaceBoy Labs
Karen Ruggles, DeSales University / D&I WG
Jim Helman, MovieLabs
Lee Kerley, Apple
Lorna Dumba, Framestore
McCarten - WetaFX
Olga Avramenko - SPI - D&I WG

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
- Dev Days - September 25th #1134
Pull in TAC Overview into main TAC website #1151
Annual Review: Open Review Initiative #436
Establish structure for projects to distribute binaries #1157

Notes

General Updates
- Dev Days - September 25th #1134
- John: seemed like a lot of action?
- Carol: would like to hear any hot takes. Was busier than we thought it would be given low level of communication. Got PRs in projects we hadn’t gotten PRs for. No stats yet, still have PRs rolling in. There was a post event survey, not just for people who submitted PRs, but also for project leads and companies which participated. Use this to give us written feedback, what you would see next time, what you liked / didn’t like this time.
Pull in TAC Overview into main TAC website #1151
- Some minor edits from Eric Enderton
- John: any issues? Carol: haven’t looked at it yet, will approve in the next day
- John: we’ll merge it by end of week
Annual Review: Open Review Initiative #436
- Presentation Slide Deck
- Erik Strauss
Establish structure for projects to distribute binaries #1157
- John: Binary Distribution for LF Hosted Projects
- Typical release for a project is source code, that source code is integrated in downstream projects distributed in binary form.
- What is a binary distribution?
  - A binary distribution is a distribution of the code project of the project in a compiled, machine-readable form, that is designed for direct execution.
  - Examples:
    - .exe, .app, or .o file
    - Python wheel
  - Not considered a binary:
    - .rpm, .deb, .zip or .tar files
- Why a separate binary distribution entity?
  - You need binary distribution entities that have a EULA, legal separation from the developers (so you’re not in the path of liability if something goes wrong), a commercial legal entity that can transact with app stores and application certificate providers, and because software distribution direct to end users is far more complex than having a URL on GitHub
  - Generally, most open source projects do not distribute binaries directly, instead letting downstream vendors do so, mostly due to the above complexities
  - OSS licenses may not apply well to binaries, like the Apache 2 license grant a license to any patents in the source code, but doesn’t say anything about a binary blob. Eric: not sure I understand why the liability is greater when a binary is involved? John: the binary includes code that doesn’t come from the project, system libraries, code from other projects. So not just distributing the project code, the binary includes more. Eric: is that where the complexity comes from? John: when downloading from a commercial vendor, there’s a EULA involved. Carol: and that usually includes third party dependencies and disclaimers. John: which is different than an open source license. Also if distributing through an app store, there are potential certificate providers which adds levels of complexity. So you are adding “additional bits” which are outside the scope of what an open source project is typically set up to handle.
  - Carol: it’s not just an issue of liability, it’s also about a separation of concerns between different licenses, making things “above board”. I don’t anticipate a lot of problems. We need the proper licenses to cover the right things.
  - John: we want to put as little burden on projects as possible, we need to do setup on our side.
  - JF: aswf-docker is definitely affected. John: we need a separate legal entity to encapsulate those works. Want to make sure we have the right license. It’s not hard for LF to set up, but for projects we need to figure out how to scope this. We had done this for OTIO initially, but other projects potentially need to do this. Should we have an ASWF-wide one rather than per project entities. Would it make sense to have a general binary entity? LF recommendation is usually to have only one.
- Direct binary distribution process
  - If a project wishes to directly distribute binaries, the following MUST be put in place:
    - Establish a separate location where binaries will be distributed
      - MUST be separate from the project - different domain name, GitHub Org, web host, email address, etc
      - Binaries MUST NOT be distributed in the GitHub repo or other project-owned accounts / services
- EULA Template
  - No responsibility
  - List of licenses included in the binary
- Example - Zowe
- Distribution through other services
  - The binary entity MUST be used for distributing binaries through other services, such as PyPI, VS Code Marketplace, JetBrains MarketPlace, and more. Key considerations:
    - The account that owns the listing on the service MUST be owned by the binary entity
    - Any contact for the ownership account emails MUST go to the binary entity domain.
- Services requiring additional provisions for projects
  - Some services require additional provisions for projects
    - Apple Developer Program, used for distributing through the Apple App Store or providing signed binaries for macOS
    - Microsoft Hardware Program
- Establish a binary entity for distribution
  - It’s a best practice for distribution of binaries is to have a dedicated legal entity for such activities…
- Questions?
  - Should we have one or many entities? Michael Min: what are the “border walls” around responsibility? Do we disclaim everything? How does that funnel into the project? John: people can raise issues with the project directly? Micheal Min: would the binary point back to the project GitHub? How do we link back? John: I can follow up what’s the best way to redirect people back to the project.
  - Carol: I vote for a single entity for binaries, we already have a similar thing with PyPI, unless a specific project really needs something different if they ask for it. But the default should be for one.
  - Michael Johnson: a version of the review tools which got the ProRes SDK from Apple, has to be an entity that gets granted that right, can’t redistribute the sdk, but the binary. A binary distribution entity could sign for such an agreement? John: a binary distribution entity can sign for this without adding liability for the project.
- John: we will run an LFX vote, have been talking to OTIO, ORI. Erik: we can follow up offline. We want to identify subset of libraries compatible with our licenses, turning into a per platform matrix, we need to work with you to make sure we are doing this right.
Annual Review: Open Review Initiative #436
- Presentation Slides
- Erik Strauss - Annual Review for Open Review Initiative
  - A collection of individual projects that have similar aims and objectives to help review media in VFX and Animation
- TSC has grown: new representatives from WDAS, SPI, AWS, WDI
- Key achievements in the past year
  - 2025 deliverables
    - Spec for OTIO based annotation exchange / persistence
    - Demo of OTIO based live synced annotations between arbitrary players
    - A new website with all 6 projects and areas for demo videos etc
  - AWSF Project Collaboration
    - OpenAPV testing and cross collaboration
      - TWO ORI TSC members now OpenAPV TSC members
    - Cross-collab on ML-WG as first target is review based tooling and potential future RPA plugin candidate
- Key Achievements for OpenRV
  - Annotation improvements
    - New Hold & Ghost (Onion skinning)
    - Clear annotations on all frames
  - Graphics Capabilities
    - Native ProRes support for Apple Silicon Mac (Hardware decoding)
    - BMD SDI output for 47.95/48/120 fps
    - High-DPI displays
    - Canon raw 3 file type
  - Performance improvements
    - 18x faster playlist loading
    - Faster H2JTK
    - OCIOIPNode - 2x speedup
  - Misc
    - VFX Reference Platform CY2024
    - Qt6
    - Native Apple Silicon
    - XCode 16
- Contributions to OpenRV
  - Active contributors: 67
  - Forks: 63
  - Org contributors
    - Autodesk
    - Lots of others
  - 2064 commits
  - Issues resolution: avg 22 days
  - PR: 244
  - A very healthy project, lots of user engagement, discussion chat always very busy
  - Autodesk remains committed to OpenRV being the base for their commercial projects, which adds commercial codecs + support
  - Autodesk leveraging work on sync in other systems, sync between RV and web player in Flow.
- X-Studio Achievements
  - xSTUDIO v1.0.0 released!
    - Complete overhaul of UI
      - Switch to new UI middleware, caused public repo to be stale / out of sync for a few months
    - Multi-track timeline
      - Big differentiator with OpenRV
      - If your workflow is based around editorial style reviews, for instance WDAS where editors drive reviews, as opposed to being playlist oriented.
    - fully cross platform
    - refreshed user documentation
    - lots of new features
    - Many under-the-hood improvements
- Contributions to x-Studio
  - 29 active contributors
  - 27 forks
  - Most of the contributions from DNeg since this is a “brand new” project release, not that many commits to public repo, this will change going forward.
- Key achievements for Encoding
  - Fleshed out an editorial page, with a number of community contributions
  - Added pages for MJPEG, HEVC, AV1, VP9 and VP8 encoding
  - Created an HDR Encoding Guide
  - Created a whitepaper to encourage industry usage of VP8, VP9 and AV1 rather than HEVC
  - Profiled two new choses for Interframe codecs:
    - OpenAPV - Advanced Professional Video Codec
    - HTJ2K - JPEG2000 - High-Throughput JPEG2000
  - Project is mature and going well
  - Small contribution: 3 contributors, mostly Sam, but other contributors with knowledge of encoding.
  - Not that much code is being written here, mostly test suite and pages.
- Launch of RPA (Review Plugin API)
  - Official Release of the RPA project for the Shared Platform Repository
    - Shared plugin API
      - Multiple sample plugins inclusive of color correction, playlist management and more
  - The goal of RPA is to eventually build a community space with OSS plugins available to download and use
  - Useful for the broader ecosystem of users.
  - Still very nascent, 5 year goal would be to have a repository of plugins that could be downloaded and installed
  - A good place for the community to share their experience and workflows inside that ecosystem, and an opportunity to draw users and devs into this space. Both xStudio and OpenRV are complex pieces of software with a high barrier to entry for external contributions. We don’t really have a good place to take a first step to contribute to the community.
  - Launched at SIGGRAPH with a collection of sample plugins which describe how RPA works.
  - Contributions: 10 contributors, Sony, WDI
- Things that might happen next year
  - An open source drawing library added to the project
    - One of our contributor studios to work on a potential future contribution of a drawing library for review tools
  - Downloadable binaries for OpenRV and X-Studio
    - Need to test in a studio when you can’t built your own, even if limited on included codecs.
  - Extension of the OTIO based collaboration protocol
    - Interop offline and online
  - Becoming a real boy…
    - We need a TAC vote on moving us from sandbox status to incubation…
- Areas the project could use help on
  - Users still desperate for downloadable binaries
  - Licensing rights for 3rd party codecs continue to be the barrier to binary distributions
    - We are currently generating a bespoke per-OS matrix…
- Questions
  - Carol: are you happy to stay as an “umbrella” when moving to incubation? It made sense to have an umbrella project in a sandbox, but it’s something to think about when moving to incubation? Erik: we are likely under-represented in the TAC because of our umbrella nature, the conversation about centralizing vs de-centralizing is around the mission of the umbrella initiative. We want exchange and cross collaboration between projects. Do we think we have enough alignment between the projects to continue down that path. Will that continue if the projects “spin off”, or do we pull all the projects together “in the same room” still? Carol: we don’t have to answer this today, and it’s not either / or. I think ORI is amazing, sandbox nature lets you spin up new ideas. Maybe ORI continues to be a sandbox project, and we bump up xStudio / OpenRV as incubation projects? Erik: this is great feedback. Christopher: is there inspiration from USD WGs? One group with sub groups, lots of work to coordinate. Erik: there may be an opportunity to structure things along those lines, even if OpenRV / xStudio become their own separate projects? John: ML WG also arriving in that place. Carol: similar for OCIO.
  - Michael B Johnson: from public perspective, OpenRV has shown a lot of progress, whereas xStudio progressed differently. So from a public open source perspective, OpenRV seems “ready”, xStudio less? Erik: Autodesk is a commercial product company which knows how to build software, whereas DNeg is a VFX company (Michael: not a judgement!). Challenge to get “product mindset” for xStudio. Open Source Community can get you that help. Michael: so do you want to move the whole thing to the next level and keep them together? Carol: we should bring discussion to Slack before we bring it to a vote, or have another discussion at next TAC meeting. We can look at the different components in ORI and consider them for incubation. There is a lot of value to keeping them together, that’s been successful. The encoding project is great, but may not be a project on its own. We could also deal with this when projects are ready to graduate. Erik: will want to engage the individual TSCs to see how they feel about it. Encoding Guidelines is closer to DPEL to a software project for instance, even though it does have some code.

Next Meeting Agenda

General Updates
Annual Review: OpenAPV #803
Annual Review: Open Shading Language #437