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

  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
  

  in this github issue or per email to wm4 ([email protected]) 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.

• MPlayer always provided the slave mode, which allows closed source application to use MPlayer's playback capabilities. And there are even examples of this happening (MPlayerX). So MPlayer being GPL did not prevent it to be used from non-GPL applications. It follows that the MPlayer projects and its developers at least tolerate slave mode being used from non-GPL applications. I see no reason why this difference should be made just with the technical difference of in-process vs. out-of-process and C API vs. text protocol. Thus allowing libmpv to be used from non-GPL application is just natural. Relicensing to LGPL would achieve this.

• GPL-incompatible dependencies such as OpenSSL are a big issue for library users, even if the library user is ok with the GPL. OpenSSL specifically is not compatible with the GPL, unless all involved GPL projects include an OpenSSL exception (but this is equivalent to a license change, so why not just use the less problematic LGPL). Note that not-GPL does not mean closed-source. There are many potential users who want to stick to other open source licenses that are not GPL.

• Even many GNU libraries don't force GPL on the user (consider glibc, Guile, gettext, GNU lightning, GNU pth).

• LGPL is almost like GPL, except it gives more freedom to the library user. This should be a rather inoffensive change (compared to e.g. changing it to BSD). Since (lib)mpv is a complete player, rather than something like a multimedia library, the "freedom" of libmpv isn't in danger either. For example, if you wanted to add a filter or a decoder to your playback chain, you would have to do that in libmpv itself (licensing the addition as LGPL), rather than making it a closed-source part of your evil proprietary application.

• Even if libmpv were to stay GPL, it would not necessarily lead to more applications going open source. It's far more likely such an application would choose something like libvlc or gstreamer as backend instead. This could even happen with potential libmpv users which are open source, but not GPL, as its authors might want to escape from the complications of the GPL license. Likewise, existing non-GPL applications, which just want to integrate video playback as another feature, would obviously not be able to pick a GPL libmpv (libmpv isn't that attractive as they would relicense to GPL just to use it). My conclusion is that libmpv going LGPL would give back more to the open source community than a GPL libmpv.

• VLC did it too, and nothing bad happened.

• Parts of MPlayer code have been relicensed/"extracted" under more liberal licenses before: libswscale (LGPL), libass (ISC)

• An exception for non-GPL libmpv usage might work. This would be a GPL linking exception. It'd require as much effort as a switch to LGPL, so we might as well change to LGPL.

• Some libmpv user opinions: LGPL relicensing #2033 (comment) and LGPL relicensing #2033 (comment)

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:

• VLC thinks 99.99% of the code must be covered and 99% of all developers (https://mailman.videolan.org/pipermail/vlc-commits/2011-November/010353.html)
• Dolphin and Mozilla think only 95% of all contributors must have agreed (https://dolphin-emu.org/blog/2015/05/25/relicensing-dolphin/ http://blogs.fsfe.org/ciaran/?p=58)

Relicensing plan

The actual relicensing will be done as follows:

• Phase 1: broadly probe for consent (done)
  • ask everyone who submitted a patch to mpv
  • contact everyone who wrote a major piece of code and ask for permission
• Phase 2: ask every contributor (mostly done, waiting for potential late replies)
  • go through the commit list, and look at every single of those ~44k commits
  • if the commit message says the patch was by someone else (or we know it was by someone else or copied from somewhere else), contact that external controbutor as well
  • if the code is most likely still present in mpv (directly or refactored), and not in code we don't want to relicense, make sure that person was contacted
• Phase 3: actual relicensing (mostly done)
  • try to relicense each source file
  • go through every change to that file, and make sure that for each change (unless it was completely removed) the author was contacted and agreed
  • if that is not the case, do one of those things, depending on what's possible:
    • guard the code as GPL-only (so it won't be compiled for LGPL binaries)
    • remove/replace the code
    • declare the change as trivial
    • fail the relicensing and go with plan B, and write a new player
  • in some cases, code might have been copied from other source files or projects, which complicates this step
• Phase 4: verification and finishing up (done, relicensing of some optional parts is still pending)
  • add a preliminary --enable-preliminary-lgpl3 configure option (done)
  • post to mplayer-dev-eng mailing list for anyone who wants to verify (done)
  • let it sit for a few weeks or so (done)
  • make the LGPL change final by renaming the configure option to --enable-lgpl and updating the main copyright notice (done)

More information

Other arguments pro-LGPL: #2033 (comment) #2033 (comment)

MPlayer developers status: #2033 (comment)

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