Legal issues in shipping apps based on Electron framework (libffmpeg)

Question

We're in the process of building and deploying a desktop based app on electron v 12.0.7. It'll be a (free) commercial software deployed to ~2-3M users worldwide. Recently our legal team enquired about the proprietary codecs bundled with chromium and I thought the best way to confirm this would be to reach out here.

So, here're specific things that I need help with:

1. Are we shipping chromium with proprietary codecs? If yes, what are potentially contentious codecs that come by default in chromium bundled with electron v 12.0.7?

2. Is there any documentation around how the electron team builds chromium (with what flags)?

3. Is the default libffmpeg.dylib/dll bundled with electron building ffmpeg with support for things like H.264 and MP3 codecs?

4. I noticed there are libffmpeg binaries available with each electron build, e.g. https://github.com/electron/electron/releases/download/v12.0.7/ffmpeg-v12.0.7-darwin-arm64.zip . What's the purpose of this binary?

Any help would be appreciated.

Answer 1

Ok, it took a while to plummet through all the information out there. I started wth https://github.com/electron/libchromiumcontent/issues/174#issuecomment-184187254 and ended up on electron's discord server talking with multiple folks from electron team. I'm collating my findings here so that it may save some time for someone. Here're what I found out. Any corrections/edits are more than welcome so that the information presented here is correct.

1. Are we shipping chromium with proprietary codecs? If yes, what are potentially contentious codecs that come by default in chromium bundled with electron v 12.0.7?

YES. At least on OSX, the libffmpeg.dylib that comes by default with electron contains exported symbols (for proprietary decoders) for AAC and H264. So, they remain in the realm of non-royalty-free software. I think legal advice is required here if you're planning to ship your application commercially(using default electron + libffmpeg.dylib)

e.g. List of exported decoders from the dylib can be viewed using the following command:

nm -gU /Applications/{your-app-name}.app/Contents/Frameworks/Electron\ Framework.framework/Versions/A/Libraries/libffmpeg.dylib | grep 'decoder'

I wrote a simple python script to look at any electron-based app, and print list of decoders available inside libffmpeg (bundled inside an electron based app). Sample output from my script: (My app is built with electron v 12.0.7)

Decoders available/exported from libffmpeg.dylib: ['aac', 'aac-latm', 'flac', 'h264', 'libopus', 'mp3', 'pcm-alaw', 'pcm-f32le', 'pcm-mulaw', 'pcm-s16be', 'pcm-s16le', 'pcm-s24be', 'pcm-s24le', 'pcm-s32le', 'pcm-u8', 'theora', 'vorbis', 'vp3', 'vp8']

So defintely we have aac and h264 decoders (non-royalty-free-software) going out by default with our electron-based application. To the best I know, these could lead to possible patent-infringement issues.

2. Is there any documentation around how the electron team builds chromium (with what flags)?

I couldn't find any conclusive documents but https://github.com/electron/electron/blob/58c58c46c4e03c996983a0c71163e1a5efed12fa/build/args/all.gn hints that by default proprietary_codecs is set to true in electron's build

3. Is the default libffmpeg.dylib/dll bundled with electron building ffmpeg with support for things like H.264 and MP3 codecs?

It certainly looks to be the case (based on above)

4. I noticed there are libffmpeg binaries available with each electron build, e.g. https://github.com/electron/electron/releases/download/v12.0.7/ffmpeg-v12.0.7-darwin-arm64.zip . What's the purpose of this binary?

If you care about shipping royalty free binaries and not deal with patent issues, this is what probably you should use (unless you chose to build whole electron by yourself tweaking gn args).

A quick check of these ffmpeg.dylib reveal that AAC and H264 decoders are not present(or atleast it doesn't have exported symbols for them). So it leads me to believe that these custom versions of dylib are built by electron team keeping this in mind. Using same script this is the output for list of decoders available in custom version of libffmpeg

Decoders available/exported from libffmpeg.dylib: ['flac', 'libopus', 'mp3', 'pcm-alaw', 'pcm-f32le', 'pcm-mulaw', 'pcm-s16be', 'pcm-s16le', 'pcm-s24be', 'pcm-s24le', 'pcm-s32le', 'pcm-u8', 'theora', 'vorbis', 'vp3', 'vp8']

So this is the difference between two versions of dylib (left one is downloaded from electron site, right one is what comes by default with electron) It also appears that this problem was already identified and we have a plugin for electron-packager that does all the heavy-lifting for you: https://github.com/MarshallOfSound/electron-packager-plugin-non-proprietary-codecs-ffmpeg

Since we din't use electron-packager (but electron-builder), i had to resort to put this logic of replacing libffmpeg in afterPackHook : https://www.electron.build/configuration/configuration#afterpack

Important step to remember is that: this replacement needs to be done before we code-sign the whole app (or it breaks the code-sign integrity).

Hope it helps someone else going through the same problem. Cheers!