Licensing issue with ffmpeg

[ozancaglayan]

Hello,

I see that whisper package is licensed with MIT. However, it uses ffmpeg under the hood, although it doesn't list it as a dependency (as its installation is system-dependent). Now ffmpeg is a complex package, some of it being licensed under GPL, other parts under LGPL. Does this invalidate the license of whisper? Is there an obstacle in replacing the use of ffmpeg with
torchaudio.load or librosa, or some other simpler alternatives?

Thanks!

[glangford]

License contamination is a complicated discussion, but here is one line of thinking.

• I don't know that torchaudio successfully evades (L)GPL since it uses ffmpeg as well; see
  https://github.com/pytorch/audio/releases
  and search for ffmpeg.

• whisper in its current form uses ffmpeg here via ffmpeg-python
  

  whisper/whisper/audio.py

  Line 22 in 9f70a35

  def load_audio(file: str, sr: int = SAMPLE_RATE):

  
  In this code is the comment
  # This launches a subprocess to decode audio while down-mixing and resampling as necessary.

As far as I know, the general consensus seems to be that this type of subprocess invocation preserves separation of components and avoids license contamination. See for example the discussion here:
https://www.ifross.org/?q=en/program-forks-gpl-licensed-program-system-or-vice-versa-call-derivative-work

Starting an application from another application and exchanging data between the calling and the called program via command line, files or pipes is a normal and established procedure. This happens, for example, nearly every time a program is started from the shell. If this procedure implied that the called program is assumed a derivative work of the calling program and the shell in use is licensed under the GPL such as the standard shell bash, it would no longer be possible to run a non-GPL application from shell level. This would not reflect the intention of the GPL and would contradict common practice accepted from the authors of the GPL over many years.