search

ytdl-org / youtube-dl

Command-line program to download videos from YouTube.com and other video sites
http://ytdl-org.github.io/youtube-dl/
The Unlicense
131.82k stars 10k forks source link

Possibility of changing the project license #10581

Open Parent5446 opened 8 years ago

Parent5446 commented 8 years ago

So I know this is going to be a controversial suggestion, and please take the filing of this issue as just that, a suggestion.

tl;dr - The current public domain license causes licensing issues as well as contributing issues that could be fixed with something like Apache. Adopting another license is a trivial amount of effort, involves no operational changes to the project, and has some non-zero possibility of providing legal or contributory advantages.

Problems with Current License

The current license Unlicense has a variety of issues:

  1. It's not a comprehensive public domain license in the first place. Because of it's wording, it may not be applicable in some countries due to the legal differences in the definition of public domain. IANAL, so I cannot claim expertise, but I know the community has wrestled with this issue before, and is why CC0 is generally considered a better alternative, since in cases where public domain does not really exist, CC0 falls back and becomes a normal, lax copyright license that gives almost the same effects.
  2. It prevents the inclusion of most third-party code or libraries. Pretty much any Python library (many of which are MIT, BSD, or Apache licensed), any StackOverflow code, or even code copied from other libraries indirectly (see #10557) cannot be included unless explicitly authorized by all copyright holders of such software. That's because the licenses are incompatible. Getting authors' permissions for every included snippet of code is cumbersome, and creates a lot of extra work.
  3. It prevents many corporate contributors from contributing. Speaking from personal experience as a Google employee, it is significantly more difficult (albeit not impossible) for me to submit code to this project during work hours because of the license. Many large companies have policies allowing employees to contribute to open source projects, but if the license is not one reviewed or approved by the company (usually Apache, GPL, etc.) then you have to jump through more hoops. (This is because all contributions made during work hours or with work equipment is property of the company, so you need company permission to actually release it under the given license.) To be more concrete with my anecdote, for me, if this project was under the Apache or GPL license, I could contribute indefinitely and without approval. But as it stands, I need to submit every patch I plan on uploading along with the project's information to a compliance committee who has to review my change and ensure it's OK.

    Counterpoints

  4. This is a small project, so there's really no need to care about whether public domain applies in certain countries. Nobody is going to sue the youtube-dl contributors.
  5. This project uses very little third-party code, so the issues I mentioned regarding licensing really don't apply often.
  6. I don't have any non-anecdotal evidence on what the actual impact of these issues are on the project, or whether it actually affects the number of contributors.

    Counter-counterpoints

  7. Better safe than sorry.
  8. Changing the license takes less effort than asking permission for even a single inclusion of third-party code.
  9. There is the possibility there is an impact, and the current license is holding back people from contributing that we don't know about.

    Why Public Domain Isn't Necessary

This is a more personal opinion, but I believe public domain is unnecessary. In other words, presuming the current authors already don't care about copyright or its enforcement for this project, there is no advantage that the public domain gives over a standard relaxed license like the Apache license.

The differences between Unlicense and Apache are (roughly):

My general position is that adopting another license is a trivial amount of effort, involves no operational changes to the project, and has some non-zero possibility of providing legal or contributory advantages. The contributors don't have to do anything special. The project can be packaged and distributed as it has always been done. The only effort is the changing of a single text file. And the result will be additional legal protection (if it ever becomes needed) as well as the possibility of easier development and more contributors.

Possible Replacement Licenses

If by now you are at least convinced of choosing a new license, I three recommendations:

There are, of course, many other choices, but I don't recommend licenses like MIT or BSD. They don't provide the same patent protections as the Apache license, and otherwise have zero advantage over Apache. I know the Apache license is longer and has more legalese, but that's just because it's an actual, modern software license.

Summary

I know I've said a lot, and this is pretty much an essay, but it would be really cool if it was easier for me, and I presume others, to contribute code to and include third-party code in this project freely. I don't presume to be a core contributor to this project, so I hope this essay does not sound too prescriptive. If you all decide just to close this, then obviously that's your decision. But I hope I could get at least your consideration, because the amount of effort that would be saved for me alone would outweigh even the amount of effort I put into writing this bug report.

ghost commented 8 years ago

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 8 years ago

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).

yan12125 commented 8 years ago

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:

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 8 years ago

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:

(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 8 years ago

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

Parent5446 commented 8 years ago

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.

yan12125 commented 8 years ago

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

TRox1972 commented 8 years ago

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

ghost commented 8 years ago

@TRox1972 Yes.

Parent5446 commented 8 years ago

@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.)

yan12125 commented 8 years ago

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.

Parent5446 commented 8 years ago

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.

yan12125 commented 8 years ago

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

g4jc commented 6 years ago

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.

rautamiekka commented 5 years ago

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

Parent5446 commented 5 years ago

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.

bittner commented 5 years ago

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 5 years ago

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.)

Pharap commented 4 years ago

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

MrRawes commented 2 years ago

(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 2 years ago

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

rautamiekka commented 2 years ago

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.

MrRawes commented 2 years ago

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

Pharap commented 2 years ago

@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.

rg3 commented 2 years ago

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:

MrRawes commented 2 years ago

@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 2 years ago

IMO 0BSD is better then CC0-1.0

Bertaz commented 2 years ago

IMO 0BSD is better then CC0-1.0

From my understanding CC0 is better for all the countries that legally either don't have Public Domain as a concept or the concept is uniquely 'x time after which copyright expires' (most countries in Europe). That's because 0BSD is only explicitly giving the same rights as PD, same thing Unlicense does while accounting for more edge cases. But that doesn't work in countries where you can't waiver those rights. CC0 is written with the legal codes of those countries in mind, making it slightly more difficult to understand, but effective.

See opensource.stackexchange.com/a/9873 for a better explanation Also: lists.opensource.org/pipermail/license-review/2012-January/001386.html

MrRawes commented 2 years ago

IMO 0BSD is better then CC0-1.0

From my understanding CC0 is better for all the countries that legally either don't have Public Domain as a concept or the concept is uniquely 'x time after which copyright expires' (most countries in Europe). That's because 0BSD is only explicitly giving the same rights as PD, same thing Unlicense does while accounting for more edge cases. But that doesn't work in countries where you can't waiver those rights. CC0 is written with the legal codes of those countries in mind, making it slightly more difficult to understand, but effective.

See opensource.stackexchange.com/a/9873 for a better explanation Also: lists.opensource.org/pipermail/license-review/2012-January/001386.html

yes, but 0BSD is just the ISC license without any requirements to retain copyright and permission notices