mingw-cross-env-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mingw-cross-env-list] Introduction and general question


From: Tony Theodore
Subject: Re: [Mingw-cross-env-list] Introduction and general question
Date: Thu, 7 Mar 2013 14:46:41 +1100

Hi Ulrich,

On 04/03/2013, at 6:47 AM, Ulrich Klauer <address@hidden> wrote:

> Hi,
> my first post here, so I guess I should introduce myself

Welcome, and thanks again for your recent contributions!

> Now for the general question: Should MXE packages be as feature-complete as 
> possible (= as prerequisites allow) or should they only offer a sensible 
> subset, if there are many optional features?
> 
> Taking the sox package as an example, it currently depends on flac, lame, 
> libgomp, libmad, libsndfile, vorbis, and wavpack. It could also make use of 
> packages file (libmagic), libpng, libtool (libtldl), and opencore-amr for 
> more optional features.
> 
> Apart from the obvious issues regarding build time etc., including more 
> features can also lead to licensing restrictions. Although libsox is, by 
> itself, LGPL 2.1+, linking in libmad makes it GPL 2+. Linking in the AMR 
> codecs from opencore-amr makes it GPL 3+ (because the Apache licence is 
> incompatible with GPL 2). This is why I'd tend to not include libmad, at 
> least.

We try to avoid licensing threads [1,2], but sensible defaults for mxe are [3]:

1) don't make the developer run into unexpected licensing issues
2) make the packages as feature complete as possible

The hypothetical "developer" in this case is following the spirit of the 
DFSG[4]/FSF[5]/OSD[6], so unexpected would be "non-free" packages (eg. 
faac[7]). For sox in mxe, I'd say we enable everything that's "free" since it's 
much easier to disable something downstream than enable it.

> There is support in libsox for dlopen()ing optional libraries at runtime. 
> This is what we do for the "official" SoX Windows binary: libmad, 
> opencore-amr, and lame are left out, but if the user has a relevant DLL, they 
> can use it.

That sounds like a very good solution for final distribution - it would be 
interesting to see what it looks like. Is it just a matter of excluding those 
packages? The ffmpeg package has some configure options like --enable-gpl 
(along with a page of notes[8]), does sox have something similar?

>  I could set up the MXE sox package in this way, too, if that is desired.

We'd probably keep the full set enabled in mxe, and support local modifications 
with something like "settings.mk". This won't work at the moment since it's 
read in before the build rules, but we should be able to come up with something 
that's easier than merging branches.

Cheers,

Tony


[1] 
http://lists.nongnu.org/archive/html/mingw-cross-env-list/2010-12/msg00025.html
[2] 
http://lists.nongnu.org/archive/html/mingw-cross-env-list/2011-02/msg00018.html
[3] 
http://lists.nongnu.org/archive/html/mingw-cross-env-list/2011-02/msg00032.html
[4] http://www.debian.org/social_contract#guidelines
[5] http://www.gnu.org/philosophy/free-sw.html
[6] http://www.opensource.org/osd.html
[7] http://www.audiocoding.com/faac.html
[8] http://www.ffmpeg.org/legal.html




reply via email to

[Prev in Thread] Current Thread [Next in Thread]