Follow-up Comment #2, task #16553 (group administration):
>> I am Martin Guy <[email protected]> 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/
