Skip to content

Commit ca1712c

Browse files
authored
2025-10-01 TAC meeting notes (#1172)
Signed-off-by: Jean-Francois Panisset <[email protected]>
1 parent 47e13be commit ca1712c

File tree

2 files changed

+270
-0
lines changed

2 files changed

+270
-0
lines changed

meetings/2025-10-01/2025-10-01.md

Lines changed: 270 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,270 @@
1+
---
2+
parent: Meetings
3+
title: "2025-10-01"
4+
---
5+
6+
# Academy Software Foundation Technical Advisory Council (TAC) Meeting - October 1st, 2025
7+
8+
Join the meeting at [https://zoom-lfx.platform.linuxfoundation.org/meeting/97880950229?password=81d2940e-c055-43b9-9b5a-6cd7d7090feb](https://zoom-lfx.platform.linuxfoundation.org/meeting/97880950229?password=81d2940e-c055-43b9-9b5a-6cd7d7090feb)
9+
10+
## Voting Representative Attendees
11+
12+
### Premier Member Representatives
13+
14+
- [x] Andy Jones - Netflix, Inc.
15+
- [ ] Chris Hall - Advanced Micro Devices (AMD)
16+
- [x] Christopher Moore - Skydance Animation, LLC
17+
- [x] Eric Enderton - NVIDIA Corporation
18+
- [ ] Erik Niemeyer - Intel Corporation
19+
- [ ] Gordon Bradley - Autodesk
20+
- [ ] Greg Denton - Microsoft Corporation
21+
- [x] Jean-Michel Dignard - Epic Games, Inc
22+
- [ ] Jonathan Gerber - LAIKA, LLC
23+
- [x] Kimball Thurston - Wētā FX Limited
24+
- [ ] Larry Gritz - Sony Pictures Imageworks
25+
- [x] Matthew Low - DreamWorks Animation
26+
- [x] Michael Min - Adobe Inc.
27+
- [x] Michael B. Johnson - Apple Inc.
28+
- [ ] Rebecca Bever - Walt Disney Animation Studios
29+
- [ ] Ross Dickson - Amazon Web Services, Inc.
30+
- [x] Scott Dyer - Academy of Motion Picture Arts and Sciences
31+
- [ ] Youngkwon Lim - Samsung Electronics Co. Ltd.
32+
33+
### Project Representatives
34+
35+
- [x] Carol Payne - Diversity & Inclusion Working Group Representative, OpenColorIO Representative
36+
- [ ] Cary Phillips - OpenEXR Representative
37+
- [x] Chris Kulla - Open Shading Language Representative
38+
- [ ] Daniel Greenstein - OpenImageIO Representative
39+
- [ ] Diego Tavares Da Silva - OpenCue Representative
40+
- [ ] Jonathan Stone - MaterialX Representative
41+
- [x] Ken Museth - OpenVDB Representative
42+
- [ ] Nick Porcino - Universal Scene Description Working Group Representative
43+
- [ ] Rachel Rose - Diversity & Inclusion Working Group Representative
44+
45+
### Industry Representatives
46+
47+
- [x] Jean-Francois Panisset - Visual Effects Society
48+
49+
## Non-Voting Attendees
50+
51+
### Non-Voting Project and Working Group Representatives
52+
53+
- [ ] Alexander Schwank - Universal Scene Description Working Group Representative
54+
- [x] Anton Dukhovnikov - rawtoaces Representative
55+
- [ ] Daryll Strauss - Zero Trust Working Group Representative
56+
- [ ] David Feltell - OpenAssetIO Representative
57+
- [ ] Eric Reinecke - OpenTimelineIO Representative
58+
- [x] Erik Strauss - Open Review Initiative Representative
59+
- [x] Gary Oberbrunner - OpenFX Representative
60+
- [ ] Jean-Christophe Morin - Rez Representative
61+
- [ ] John Mccarten - Rongotai Model Train Club (RMTC) Representative
62+
- [ ] Josh Bainbridge - OpenQMC Representative
63+
- [x] Stephen Mackenzie - Rez Representative
64+
- [x] Tommy Burnette - Dailies Notes Assistant Representative
65+
66+
### LF Staff
67+
68+
- [x] David Morin - Academy Software Foundation
69+
- [x] Emily Olin - Academy Software Foundation
70+
- [x] John Mertic - The Linux Foundation
71+
- [x] Yarille Ortiz - The Linux Foundation
72+
73+
### Other Attendees
74+
75+
- Cory Ormand, Walt Disney Studios
76+
- Doug Walker, Autodesk/OCIO
77+
- Bill Ballew, Dreamworks
78+
- JT Nelson, Pasadena Open Source consortium / SoCal Blender group
79+
- Jim Geduldick, SpaceBoy Labs
80+
- Karen Ruggles, DeSales University / D&I WG
81+
- Jim Helman, MovieLabs
82+
- Lee Kerley, Apple
83+
- Lorna Dumba, Framestore
84+
- McCarten - WetaFX
85+
- Olga Avramenko - SPI - D&I WG
86+
87+
## Antitrust Policy Notice
88+
89+
Linux Foundation meetings involve participation by industry competitors, and it
90+
is the intention of the Linux Foundation to conduct all of its activities in
91+
accordance with applicable antitrust and competition laws. It is therefore
92+
extremely important that attendees adhere to meeting agendas, and be aware of,
93+
and not participate in, any activities that are prohibited under applicable US
94+
state, federal or foreign antitrust and competition laws.
95+
96+
Examples of types of actions that are prohibited at Linux Foundation meetings
97+
and in connection with Linux Foundation activities are described in the Linux
98+
Foundation Antitrust Policy available at
99+
[linuxfoundation.org/antitrust-policy](https://www.linuxfoundation.org/antitrust-policy).
100+
If you have questions about these matters, please contact your company counsel,
101+
or if you are a member of the Linux Foundation, feel free to contact Andrew
102+
Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to
103+
the Linux Foundation.
104+
105+
## Agenda
106+
107+
- General Updates
108+
- Dev Days - September 25th [#1134](https://github.com/AcademySoftwareFoundation/tac/issues/1134)
109+
- Pull in TAC Overview into main TAC website [#1151](https://github.com/AcademySoftwareFoundation/tac/pull/1151)
110+
- Annual Review: Open Review Initiative [#436](https://github.com/AcademySoftwareFoundation/tac/issues/436)
111+
- Establish structure for projects to distribute binaries [#1157](https://github.com/AcademySoftwareFoundation/tac/issues/1157)
112+
113+
## Notes
114+
115+
- General Updates
116+
- Dev Days - September 25th [#1134](https://github.com/AcademySoftwareFoundation/tac/issues/1134)
117+
- John: seemed like a lot of action?
118+
- 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.
119+
120+
- Pull in TAC Overview into main TAC website [#1151](https://github.com/AcademySoftwareFoundation/tac/pull/1151)
121+
- Some minor edits from Eric Enderton
122+
- John: any issues? Carol: haven't looked at it yet, will approve in the next day
123+
- John: we'll merge it by end of week
124+
- Annual Review: Open Review Initiative [#436](https://github.com/AcademySoftwareFoundation/tac/issues/436)
125+
- [Presentation Slide Deck](./ORI_2025_Annual_Review_v1.pdf)
126+
- Erik Strauss
127+
- Establish structure for projects to distribute binaries [#1157](https://github.com/AcademySoftwareFoundation/tac/issues/1157)
128+
- John: Binary Distribution for LF Hosted Projects
129+
- Typical release for a project is source code, that source code is integrated in downstream projects distributed in binary form.
130+
- What is a binary distribution?
131+
- 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.
132+
- Examples:
133+
- .exe, .app, or .o file
134+
- Python wheel
135+
- Not considered a binary:
136+
- .rpm, .deb, .zip or .tar files
137+
- Why a separate binary distribution entity?
138+
- 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
139+
- Generally, most open source projects do not distribute binaries directly, instead letting downstream vendors do so, mostly due to the above complexities
140+
- 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.
141+
- 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.
142+
- John: we want to put as little burden on projects as possible, we need to do setup on our side.
143+
- 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.
144+
- Direct binary distribution process
145+
- If a project wishes to directly distribute binaries, the following MUST be put in place:
146+
- Establish a separate location where binaries will be distributed
147+
- MUST be separate from the project - different domain name, GitHub Org, web host, email address, etc
148+
- Binaries MUST NOT be distributed in the GitHub repo or other project-owned accounts / services
149+
- EULA Template
150+
- No responsibility
151+
- List of licenses included in the binary
152+
- Example - Zowe
153+
- Distribution through other services
154+
- The binary entity MUST be used for distributing binaries through other services, such as PyPI, VS Code Marketplace, JetBrains MarketPlace, and more. Key considerations:
155+
- The account that owns the listing on the service MUST be owned by the binary entity
156+
- Any contact for the ownership account emails MUST go to the binary entity domain.
157+
- Services requiring additional provisions for projects
158+
- Some services require additional provisions for projects
159+
- Apple Developer Program, used for distributing through the Apple App Store or providing signed binaries for macOS
160+
- Microsoft Hardware Program
161+
- Establish a binary entity for distribution
162+
- It's a best practice for distribution of binaries is to have a dedicated legal entity for such activities...
163+
- Questions?
164+
- 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.
165+
- 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.
166+
- 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.
167+
- 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.
168+
169+
- Annual Review: Open Review Initiative [#436](https://github.com/AcademySoftwareFoundation/tac/issues/436)
170+
- [Presentation Slides](./ORI_2025_Annual_Review_v1.pdf)
171+
- Erik Strauss - Annual Review for Open Review Initiative
172+
- A collection of individual projects that have similar aims and objectives to help review media in VFX and Animation
173+
- TSC has grown: new representatives from WDAS, SPI, AWS, WDI
174+
- Key achievements in the past year
175+
- 2025 deliverables
176+
- Spec for OTIO based annotation exchange / persistence
177+
- Demo of OTIO based live synced annotations between arbitrary players
178+
- A new website with all 6 projects and areas for demo videos etc
179+
- AWSF Project Collaboration
180+
- OpenAPV testing and cross collaboration
181+
- TWO ORI TSC members now OpenAPV TSC members
182+
- Cross-collab on ML-WG as first target is review based tooling and potential future RPA plugin candidate
183+
- Key Achievements for OpenRV
184+
- Annotation improvements
185+
- New Hold & Ghost (Onion skinning)
186+
- Clear annotations on all frames
187+
- Graphics Capabilities
188+
- Native ProRes support for Apple Silicon Mac (Hardware decoding)
189+
- BMD SDI output for 47.95/48/120 fps
190+
- High-DPI displays
191+
- Canon raw 3 file type
192+
- Performance improvements
193+
- 18x faster playlist loading
194+
- Faster H2JTK
195+
- OCIOIPNode - 2x speedup
196+
- Misc
197+
- VFX Reference Platform CY2024
198+
- Qt6
199+
- Native Apple Silicon
200+
- XCode 16
201+
- Contributions to OpenRV
202+
- Active contributors: 67
203+
- Forks: 63
204+
- Org contributors
205+
- Autodesk
206+
- Lots of others
207+
- 2064 commits
208+
- Issues resolution: avg 22 days
209+
- PR: 244
210+
- A very healthy project, lots of user engagement, discussion chat always very busy
211+
- Autodesk remains committed to OpenRV being the base for their commercial projects, which adds commercial codecs + support
212+
- Autodesk leveraging work on sync in other systems, sync between RV and web player in Flow.
213+
- X-Studio Achievements
214+
- xSTUDIO v1.0.0 released!
215+
- Complete overhaul of UI
216+
- Switch to new UI middleware, caused public repo to be stale / out of sync for a few months
217+
- Multi-track timeline
218+
- Big differentiator with OpenRV
219+
- If your workflow is based around editorial style reviews, for instance WDAS where editors drive reviews, as opposed to being playlist oriented.
220+
- fully cross platform
221+
- refreshed user documentation
222+
- lots of new features
223+
- Many under-the-hood improvements
224+
- Contributions to x-Studio
225+
- 29 active contributors
226+
- 27 forks
227+
- 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.
228+
- Key achievements for Encoding
229+
- Fleshed out an editorial page, with a number of community contributions
230+
- Added pages for MJPEG, HEVC, AV1, VP9 and VP8 encoding
231+
- Created an HDR Encoding Guide
232+
- Created a whitepaper to encourage industry usage of VP8, VP9 and AV1 rather than HEVC
233+
- Profiled two new choses for Interframe codecs:
234+
- OpenAPV - Advanced Professional Video Codec
235+
- HTJ2K - JPEG2000 - High-Throughput JPEG2000
236+
- Project is mature and going well
237+
- Small contribution: 3 contributors, mostly Sam, but other contributors with knowledge of encoding.
238+
- Not that much code is being written here, mostly test suite and pages.
239+
- Launch of RPA (Review Plugin API)
240+
- Official Release of the RPA project for the Shared Platform Repository
241+
- Shared plugin API
242+
- Multiple sample plugins inclusive of color correction, playlist management and more
243+
- The goal of RPA is to eventually build a community space with OSS plugins available to download and use
244+
- Useful for the broader ecosystem of users.
245+
- Still very nascent, 5 year goal would be to have a repository of plugins that could be downloaded and installed
246+
- 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.
247+
- Launched at SIGGRAPH with a collection of sample plugins which describe how RPA works.
248+
- Contributions: 10 contributors, Sony, WDI
249+
- Things that might happen next year
250+
- An open source drawing library added to the project
251+
- One of our contributor studios to work on a potential future contribution of a drawing library for review tools
252+
- Downloadable binaries for OpenRV and X-Studio
253+
- Need to test in a studio when you can't built your own, even if limited on included codecs.
254+
- Extension of the OTIO based collaboration protocol
255+
- Interop offline and online
256+
- Becoming a real boy...
257+
- We need a TAC vote on moving us from sandbox status to incubation...
258+
- Areas the project could use help on
259+
- Users still desperate for downloadable binaries
260+
- Licensing rights for 3rd party codecs continue to be the barrier to binary distributions
261+
- We are currently generating a bespoke per-OS matrix...
262+
- Questions
263+
- 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.
264+
- 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.
265+
266+
## Next Meeting Agenda
267+
268+
- General Updates
269+
- Annual Review: OpenAPV [#803](https://github.com/AcademySoftwareFoundation/tac/issues/803)
270+
- Annual Review: Open Shading Language [#437](https://github.com/AcademySoftwareFoundation/tac/issues/437)
2.47 MB
Binary file not shown.

0 commit comments

Comments
 (0)