Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 492424 - www-client/chromium: incomplete LICENSE
Summary: www-client/chromium: incomplete LICENSE
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Chromium Project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-24 11:58 UTC by Ulrich Müller
Modified: 2017-04-20 21:13 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ulrich Müller gentoo-dev 2013-11-24 11:58:30 UTC
LICENSE says just "BSD", but there are several other licenses, especially in the various third-party directories. I haven't done a complete license audit, but some random sampling shows GPL, LGPL, MIT, and MPL-1.1.

Please specify all relevant licenses in the LICENSE string. It should also be clarified if redistribution of the binary package is allowed, as it apparantly combines GPL code with code under GPL-incompatible licenses (such as MPL-1.1 or openssl).
Comment 1 Paweł Hajdan, Jr. (RETIRED) gentoo-dev 2013-12-10 16:26:57 UTC
(In reply to Ulrich Müller from comment #0)
> Please specify all relevant licenses in the LICENSE string.

Will do. Could you clarify what is considered relevant?

Is code that is not part of compiled package relevant? What about code that is only used during build, but does not make it into the binaries? Then there is also likely code that is not used for anything (either used on other platform, or e.g. unbundled, or only used for some tests).

> It should also be clarified if redistribution of the binary package
> is allowed, as it apparantly combines GPL code with code under
> GPL-incompatible licenses (such as MPL-1.1 or openssl).

Please avoid speculating about this.

First, how would I clarify this? Note that there is a "bindist" USE flag for binary redistribution. Of course there are no guarantees.

Then, the browser itself cannot be GPL, to allow Google to ship Chrome. My understanding is that GPL code can only be used for tests, and some files/dependencies are under a dual license in which case we'd be using them under non-GPL terms.

Standard disclaimer (applies to this and all of my posts on this bug): I'm not a lawyer.
Comment 2 Richard Freeman gentoo-dev 2013-12-10 17:48:46 UTC
(In reply to Paweł Hajdan, Jr. from comment #1)
> (In reply to Ulrich Müller from comment #0)
> > Please specify all relevant licenses in the LICENSE string.
> 
> Will do. Could you clarify what is considered relevant?
> 
> Is code that is not part of compiled package relevant? What about code that
> is only used during build, but does not make it into the binaries? Then
> there is also likely code that is not used for anything (either used on
> other platform, or e.g. unbundled, or only used for some tests).

Just my own personal two cents, but I'd think that we'd want LICENSE to cover anything in the SRC_URI.  That's what is actually getting distributed by us.  If we include a copy of a Top-40 CD in the tarball we'll have problems even if the first thing the ebuild does is delete it.
Comment 3 Ulrich Müller gentoo-dev 2013-12-10 18:08:32 UTC
(In reply to Paweł Hajdan, Jr. from comment #1)
> > Please specify all relevant licenses in the LICENSE string.
> 
> Will do. Could you clarify what is considered relevant?
> 
> Is code that is not part of compiled package relevant? What about code that
> is only used during build, but does not make it into the binaries? Then
> there is also likely code that is not used for anything (either used on
> other platform, or e.g. unbundled, or only used for some tests).

My interpretation was always that LICENSE should specify everything that will be installed on a user's system. So build tools and files used only on another platform would be excluded, but e.g. the license of a file installed from ${FILESDIR} would have to be included. This also allows to control optionally installed pieces of a package (that have a more restrictive license) via USE flags, without jumping through hoops.

I'm aware that there are other opinions, see rich0's comment.

> > It should also be clarified if redistribution of the binary package
> > is allowed, as it apparantly combines GPL code with code under
> > GPL-incompatible licenses (such as MPL-1.1 or openssl).
> 
> Please avoid speculating about this.
> 
> First, how would I clarify this? Note that there is a "bindist" USE flag for
> binary redistribution. Of course there are no guarantees.

As I said, I haven't done a complete license audit, and I haven't investigated the details of what parts are linked together. Some of the MPL-1.1 stuff seems to be dual-licensed, so maybe it is o.k.
Comment 4 Alexander Berntsen (RETIRED) gentoo-dev 2013-12-10 18:59:22 UTC
The fact that there are multiple interpretations of the ramifications of the LICENSE field, coupled with the fact that neither the PMS nor the devmanual actually specifies it any more than "The package’s license" leads me to believe we need a clear and concise definition of this.