from https://raw.githubusercontent.com/mpv-player/mpv/master/Copyright > mpv is a fork of mplayer2, which is a fork of MPlayer. > > mpv as a whole is licensed as GPL version 2 or later (see LICENSE). Most source > files are GPLv2+, but some files are available under a more liberal license, > such as LGPLv2+, BSD, MIT, ISC, and possibly others. Look at the copyright > header of each source file, and grep the sources for "Copyright" if you need > to know details. Files without Copyright notice are licensed as LGPLv2+. > > For information about authors and contributors, consult the git log, which > contains the complete SVN and CVS history as well. > > Note that mplayer2 as a whole is licensed under GPLv3+. This is because it uses > a copy of talloc (part of Samba), which is LGPLv3+, and the next compatible > license for this mix is GPLv3+. > > MPlayer as a whole is licensed under GPLv2 (incompatible to GPLv3!), because > some files are licensed to GPLv2 (and _not_ any later version of the license). > In particular, this affects the file libmpdemux/demux_ty_osd.c. It is disabled > under mplayer2, and has been removed from mpv.
> mpv as a whole is licensed as GPL version 2 or later now ebuild has LICENSE="GPL-2", do you mean it should be 'LICENSE="GPL-2+"'?
(In reply to Nikoli from comment #1) > > mpv as a whole is licensed as GPL version 2 or later > > now ebuild has LICENSE="GPL-2", do you mean it should be 'LICENSE="GPL-2+"'? see the quote: > mpv as a whole is licensed as GPL version 2 or later (see LICENSE). Most source > files are GPLv2+, but some files are available under a more liberal license, > such as LGPLv2+, BSD, MIT, ISC, and possibly others. Look at the copyright > header of each source file also, while at it, there is no need to install /usr/share/doc/mpv-0.3.7/Copyright.xz
the quote implies that GPL is not the only license... and even suggests to check the source code headers, which will be some work...
also, the waf script you download has BSD license
Do not know much about license related rules in Gentoo, reading http://devmanual.gentoo.org/ebuild-writing/variables/index.html#license and https://wiki.gentoo.org/wiki/GLEP:23 did not help much too. As i understand from my experience, ebuilds do not keep list of licenses of _every_ file from sources in LICENSE variable, instead they only set license for compiled bins, which in some cases depends on enabled USE flags. I think turning LICENSE variable into a long list does not make any sense and affects usability of package managers negatively. If 'LGPLv2+, BSD, MIT, ISC, and possibly others' do not conflict with GPL-2+ and are not stricter, then i think it is correct to consider mpv bins GPL-2+. Docs and logos, i suppose, are licensed GPL-2+, because they are created as part of mpv project and nothing says copyright for them is different.
(In reply to Nikoli from comment #5) > As i understand from my experience, ebuilds do not keep list of licenses of > _every_ file from sources in LICENSE variable yes, they do
(In reply to Julian Ospald (hasufell) from comment #6) > (In reply to Nikoli from comment #5) > > As i understand from my experience, ebuilds do not keep list of licenses of > > _every_ file from sources in LICENSE variable > > yes, they do maybe license team thinks different about this at least BSD _must_ be included, since you redistribute and use the waf script directly in the ebuild
> yes, they do Can you provide link to Gentoo documentation stating this? Seems there was no such decision made yet, from #gentoo-dev-help: [19:16:34] <Nikoli> hi, i have question about licenses: do ebuilds set licenses for all files in sources or only for all installed files? [19:16:35] <Nikoli> https://bugs.gentoo.org/show_bug.cgi?id=506946#c5 [19:17:37] <floppym> Nikoli: That is a matter of some debate. I don't think we have documented policy on that. [19:17:53] <Nikoli> heh, as expacted [19:18:21] <floppym> Someone proposed adding a use flag to differentiate between them. [19:19:01] <Nikoli> but why would any user care about license for sources? [19:19:20] <Nikoli> if it does not have conlicts with license for installed files, it is fine [19:19:35] <Nikoli> if it has conflicts - it is task of package maintainer and upstream [19:20:17] <Tommy[D]> e.g. if you want to redistribute the source tarball locally via some mirror and the license of the source forbids it [19:20:34] <floppym> Here the discussion of that use flag: http://thread.gmane.org/gmane.linux.gentoo.devel/89408 [19:24:05] <Nikoli> Tommy[D], i think it is not problem at all: [19:25:30] <Nikoli> same license can allow you to build from your copy of sources, allow to distrubute compiled bins, but not allow to distribute your copy of sources [19:26:00] <ssuominen> Nikoli: LICENSE is only for files that actually get installed on the FS, or used during the build [19:26:52] <ssuominen> Nikoli: If the tarball has a subdirectory libs/ that has ~100 different bundled libs, but none of them are used during the build, and none of them are installed, LICENSE shouldn't cover them either [19:27:17] <Nikoli> 'used during the build' can mean a lot different things [19:27:34] <ssuominen> Otherwise we might as well reopen every bundled libs -bug ever fixed to refix them for LICENSE field or rerolling tarball [19:28:29] <ssuominen> Well if it's some .m4 file that's licensed BSD and the .m4 is used by the package's configure.ac, then you use it when you emerge it, LICENSE should reflect that [19:29:22] <ssuominen> but this is just how i've always seen it... i don't know if any of this is written down anywhere... [19:30:15] <Nikoli> what is use case for it? allow only GPL files, but disable packages with BSD files in sources? [19:30:58] <Nikoli> seems a bit like spamming LICENSE variable [19:32:22] <Nikoli> if building GPL software requires running some non gpl compatible (or even closed source) bin, then it makes sense to add license of the bin to LICENSE variable [19:32:56] <Nikoli> but if user agrees to run GPL code, he most likely will not be against running BSD code at build time
> but if user agrees to run GPL code, he most likely will not be against running > BSD code at build time That's a pretty wild assumption. And as said above... BSD must be included, since we redistribute that script separately on our mirrors... it is not affiliated with the mpv tarball at all.
> That's a pretty wild assumption. Well, BSD does not conflict with GPL, most likely it is not even possible to build and run GPL only linux distro without using BSD code, but i did not check. > BSD must be included, since we redistribute that script separately on our mirrors... it is not affiliated with the mpv tarball at all. Indeed waf is separate project and may be it would be better to package it instead of downloading precompiled python bytecode. While it is downloaded by mpv ebuild it makes sense to add license of waf to LICENSE. But may be it should be indicated, that waf is used only at build time?
From my point of view it is enough if the LICENSE covers all installed files, but there are other opinions, see the ML thread mentioned in comment #8. However, for free software it won't harm if licenses of all files in the source tarball are listed (as it doesn't affect license filtering for users accepting @FREE). The "srcdist" hasn't been implemented yet, and even if it was, I wouldn't use it for free licenses.
I've changed it to LICENSE="GPL-2+ BSD ISC" - GPL-2+ covers the main application - BSD for waf, which we distribute separately and is used in building - ISC for libmpv
I think current LICENSE="GPL-2+ BSD ISC" is not optimal, LICENSE="GPL-2+" is better: 1) Upstream Copyright tells "mpv as a whole is licensed as GPL version 2 or later" 2) GPL-2+ is stricter then both and any of BSD and ISC. Both BSD and ISC do not add any more restrictions then GPL-2, do they? 3) Listing all GPL-2+, WTFPL, Ms-PL, AGPLv3, 'LGPLv2+, BSD, MIT, ISC, and possibly others' (quote from upstream Copyright) in LICENSE variable is just too much noise, displaying the strictest is enough and makes most sense, and this is exactly what ffmpeg-2.6.1.ebuild does: LICENSE=" !gpl? ( LGPL-2.1 ) gpl? ( GPL-2 ) amr? ( gpl? ( GPL-3 ) !gpl? ( LGPL-3 ) ) encode? ( aac? ( gpl? ( GPL-3 ) !gpl? ( LGPL-3 ) ) amrenc? ( gpl? ( GPL-3 ) !gpl? ( LGPL-3 ) ) ) samba? ( GPL-3 ) "
(In reply to Nikoli from comment #13) > I think current LICENSE="GPL-2+ BSD ISC" is not optimal, LICENSE="GPL-2+" is > better: > 1) Upstream Copyright tells "mpv as a whole is licensed as GPL version 2 or > later" The LICENSE variable reflects the license(s) of the upstream package. mpv includes source files under BSD and ISC. These cannot be distributed under GPL-2+ instead. > 2) GPL-2+ is stricter then both and any of BSD and ISC. Both BSD and ISC do > not add any more restrictions then GPL-2, do they? Each of these licenses has its own different set of clauses. For example, BSD contains a non-endorsement clause which doesn't have its equivalent in the GPL. > 3) Listing all GPL-2+, WTFPL, Ms-PL, AGPLv3, 'LGPLv2+, BSD, MIT, ISC, and > possibly others' (quote from upstream Copyright) in LICENSE variable is just > too much noise, displaying the strictest is enough and makes most sense, Why is it too much noise? The upstream situation is (slightly) complex and the LICENSE variable represents this. I suggest to leave LICENSE at its current value ("GPL-2+ BSD ISC") and to close this bug again. All three licenses are listed in @FREE (even @GPL-COMPATIBLE), so users with common settings of their ACCEPT_LICENSE won't have any problems.
So is LICENSE= purpose to indicate all licenses of all compiled bins, installed files, files in source code archives and all other files used or downloaded during build? Also what about systems which do not build anything, but only use binary packages? I try to understand how licensing is working in Gentoo. About current ' # See Copyright in source tarball and bug #506946. Waf is BSD, libmpv is ISC. LICENSE="GPL-2+ BSD ISC" ': should not it be ' LICENSE="GPL-2+ BSD libmpv? ( ISC )" ' libmpv.a and libmpv.so are GPL-2+, only headers are ISC, these headers are not installed when USE libmpv is disabled. So are you sure ISC applies to USE='cli -libmpv' case?
(In reply to Nikoli from comment #15) > So is LICENSE= purpose to indicate all licenses of all compiled bins, > installed files, files in source code archives and all other files used or > downloaded during build? Also what about systems which do not build > anything, but only use binary packages? I try to understand how licensing is > working in Gentoo. > The fact is... it is not properly documented, see http://dev.gentoo.org/~ulm/pms/head/pms.html#x1-660007.2 https://devmanual.gentoo.org/general-concepts/licenses/index.html If you want to go through the pain of fixing either of those sources... have fun.
(In reply to Nikoli from comment #15) > About current ' > # See Copyright in source tarball and bug #506946. Waf is BSD, libmpv is ISC. > LICENSE="GPL-2+ BSD ISC" > ': should not it be ' > LICENSE="GPL-2+ BSD libmpv? ( ISC )" > ' > libmpv.a and libmpv.so are GPL-2+, only headers are ISC, these headers are > not installed when USE libmpv is disabled. So are you sure ISC applies to > USE='cli -libmpv' case? There is a couple of ISC licensed files in other directories too (audio, osdep, player, ta), so presumably ISC shouldn't be conditional with USE=libmpv. But feel free to do a full audit what is actually installed with different USE flags.
The best thing to do here would be a full audit, and adding complete license information, in the vein of the ffmpeg example. I agree it looks messy, but it is better to err on the side of (over-)completeness when it comes to licensing matters. This is why I will leave this bug report open now. For the time being, I think we have a better situation than before, so we should not regress to less license information.
Recent versions of mpv have '--enable-gpl3' configure option, which enables more code with unclear license information. Upstream claims it should be GPL-3/LGPL-3, but from the gathered info it follows that it's not this simple. See https://bugs.gentoo.org/show_bug.cgi?id=571728 for more info on this matter. Currently this configure option is forcibly disabled.
(In reply to Coacher from comment #19) > Recent versions of mpv have '--enable-gpl3' configure option, which enables > more code with unclear license information. Upstream claims it should be > GPL-3/LGPL-3, but from the gathered info it follows that it's not this > simple. > > See https://bugs.gentoo.org/show_bug.cgi?id=571728 for more info on this > matter. > > Currently this configure option is forcibly disabled. now there is such option like '--disable-gpl3' and '--enable-gpl3'
(In reply to Perfect Gentleman from comment #20) > (In reply to Coacher from comment #19) > > Recent versions of mpv have '--enable-gpl3' configure option, which enables > > more code with unclear license information. Upstream claims it should be > > GPL-3/LGPL-3, but from the gathered info it follows that it's not this > > simple. > > > > See https://bugs.gentoo.org/show_bug.cgi?id=571728 for more info on this > > matter. > > > > Currently this configure option is forcibly disabled. > > now there is such option like '--disable-gpl3' and '--enable-gpl3' now there are no such options like '--disable-gpl3' and '--enable-gpl3'
Latest versioned (0.25.0) and current live ebuilds have LICENSE that matches the current mpv licensing status [1]. Thus, I think this bug can be considered fixed as the license information is now as complete as upstream knows about it. Upstream LGPL relicensing will take a while, I'll be keeping an eye for any further required LICENSE updates. Thanks everyone. [1]: https://github.com/mpv-player/mpv/blob/e2b9551213187a62674e8e68e963af934e99ef9f/Copyright#L49
