[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