Legal ramifications of using proprietary_codecs

[MarshallOfSound]

I was wondering how the atom / electron team handle the legal issues regarding proprietary_codecs in chromium.

https://github.com/atom/libchromiumcontent/pull/69/files#diff-2544685f4860e4633fd5747ed88ec2caR6

As far as I am aware this flag tells chromium to build ffmpeg with support for things like H.264 and MP3 codecs. According to ffpmeg's own website the usage of this flag is a grey area at best and against patent laws at worst.

If a company decides to use electron to make a marketable product surely this flag being on by default leaves them open to potential legal issues due to codec licensing.

Can someone please confirm the legality around this flag in libchromiumcontent.

[felixrieseberg]

I heavily recommend consulting a lawyer for any legal questions you have - nobody will be able to provide proper legal advice that holds water.

However, keep in mind that in Electron, ffmpeg is statically linked (#69).

[MarshallOfSound]

@felixrieseberg Could you briefly explain what statically linked means?

[anaisbetts]

This comment seems to state the opposite:

This PR makes Chromium recognize proprietary formats and use the right codecs if they are available. This does not build proprietary codecs in ffmpeg.

[MarshallOfSound]

@paulcbetts I'm querying as to exactly how thats possible, all my other research into this seems to indicate that flag does build FFMPEG with those codecs.

MP3 support ends up in electron somehow, I'm just trying to find out how?

[anaisbetts]

@MarshallOfSound It probably uses the codecs built into the OS if they're available

[zcbenz]

We can't answer the question, we are not lawyers.

However since all possible legal problems are from ffmpeg, I think we can make Electron dynamically linked to it, so if you are concerned about the legal problems, you can just remove it or replace it with a custom build that you believe to be license-safe.

[lee-dohm]

To build libchromiumcontent we are using the same configuration of ffmpeg as Chrome, which is:

--disable-everything --disable-all --disable-doc --disable-htmlpages --disable-manpages --disable-podpages --disable-txtpages --disable-static --disable-valgrind-backtrace --enable-avcodec --enable-avformat --enable-avutil --enable-fft --enable-rdft --enable-static --disable-bzlib --disable-error-resilience --disable-iconv --disable-lzo --disable-network --disable-schannel --disable-sdl --disable-symver --disable-xlib --disable-zlib --disable-securetransport --disable-d3d11va --disable-dxva2 --disable-vaapi --disable-vda --disable-vdpau --disable-videotoolbox --enable-decoder=vorbis --enable-decoder='pcm_u8,pcm_s16le,pcm_s24le,pcm_s32le,pcm_f32le' --enable-decoder='pcm_s16be,pcm_s24be,pcm_mulaw,pcm_alaw' --enable-demuxer='ogg,matroska,wav' --enable-parser='opus,vorbis' --optflags='\0-O2\0' --enable-decoder='theora,vp8' --enable-parser='vp3,vp8' --enable-pic --enable-yasm --cc=clang --cxx=clang++ --arch=x86_64 --extra-cflags=-m64 --extra-ldflags=-m64 --enable-decoder='aac,h264,mp3' --enable-demuxer='aac,mp3,mov' --enable-parser='aac,h264,mpegaudio'

According to Chromium's documentation this results, at the time of this writing, in the following formats being supported:

Vorbis audio codec
Theora video codec
Opus audio codec
VP8 video codec
VP9 video codec
PCM 8-bit unsigned integer
PCM 16-bit signed integer little endian
PCM 32-bit float little endian
Ogg container format
WebM container format
WAV container format

MP3 audio codec
AAC audio codec (Main only, not AAC-LC, AAC-SSR, HE-AAC)
H.264 video codec
MP4 container format

As @zcbenz said, we can't give legal advice on what including these codecs or support for other formats means for your intended use, you'll have to consult your own legal experts to give you the most relevant information.

We hope that gives you enough information to start that conversation though 😀

[simongregory]

Alongside the media patent issues you should also consider that, with these flags enabled, libchromiumcontent uses the x264 library. x264 is only free under the GNU GPL, otherwise a commercial license is needed.

[simongregory]

Looks like I might well be wrong about the use of x264, I don't see --libx264 in the argument list provided by @lee-dohm and searching a checkout of libchromiumcontent only yields potentially related files with LGPL headers.

[bpasero]

@zcbenz would it be possible to get some pointers how you build official releases of Electron so that it becomes possible for consumers to revert the ffmpeg change and build our own flavor without it?

[zcbenz]

@bpasero You can find how official releases are built in cibuild: https://github.com/atom/electron/blob/v0.36.7/script/cibuild#L69-L72

However it is bit tricky on how to build Electron with a custom build of libchromiumcontent, you need to modify chromiumcontent/chromiumcontent.gypi for your needs first, and then do a rebuild of libchromiumcontent:

cd /path/to/libchromiumcontent
./script/bootstrap
./script/update
./script/build
./script/create-dist

And then make Electron bootstrap with your custom build of libchromiumcontent:

# Identify the commit of libchromiumcontent Electron is expecting, see electron/script/lib/config.py:11
LIBCHROMIUMCONTENT_COMMIT='451ea93cc3090f7000f8f0daa4cb84e90ad6c842'

cd /path/to/libchromiumcontent

# Use either win|linux|osx to reference the platform
mkdir -p osx/x64/$LIBCHROMIUMCONTENT_COMMIT
mv libchromiumcontent* osx/x64/$LIBCHROMIUMCONTENT_COMMIT

cd /path/to/electron

# Build with custom libchromiumcontent
./script/bootstrap.py -v -u file:///path/to/libchromiumcontent
./script/build.py -c R
./script/create-dist.py

[felixrieseberg]

We should probably document that stuff somewhere - I'll try to put together a little mini-doc.

[MarshallOfSound]

@zcbenz I am trying to follow those build instructions you posted but am stuck with this error during the libchromiumcontent build phase

[347/11756] OBJCXX obj/base/mac/base.sdk_forward_declarations.o
FAILED: ../../third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF obj/base/mac/base.sdk_forward_declarations.o.d -DU_COMBINED_IMPLEMENTATION -DUNISTR_FROM_CHAR_EXPLICIT= -DUNISTR_FROM_STRING_EXPLICIT= -DU_NO_DEFAULT_INCLUDE_UTF_HEADERS=0 -DV8_DEPRECATION_WARNINGS -DCLD_VERSION=2 -D__ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORE=0 -DDISABLE_NACL -DCHROMIUM_BUILD -DCR_CLANG_REVISION=247874-1 -DUSE_LIBJPEG_TURBO=1 -DENABLE_ONE_CLICK_SIGNIN -DENABLE_PRE_SYNC_BACKUP -DENABLE_WEBRTC=1 -DENABLE_MEDIA_ROUTER=1 -DENABLE_PEPPER_CDMS -DENABLE_CONFIGURATION_POLICY -DENABLE_NOTIFICATIONS -DENABLE_HIDPI=1 -DSYSTEM_NATIVELY_SIGNALS_MEMORY_PRESSURE -DDONT_EMBED_BUILD_METADATA -DFIELDTRIAL_TESTING_ENABLED -DENABLE_TASK_MANAGER=1 -DENABLE_EXTENSIONS=1 -DENABLE_PDF=1 -DENABLE_PLUGIN_INSTALLATION=1 -DENABLE_PLUGINS=1 -DENABLE_SESSION_SERVICE=1 -DENABLE_THEMES=1 -DENABLE_AUTOFILL_DIALOG=1 -DENABLE_BACKGROUND=1 -DENABLE_GOOGLE_NOW=1 -DENABLE_PRINTING=1 -DENABLE_BASIC_PRINTING=1 -DENABLE_PRINT_PREVIEW=1 -DENABLE_SPELLCHECK=1 -DUSE_BROWSER_SPELLCHECKER=1 -DENABLE_CAPTIVE_PORTAL_DETECTION=1 -DENABLE_APP_LIST=1 -DENABLE_SETTINGS_APP=1 -DENABLE_SUPERVISED_USERS=1 -DENABLE_SERVICE_DISCOVERY=1 -DENABLE_WIFI_BOOTSTRAPPING=1 -DV8_USE_EXTERNAL_STARTUP_DATA -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DSAFE_BROWSING_SERVICE -DUSE_LIBPCI=1 -DUSE_OPENSSL=1 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DBASE_IMPLEMENTATION -DSYSTEM_NATIVE_UTF8 -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -D_FORTIFY_SOURCE=2 -Igen -I../.. -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -O2 -gdwarf-2 -fvisibility=hidden -Werror -Wnewline-eof -mmacosx-version-min=10.8 -arch x86_64 -Wno-deprecated-declarations -Wall -Wendif-labels -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wno-selector-type-mismatch -Wpartial-availability -Wheader-hygiene -Wno-char-subscripts -Wno-unneeded-internal-declaration -Wno-covered-switch-default -Wstring-conversion -Wno-c++11-narrowing -Wno-deprecated-register -Wno-inconsistent-missing-override -Wno-shift-negative-value -Wno-bitfield-width -Wexit-time-destructors -std=c++11 -stdlib=libc++ -fno-rtti -fno-exceptions -fvisibility-inlines-hidden -fno-threadsafe-statics -Xclang -load -Xclang /Users/samuela/projects/custom-electron/libchromiumcontent/vendor/chromium/src/third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.dylib -Xclang -add-plugin -Xclang find-bad-constructs -Xclang -plugin-arg-find-bad-constructs -Xclang check-templates -fcolor-diagnostics -fno-strict-aliasing -Wobjc-missing-property-synthesis -fobjc-call-cxx-cdtors  -c ../../base/mac/sdk_forward_declarations.mm -o obj/base/mac/base.sdk_forward_declarations.o
In file included from ../../base/mac/sdk_forward_declarations.mm:5:
../../base/mac/sdk_forward_declarations.h:499:3: error: redefinition of enumerator 'NSPressureBehaviorUnknown'
  NSPressureBehaviorUnknown = -1,
  ^

Any ideas?

[zcbenz]

@MarshallOfSound It is probably because you are not using the correct OS X SDK. The prebuilt binaries are built with Xcode 6.4 and OS X 10.10 SDK.

[zcbenz]

This is what I'm going to do:

• Change the prebuilt binaries of Electron to link with ffmpeg dynamically;
• Provide prebuilt binaries of ffmpeg which do not include the codecs that have potential patent problems.

So for people care about patent issues, they can just download the prebuilt binaries of Electron, and then replace its ffmpeg library with the patent safe one.

[xstof]

@zcbnez for my understanding: would this mean we would be able to build or download Electron binaries without any dependencies on ffmpeg? (Removing the licensing concerns.)

What's the implication thereof - would you lose the ability to play back h.264 content? Any timelines on this please?

[dteirney]

I'm also interested in the solution proposed here to remove some concerns regarding patents for various codecs supported by FFmpeg. Our product isn't displaying any video or audio content so avoiding that whole area would be valuable for our commercial product.

[dteirney]

@zcbenz is the proposed solution to avoid patent concerns likely to be available in the next release of Electron?

[zcbenz]

The default prebuilt binaries of Electron will still include the possible proprietary codecs, but it will be very easy to replace the ffmpeg library with one that removes all proprietary codecs, which will also be provided by us.

It is hard to say whether the solution would be in next release, but I will put my focus on it.

[felixrieseberg]

@zcbenz: There's a bunch of interest from our legal team, too - we also don't really need any codecs and would rather avoid any concern. If there's anything I/we can do to help, let me know!

[johndeu]

To @xstof comment, @zcbenz Would the version of Electron without FFmpeg binaries and proprietary codecs be capable of picking up OS distributed codecs for playback - or does this essentially break all video decoding support for H.264 and AAC in an Electron application without distributing a custom version of FFMPEG library with licensed codecs.

[zcbenz]

@johndeu It is possible by replacing the backend of Chromium's media system with OS's codecs, and it would be huge work, only Chromium team may have the resources to do this but I'm sure they are not interested.

[bpasero]

@zcbenz are you building all Electron releases for all platforms from one machine? Or do you need to have the matching platform for the target release?

[zcbenz]

@bpasero We have 3 machines for building Electron, they are Windows, Linux and OS X.

[IlyaBiryukov]

@zcbenz The chromiumcontent.gypi still has these lines:

     # Enalbe using proprietary codecs.
      'proprietary_codecs': 1,

Does this mean that by default proprietary codecs are still included into ffmpeg.dll?
If so, how can they be excluded? Does that mean we should not ship ffmpeg binary along with Electron to avoid having these codecs?

[zcbenz]

@IlyaBiryukov The codecs shipped with ffmpeg is decided by ffmpeg_branding, the proprietary_codecs only tells Chromium to recognize those codecs.

[nhurde]

What is the current state of FFmpeg in Electron now?