[task #16553] Submission of sox_ng

[SoX NG]

Follow-up Comment #2, task #16553 (group administration):


>> I am Martin Guy <martinwguy@gmail.com> but wish to register sox_ng as a
separate entity on Savannah so that its keys can be shared with other core
developers to avoid there being a single point of failure for the project.

> I don't think I understand the scenario.  Could you please elaborate if you
really want an account shared by multiple people, and why?

For nine years, SoX has had a sole admin on sf.net, who has ignored all new
work including bug tracker submissions with patches, has just made commits to
the main line - patches for some bug fixes, small new features and mere
reformatting of source files to his preferred indentation and line break style
- but has never made a new release, leaving the 45 non-derivative distros that
package it each with a different slew of patches they apply or making a
snapshot of the mainline HEAD and patching that. The result is disillusion and
frustration among the still-numerous would-be developers, with hundreds of
dormant forks on github and elsewhere, and a lack of faith in SoX as
effectively abandonware.

Personally, I am willing to switch this inaction to a six-month release cycle
on each of three branches, micro, minor and major for bug fixes, new
backward-compatibile features and non-backward-compatible changes
respectively, but do not want my disappearance to mean the end of SoX
maintenance. I also do "social work" in an inner city area and they try to
kill me on average about twice a year, always different people, always for
different reasons. The frequency of attacks seems to be reducing in the last
years, fortunately, but if I do go, or end up in hospital again, I would like
there to be continuity on the project.

There may be other ways to achieve this, like making other group members also
admins of the project, but that may be too much. If I can privately give the
keys to its admin mail and site logins to one or two people whose trust level
is high but who may no longer be active SoX developers, that seems a more
reliable way to achieve this.

>> == Other Software Required: ==
>> None. Well, many, but all optional.
> Please list them, with their licenses.
INSTALL says that the optional libraries it can use are:

OpencoreAMR-NB/WB http://sourceforge.net/projects/opencore-amr  Apache
VisualOn AMR-WB   http://sourceforge.net/projects/opencore-amr  Apache
AO                http://xiph.org/ao                    GPL
FLAC              http://flac.sourceforge.net           BSD
LADSPA            http://www.ladspa.org                 LGPL + plugins'
licence
Lame MP3 encoder  http://lame.sourceforge.net           LGPL
Twolame MP2 enc.  http://www.twolame.org                LGPL
libltdl           http://www.gnu.org/software/libtool   LGPL
MAD MP3 decoder   http://www.underbit.com/products/mad  GPL
MP3 ID3 tags      http://www.underbit.com/products/mad  GPL
Magic             http://www.darwinsys.com/file         BSD
Ogg Vorbis        http://www.vorbis.com                 BSD
Opus              http://www.opus-codec.org/            BSD
PNG               http://www.libpng.org/pub/png         zlib (BSD-like)
Sndfile           http://www.mega-nerd.com/libsndfile   LGPL
WavPack           http://www.wavpack.com                BSD

and its COPYING file reads:
---------------
SoX source code is distributed under two main licenses. The two
licenses are in the files LICENSE.GPL and LICENSE.LGPL.

sox.c, and thus SoX-the user application, is distributed under the
GPL, while the files that make up libsox are licensed under the less
restrictive LGPL.

Note that some of the external packages that can be linked into libsox
are GPLed and/or may have licensing problems, so they can be disabled
at configure time with the relevant--with-* options. If libsox is built
with such libraries, it must be distributed under the GPL.
---------------

I would appreciate guidance on how we could license a hard fork to comply with
its current situation and best move forward. Incidentally, a planned move for
the next major release is to stop installing libsox and make it internal. No
projects on Debian or FreeBSD have libsox as a dependency, so it appears that
no one uses it. This would allow us to GPL the whole thing, which would allow
us to replace its own two (!) internal FFT routines, both immensely slow, and
use FFTW3, which is GPL'ed and so cannot be used at present because it would
be called by the LGPL'ed libsox.

I also have yet to understand whether GPL with a Linking Exception would
embrace the current dual-licencing model, whether we can simply GPL the
derivative work and make libsox_ng GPL instead of LGPL for legal simplicity,
or whether it should continue with a dual licence until we can dump libsox.

Many thanks for your time and consideration

    M



    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/task/?16553>

_______________________________________________
Message sent via Savannah
https://savannah.nongnu.org/