License issue

[Colerar]

I am not a lawyer or an ardent supporter of the GNU project. However, I would like to bring to your attention the following concern:

This fork incorporates some dependencies licensed under the GPL, which makes distributing it under the BSD-3 license a potential violation of the GPL license.

For instance, both x264 and x265 are distributed under GPLv2.

A possible solution to this issue could involve allowing users to select which encoders to enable through compile options, similar to the approach taken by FFmpeg.

[arch1t3cht]

I'm not sure which exact dependencies you mean here (or which way of distribution) - x264 and x265 aren't used as direct dependencies anywhere, and are not linked into ffmpeg on Windows builds, partly for that exact reason. One GPL-licensed library that is a direct dependency of Aegisub is FFTW, but that is already an optional dependency that can be enabled through compile options and is not linked in by default.

Also, by "This fork incorporates", do you mean that these license issues were introduced by this fork, or that they're issues carried over from upstream (either Aegisub/Aegisub or TypesettingTools/Aegisub)?

[Colerar]

1

I'm not sure which exact dependencies you mean here (or which way of distribution) - x264 and x265 aren't used as direct dependencies anywhere, and are not linked into ffmpeg on Windows builds, partly for that exact reason.

The macOS application downloaded from the release dynamically links x264, x265, etc. with the Aegisub binary.

Tree-view of Aegisub.app

```plaintext Aegisub.app └── Contents ├── Info.plist ├── MacOS │ ├── aegisub │ ├── libaom.3.5.0.dylib │ ├── libaom.3.dylib ⇒ libaom.3.5.0.dylib │ ├── libaribb24.0.dylib │ ├── libass.9.dylib │ ├── libavcodec.59.37.100.dylib │ ├── libavcodec.59.dylib ⇒ libavcodec.59.37.100.dylib │ ├── libavformat.59.27.100.dylib │ ├── libavformat.59.dylib ⇒ libavformat.59.27.100.dylib │ ├── libavutil.57.28.100.dylib │ ├── libavutil.57.dylib ⇒ libavutil.57.28.100.dylib │ ├── libbluray.2.dylib │ ├── libbrotlicommon.1.0.9.dylib │ ├── libbrotlicommon.1.dylib ⇒ libbrotlicommon.1.0.9.dylib │ ├── libbrotlidec.1.0.9.dylib │ ├── libbrotlidec.1.dylib ⇒ libbrotlidec.1.0.9.dylib │ ├── libbrotlienc.1.0.9.dylib │ ├── libbrotlienc.1.dylib ⇒ libbrotlienc.1.0.9.dylib │ ├── libcjson.1.7.15.dylib │ ├── libcjson.1.dylib ⇒ libcjson.1.7.15.dylib │ ├── libcrypto.1.1.dylib │ ├── libdav1d.6.dylib │ ├── libffms2.4.dylib │ ├── libfftw3.3.dylib │ ├── libFLAC.12.dylib │ ├── libfontconfig.1.dylib │ ├── libfreetype.6.dylib │ ├── libfribidi.0.dylib │ ├── libglib-2.0.0.dylib │ ├── libgmp.10.dylib │ ├── libgnutls.30.dylib │ ├── libgraphite2.3.2.1.dylib │ ├── libgraphite2.3.dylib ⇒ libgraphite2.3.2.1.dylib │ ├── libharfbuzz.0.dylib │ ├── libhogweed.6.6.dylib │ ├── libhogweed.6.dylib ⇒ libhogweed.6.6.dylib │ ├── libhunspell-1.7.0.dylib │ ├── libhwy.1.0.3.dylib │ ├── libhwy.1.dylib ⇒ libhwy.1.0.3.dylib │ ├── libidn2.0.dylib │ ├── libintl.8.dylib │ ├── libjxl.0.8.0.dylib │ ├── libjxl.0.8.dylib ⇒ libjxl.0.8.0.dylib │ ├── liblzma.5.dylib │ ├── libmbedcrypto.13.dylib ⇒ libmbedcrypto.3.3.0.dylib │ ├── libmbedcrypto.3.3.0.dylib │ ├── libmp3lame.0.dylib │ ├── libmpg123.0.dylib │ ├── libnettle.8.6.dylib │ ├── libnettle.8.dylib ⇒ libnettle.8.6.dylib │ ├── libogg.0.dylib │ ├── libopencore-amrnb.0.dylib │ ├── libopencore-amrwb.0.dylib │ ├── libopenjp2.2.5.0.dylib │ ├── libopenjp2.7.dylib ⇒ libopenjp2.2.5.0.dylib │ ├── libopus.0.dylib │ ├── libp11-kit.0.dylib │ ├── libpcre2-8.0.dylib │ ├── libpng16.16.dylib │ ├── libpulse.0.dylib │ ├── libpulsecommon-14.2.dylib │ ├── librav1e.0.6.3.dylib │ ├── librav1e.0.6.dylib ⇒ librav1e.0.6.3.dylib │ ├── librist.4.dylib │ ├── libsharpyuv.0.dylib │ ├── libsnappy.1.1.9.dylib │ ├── libsnappy.1.dylib ⇒ libsnappy.1.1.9.dylib │ ├── libsndfile.1.dylib │ ├── libsodium.23.dylib │ ├── libsoxr.0.1.2.dylib │ ├── libsoxr.0.dylib ⇒ libsoxr.0.1.2.dylib │ ├── libspeex.1.dylib │ ├── libsrt.1.5.1.dylib │ ├── libsrt.1.5.dylib ⇒ libsrt.1.5.1.dylib │ ├── libssl.1.1.dylib │ ├── libSvtAv1Enc.1.4.1.dylib │ ├── libSvtAv1Enc.1.dylib ⇒ libSvtAv1Enc.1.4.1.dylib │ ├── libswresample.4.7.100.dylib │ ├── libswresample.4.dylib ⇒ libswresample.4.7.100.dylib │ ├── libswscale.6.7.100.dylib │ ├── libswscale.6.dylib ⇒ libswscale.6.7.100.dylib │ ├── libtasn1.6.dylib │ ├── libtheoradec.1.dylib │ ├── libtheoraenc.1.dylib │ ├── libunibreak.5.dylib │ ├── libunistring.5.dylib │ ├── libvmaf.1.dylib │ ├── libvorbis.0.dylib │ ├── libvorbisenc.2.dylib │ ├── libvpx.7.dylib │ ├── libwebp.7.dylib │ ├── libwebpmux.3.dylib │ ├── libX11.6.dylib │ ├── libx264.164.dylib │ ├── libx265.199.dylib │ ├── libXau.6.0.0.dylib │ ├── libXau.6.dylib ⇒ libXau.6.0.0.dylib │ ├── libxcb.1.1.0.dylib │ ├── libxcb.1.dylib ⇒ libxcb.1.1.0.dylib │ ├── libXdmcp.6.dylib │ └── libzmq.5.dylib ├── Resources │ ├── ... └── SharedSupport ├── automation └── dictionaries ```

And in the Windows portable, the AviSynth library are linked with Aegisub.

Tree-view of aegisub-portable

```plaintext aegisub-portable ├── aegisub.exe ├── automation │ ├── autoload │ ├── demos │ └── include ├── AviSynth.dll ├── config.json ├── csri │ └── VSFilter.dll ├── DevIL.dll ├── DirectShowSource.dll ├── locale │ ├── ... └── Microsoft.CRT └── VC_redist.x64.exe ```

For your information, the AviSynth wiki says:

AviSynth is free open-source software, and licensed under the GNU General Public License GPLv2.

This also applies to VSFilter (VSFilter.dll).

2

Also, by "This fork incorporates", do you mean that these license issues were introduced by this fork, or that they're issues carried over from upstream (either Aegisub/Aegisub or TypesettingTools/Aegisub)?

I am not sure. It is possible that either TypesettingTools/Aegisub or even Aegisub/Aegisub may have violated the terms of the GPL.

Additionally, the xy-vsfilter-aegisub64.dll file is included with the Aegisub binary from the Aegisub/Aegisub builds. However, the Aegisub/Aegisub source states the following:

The Aegisub installer includes some files not built as part of Aegisub (such as Avisynth and VSFilter), so for a fully functional copy of Aegisub you now need to copy all of the files from an installed copy of Aegisub into your bin directory ...

---

License issues are complex, and my purpose is not to ask anyone what to do. Feel free to close this issue.

[TheOneric]

IANAL, etc...

Every typical Aegisub build includes GPL components and this is not specific to arch1t3cht/Aegisub. For TypesettingTools/Aegisub, I commented on this before here (see for more details on non-BSD bits). Notably, even in Aegisub’s very own source, CSRI (in practice used only in Windows builds nowadays; RIP asa) code contains GPL licenced files.

However, besides README’s claim that “All files in this repository are licensed under various GPL-compatible BSD-style licenses” and the self-description as “BSD_style licenses” being inaccurate (for Windows builds) it is not obvious to me why GPL bits being contained in or linked to from the builds should be problematic. Afaict all directly involved licences are GPL-compatible so the resulting binary is effectively GPL-licenced (and more precisely GPL(v2+|v3) AND ... where all following conditions are a subset of GPL). README also already points this out: “The official Windows and OS X builds are GPLv2 due to including fftw3.” (although there’s more than just fftw). And iirc the Windows installer also again refers to the GPLv2.

Problems could arise if:

• a --enable-nonfree ffmpeg builds (e.g. with libfdk_aac) gets bundled with published binaries (it’s not GPL-compatible)
• some deps or optional-but-bundled libraries are GPLv2-only and others GPLv3-only (haven't checked)
  • even if it’s just GPLv2-or-later and some GPLv3-(only|or-later) the Windows installer and README should be updated to refer to GPLv3 instead of GPLv2.

• published binaries do not contain a copy of the licences which require redistribution of licence text (e.g. GPL) or do not honour the attribution of all copyright holders (affects almost all licences; haven't checked if applies)

  @Colerar, does any of those problems apply or do you see something else which is problematic?