Possibility of changing the project license #8664

Author

Owner

@ghost commented on GitHub (Sep 7, 2016):

I agree, i personally have less motivation for helping this project with current license.

And you are not correct about license used by MPV, see their Copyright file, project as a whole licensed under GPLv2+, with all new contributions under LGPLv2.1+ license, under which project might potentially be relicensed. So i suggest this one.

And thus it will make youtube-dl compatible with license of livestreamer (BSD-like), that will allow use of their code.

@ghost commented on GitHub (Sep 7, 2016): I agree, i personally have less motivation for helping this project with current license. And you are not correct about license used by MPV, see their [Copyright](https://github.com/mpv-player/mpv/blob/master/Copyright#L13) file, project as a whole licensed under GPLv2+, with all new contributions under LGPLv2.1+ license, under which project might potentially be relicensed. So i suggest this one. And thus it will make youtube-dl compatible with license of livestreamer (BSD-like), that will allow use of their code.

deekerman commented

Author

Owner

@ghost commented on GitHub (Sep 23, 2016):

I just want to add that it's not even necessary to ship the full text of the license, stating the license's and copyright owner's name is enough. Distributing the full text is just a habit in the software community, it's not compulsory (I read this somewhere in the Creative Commons website).

@ghost commented on GitHub (Sep 23, 2016): I just want to add that it's not even necessary to ship the full text of the license, stating the license's and copyright owner's name is enough. Distributing the full text is just a habit in the software community, it's not compulsory (I read this somewhere in the Creative Commons website).

deekerman commented

Author

Owner

@yan12125 commented on GitHub (Sep 23, 2016):

Thanks @Parent5446! You have pointed out some real problems of the current license. Here are my ideas:

It prevents the inclusion of most third-party code or libraries

This issue can be separated into two cases. First is using 3rd party libraries to achieve supporting mechanisms for multimedia handling. For example:

SOCKS proxies (#402) - resolved with a public domain alternative
DRM decryption (#1753)
AMF serializing/deserializing (#4068)
DNS resolver (#4726)
websocket (#9671)

Second is using 3rd party libraries to achieve reverse engineering of websites. Examples include Crunchyroll (#10557) and Spotify (#10344).

For the first case, it would be great to allow embedding 3rd party libraries with different licenses. Large projects like Mozilla Firefox and Android Open Source Project are taking this way. The main part of a project uses one license (MPL2 and Apache in these cases) and depedencies keep their original licenses. This allows implementing some new features without bothering with licenses and keeps developers away from re-inventing the wheel. Of course there are plenty of technical issues on embedding external dependencies. Those can be left to new issues if we are going to do that.

For the reverse engineering part, I have a question. As you've mentioned, licenses are not compatible. Is it allowed to use codes with different licenses? For example, if youtube-dl switches to GPL3, can MIT-like (used by you-get, another popular downloader focusing on Chinese websites), BSD-like (used by livestreamer) and Apache2 (used by get-flash-videos) codes ported to youtube-dl without asking for permissions?

It prevents many corporate contributors from contributing.

Thanks for this information. I didn't know that. It's also a good reason to change the license if lots of contributions are from companies.

MPV ... all new contributions under LGPLv2.1+ license, under which project might potentially be relicensed. So i suggest this one.

Sorry not getting it. If I remember it correctly mpv uses youtube-dl via the command line interface. They don't embed or distribute youtube-dl copies. Is there a need to use the same license for both projects?

Distributing the full text is just a habit in the software community, it's not compulsory

As a side note: a copy is necessary for MIT/BSD/ISC. Those are license templates rather than real licenses.

@yan12125 commented on GitHub (Sep 23, 2016): Thanks @Parent5446! You have pointed out some real problems of the current license. Here are my ideas: > It prevents the inclusion of most third-party code or libraries This issue can be separated into two cases. First is using 3rd party libraries to achieve supporting mechanisms for multimedia handling. For example: - SOCKS proxies (#402) - resolved with a public domain alternative - DRM decryption (#1753) - AMF serializing/deserializing (#4068) - DNS resolver (#4726) - websocket (#9671) Second is using 3rd party libraries to achieve reverse engineering of websites. Examples include Crunchyroll (#10557) and Spotify (#10344). For the first case, it would be great to allow embedding 3rd party libraries with different licenses. Large projects like Mozilla Firefox and Android Open Source Project are taking this way. The main part of a project uses one license (MPL2 and Apache in these cases) and depedencies keep their original licenses. This allows implementing some new features without bothering with licenses and keeps developers away from re-inventing the wheel. Of course there are plenty of technical issues on embedding external dependencies. Those can be left to new issues if we are going to do that. For the reverse engineering part, I have a question. As you've mentioned, licenses are not compatible. Is it allowed to use codes with different licenses? For example, if youtube-dl switches to GPL3, can MIT-like (used by [you-get](https://raw.githubusercontent.com/soimort/you-get/master/LICENSE.txt), another popular downloader focusing on Chinese websites), BSD-like (used by [livestreamer](https://github.com/chrippa/livestreamer/blob/develop/LICENSE)) and Apache2 (used by [get-flash-videos](https://github.com/monsieurvideo/get-flash-videos/blob/master/LICENSE)) codes ported to youtube-dl without asking for permissions? > It prevents many corporate contributors from contributing. Thanks for this information. I didn't know that. It's also a good reason to change the license if lots of contributions are from companies. > MPV ... all new contributions under LGPLv2.1+ license, under which project might potentially be relicensed. So i suggest this one. Sorry not getting it. If I remember it correctly mpv uses youtube-dl via the command line interface. They don't embed or distribute youtube-dl copies. Is there a need to use the same license for both projects? > Distributing the full text is just a habit in the software community, it's not compulsory As a side note: a copy is necessary for MIT/BSD/ISC. Those are license templates rather than real licenses.

deekerman commented

Author

Owner

@yan12125 commented on GitHub (Sep 23, 2016):

Here's another reason to change the license of youtube-dl. In this project, there are some codes copied/adapted from CPython to provide missing features and/or fix bugs in old Python versions. Examples are:

9631a94fb5: compat_html_entities_html5 copied from html/entities.py
c9c854cea7: adapted from urllib/parse.py
0a67a3632b: adapted from urllib/request.py

(There are way more. I don't have time to check them one by one)

I guess UNLICENSE is not compatible with CPython's license? A new license is necessary so that youtube-dl can embed codes under the Python license, at least for affected files.

@yan12125 commented on GitHub (Sep 23, 2016): Here's another reason to change the license of youtube-dl. In this project, there are some codes copied/adapted from CPython to provide missing features and/or fix bugs in old Python versions. Examples are: - 9631a94fb5e5ee9b92135f938df00866535fc6c6: `compat_html_entities_html5` copied from `html/entities.py` - c9c854cea7fa5992356dee5eab0d3615b4d40dc6: adapted from `urllib/parse.py` - 0a67a3632bb9cf76f64658986defc1947090ef50: adapted from `urllib/request.py` (There are way more. I don't have time to check them one by one) I guess UNLICENSE is not compatible with CPython's license? A new license is necessary so that youtube-dl can embed codes under the Python license, at least for affected files.

deekerman commented

Author

Owner

@yan12125 commented on GitHub (Sep 23, 2016):

Add 'bug' label as there are already license conflicts in this project as I've mentioned in the previous comment.

@yan12125 commented on GitHub (Sep 23, 2016): Add 'bug' label as there are already license conflicts in this project as I've mentioned in the previous comment.

deekerman commented

Author

Owner

@Parent5446 commented on GitHub (Sep 23, 2016):

For the reverse engineering part, I have a question. As you've mentioned, licenses are not compatible. Is it allowed to use codes with different licenses? For example, if youtube-dl switches to GPL3, can MIT-like (used by you-get, another popular downloader focusing on Chinese websites), BSD-like (used by livestreamer) and Apache2 (used by get-flash-videos) codes ported to youtube-dl without asking for permissions?

If youtube-dl switched to GPL3 specifically, then yes, MIT-like, BSD-like, and Apache2 code can be moved into this project without permission (forming a derivative work). However, youtube-dl's code would not be able to be reverse ported back into those projects. On the flip side, if youtube-dl is MIT licensed, then we can use some other project's code in youtube-dl, and youtube-dl code can be used in any other open source project, but we can't use GPL code within youtube-dl. In other words, in many cases, license compatibility is only in one direction.

@Parent5446 commented on GitHub (Sep 23, 2016): > For the reverse engineering part, I have a question. As you've mentioned, licenses are not compatible. Is it allowed to use codes with different licenses? For example, if youtube-dl switches to GPL3, can MIT-like (used by you-get, another popular downloader focusing on Chinese websites), BSD-like (used by livestreamer) and Apache2 (used by get-flash-videos) codes ported to youtube-dl without asking for permissions? If youtube-dl switched to GPL3 specifically, then yes, MIT-like, BSD-like, and Apache2 code can be moved into this project without permission (forming a derivative work). However, youtube-dl's code would not be able to be reverse ported back into those projects. On the flip side, if youtube-dl is MIT licensed, then we can use some other project's code in youtube-dl, and youtube-dl code can be used in any other open source project, but we can't use GPL code within youtube-dl. In other words, in many cases, license compatibility is only in one direction.

deekerman commented

[1] https://news.ycombinator.com/item?id=11455208
[2] https://anonscm.debian.org/cgit/collab-maint/youtube-dl.git/tree/youtube-dl?id=b1e8c1f49aec204ae7b90abd71dead191d647c3c
[3] http://rg3.name/200807240952.html

Author

Owner

@yan12125 commented on GitHub (Sep 24, 2016):

Thanks for detailed explanation. As you've said, changing the license brings few technical changes, but it would definitely affect the relationship of youtube-dl and other multimedia downloading tools.

Here I also want to mention something interesting when studying the history of youtube-dl. The first release of this project is 2006.08.08 [1], and the oldest version I can find on the Internet is 2006.08.28 [2], which was MIT-like. In rg3's blog [3], it's mentioned that the license was switched to public domain. @rg3, would you like to share the reason behind the switch?

@yan12125 commented on GitHub (Sep 24, 2016): Thanks for detailed explanation. As you've said, changing the license brings few technical changes, but it would definitely affect the relationship of youtube-dl and other multimedia downloading tools. Here I also want to mention something interesting when studying the history of youtube-dl. The first release of this project is 2006.08.08 [1], and the oldest version I can find on the Internet is 2006.08.28 [2], which was MIT-like. In rg3's blog [3], it's mentioned that the license was switched to public domain. @rg3, would you like to share the reason behind the switch? [1] https://news.ycombinator.com/item?id=11455208 [2] https://anonscm.debian.org/cgit/collab-maint/youtube-dl.git/tree/youtube-dl?id=b1e8c1f49aec204ae7b90abd71dead191d647c3c [3] http://rg3.name/200807240952.html

deekerman commented

Author

Owner

@TRox1972 commented on GitHub (Oct 4, 2016):

@Parent5446 but if youtube-dl were to switch license, previous code declared public domain would not be applicable to that license, right?

@TRox1972 commented on GitHub (Oct 4, 2016): @Parent5446 but if youtube-dl were to switch license, previous code declared public domain would not be applicable to that license, right?

deekerman commented

Author

Owner

@ghost commented on GitHub (Oct 4, 2016):

@TRox1972 Yes.

@ghost commented on GitHub (Oct 4, 2016): @TRox1972 Yes.

deekerman commented

Author

Owner

@Parent5446 commented on GitHub (Oct 4, 2016):

@Parent5446 but if youtube-dl were to switch license, previous code declared public domain would not be applicable to that license, right?

Sort of. It's complicated.

(Disclaimer: I am not a lawyer, and am not authorized to practice law in any jurisdiction. This comment is not legal advice, and should not be taken as such.)

If this project were to switch, the "previous code", i.e., all lines of code that has not been changed since the license change, would remain in the public domain. All future contributions would be under the new license, and any existing code that is modified after the license change will be under the new license. Furthermore, the youtube-dl application taken as a whole would be distributed under the new license.

(There is a slight catch here, in that since this project does not have developers sign CLAs before contributing, it is arguable about whether the original authors of code have actually released their code into the public domain in the first place.)

@Parent5446 commented on GitHub (Oct 4, 2016): > @Parent5446 but if youtube-dl were to switch license, previous code declared public domain would not be applicable to that license, right? Sort of. It's complicated. (Disclaimer: I am not a lawyer, and am not authorized to practice law in any jurisdiction. This comment is not legal advice, and should not be taken as such.) If this project were to switch, the "previous code", i.e., all lines of code that has not been changed since the license change, would remain in the public domain. All future contributions would be under the new license, and any existing code that is modified after the license change will be under the new license. Furthermore, the youtube-dl application taken as a whole would be distributed under the new license. (There is a slight catch here, in that since this project does not have developers sign CLAs before contributing, it is arguable about whether the original authors of code have actually released their code into the public domain in the first place.)

deekerman commented

Author

Owner

@yan12125 commented on GitHub (Oct 9, 2016):

any existing code that is modified after the license change will be under the new license.

Sorry I'm confusing here. For example, if I change this line:

_VALID_URL = r'https?://www\.foo\.com/(?P<id>\d+)'

to

_VALID_URL = r'https?://www\.foo\.com/(?P<id>[0-9a-zA-z-])'

Then this line will be under the new license? That's not intuitive.

it is arguable about whether the original authors of code have actually released their code into the public domain in the first place

https://github.com/mpv-player/mpv/issues/2033 seems a good solution. It solves my first question, too.

@yan12125 commented on GitHub (Oct 9, 2016): > any existing code that is modified after the license change will be under the new license. Sorry I'm confusing here. For example, if I change this line: ``` _VALID_URL = r'https?://www\.foo\.com/(?P<id>\d+)' ``` to ``` _VALID_URL = r'https?://www\.foo\.com/(?P<id>[0-9a-zA-z-])' ``` Then this line will be under the new license? That's not intuitive. > it is arguable about whether the original authors of code have actually released their code into the public domain in the first place https://github.com/mpv-player/mpv/issues/2033 seems a good solution. It solves my first question, too.

deekerman commented

Author

Owner

@Parent5446 commented on GitHub (Oct 9, 2016):

Sorry I'm confusing here. For example, if I change this line:

To be honest I'm not sure. I really don't know where the law draws the line at "copyrightable". For example, maybe what you're saying is right, and only the new line is under the license. Or maybe the line is actually drawn at the file level, and the entire file comes under the new license. IANAL, so I don't really know.

In the end, though, we don't need to worry too much about it. All we would do is say that the entire project is under license X, and that it contains public domain code from the old youtube-dl, and include a link.

mpv-player/mpv#2033 seems a good solution. It solves my first question, too.

True, but I do not know what the legal enforceability of such as a short statement. IANAL so I don't really know much further, but at the very least the short statement does not have the proper language to constitute a grant of a copyright license.

@Parent5446 commented on GitHub (Oct 9, 2016): > Sorry I'm confusing here. For example, if I change this line: To be honest I'm not sure. I really don't know where the law draws the line at "copyrightable". For example, maybe what you're saying is right, and only the new line is under the license. Or maybe the line is actually drawn at the file level, and the entire file comes under the new license. IANAL, so I don't really know. In the end, though, we don't need to worry too much about it. All we would do is say that the entire project is under license X, and that it contains public domain code from the old youtube-dl, and include a link. > mpv-player/mpv#2033 seems a good solution. It solves my first question, too. True, but I do not know what the legal enforceability of such as a short statement. IANAL so I don't really know much further, but at the very least the short statement does not have the proper language to constitute a grant of a copyright license.

deekerman commented

Author

Owner

@yan12125 commented on GitHub (Oct 9, 2016):

Never mind. Those question can be left until youtube-dl finally decides to use a new license. Thanks for all the help!

@yan12125 commented on GitHub (Oct 9, 2016): Never mind. Those question can be left until youtube-dl finally decides to use a new license. Thanks for all the help!

deekerman commented

Author

Owner

@g4jc commented on GitHub (Oct 15, 2018):

I second the CC0 suggestion. Not all countries have the term "public domain", making the unlicense in fact a restrictive license in those jurisdictions. CC0 helps fill the void even in those cases by enforcing the public domain in places where it may not otherwise be possible.

@g4jc commented on GitHub (Oct 15, 2018): I second the CC0 suggestion. Not all countries have the term "public domain", making the unlicense in fact a restrictive license in those jurisdictions. CC0 helps fill the void even in those cases by enforcing the public domain in places where it may not otherwise be possible.

deekerman commented

Author

Owner

@rautamiekka commented on GitHub (Oct 15, 2018):

What's wrong with BSD license ? If anything, by what I understand of GPL it's the absolute worst series of Open Source licenses.

@rautamiekka commented on GitHub (Oct 15, 2018): What's wrong with BSD license ? If anything, by what I understand of GPL it's the absolute worst series of Open Source licenses.

deekerman commented

Author

Owner

@Parent5446 commented on GitHub (Oct 15, 2018):

What's wrong with BSD license ?

I mean, it depends on which BSD license you mean, but in general the Apache license is a bit safer, because it includes a patent grant in addition to just a copyright license. In other words, if a contributor submits a pull request that contains patented ideas that they own, with just a BSD license the original contributor could assert patent rights and stop people from using the software. Now, that said, it's not particularly a huge risk as I said above. Software patents are a bit of a controversial area, and it's not very clear what kind of software is even in scope for patents. But better safe than sorry. Having a patent grant like in the Apache license doesn't hurt, it only helps.

If anything, by what I understand of GPL it's the absolute worst series of Open Source licenses.

Not sure what makes you think that, but the GPL is a solid license written by lawyers (same as the Apache license). It just has different properties than permissive licenses. Specifically, it has a copyleft. If a company copied youtube-dl, added some custom plug-ins, and then starting selling it, would you want to ensure that they distributed the source code any time they sold it? If so, the GPL (and associated licenses) help protect that. If the answer is "I don't care", then just use a permissive license like Apache. It's just a matter of philosophy, and whether you're open-sourcing your software more out of convenience or because you want to protect users' rights.

@Parent5446 commented on GitHub (Oct 15, 2018): > What's wrong with BSD license ? I mean, it depends on which BSD license you mean, but in general the Apache license is a bit safer, because it includes a patent grant in addition to just a copyright license. In other words, if a contributor submits a pull request that contains patented ideas that they own, with just a BSD license the original contributor could assert patent rights and stop people from using the software. Now, that said, it's not particularly a huge risk as I said above. Software patents are a bit of a controversial area, and it's not very clear what kind of software is even in scope for patents. But better safe than sorry. Having a patent grant like in the Apache license doesn't hurt, it only helps. > If anything, by what I understand of GPL it's the absolute worst series of Open Source licenses. Not sure what makes you think that, but the GPL is a solid license written by lawyers (same as the Apache license). It just has different properties than permissive licenses. Specifically, it has a copyleft. If a company copied youtube-dl, added some custom plug-ins, and then starting selling it, would you want to ensure that they distributed the source code any time they sold it? If so, the GPL (and associated licenses) help protect that. If the answer is "I don't care", then just use a permissive license like Apache. It's just a matter of philosophy, and whether you're open-sourcing your software more out of convenience or because you want to protect users' rights.

deekerman commented

Author

Owner

@bittner commented on GitHub (Feb 13, 2019):

Sorry I'm confusing here. For example, if I change this line:

To be honest I'm not sure. I really don't know where the law draws the line at "copyrightable". For example, maybe what you're saying is right, and only the new line is under the license. Or maybe the line is actually drawn at the file level, and the entire file comes under the new license. IANAL, so I don't really know.

It would be intuitive to draw the conclusion that the changed line bears both the license that the original contributor granted and the license the contributor providing the change granted. Both are authors, no matter how simple, small or trivial the contribution is. That's why it's necessary that contributors waive their rights (drawn from the original license) when a project switches license---if you want to avoid potential licensing threats.

@bittner commented on GitHub (Feb 13, 2019): > > Sorry I'm confusing here. For example, if I change this line: > > To be honest I'm not sure. I really don't know where the law draws the line at "copyrightable". For example, maybe what you're saying is right, and only the new line is under the license. Or maybe the line is actually drawn at the file level, and the entire file comes under the new license. IANAL, so I don't really know. It would be intuitive to draw the conclusion that the changed line bears both the license that the original contributor granted and the license the contributor providing the change granted. Both are authors, no matter how simple, small or trivial the contribution is. That's why it's necessary that contributors waive their rights (drawn from the original license) when a project switches license---if you want to avoid potential licensing threats.

deekerman commented

Author

Owner

@bittner commented on GitHub (Feb 13, 2019):

If anything, by what I understand of GPL it's the absolute worst series of Open Source licenses.

I believe, this concern has faded largely under recent developments in society. The threats that Internet giants and secret agencies pose on democracy and our personal freedom have become so large, so real that the concerns on not being able to monetize software easily have lost their pole position.

What in the past seemed extreme, almost anarchic, is now showing to be the only real protection against malicious intents from anyone, threatening a safe society: All software must be free, without exception.

(Users must be in control of what software does, not the other way around. Here's some more reading, if you're interested.)

@bittner commented on GitHub (Feb 13, 2019): > If anything, by what I understand of GPL it's the absolute worst series of Open Source licenses. I believe, this concern has faded largely under recent developments in society. The threats that Internet giants and secret agencies pose on democracy and our personal freedom have become so large, so real that the concerns on not being able to monetize software easily have lost their pole position. What in the past seemed extreme, almost anarchic, is now showing to be the only real protection against malicious intents from anyone, threatening a safe society: _All_ software must be free, without exception. (Users must be in control of what software does, not the other way around. Here's [some more reading](https://puri.sm/posts/how-to-avoid-the-frightful-5-big-tech-corporations/), if you're interested.)

deekerman commented

Author

Owner

@Pharap commented on GitHub (Dec 3, 2019):

Sorry to dig up an old issue, but I might be able to shed a bit of light on the situation. I'm not a lawyer, but I've read quite a lot into source code licencing.

Sorry I'm confusing here. For example, if I change this line:

From the way I understand licensing, in that example both snippets would be under the new licence, but the original version would also be available under the old licence, meaning it would effectively be dual licensed and people would be free to choose which licence they wish to use it under.

The way a licence changeover would work is as thus:

The current state of the project, and all previous versions, would be available under the old licence. A commit would occur that changes the project's licence to the new licence, meaning that anything from that commit onwards (including that commit) would be under the new licence.
(It ideally should be just a single commit, else there would be commits that would arguably be in a state of flux, where the licensing of the project in that state is unclear.)

At a file level, if a file released under the new licence is identical to a file released under the old licence, that file is effectively dual licenced, and anyone could argue that they received a copy of the file under either licence.
Any changes made after the licence changeover would unambiguously be available exclusively under the new licence.

In regards to 3rd party code, the situation would be mostly the same regardless of what licence this project is licenced under.

The 3rd party code must either be included under the licence it was published under (and that licence must be made clear), or a new licence must be negotiated with the code's author.

The consequence of this is that unless the maintainers are willing to forgo using 3rd party code or they are willing to negotiate new licencing terms each time, it will not be possible to have the entire project in the public domain.

In regards to actually selecting a licence:

CC0 is the best for placing code in the public domain.
As @g4jc pointed out, CC0 does a better job of this than 'the Unlicense',
However, as I mentioned before, the use of 3rd party libraries will have an impact on this.

If ensuring the code stays public domain isn't the top priority then other licences should be evaluated and considered.
I can't really comment on any other licences without a better idea of what the project maintainer's goals are/would be.
E.g. whether 'copyleft' is desirable, whether user freedom is more important than fighting closed source derivatives

@Pharap commented on GitHub (Dec 3, 2019): Sorry to dig up an old issue, but I might be able to shed a bit of light on the situation. I'm not a lawyer, but I've read quite a lot into source code licencing. > Sorry I'm confusing here. For example, if I change this line: From the way I understand licensing, in that example both snippets would be under the new licence, but the original version would also be available under the old licence, meaning it would effectively be dual licensed and people would be free to choose which licence they wish to use it under. --- The way a licence changeover would work is as thus: The current state of the project, and all previous versions, would be available under the old licence. A commit would occur that changes the project's licence to the new licence, meaning that anything from that commit onwards (including that commit) would be under the new licence. (It ideally should be just a single commit, else there would be commits that would arguably be in a state of flux, where the licensing of the project in that state is unclear.) At a file level, if a file released under the new licence is identical to a file released under the old licence, that file is effectively dual licenced, and anyone could argue that they received a copy of the file under either licence. Any changes made after the licence changeover would unambiguously be available exclusively under the new licence. --- In regards to 3rd party code, the situation would be mostly the same regardless of what licence this project is licenced under. The 3rd party code must either be included under the licence it was published under (and that licence must be made clear), or a new licence must be negotiated with the code's author. The consequence of this is that unless the maintainers are willing to forgo using 3rd party code or they are willing to negotiate new licencing terms each time, it will not be possible to have the entire project in the public domain. --- In regards to actually selecting a licence: CC0 is the best for placing code in the public domain. As @g4jc pointed out, CC0 does a better job of this than 'the Unlicense', However, as I mentioned before, the use of 3rd party libraries will have an impact on this. If ensuring the code stays public domain isn't the top priority then other licences should be evaluated and considered. I can't really comment on any other licences without a better idea of what the project maintainer's goals are/would be. E.g. whether 'copyleft' is desirable, whether user freedom is more important than fighting closed source derivatives

deekerman commented

Author

Owner

@MrRawes commented on GitHub (Mar 26, 2022):

(There is a slight catch here, in that since this project does not have developers sign CLAs before contributing, it is arguable about whether the original authors of code have actually released their code into the public domain in the first place.)

actually in the terms of service there is this, although it was not always there

@MrRawes commented on GitHub (Mar 26, 2022): > (There is a slight catch here, in that since this project does not have developers sign CLAs before contributing, it is arguable about whether the original authors of code have actually released their code into the public domain in the first place.) actually in the terms of service there is [this](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license), although it was not always there

deekerman commented

Author

Owner

@MrRawes commented on GitHub (Apr 15, 2022):

~~DO NOT USE Apache-2.0 because a program used with --exec under GPL-2.0-only may be ilegal~~

@MrRawes commented on GitHub (Apr 15, 2022): ~~DO NOT USE [Apache-2.0](https://spdx.org/licenses/Apache-2.0.html) because a program used with `--exec` under [GPL-2.0-only](https://spdx.org/licenses/GPL-2.0-only.html) may be ilegal~~

deekerman commented

Author

Owner

@rautamiekka commented on GitHub (Apr 15, 2022):

DO NOT USE Apache-2.0 because using --exec with a program under GPL-2.0-only may be ilegal

You better explain how that works, with proof.

@rautamiekka commented on GitHub (Apr 15, 2022): > DO NOT USE [Apache-2.0](https://spdx.org/licenses/Apache-2.0.html) because using `--exec` with a program under [GPL-2.0-only](https://spdx.org/licenses/GPL-2.0-only.html) may be ilegal You better explain how that works, with proof.

deekerman commented

Author

Owner

@MrRawes commented on GitHub (Apr 15, 2022):

DO NOT USE Apache-2.0 because using --exec with a program under GPL-2.0-only may be ilegal

You better explain how that works, with proof.

~~the reason is that using a program as a post-processor through --exec is dynamic linking and Apache-2.0 is incompatble with GPL-2.0-only~~

@MrRawes commented on GitHub (Apr 15, 2022): > > DO NOT USE [Apache-2.0](https://spdx.org/licenses/Apache-2.0.html) because using `--exec` with a program under [GPL-2.0-only](https://spdx.org/licenses/GPL-2.0-only.html) may be ilegal > > You better explain how that works, with proof. ~~the reason is that using a program as a post-processor through `--exec` is dynamic linking and [Apache-2.0](https://spdx.org/licenses/Apache-2.0.html) is [incompatble](https://www.gnu.org/licenses/license-list.en.html#apache2) with [GPL-2.0-only](https://spdx.org/licenses/GPL-2.0-only.html)~~

deekerman commented

The GPL FAQ does state that:

Author

Owner

@Pharap commented on GitHub (Apr 15, 2022):

@MrRawes The 'incompatible' link explains one incompatibility:

These include certain patent termination and indemnification provisions.

But it does not explain why dynamic linking violates GPL 2.0.

Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination.

But using the LGPL instead solves that issue because it has a link exception.

That leaves the issue of whether the "patent termination and indemnification provisions" would be an issue when using the LGPL.

Though I have to ask, was anybody actually contemplating using both the Apache 2.0 licence with the GPL 2.0 licence, or did that comment come from nowhere?

As far as I can see, most of the weight is behind CC0, which is the sensible equivalent of the Unlicence.

@Pharap commented on GitHub (Apr 15, 2022): @MrRawes The 'incompatible' link explains one incompatibility: > These include certain patent termination and indemnification provisions. But it does not explain why dynamic linking violates GPL 2.0. [The GPL FAQ does state that](https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic): > Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination. But using [the LGPL](https://choosealicense.com/licenses/lgpl-3.0/) instead solves that issue because it has a link exception. That leaves the issue of whether the "patent termination and indemnification provisions" would be an issue when using the LGPL. --- Though I have to ask, was anybody actually contemplating using both the Apache 2.0 licence with the GPL 2.0 licence, or did that comment come from nowhere? As far as I can see, most of the weight is behind CC0, which is the sensible equivalent of the Unlicence.

deekerman commented

Author

Owner

@rg3 commented on GitHub (Apr 15, 2022):

DO NOT USE Apache-2.0 because using --exec with a program under GPL-2.0-only may be ilegal

You better explain how that works, with proof.

the reason is that using a program as a post-processor through --exec is dynamic linking and Apache-2.0 is incompatble with GPL-2.0-only

It's true if there is dynamic linking the Apache 2.0 license is incompatible with GPL-2.0-only, but I just wanted to point out if --exec calls fork+exec to run an auxiliary external program, that is not dynamic linking. They are generally two separate processes that never share the same address space or data structures, and are not packaged together.

I couldn't find a good authoritative link that explains this, but these should work:

@rg3 commented on GitHub (Apr 15, 2022): > > > DO NOT USE [Apache-2.0](https://spdx.org/licenses/Apache-2.0.html) because using `--exec` with a program under [GPL-2.0-only](https://spdx.org/licenses/GPL-2.0-only.html) may be ilegal > > > > > > You better explain how that works, with proof. > > the reason is that using a program as a post-processor through `--exec` is dynamic linking and [Apache-2.0](https://spdx.org/licenses/Apache-2.0.html) is [incompatble](https://www.gnu.org/licenses/license-list.en.html#apache2) with [GPL-2.0-only](https://spdx.org/licenses/GPL-2.0-only.html) It's true if there is dynamic linking the Apache 2.0 license is incompatible with GPL-2.0-only, but I just wanted to point out if --exec calls fork+exec to run an auxiliary external program, that is **not** dynamic linking. They are generally two separate processes that never share the same address space or data structures, and are not packaged together. I couldn't find a good authoritative link that explains this, but these should work: * https://www.ifross.org/?q=en/program-forks-gpl-licensed-program-system-or-vice-versa-call-derivative-work * https://en.wikipedia.org/wiki/Dynamic_linker

deekerman commented

Author

Owner

@MrRawes commented on GitHub (Apr 15, 2022):

@MrRawes The 'incompatible' link explains one incompatibility:

These include certain patent termination and indemnification provisions.

But it does not explain why dynamic linking violates GPL 2.0.

The GPL FAQ does state that:

Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination.

But using the LGPL instead solves that issue because it has a link exception.

That leaves the issue of whether the "patent termination and indemnification provisions" would be an issue when using the LGPL.

Though I have to ask, was anybody actually contemplating using both the Apache 2.0 licence with the GPL 2.0 licence, or did that comment come from nowhere?

As far as I can see, most of the weight is behind CC0, which is the sensible equivalent of the Unlicence.

there are no issues with any versions of LGPL or GPL with a linking exeption

yt-dlp's dependency's that are bundled into the windows/mac builds licenses are GPL-2.0-or-later, MPL-2.0, BSD-3-Clause, BSD-2-Clause, MIT and that this would not be a problem under GPL-2.0-only if they were not bundled into the builds

~~the reason this is a issue is that yt-dlp has optional dependencies under GPL-2.0-only (despite saying that it is GPLv2+ everything exept mplayer and mpv is actually GPL-2.0-only)~~

@MrRawes commented on GitHub (Apr 15, 2022): > @MrRawes The 'incompatible' link explains one incompatibility: > > > These include certain patent termination and indemnification provisions. > > But it does not explain why dynamic linking violates GPL 2.0. > > [The GPL FAQ does state that](https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic): > > > Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination. > > But using [the LGPL](https://choosealicense.com/licenses/lgpl-3.0/) instead solves that issue because it has a link exception. > > That leaves the issue of whether the "patent termination and indemnification provisions" would be an issue when using the LGPL. > > Though I have to ask, was anybody actually contemplating using both the Apache 2.0 licence with the GPL 2.0 licence, or did that comment come from nowhere? > > As far as I can see, most of the weight is behind CC0, which is the sensible equivalent of the Unlicence. there are no issues with any versions of LGPL or GPL with a linking exeption yt-dlp's dependency's that are bundled into the windows/mac builds licenses are GPL-2.0-or-later, MPL-2.0, BSD-3-Clause, BSD-2-Clause, MIT and that this would not be a problem under GPL-2.0-only if they were not bundled into the builds ~~the reason this is a issue is that [yt-dlp](https://github.com/yt-dlp/yt-dlp) has optional dependencies under [GPL-2.0-only](https://spdx.org/licenses/GPL-2.0-only.html) (despite saying that it is GPLv2+ everything exept mplayer and mpv is actually GPL-2.0-only)~~

deekerman commented

Author

Owner

@MrRawes commented on GitHub (May 4, 2022):

IMO 0BSD is better then CC0-1.0

@MrRawes commented on GitHub (May 4, 2022): IMO [0BSD](https://spdx.org/licenses/0BSD.html) is better then [CC0-1.0](https://spdx.org/licenses/CC0-1.0.html)

deekerman commented