Closed ghost closed 5 years ago
I agree that my past contributions to mpv, mplayer2, or MPlayer are relicensed to the GNU Lesser General Public License (LGPL) version 2.1 or later
I agree that my past contributions to mpv, mplayer2, or MPlayer are relicensed to the GNU Lesser General Public License (LGPL) version 2.1 or later
I waive my copyright on all my contributions to mpv, mplayer2 or MPlayer.
I agree that my past contributions to mpv, mplayer2, or MPlayer are relicensed to the GNU Lesser General Public License (LGPL) version 2.1 or later.
I agree that my past contributions to mpv, mplayer2, or MPlayer are relicensed to the GNU Lesser General Public License (LGPL) version 2.1 or later.
xI agree that my past contributions to mpv, mplayer2, or MPlayer are relicensed to the GNU Lesser General Public License (LGPL) version 2.1 or later.
I agree that my past contributions to mpv, mplayer2, or MPlayer are relicensed to the GNU Lesser General Public License (LGPL) version 2.1 or later
I agree that my past contributions to mpv, mplayer2, or MPlayer are relicensed to the GNU Lesser General Public License (LGPL) version 2.1 or later
@czarkoff Love the sentiment, but not all jurisdictions have a concept of waiving copyright; would you mind explicitly stating that you agree to the relicensing? You could mention also allowing a CC0 license if you prefer something as close to public-domain as you can get while being jurisdiction-portable.
I agree that my past contributions to mpv, mplayer2, or MPlayer are relicensed to the GNU Lesser General Public License (LGPL) version 2.1 or later
Hereby I explicitly permit to use my contributions to or whatever copyrightable assets I possess in mpv, mplayer2 and MPlayer under CC0 license 1.0 universal. I give an explicit and irrevocable permission to other copyright holders to relicense aforementioned assets in the future without asking my concent or notifying me of such change.
I agree that my past contributions to mpv, mplayer2, or MPlayer are relicensed to the GNU Lesser General Public License (LGPL) version 2.1 or later.
... I'm pretty sure I only corrected a misspelling in a comment somewhere.
I agree that my past contributions to mpv, mplayer2, or MPlayer are relicensed to the GNU Lesser General Public License (LGPL) version 2.1 or later.
... I'm pretty sure I only corrected a misspelling in a comment somewhere.
True, but it's simpler to just get permission from everyone involved, instead of deciding whether to get permission on a case-by-case basis.
I agree that my past contributions to mpv, mplayer2, or MPlayer are relicensed to the GNU Lesser General Public License (LGPL) version 2 or later
I agree that my past contributions to mpv, mplayer2, or MPlayer are relicensed to the GNU Lesser General Public License (LGPL) version 2.1 or later
108/120 = 90%
Thanks for the summary. (The MPlayer part is going to be much harder...)
As someone told me, "ghost" is not a real user, but is used by github to replace accounts that have been deleted. bugmen0t is apparently a login on bugmenot.com.
I suggest you add to the project README that all new code commuted from now is under the LGPLv2.1, so that you don't have to get new developers' consent later on. Also, the code contributed by the deleted account (now called ghost) will have to be rewritten, because his account is now deleted and even if the author wanted to agree with this re-licensing, there is no way for him to prove that he was the owner of the deleted account. Same for the bugmen0t guy.
Good idea. I've added some wording.
Also, the code contributed by the deleted account (now called ghost) will have to be rewritten, because his account is now deleted and even if the author wanted to agree with this re-licensing, there is no way for him to prove that he was the owner of the deleted account. Same for the bugmen0t guy.
Yep, this code will either have to be removed, or remain GPL forever. This will probably happen a lot with MPlayer code.
Most of bugmen0t's changes affect ao_oss or the build system, so we don't have to care much. (If it gets serious, we could add a --enable-lgpl
configure option, which would not compile ao_oss.c.)
I agree that my past contributions to mpv, mplayer2, or MPlayer are relicensed to the GNU Lesser General Public License (LGPL) version 2.1 or later
I agree that my past contributions to mpv, mplayer2 or MPlayer are relicensed to the GNU Lesser General Public License (LGPL) version 2.1 or later.
I agree that my past contributions to mpv, mplayer2, or MPlayer are relicensed to the GNU Lesser General Public License (LGPL) version 2.1 or later
I agree that my past contributions to mpv, mplayer2, or MPlayer are relicensed to the GNU Lesser General Public License (LGPL) version 2.1 or later
I agree that my past contributions to mpv, mplayer2, or MPlayer are relicensed to the GNU Lesser General Public License (LGPL) version 2 or later.
I agree that my past contributions to mpv, mplayer2, or MPlayer are relicensed to the GNU Lesser General Public License (LGPL) version 2 or later.
I agree that my past contributions to mpv, mplayer2 or MPlayer are relicensed to the GNU Lesser General Public License (LGPL) version 2.1 or later.
I agree that my past contributions to mpv, mplayer2 or MPlayer are relicensed to the GNU Lesser General Public License (LGPL) version 2.1 or later.
@bugmen0t: so are you a real person, or was your login available on bugmenot.com?
Yeah, but we don't know if this worked at some point. Now that he actually posted again, it seems somewhat unlikely that he isn't a single person, but I'd still like confirmation.
This is a shared account. I'm not the original author of that code. I don't know how this works legaly to relicensing. Better rewrite this part of the code. I will remove the relicensibg agreement message. Sorry.
I think the original author doesn't use this github account anymore, it' old. The login and pass used to be hosted on bugmenot as a public account. It's on bugmenot.com/view/gist.com now.
Should I remove or keep bugmen0t on the list?
I agree that my past GPL contributions to mpv, mplayer2, or MPlayer are relicensed to the GNU Lesser General Public License (LGPL) version 2.1 or later, or, at your option, MIT License/BSD-2 clause License.
I don't see the need to relicense the 2-clause BSD code (e.g. Parse::Matroska) to LGPL, as it's more permissive than LGPL, but I could be convinced.
Hopefully I didn't miss anything above.
I don't see the need to relicense the 2-clause BSD code (e.g. Parse::Matroska) to LGPL, as it's more permissive than LGPL, but I could be convinced.
I'm only aiming to relicense GPL code. LGPL compatible licenses are ok.
Hey, I just heard about this.
I agree that my past contributions to mpv, mplayer2, or MPlayer are relicensed to the GNU Lesser General Public License (LGPL) version 2.1 or later.
I agree that my past contributions to mpv, mplayer2, or MPlayer are relicensed to the GNU Lesser General Public License (LGPL) version 2 or later.
@bugmen0t: sine you are a shared account, it's impossible to know what person or pull request you represent, and thus relicensing is impossible. We will probably have to remove your code (and that of your co-users) if it gets into the way of relicensing.
@wm4 Aren't licensing issues irrelevant when someome has not a single identity? I don't know how this works but it seems madness to rework all changes that it made because a throwaway account was used.
Dolphin had similar issues as far as I can remember. I'm not sure, but not everyone had to agree with the license change for it to successfully happen.
Another thing to consider is the threshold of originality. A trivial change (e.g. typo correction, non-functional change such as spacing/indenting) is not actually copyrightable.
Opinions how many contributors need to agree vary. I know Mozilla considered 95% of the source code has to be covered, while VLC assumed 99.9%. Since this is open source, and the license change is rather inoffensive (GPL to LGPL; for a project that wasn't a library originally, but which could be used by closed source programs through slave mode), I'd say it's not so important to get full coverage.
But in the end, there could always be someone appearing who wasn't asked or who didn't respond, and who says he doesn't agree with the license change. How do you handle this if the contribution was anonymous? Just because it was anonymous, it doesn't mean the copyright is void.
I think if someone deliberately posted code anonymously, which is the case with the bugmenot account, then that reasonably waives their claim to copyright. On Dec 16, 2015 5:50 PM, "V. Lang" notifications@github.com wrote:
Opinions how many contributors need to agree vary. I know Mozilla considered 95% of the source code has to be covered, while VLC assumed 99.9%. Since this is open source, and the license change is rather inoffensive (GPL to LGPL; for a project that wasn't a library originally, but which could be used by closed source programs through slave mode), I'd say it's not so important to get full coverage.
But in the end, there could always be someone appearing who wasn't asked or who didn't respond, and who says he doesn't agree with the license change. How do you handle this if the contribution was anonymous? Just because it was anonymous, it doesn't mean the copyright is void.
— Reply to this email directly or view it on GitHub https://github.com/mpv-player/mpv/issues/2033#issuecomment-165152088.
Berne Convention says that any expression is automatically under copyright. The real thing that would make it ignorable isn't that it isn't copyrighted, but that it's basically unenforceable. How would someone actually prove that they were the one to contribute that code on that day using the account?
But in the end, there could always be someone appearing who wasn't asked or who didn't respond, and who says he doesn't agree with the license change. How do you handle this if the contribution was anonymous? Just because it was anonymous, it doesn't mean the copyright is void.
What I want to know is the consequences of rewriting affect code in the event this happens, rather than necessarily right now. Since I'm operating under the assumption that literally nobody will care about the exact legal status of these (e.g. bugmen0t's) contributions in practice, the best course of action might just be to assume it's reasonable to include them in the relicensing and reconsider if anybody actually ever contests it.
Unfortunately, what I don't know is how stringent any relevant punishments would be in the event that somebody does decide mpv breaks some form of law, or rather, how lax our “well, we'll fix that then” period would be. (I also have no clue how that would even be enforced in a many-faceted multi-contributor project spanning a large number of international borders...)
Also, I think it's fair to assume that after a sufficient period of time and activity, anybody who is simultaneously e.g. a prehistoric contributor of MPlayer/mplayer2 code and still cares about the status of this codebase will have heard about the LGPL licensing issue. At some level we're going to have to rely on the fact that “everybody we can no longer identify or reach no longer cares” if we want anything to get done at all.
Some more contributors with github accounts who were not mentioned yet: @presto8: for a change in ipc.c @dilaroga: videotoolbox @zekica: a fix in vf_vavpp.c
On side note, the Dolphin/Mozilla assumption seems to be incorrect for us.
I've also started a thread on the MPlayer developer mailing list: http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2015-December/073259.html Of the people who replied, 3 agreed to relicense their changes, and 1 didn't answer this question - of those 4. 3 claim it's very hard to impossible, and I guess I have to agree with them. I don't even know how to map the svn handles to email addresses, and I'd have to harass people for commits they've done over a decade ago.
Anyway, I've made another step with relicensing mpv/mplayer2-only source files: 8a9b64329c0e387dc59a1fca477a43c50f59ff34
I agree that my contributions are relicenced under LGPL v2 (whether or not they are copyrightable).
I agree that my contributions are relicenced under LGPL v2 or later (whether or not they are copyrightable).
I agree that my past contributions to mpv, mplayer2, or MPlayer are relicensed to the GNU Lesser General Public License (LGPL) version 2.1 or later.
FAQ
What, why?
The mpv project (a MPlayer and mplayer2 fork) is relicensing its code base from GPLv2 or later to LGPLv 2.1 or later. For that, we're asking MPlayer, mplayer2, and mpv contributors to give us permission. This includes occasional or one-time contributors. For reasons why we are doing this and for details on the relicensing process see the sections below.
How do I give my permission?
Posting something informal like
in this github issue or per email to wm4 (nfxjfg@googlemail.com) should be sufficient. (I've also sent a lot of mails via a private mail account, because the gmail one looks like it could be dismissed as spam too easily.)
If you post on a github issue, and your github account doesn't show your real name or an email address you used for MPlayer development, please make sure to identify yourself so that we can link you to specific MPlayer contributions!
If you don't want to give permission to relicense some specific parts, but don't mind that the core is relicensed in general, it's possible that we negotiate a list of files or a list of commits we're allowed to relicense. This could explicitly exclude parts you want to keep GPL. You could also choose to state that relicensing any code still remaining in mpv is fine (this would exclude anything that is still in MPlayer, but not mpv).
I never contributed much and I don't even know if my code is still there. Why did I get email about this / why was I pinged on github? Do I even have to give my permission?
Some people say that their contribution was too minor and uncopyrightable, or that their code was replaced or refactored. This could be true. But we are not lawyers. It's not always sure what constitutes a minor/uncopyrightable change, or when new code is considered to be derived from some piece of replaced/refactored code. So getting as many agreements as possible is very helpful for us, even if the original authors of a patch think it doesn't matter, or it was a minor patch many years ago. Please respond to relicensing requests, even if you think it's not necessary!
It's also possible that you were asked, even though you did not contribute to MPlayer directly. For example you could have contributed to a different project, and MPlayer incorporated some of its code. That code would still be copyrighted by you (at least partially), so we need to ask for relicensing permission.
Were the email for relicensing requests sent automatically?
No. Every single of them was sent manually. They were sent only to people for which there was at least a chance that their agreement would be required.
Did the MPlayer project agree with this?
Most of the MPlayer developers agreed (including original and current developers). Most contributors who have been asked so far agreed as well. See the status of MPlayer contributors.
Do you assume non-replies mean agreement (OpenSSL style relicensing)?
No. Copyright law doesn't work this way. If someone doesn't reply, and he has copyright on parts we want to relicense, we will have to remove their code to succeed.
What happens if I don't agree?
Then the entire relicensing of mpv will fail. If there are only some cases, we'll probably try to remove the code of contributors who have not agreed (if possible). My plan B would be writing a new player from scratch.
Note that it might be fine to agree to relicensing of only some parts. We're mostly interested in relicensing the core, so a LGPL libmpv is possible. Also see the next FAQ entry below.
Will all of mpv be relicensed?
Most likely only the core and components required for libmpv. For example, it's unlikely that the X11 windowing code, the V4L TV code, or the DVD code get relicensed. These parts will remain GPL, and will not be compiled in LGPL configurations. On the other hand, many patches touching X11 also added code to other parts of the player, such as adding new options (which would later be supported by other windowing code) - we'd still want to relicense those changes.
Due to the aforementioned messy licensing state of the VO windowing backends, it looks like mpv CLI LGPL will be unusable on some systems (e.g. X11), while LGPL libmpv will hopefully be useful.
In addition, the following parts were removed from mpv, and we won't ask for relicensing those parts: mencoder, the GUI, Linux 2.4 kernel drivers (!), dozens of decoder library wrappers, the win32 codec loader, ancient video outputs, filters, the build system, documentation in general, and imported libraries such as a bunch of mpeg decoders. Some libraries were moved to separate projects and have already been relicensed a long time ago, like libswscale and libass. mpv is highly reliant on FFmpeg for decoders and demuxers, which probably accounts for most of the core code removed.
Will the license of MPlayer change?
Definitely not. To make it easier for us, we're skipping a lot of MPlayer code in the relicensing that is not used by mpv anymore (and that was not used to derive new mpv code from it). This is possible because mpv dropped large parts of MPlayer code (see previous question). All this means that even if you'd apply the relicensing agreements to MPlayer, you wouldn't get anything working out of it.
Do I lose the rights to my code?
No, you retain copyright and own your code. The effect is merely that others (the mpv project) can use your code under LGPL instead of only the GPL.
I made contributions to MPlayer, but I wasn't contacted?
Please reply to this github issue or send email to give your agreement/disagreement.
See also VLC's LGPL relicensing FAQ.
Reasons
The reason is mostly that the player got turned into a library (libmpv), and the associated problems of a GPL lib for a library user. Here's a detailed list of reasons why this is desirable, alternatives, and some discussion:
The main reason is easily the fact that mpv prefers embedding video by accessing the host application's OpenGL context. This means the host application has to link to libmpv directly and run in the same process as mpv, just for the GL context. This is called the opengl-cb API in libmpv. While technically possible in many cases, sharing some sort of video context (like an OpenGL context) over process boundaries is fragile and complex, so linking to libmpv is required.
MPlayer on the other hand embeds an OS window over process boundaries (with the
-wid
option). This is becoming technically unfeasible, and the libmpv opengl-cb API sidesteps many issues with it.While mpv can still be embedded using the "old" method (and by using e.g. the JSON API), we prefer the opengl-cb, and don't want license issues to hamper this. Nor do we want the rendering method to have an influence on the application's license.
Relicensing process
We will ask mpv, MPlayer, and mplayer2 developers for their agreement. We will probably skip contributors who contributed documentation or website changes only (MPlayer has extensive documentation in multiple languages, all in the main code repository). We will also skip developers who have contributed only to now-removed code (such as vo_svga.c or libswscale).
We will also ask people who have contributed single patches a long time ago, as long as their code was used as base for further developments. It's important and appreciated that these people give their agreement as well.
So far I think it's ok to relicense a source file if:
all current contents of the file are written by authors who agreed with the LGPL switch
removed contents do not count, as long as new code was not "derived" from it (such as simple refactoring)
care has to be taken that lines, which merely went through cosmetic changes or refactoring, are considered as "current content" (i.e. mere git blame output is not necessarily meaningful)
Authors which only did minor cosmetic changes of some sort do not have a copyright on the file (consider code reindenting). Extreme care has to be taken here - copyright always sticks, even with simple changes. It's not clear when a change is uncopyrightable. Most seem to agree that entirely cosmetic changes, e.g. pure whitespace changes, are not copyrightable. Some set the bar for copyrightable much higher.
Further, some projects which have gone through relicensing claim there is a threshold above which relicensing can be done without the rest of the developers agreeing:
Relicensing plan
The actual relicensing will be done as follows:
--enable-preliminary-lgpl3
configure option (done)--enable-lgpl
and updating the main copyright notice (done)More information
Other arguments pro-LGPL: https://github.com/mpv-player/mpv/issues/2033#issuecomment-249429195 https://github.com/mpv-player/mpv/issues/2033#issuecomment-249426616
MPlayer developers status: https://github.com/mpv-player/mpv/issues/2033#issuecomment-249416217
MPlayer thread: http://lists-archives.com/mplayer-dev-eng/39326-relicensing-mplayer-or-parts-of-it-to-lgpl.html
VLC LGPL switch reasons & FAQ (yes, they mostly apply to us too): https://www.videolan.org/press/lgpl.html
VLC reasons against GPLv3 (also mostly applies to us): http://www.videolan.org/press/2007-1.html