[gentoo-dev] Contributed ebuilds and copyright questions

[gentoo-dev] Contributed ebuilds and copyright questions

[Matt Turner]

A former co-worker of mine is now at Google and wants to contribute
ebuilds he wrote for ChromeOS to Gentoo. They add packages necessary
for Vulkan (new 3D graphics API).

For instance: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/media-libs/vulkan-loader/vulkan-loader-1.0.24.0.ebuild

The copyright header says "Copyright 2016 The Chromium OS Authors. All
rights reserved." All ebuilds in gentoo.git say "Copyright 1999-20xx
Gentoo Foundation".

Can I add ebuilds copyrighted by others to gentoo.git?

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 1393 bytes --]

On Monday, October 24, 2016 3:29:30 PM EDT Matt Turner wrote:
> A former co-worker of mine is now at Google and wants to contribute
> ebuilds he wrote for ChromeOS to Gentoo. They add packages necessary
> for Vulkan (new 3D graphics API).
> 
> For instance:
> https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/
> master/media-libs/vulkan-loader/vulkan-loader-1.0.24.0.ebuild
> 
> The copyright header says "Copyright 2016 The Chromium OS Authors. All
> rights reserved." All ebuilds in gentoo.git say "Copyright 1999-20xx
> Gentoo Foundation".
> 
> Can I add ebuilds copyrighted by others to gentoo.git?

For the time being since there is not another way to address. I have been 
going with the following. Which should suffice for now, but could clutter up 
ebuilds if it happens to allot. At the same time it should reflect origin 
somewhere, and not sure buried VC commit log  is enough.

# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$
#
# Original work Copyright 2016 Obsidian-Studios, Inc.
# Ebuild written by "William L. Thomson Jr." <wlt@o-sinc.com>
# <link to ebuild in this repo>

Per my readme
https://github.com/Obsidian-StudiosInc/os-xtoo

It was inspired by from source icedtea ebuilds. I can't recall where I saw the 
original work but got it from some where.

-- 
William L. Thomson Jr.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Rich Freeman]

On Mon, Oct 24, 2016 at 6:29 PM, Matt Turner <mattst88@gentoo.org> wrote:
> A former co-worker of mine is now at Google and wants to contribute
> ebuilds he wrote for ChromeOS to Gentoo. They add packages necessary
> for Vulkan (new 3D graphics API).
>
> For instance: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/media-libs/vulkan-loader/vulkan-loader-1.0.24.0.ebuild
>
> The copyright header says "Copyright 2016 The Chromium OS Authors. All
> rights reserved." All ebuilds in gentoo.git say "Copyright 1999-20xx
> Gentoo Foundation".
>
> Can I add ebuilds copyrighted by others to gentoo.git?
>

As long as you have their permission to change the copyright notice.
You cannot currently commit anything with a different copyright notice
to gentoo.git, and you cannot legally change it without permission.

-- 
Rich

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Matt Turner]

On Mon, Oct 24, 2016 at 4:03 PM, Rich Freeman <rich0@gentoo.org> wrote:
> You cannot currently commit anything with a different copyright notice
> to gentoo.git

According to whom or what?

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Rich Freeman]

On Mon, Oct 24, 2016 at 7:12 PM, Matt Turner <mattst88@gentoo.org> wrote:
> On Mon, Oct 24, 2016 at 4:03 PM, Rich Freeman <rich0@gentoo.org> wrote:
>> You cannot currently commit anything with a different copyright notice
>> to gentoo.git
>
> According to whom or what?
>

https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
Under ebuild header.

This is a Gentoo policy.  Repoman will complain if you violate this.
It will get noticed and treecleaned if you ignore repoman.  Devs who
violate the policy will be warned, etc.

The policy could be changed, and there have been discussions around
improvements:
https://dev.gentoo.org/~rich0/copyrightpolicy.xml

The main issue I'm aware of with that draft is that it is painful to
track who has copyright on what to put the proper copyright notice on
each file.  Suggestions are welcome.

-- 
Rich

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Matt Turner]

On Mon, Oct 24, 2016 at 4:18 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Mon, Oct 24, 2016 at 7:12 PM, Matt Turner <mattst88@gentoo.org> wrote:
>> On Mon, Oct 24, 2016 at 4:03 PM, Rich Freeman <rich0@gentoo.org> wrote:
>>> You cannot currently commit anything with a different copyright notice
>>> to gentoo.git
>>
>> According to whom or what?
>>
>
> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
> Under ebuild header.

Thank you.

> This is a Gentoo policy.  Repoman will complain if you violate this.
> It will get noticed and treecleaned if you ignore repoman.  Devs who
> violate the policy will be warned, etc.
>
> The policy could be changed, and there have been discussions around
> improvements:
> https://dev.gentoo.org/~rich0/copyrightpolicy.xml
>
> The main issue I'm aware of with that draft is that it is painful to
> track who has copyright on what to put the proper copyright notice on
> each file.  Suggestions are welcome.

Yeah, it seems to be painful no matter what you do (CLA, copyright
assignment, listing copyright holders) just in different ways :)

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Rich Freeman]

On Mon, Oct 24, 2016 at 7:31 PM, Matt Turner <mattst88@gentoo.org> wrote:
>
> Yeah, it seems to be painful no matter what you do (CLA, copyright
> assignment, listing copyright holders) just in different ways :)
>

Well, the advantage of assignment is that it does simplify copyright
tracking, since you own the copyright on everything.

The problem is that it potentially cuts out a lot of contributions.
There is also the problem of nations that do not allow assignment
(though that could also be fixed in theory by just ending the Gentoo
German conspiracy).

I personally tend to favor a mandatory DCO (we absolutely need to know
the copyright status of our code), and a voluntary FLA (which I tend
to prefer to outright assignment as I think it lines up well with our
always-free social contract).

The issue remains of what to do with the copyright notice.  I
suggested just having enough names on the line to account for 51% of
the code, which as far as I can tell is completely legal.  That
doesn't preclude just listing all the names (which is ugly, but
administratively simple).  But, that does help cover us in cases where
we have some ebuild where we can only account for 60% of it.  It also
allows us to borrow anything from any other project that already has
its copyrights well-documented.

FYI, one of the original sparks that drove some of this thinking was
the eudev copyright fiasco (which like a lot of systemd-related stuff
was blown out of proportion IMO with things being attributed to malice
which were simply a lack of thinking things through).  This was the
first time Gentoo really forked and internalized a major external
project, and there was a clash between our previous practices designed
for dev-written code and the large import of external code.  Under the
draft copyright policy we'd have just maintained the previous
copyright headers, perhaps just reformatting them to the top of the
file per our convention if they weren't already there (which is
completely legal).  If at some point enough code in a file got
rewritten to have majority-FLA authorship we'd have the option to
change it to Gentoo and others, though we wouldn't have to.

-- 
Rich

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Matt Turner]

On Mon, Oct 24, 2016 at 4:43 PM, Rich Freeman <rich0@gentoo.org> wrote:
> I personally tend to favor a mandatory DCO (we absolutely need to know
> the copyright status of our code), and a voluntary FLA (which I tend
> to prefer to outright assignment as I think it lines up well with our
> always-free social contract).

Do you have any ideas about how that might work for previous
contributions? Plenty of developers have come and gone (and died!)
since gentoo began accepting commits.

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Rich Freeman]

On Mon, Oct 24, 2016 at 7:47 PM, Matt Turner <mattst88@gentoo.org> wrote:
> On Mon, Oct 24, 2016 at 4:43 PM, Rich Freeman <rich0@gentoo.org> wrote:
>> I personally tend to favor a mandatory DCO (we absolutely need to know
>> the copyright status of our code), and a voluntary FLA (which I tend
>> to prefer to outright assignment as I think it lines up well with our
>> always-free social contract).
>
> Do you have any ideas about how that might work for previous
> contributions? Plenty of developers have come and gone (and died!)
> since gentoo began accepting commits.
>

Existing copyright headers would be grandfathered as-is unless
somebody comes forward with a specific concern.  Over time the tree
just improves.  That is my suggestion at least, it is certainly no
worse than we are today, and a decade from now the really old stuff
will be gone.

-- 
Rich

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 1742 bytes --]

On 10/24/2016 04:18 PM, Rich Freeman wrote:
> On Mon, Oct 24, 2016 at 7:12 PM, Matt Turner <mattst88@gentoo.org> wrote:
>> On Mon, Oct 24, 2016 at 4:03 PM, Rich Freeman <rich0@gentoo.org> wrote:
>>> You cannot currently commit anything with a different copyright notice
>>> to gentoo.git
>>
>> According to whom or what?
>>
> 
> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
> Under ebuild header.
> 
> This is a Gentoo policy.  Repoman will complain if you violate this.
> It will get noticed and treecleaned if you ignore repoman.  Devs who
> violate the policy will be warned, etc.
> 
> The policy could be changed, and there have been discussions around
> improvements:
> https://dev.gentoo.org/~rich0/copyrightpolicy.xml
> 
> The main issue I'm aware of with that draft is that it is painful to
> track who has copyright on what to put the proper copyright notice on
> each file.  Suggestions are welcome.
> 
This made me think of another scenario; let's say I have my own fork of
Gentoo, maintained in an overlay complete with docs, etc, under an MIT
or BSD license, but as a Gentoo developer, I must copyright under GPL.
Could I do such dual licensing on a case-by-case basis because (in this
hypothetical) I'm the original author of the ebuilds?

If so, then Matt's coworker could offer the same ebuild under a
Gentoo-friendly license and maintain copyright on Google's overlay. The
only question at that point would be Google's own copyright policy and
whether or not its employees own any of what they produce on company time.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Rich Freeman]

On Tue, Oct 25, 2016 at 12:48 AM, Daniel Campbell <zlg@gentoo.org> wrote:
> This made me think of another scenario; let's say I have my own fork of
> Gentoo, maintained in an overlay complete with docs, etc, under an MIT
> or BSD license, but as a Gentoo developer, I must copyright under GPL.
> Could I do such dual licensing on a case-by-case basis because (in this
> hypothetical) I'm the original author of the ebuilds?

Well, you could certainly dual-license anything you're the author of.
A complete fork of Gentoo under the BSD license would probably be
impractical though since you'd have to rewrite everything.

>
> If so, then Matt's coworker could offer the same ebuild under a
> Gentoo-friendly license and maintain copyright on Google's overlay. The
> only question at that point would be Google's own copyright policy and
> whether or not its employees own any of what they produce on company time.

The chromiumos ebuilds are already under a friendly license.  The only
issue is what to put in the copyright header.  Under the proposed new
policy the ebuilds could just be copied into the tree wholesale, since
they're already under the correct license and the chromiumos headers
would be fine under the new policy, perhaps just with the addition of
"and others" as soon as any changes get made.

If they were under a non-compatible license like the CDDL then it
would depend on whether the authors have the right to dual-license it
under the GPL, or whether Gentoo is willing to accept CDDL-licensed
ebuilds into the repository.  Part of the draft policy is that every
Gentoo project/repository have a list of accepted licenses.  Off the
top of my head I can't think of any issues with allowing incompatible
but similar copyleft licenses into the main tree.  The files
themselves are standalone, and I'm not sure to what degree the actual
built binaries inherit their copyright.  Perhaps there are some
situations where you could have bindist issues, but I suspect they
would be isolated.

I was actually chatting with somebody about the issue of package
licensing vs upstream licensing (which is an issue we don't have as
many problems with since we don't aggregate package metadata with the
actual package contents).  We didn't really talk about the licensing
of the final on-system binary which is mainly upstream-controlled but
whose installation details are influenced by the distro.

-- 
Rich

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Paweł Hajdan, Jr.]

[-- Attachment #1.1: Type: text/plain, Size: 377 bytes --]

On 25/10/2016 01:03, Rich Freeman wrote:
> As long as you have their permission to change the copyright notice.
> You cannot currently commit anything with a different copyright notice
> to gentoo.git, and you cannot legally change it without permission.

How should that permission be documented?

Is a statement the original author consents sufficient?

Paweł



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Rich Freeman]

On Tue, Oct 25, 2016 at 6:49 AM, Paweł Hajdan, Jr.
<phajdan.jr@gentoo.org> wrote:
> On 25/10/2016 01:03, Rich Freeman wrote:
>> As long as you have their permission to change the copyright notice.
>> You cannot currently commit anything with a different copyright notice
>> to gentoo.git, and you cannot legally change it without permission.
>
> How should that permission be documented?
>
> Is a statement the original author consents sufficient?
>

I suspect that the DCO is probably sufficient under the proposed new
policy.  If the Linux Foundation can stick code written by full-time
employees of the likes of Oracle into their repository with nothing
more than a Signed-off-by saying that whoever contributed it is sure
it is fine, we should probably consider that this ought to be good
enough for that.

Reading the DCO clauses b/c are designed to cover code from 3rd parties.

If you're asking about the current policy, I doubt we have anything so
formal in writing (which was one of the reasons I started the draft of
the new policy).  I'd suggest working with the license team or the
Trustees before bringing any code of questionable copyright status
into the tree.

-- 
Rich

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]

>>>>> On Tue, 25 Oct 2016, Rich Freeman wrote:

> If they were under a non-compatible license like the CDDL then it
> would depend on whether the authors have the right to dual-license
> it under the GPL, or whether Gentoo is willing to accept
> CDDL-licensed ebuilds into the repository. Part of the draft policy
> is that every Gentoo project/repository have a list of accepted
> licenses. Off the top of my head I can't think of any issues with
> allowing incompatible but similar copyleft licenses into the main
> tree.

Having different licenses for ebuilds in the main tree would be a
nightmare, IMHO. It would make exchange of code between different
ebuilds much harder, if not impossible. Think of global issues like
the multilib conversion where similar code is used in many places.

Also, calling eclass functions could be considered linking. It is not
entirely clear to me if e.g. a binpkg built with a CDDL licensed
ebuild calling GPL licensed eclasses would be distributable at all.

So can we be strict there, please? Contributed ebuilds should have our
standard copyright header, or they will be rejected.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Rich Freeman]

On Tue, Oct 25, 2016 at 8:54 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>
> Also, calling eclass functions could be considered linking. It is not
> entirely clear to me if e.g. a binpkg built with a CDDL licensed
> ebuild calling GPL licensed eclasses would be distributable at all.

Honestly, I think the GPL linking argument is a difficult one at best,
but setting that aside I think it is even harder to consider calling a
function in an interpreted language "linking."  Is it a violation of
the GPL to execute a GPL binary from a bash script that is
GPL-incompatible?  Heck, is it a violation of the other license for
the GPL bash interpreter to read and execute the non-GPL lines in the
script?

To me linking and word processing are actually on a continuum and I
think it is hard to draw a line and say that the GPL prohibits one and
not the other, but if you are going to try to draw a line I think
interpreted languages are going to fall on the safe side of it.

I guess it comes down to what are the essential elements of linking
that leads one to believe that it constitutes a violation of copyright
to do it without explicit permission?  If there is agreement on that
(which I think is harder to achieve than some seem to think), then the
question becomes whether calling a function in an interpreted language
contains those elements.

>
> So can we be strict there, please? Contributed ebuilds should have our
> standard copyright header, or they will be rejected.
>

Certainly this is the current policy.  The draft policy envisions a
table of licenses for each project, and we of course can make that
table as restrictive or free as desired.  I do think it makes sense to
whitelist licenses individually by project for the very sorts of
reasons that you bring up.

-- 
Rich

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Alexis Ballier]

On Tue, 25 Oct 2016 09:17:08 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Tue, Oct 25, 2016 at 8:54 AM, Ulrich Mueller <ulm@gentoo.org>
> wrote:
> >
> > Also, calling eclass functions could be considered linking. It is
> > not entirely clear to me if e.g. a binpkg built with a CDDL licensed
> > ebuild calling GPL licensed eclasses would be distributable at
> > all.  
> 
> Honestly, I think the GPL linking argument is a difficult one at best,
> but setting that aside I think it is even harder to consider calling a
> function in an interpreted language "linking."  Is it a violation of
> the GPL to execute a GPL binary from a bash script that is
> GPL-incompatible?  Heck, is it a violation of the other license for
> the GPL bash interpreter to read and execute the non-GPL lines in the
> script?


The concept is "derived work": If your script cannot work without the
GPL binary, then it is derived work.


Alexis.

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Rich Freeman]

On Tue, Oct 25, 2016 at 9:56 AM, Alexis Ballier <aballier@gentoo.org> wrote:
> On Tue, 25 Oct 2016 09:17:08 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>
>> On Tue, Oct 25, 2016 at 8:54 AM, Ulrich Mueller <ulm@gentoo.org>
>> wrote:
>> >
>> > Also, calling eclass functions could be considered linking. It is
>> > not entirely clear to me if e.g. a binpkg built with a CDDL licensed
>> > ebuild calling GPL licensed eclasses would be distributable at
>> > all.
>>
>> Honestly, I think the GPL linking argument is a difficult one at best,
>> but setting that aside I think it is even harder to consider calling a
>> function in an interpreted language "linking."  Is it a violation of
>> the GPL to execute a GPL binary from a bash script that is
>> GPL-incompatible?  Heck, is it a violation of the other license for
>> the GPL bash interpreter to read and execute the non-GPL lines in the
>> script?
>
> The concept is "derived work": If your script cannot work without the
> GPL binary, then it is derived work.
>

I don't think any well-recognized organization argues that scripts are
derived works of the binaries they call.  Besides, literally the only
thing about the binary that a script contains is the name of the
binary, and some command line options.  This seems like it is going
even further than suggesting that APIs be copyrightable.

-- 
Rich

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Alexis Ballier]

On Tue, 25 Oct 2016 10:15:09 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Tue, Oct 25, 2016 at 9:56 AM, Alexis Ballier <aballier@gentoo.org>
> wrote:
> > On Tue, 25 Oct 2016 09:17:08 -0400
> > Rich Freeman <rich0@gentoo.org> wrote:
> >  
> >> On Tue, Oct 25, 2016 at 8:54 AM, Ulrich Mueller <ulm@gentoo.org>
> >> wrote:  
> >> >
> >> > Also, calling eclass functions could be considered linking. It is
> >> > not entirely clear to me if e.g. a binpkg built with a CDDL
> >> > licensed ebuild calling GPL licensed eclasses would be
> >> > distributable at all.  
> >>
> >> Honestly, I think the GPL linking argument is a difficult one at
> >> best, but setting that aside I think it is even harder to consider
> >> calling a function in an interpreted language "linking."  Is it a
> >> violation of the GPL to execute a GPL binary from a bash script
> >> that is GPL-incompatible?  Heck, is it a violation of the other
> >> license for the GPL bash interpreter to read and execute the
> >> non-GPL lines in the script?  
> >
> > The concept is "derived work": If your script cannot work without
> > the GPL binary, then it is derived work.
> >  
> 
> I don't think any well-recognized organization argues that scripts are
> derived works of the binaries they call.  Besides, literally the only
> thing about the binary that a script contains is the name of the
> binary, and some command line options.  This seems like it is going
> even further than suggesting that APIs be copyrightable.


This has nothing to do with APIs nor what it contains. This has to do
whether your program still does what you claim it does if you remove
the GPL parts.

If I write a QT gui that forks/exec x264 cli and want to sell it as the
best H264 encoder on the market, then I have to comply with x264
license since it won't do what I claim once x264 is removed.
If I want to sell the same program as a QT gui for x264 cli, then it is
far less clear whether it is derivative work, but I'll certainly have
more difficulties in selling it :)



Back to the subject, a CDDL ebuild is a CDDL script to install a
program. If you can't install the program without the GPL parts (that
are distributed inside the same binpkg iirc), then it is derivative
work.

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]

>>>>> On Tue, 25 Oct 2016, Rich Freeman wrote:

>> Also, calling eclass functions could be considered linking. It is not
>> entirely clear to me if e.g. a binpkg built with a CDDL licensed
>> ebuild calling GPL licensed eclasses would be distributable at all.

> Honestly, I think the GPL linking argument is a difficult one at best,
> but setting that aside I think it is even harder to consider calling a
> function in an interpreted language "linking."  Is it a violation of
> the GPL to execute a GPL binary from a bash script that is
> GPL-incompatible?  Heck, is it a violation of the other license for
> the GPL bash interpreter to read and execute the non-GPL lines in the
> script?

Generally, the user can execute any combination of such functions on
his system, without violating their licenses. The question is if a
combined work containing parts of the ebuild and of the eclass can be
distributed.

Now a Gentoo binary package contains an xpak part, which in turn
contains a file named environment.bz2 where you will find functions
originating both from the ebuild and from its inherited eclasses.
Certainly the xpak is a derived work of ebuild _and_ eclasses, so for
distributing the binpkg both CDDL (to come back to the original
example) and GPL-2 would have to be honoured. Which is not possible
because these two licenses are incompatible.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Rich Freeman]

On Tue, Oct 25, 2016 at 11:17 AM, Alexis Ballier <aballier@gentoo.org> wrote:
>
> If I write a QT gui that forks/exec x264 cli and want to sell it as the
> best H264 encoder on the market, then I have to comply with x264
> license since it won't do what I claim once x264 is removed.

The QT gui could be distributed under any license you care to, since
it doesn't contain anything from x264.  It might not actually do
anything without the x264 binary, but it can be legally redistributed
on its own under your choice of license (if you're the author).

Now, if you want to redistribute the x264 binary then of course you
need to comply the with the x264 license.

Running a program from a script doesn't make your script a derivative
work of that program.  They each have their own license, and can be
independently redistributed.

> If I want to sell the same program as a QT gui for x264 cli, then it is
> far less clear whether it is derivative work, but I'll certainly have
> more difficulties in selling it :)

I don't really see how marketing changes something's status as a
derivative work.  Certainly I'm not aware of any court decision to
this effect, or any law.

> Back to the subject, a CDDL ebuild is a CDDL script to install a
> program. If you can't install the program without the GPL parts (that
> are distributed inside the same binpkg iirc), then it is derivative
> work.

I disagree.  We in fact allow GPL ebuilds in the Gentoo repository
that install proprietary software which is subject to licenses which
are GPL-incompatible.  The fact that your script automates running a
bunch of proprietary code doesn't change the fact that your script
itself is completely free software, governed by its own license.

-- 
Rich

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Rich Freeman]

On Tue, Oct 25, 2016 at 11:53 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Tue, 25 Oct 2016, Rich Freeman wrote:
>
>>> Also, calling eclass functions could be considered linking. It is not
>>> entirely clear to me if e.g. a binpkg built with a CDDL licensed
>>> ebuild calling GPL licensed eclasses would be distributable at all.
>
>> Honestly, I think the GPL linking argument is a difficult one at best,
>> but setting that aside I think it is even harder to consider calling a
>> function in an interpreted language "linking."  Is it a violation of
>> the GPL to execute a GPL binary from a bash script that is
>> GPL-incompatible?  Heck, is it a violation of the other license for
>> the GPL bash interpreter to read and execute the non-GPL lines in the
>> script?
>
> Generally, the user can execute any combination of such functions on
> his system, without violating their licenses. The question is if a
> combined work containing parts of the ebuild and of the eclass can be
> distributed.

Sure, I'll buy that much.

> Now a Gentoo binary package contains an xpak part, which in turn
> contains a file named environment.bz2 where you will find functions
> originating both from the ebuild and from its inherited eclasses.

Sure, and I wasn't really speaking to the ability to redistribute
binary packages.  I was concerned more with the ebuilds themselves,
and the on-disk packages.

However, other distros do actually consider their binary packages to
be combinations of incompatible licenses in some cases, and they argue
that this is mere aggregation.  In this case we're talking about
aggregating ebuild and eclass functions and that is probably a step
further down the line from what other distros are likely doing.

> Certainly the xpak is a derived work of ebuild _and_ eclasses, so for
> distributing the binpkg both CDDL (to come back to the original
> example) and GPL-2 would have to be honoured. Which is not possible
> because these two licenses are incompatible.

Maybe.  They're aggregated, but whether this prevents redistribution
is another matter.  You could provide the source for the whole, and
tell the recipient that the various functions in the package are
redistributable under their original licenses.  It is trivial to split
an environment file back into its component functions.

Again, I wasn't really considering binary packages and I tend to agree
that mixed licenses do complicate this situation.

-- 
Rich

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Mart Raudsepp]

Ühel kenal päeval, E, 24.10.2016 kell 15:29, kirjutas Matt Turner:
> A former co-worker of mine is now at Google and wants to contribute
> ebuilds he wrote for ChromeOS to Gentoo. They add packages necessary
> for Vulkan (new 3D graphics API).
> 
> For instance: https://chromium.googlesource.com/chromiumos/overlays/c
> hromiumos-overlay/+/master/media-libs/vulkan-loader/vulkan-loader-
> 1.0.24.0.ebuild
> 
> The copyright header says "Copyright 2016 The Chromium OS Authors.
> All
> rights reserved." All ebuilds in gentoo.git say "Copyright 1999-20xx
> Gentoo Foundation".
> 
> Can I add ebuilds copyrighted by others to gentoo.git?

I don't see anything significantly artistic there to be copyrightable
in the first place. Just boilerplate of ebuild variables (one could say
this is derivative work on Gentoo stuff), and passing of variables to
cmake via a method whose copyrightable significant work is inside
cmake-utils.eclass, which is in main tree (probably with wrong
copyright headers, but...).

Given they only care about ICD loader, we'd want to re-do much of the
work and checking anyway, to perhaps build more stuff than the ICD
loader.


IANAL,
Mart