[gentoo-dev] license issue with fretsonfire

[gentoo-dev] license issue with fretsonfire

[Mounir Lamouri]

Hi,

I was going to put frets on fire into the tree when I realized the
license of this game [1] is not very easy to get. The source code is
GPL-2 (with this note "some source files derived from other sources might
have differing licenses."), 3 fonts files have specific licenses and the
songs follow this rule "Distribution, modification or commercial usage
of the songs is not allowed.".

I think the code can be considered GPL-2 (i will check if there is no
header specifying something else) and for the fonts, I will have to add
2 licenses not in the tree at the moment.
But what to do with the songs ? I suppose it's not the first GPL game
having "non very clear" license about data. How games team is managing
that ?

[1] http://dev.gentoo.org/~volkmar/fretsonfire_copying.txt

Thanks,
Mounir

Re: [gentoo-dev] license issue with fretsonfire

[Arun Raghavan]

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

On Sat, 2009-05-02 at 18:17 +0200, Mounir Lamouri wrote:
[...]
> I think the code can be considered GPL-2 (i will check if there is no
> header specifying something else) and for the fonts, I will have to add
> 2 licenses not in the tree at the moment.
> But what to do with the songs ? I suppose it's not the first GPL game
> having "non very clear" license about data. How games team is managing
> that ?

The fonts license seems to be the same as licenses/BitstreamVera which
is in-tree.

As for the songs, does it make sense to put that in a separate package
that the code package depends on? The package can have the restrictive
license it is distributed under and RESTRICT="mirror bindist".

-- Arun

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

Re: [gentoo-dev] license issue with fretsonfire

[Richard Freeman]

Arun Raghavan wrote:
> 
> As for the songs, does it make sense to put that in a separate package
> that the code package depends on? The package can have the restrictive
> license it is distributed under and RESTRICT="mirror bindist".
> 

That was my first thought as well - just split out the songs and 
restrict mirroring.  This also works well if more open community-based 
songs come out - just add packages for them.

Re: [gentoo-dev] license issue with fretsonfire

[Mounir Lamouri]

Arun Raghavan wrote:
> The fonts license seems to be the same as licenses/BitstreamVera which
> is in-tree.
>   
One of them, yes. But the two others fonts license are more difficult to
get.
> As for the songs, does it make sense to put that in a separate package
> that the code package depends on? The package can have the restrictive
> license it is distributed under and RESTRICT="mirror bindist".
>   
Yes, I can do a fretsonfire package and a fretsonfire-data package like
nwn. It makes sense for licensing but it will force us to mirror
self-splitted packages.
But even if doing that, what will be the LICENSE for fretsonfire-data ?
"Distribution, modification or commercial usage of the songs is not
allowed" is not really a license ;) (and I will have to add the 3 fonts
license with 2 unknown)

By the way, I have contacted upstream about this issue and I didn't get
any answer.

For information, copying file is here :
http://dev.gentoo.org/~volkmar/fretsonfire_copying.txt

Thanks,
Mounir

Re: [gentoo-dev] license issue with fretsonfire

[Mounir Lamouri]

Arun Raghavan wrote:
> On Sat, 2009-05-02 at 18:17 +0200, Mounir Lamouri wrote:
> [...]
>   
>> I think the code can be considered GPL-2 (i will check if there is no
>> header specifying something else) and for the fonts, I will have to add
>> 2 licenses not in the tree at the moment.
>> But what to do with the songs ? I suppose it's not the first GPL game
>> having "non very clear" license about data. How games team is managing
>> that ?
>>     
>
> The fonts license seems to be the same as licenses/BitstreamVera which
> is in-tree.
>
> As for the songs, does it make sense to put that in a separate package
> that the code package depends on? The package can have the restrictive
> license it is distributed under and RESTRICT="mirror bindist".
>
> -- Arun
>   
I've contacted upstream and I sent me the Debian bug [1] about
fretsonfire. They suffered from similar issues.

To solve fonts issue, I think we can fix that like Debian: using other
fonts. We can even using the same ones.
To solve the songs issue, I see two solutions:
1. removing songs from the tarball (should we do/mirror a new tarball ?)
and adding packages with free songs (Debian's solution)
2. using RESTRICT="mirror bindist" as Arun proposed (btw, is bindist
really for "binary" because it's in python so there is no binary)
I don't know if we can solve the song issue with a separated package.
Because this songs are following the Toesto (Finish organization to
protect artists work iirc) rules they must be bundled with the game. We
probably should do the same. Or maybe RESTRICT="fetch" can solve this ?
I think the real issue with the songs is there is no real license linked
with it except "you can't do anything with them except listening to". I
think even with the most restrictive parameters, we can't deal with
that. Am I right ?

I think the most secure way for Gentoo is to do as Debian is doing. May
be even using Debian's package.

I would appreciate some help/advice here as I'm not a lawyer :)

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=383316

Thanks,
Mounir