Clarify third-party licenses and license Windows builds under GPL due to `mutagen`

Checklist

• I’m reporting a broken site support issue
• I’ve verified that I’m running yt-dlp version 2021.05.20
• I’ve checked that all provided URLs are alive and playable in a browser
• I’ve checked that all URLs and arguments with special characters are properly quoted or escaped
• I’ve searched the bugtracker for similar bug reports including closed ones
• I’ve read bugs section in FAQ

Verbose log

N/A

Description

As I was reading the README, I noticed this line:

Although there are no other required dependencies, ffmpeg and ffprobe are highly recommended. Other optional dependencies are sponskrub, AtomicParsley, mutagen, pycryptodome, phantomjs and any of the supported external downloaders. Note that the windows releases are already built with the python interpreter, mutagen and pycryptodome included.

I decided to check the licenses for each project, and got:

• ffmpeg (and ffprobe): LGPLv2.1 or later / GPLv2 or later / non-free, depending on the build
• sponskrub: GPLv3 or later
• AtomicParsley: GPLv2 or later
• mutagen: GPLv2 or later
• pycryptodome: BSD 2-Clause (with some code in the public domain via Unlicense)
• phantomjs: BSD 3-Clause

First of all, I recommend that we include a line stating that these optional dependencies may be distributed under different license terms than yt-dlp, and so, using them and/or redistributing them will require you to follow their specific licenses:

An example:

Each optional dependency may be licensed under different terms than yt-dlp. If you choose to use these optional dependencies, you must agree to their license terms. Please refer to each dependency’s repository or README file for more information.

Additionally, if you wish to redistribute yt-dlp with any of these optional dependencies included, you must ensure that you follow all of your dependencies’ license terms, such as distributing the whole software under the terms of the GPL if you link to a GPL library.

Additionally, because of this line pertaining to the Windows builds:

Note that the windows releases are already built with the python interpreter, mutagen and pycryptodome included.

I believe that the Windows builds now fall under the terms of the GPL since mutagen is licensed under the GPLv2 and we include it in the final binary, as well as using it in the code.

Additionally, we should include both a LICENSE file containing the text of the GPLv2 license (because of mutagen) and a THIRD-PARTY-NOTICES file or similar that includes the text of the license for pycryptodome and for Python itself since we embed the interpreter into the executable.

PSF License and license stack: https://docs.python.org/3/license.html FAQ on bundling Python: https://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq

If I bundle Python with my application, what do I need to include in my software and/or printed documentation?

You must retain all copyright notices found in the code you are redistributing and include a copy of the PSF License and all of the other licenses in the Python “license stack” with the software distribution. The “license stack” is a result of the history of Python’s development as described here (this page also lists all licenses in the stack).

Separate from the issue of copyright, the name “Python” is also a trademark. You should include the notice ““Python” is a registered trademark of the Python Software Foundation” in the appropriate part of your documentation or About box and place the “®” symbol after the first mention of “Python” in your documentation. (For example: “Python® is used as the scripting language for…”)

I’m not sure whether yt-dlp as a whole needs to be licensed under the GPL since it’s not exactly clear what constitutes as “linking” and therefore making a “combined work”, but I’d (personally) lean on the side of “no” since we disable the relevant features if the dependency is not present. The way we use some of these libraries isn’t exactly deeply linking into them, but that’s up for debate and out of the scope of this issue.

Though, I do finally suggest that we remove mutagen and pycryptodome from requirements.txt or at least make them an optional dependency under another package like yt-dlp[full] or something which is listed as GPL-licensed rather than Public Domain just to be safe.

In summary, I have 4 suggestions:

1. Add text in the README saying that optional dependencies have different license terms
2. Add text in the README saying that redistributions which include optional dependencies may be licensed under different terms than the Unlicense
3. License the Windows builds under GPL and package LICENSE + THIRD-PARTY-NOTICES files along with the .exe
4. Move mutagen and pycryptodome requirements to another package like yt-dlp[full] with GPL license if possible

I apologize for the rather long write-up, and I am willing to help with this if necessary.

[pukkandan]

1. Add text in the README saying that optional dependencies have different license terms
2. Add text in the README saying that redistributions which include optional dependencies may be licensed under different terms than the Unlicense

Separate from the issue of copyright, the name “Python” is also a trademark. You should include the notice ““Python” is a registered trademark of the Python Software Foundation” in the appropriate part of your documentation or About box and place the “®” symbol after the first mention of “Python” in your documentation. (For example: “Python® is used as the scripting language for…”)

These can be easily done

---

and a THIRD-PARTY-NOTICES file or similar … and for Python itself since we embed the interpreter into the executable.

The python interpretter is not “bundled” into the release package in the conventional sense. As I understand, the “bootloader exception” in pyinstaller’s licence already covers for this

Bootloader Exception
--------------------

In addition to the permissions in the GNU General Public License, the
authors give you unlimited permission to link or embed compiled bootloader
and related files into combinations with other programs, and to distribute
those combinations without any restriction coming from the use of those
files. (The General Public License restrictions do apply in other respects;
for example, they cover modification of the files, and distribution when
not linked into a combined executable.)

If it does not, then youtube-dl is also in violation of the license since they use py2exe which similarly embeds required portions of the python interpretter

---

and a THIRD-PARTY-NOTICES file or similar that includes the text of the license for pycryptodome

The BSD-2 licence doesn’t impose any restrictions on linking (similar to AGPL), so this is not necessary

---

I believe that the Windows builds now fall under the terms of the GPL since mutagen is licensed under the GPLv2 and we include it in the final binary

This is in-fact an issue

, as well as using it in the code.

We are not distributing it with our code, so it does not matter

License the Windows builds under GPL and package LICENSE + THIRD-PARTY-NOTICES files along with the .exe

As I understand, adding a COPYING.txt to the releases is sufficient. Could you help me write one?

Move mutagen and pycryptodome requirements to another package like yt-dlp[full] with GPL license if possible

No. The requirements.txt may contain either necessary or optional dependancies according to PyPi documents. Also, adding the libraries to requirements.txt does not violate any licenses

---

I am just a guy trying to improve on the youtube-dl project and make my modifications available to the public. I am honestly not interested in all this copyright bullshit. But I suppose it is a part of releasing a project 😩

[fstirlitz]

It doesn’t require packaging all dependencies with the source code, but it still has to meaningfully be you who is offering them for download. You can’t just say ‘oh well, you can get the dependencies from those other people’ and count on them not pulling a left-pad on you. The last sentence is clear here:

Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.

Putting everything into a single, complete source code package just seems like the easiest way to satisfy this requirement.

Unless you really prefer the ‘written offer’ alternative. To be honest, it starts looking more and more attractive now…