taskSavannah Administration - Tasks: task #16553, Submission of sox_ng

 
 

task #16553: Submission of sox_ng

Submitter:  SoX NG <sox_ng>
Submitted:  Thu 13 Jun 2024 06:30:47 AM UTC
   
 
Should Start On:  Thu 13 Jun 2024 12:00:00 AM UTC Should be Finished on:  Sun 23 Jun 2024 12:00:00 AM UTC
Category:  Project Approval Priority:  * 5 - Normal
Status:  In Progress Privacy:  Public
Assigned to:  ineiev Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 11 Jul 2024 10:06:17 AM UTC, comment #14: 


> Why can't you tell this yourself?

Because I am not a license lawyer. I'm a programmer and know when I don't know.

> What info do you miss?

Legal understanding

Your help and info are appreciated and have helped me dig deeper into the problem and understand the area better, as well as aiding me in sorting out the status of the most difficult files, but I feel I am now wasting your time. I haven't even been able to test drive savannah to see if it it suitable.

I'll progress elsewhere, do what I have understood and take my chances, which can't be any worse than those of the original project which has had no trouble in all its long life.

You can close this issue now and I'll delete nongnu.sox_ng

If you wish you may also delete the issue which is embarassingly public. I've taken a copy for my reference.

Best wishes & thanks again

   M

SoX NG <sox_ng>
Wed 10 Jul 2024 04:45:04 PM UTC, comment #13: 

comment #12:

> To put it another way, are any of the categories of files, given the new permissions from the contactable authors, incompatible with the GPLv3-or-later?
>
> I've examined all the files, now someone needs to examine each category of file. They only have to find one that is duff to resolve the question, or say they consider all to be OK or remediable.


Why can't you tell this yourself?  What info do you miss?

> My second question is: which of the categories can be licensed or relicensed as GPLv3-o-l, other than the GPLv2-o-l ones?


For Savannah, what matters is not whether some code can be re-licensed under the GPL, but whether it can be combined with parts released under the GPL in the same program, that is, whether it is GPL-compatible.  For the list of GPL-compatible licenses, you can check https://www.gnu.org/licenses/license-list.html.

comment #8:

> > the fact that it's a work of the US should ideally be checked
> I've checked those files' authorship from the git logs. 2 were first comitted by Rob Sykes, UK citizen, whose permission I have, 2 by Chris Bagwell the main author, for 3 I now have Coelho's permission to use them and 1 by Chris Ausbrooks whose email at the time was @ualr.edu in the US.


"Work of the US" means that it is legally a work of the state; it has nothing to do with the citizenship of the people who did the work.

Ineiev <ineiev>
Site Administrator
Wed 10 Jul 2024 03:01:51 PM UTC, comment #12: 

My question is: are all of its source files compatible with savannah's hosting requirements, in the light of comments 4, 6 and 8?

To put it another way, are any of the categories of files, given the new permissions from the contactable authors, incompatible with the GPLv3-or-later?

I've examined all the files, now someone needs to examine each category of file. They only have to find one that is duff to resolve the question, or say they consider all to be OK or remediable.

My second question is: which of the categories can be licensed or relicensed as GPLv3-o-l, other than the GPLv2-o-l ones? That would be useful even if savannah's requirements are not met.

SoX NG <sox_ng>
Tue 09 Jul 2024 03:28:41 PM UTC, comment #11: 

The licensing team told me they are not sure what you are asking about.  Could you formulate specific questions?

Ineiev <ineiev>
Site Administrator
Mon 24 Jun 2024 08:20:50 AM UTC, comment #10: 

Thanks. Fortunately I don't have to deal with any of those licenses.

At this point I think I need -email is unavailable- to review the situation and advise. I'll point them at this and let you know what they think is the best way forward.

SoX NG <sox_ng>
Sun 23 Jun 2024 05:41:35 PM UTC, comment #9: 


> The problem files seem to be:
>
> >> 38 are copyright and "freely distributable for any purpose"
> > This permission isn't sufficient for code to be free software;
> although
> > If a release has one statement that "This program is released under license
> > FOO," in a central place, that makes the situation clear for that release.
> and I'm starting from the last official release made by Bagwell, sifting the
> patches on git.sf.net since then the same as all the other forks and distros'
> patches. Also, I assume that "for any purpose" includes relicensing it under
> the GPL, and anyone who has "other purposes" can base their work on the last
> official release's code.


I'm not sure we may take this interpretation for granted.  I would say,
usually licenses give separate permissions for distributing and modification,
for instance,

https://directory.fsf.org/wiki/License:W3C_31Dec2002
https://directory.fsf.org/wiki/License:SMLNJ
https://directory.fsf.org/wiki/License:ISC

Note that all those licenses say 'for any purpose,' but mention modifying
as well as distributing.

And sincerely speaking, understanding 'for any purpose' as a permission
to relicense the work under an arbitrary license sounds far-fetched to me.
In particular,
Gnuplot license also says
'for any purpose,' but it's GPL-incompatible,



Ineiev <ineiev>
Site Administrator
Sun 23 Jun 2024 08:00:12 AM UTC, comment #8: 

Hi again and sorry to keep bothering you. I see that you (inei) do a lot of work helping a lot of people.

I would like to choose the public platform for this and Savannah would be my No.1 choice for three reasons:
- best accessibility according to partially-sighted SoX developer Eric Wong
- provides mailing lists, unlike No.2, codeberg
- Highest visibility
and a +/-:
- Getting project approval is more difficult, but this is likely to improve its quality and legal standing.
  No hurry though. The first hard fork release (micro) will be on 18 August and I can work on it elsewhere as it will not be public until then to avoid sabotage from mainline. Most of the patches for the micro release are there as patches in Debian and 47 other non-dependent distros, just not being handled properly by mainline.

The problem files seem to be:

>> 38 are copyright and "freely distributable for any purpose"
> This permission isn't sufficient for code to be free software;

although

> If a release has one statement that "This program is released under license
> FOO," in a central place, that makes the situation clear for that release.

and I'm starting from the last official release made by Bagwell, sifting the patches on git.sf.net since then the same as all the other forks and distros' patches. Also, I assume that "for any purpose" includes relicensing it under the GPL, and anyone who has "other purposes" can base their work on the last official release's code.

and

>> 8 have no copyright statement or are "Written by" someone
> the fact that it's a work of the US should ideally be checked

I've checked those files' authorship from the git logs. 2 were first comitted by Rob Sykes, UK citizen, whose permission I have, 2 by Chris Bagwell the main author, for 3 I now have Coelho's permission to use them and 1 by Chris Ausbrooks whose email at the time was @ualr.edu in the US.

Lastly I would appreciate your comments on the idea of boilerplating the GPLv3 at the top of source files with a proviso for the preceding terms where applicable (like "provided that the above copyright notice and this permission notice appear in all copies").

SoX NG <sox_ng>
Sun 16 Jun 2024 08:30:58 PM UTC, comment #7: 

Sorry, forgot Andy Fingerhuts headers:

From: Andy Fingerhut <andy.fingerhut@gmail.com>
To: Martin Guy <martinwguy@gmail.com>
Date: Sun, 16 Jun 2024 11:57:18 -0400
Message-ID: <CAKvLtDZxVyE0T1v=BJ+3FoyeebTKoLN4ZDq_QkzyaCByqRNoTA@mail.gmail.com>
Subject: Re: lpc10 copyright status

SoX NG <sox_ng>
Sun 16 Jun 2024 07:49:37 PM UTC, comment #6: 

Any Fingerhut write to me re: the lpc10 source code:
=================
I have updated the files in this repository https://github.com/jafingerhut/lpc10

to have an explicit copyright notice on all C source files, and that they are released under the BSD 3-clause new or revised license.

I also updated the top level README to mention some of the things you say in your email (I did not name you), and that my copyright and choice of license are conditional on those statements being correct.
=================
and Fabien Coelho:
=================
Delivered-To: -email is unavailable-
From: Fabien COELHO <fabien.coelho@mines-paristech.fr>
To: Martin Guy <martinwguy@gmail.com>
Subject: Re: Boring SoX copyright stuff
Message-ID: <7d513f9e-eb9d-58a9-53ff-6f5f367bde3a@mines-paristech.fr>

Hello Martin,

"Sox" rings a little bell, from a very long time ago, probably much before
2015:-) I'm sorry for the legal mess, which is not my area of expertise.

I'm happy to say that I hereby grant permission to use my code that is
included in SoX for any purpose.

In other words, from my point of view all my contributions to sox can be
considered "public domain".

Is that enough for you? Do you need more?

Fabien.

--
Fabien Coelho - Mines Paris - PSL
=================

What I am thinking is to boilerplate a GPLv3 copyright notice at the top of every source file, assigning copyright to the Free Software Foundation with written underneath: "subject to the requirements of the previous copyright notice:" and whatever there was before. From my studies, none of them are "incompatible" with the GPLv3 but I'd appreciate guidance on the correctness of reassigning copyright in this manner.

Legal consequences, frankly, let anyone who wants to study and contest incompatabilities between the GPLv3 and the ten or so licences (or lack thereof) do so. After all, I'd be the one to take the rap, having made the changes in prima persona, so Bring It On! :) I think I am bulletproof, but then doesn't everyone?

Blessings

   M

SoX NG <sox_ng>
Sat 15 Jun 2024 01:24:28 PM UTC, comment #5: 


> I've done an analysis of its source code and optional libraries. The optional
> libraries with which it can link are all GPLv2 or later, LGPLv2 or later,
> LGPLv2.1 or later, Two-clause BSD, Xiph, Wavpack or Zlib except for two,
> Opencore and VisualOn AMR, which are "Apache"
> https://sourceforge.net/p/opencore-amr/code/ci/master/tree/LICENSE
> which I gather is incompatible with GPLv3 or later.


Apache License Version 2.0 is compatible with GPLv3 (in such cases we assume that the license will also be compatible with future GPL versions).

> 141 are free software copyright to one or more individuals with year stamps
> and with GPLv2 or later or LGPLv2.1 or later notices. A few only say "(c)
> 2006-2012 SoX contributors" or "(c) SoX Contributers" which I assume are not
> legally binding copyright notices as they do not indicate a physical person or
> legal entity, or even the year in one case.


I think the years could be found out, 'SoX contributors' as the reference to the copyright holder isn't ideal, but acceptable.

> 38 are copyright and "freely distributable for any purpose"


This permission isn't sufficient for code to be free software; it may only be acceptable for specific cases of non-functional data (like copies of the licenses).

> 8 have no copyright statament or are "Written by" someone with no copyright
> line.
>
> 6 are copyright to someone, usually a SoX developer, but contain no licence
> terms. Of these, some authors may no longer be contactable.
>
> Lastly there's the included lpc10 library, which has no copyright statements
> and was published in Fortran in October 1993 by the US Department of Defence,


Works of the US may be considered public domain (IIRC, they are technically uncopyrightable), but the fact that it's a work of the US should ideally be checked, and a note added in the files in question.

> and translated to C in 1996.


If the translation is made with a grain of creativity, its authors may hold copyright on it independently, therefore their separate permission is needed for the work to be free.

> but I assume that, as it was published without copyright statements, and long
> ago, it is in the public domain.


1993 isn't sufficiently long ago; depending on the jurisdiction, the copyright term is often 50 years after the death of the last author, or more.

Without copyright and license notices, one should assume that little is permitted to do with the work; definitely not public domain.

> The 6 source files containing copyright notices but no explicit licensing text
> say one of:
>
> * Copyright 2008 Chris Bagwell And Sundry Contributors

...

> while wav.c says all of:
>
> * Copyright 1998-2006 Chris Bagwell and SoX Contributors
> * Copyright 1997 Graeme W. Gill, 93/5/17
> * Copyright 1992 Rick Richardson
> * Copyright 1991 Lance Norskog And Sundry Contributors
>
> Of these, Chris Bagwell was the main SoX maintainer from 1996 to 2015 though
> no one has heard from him for some years. However, his explicit copyright to
> GPLv2 or later or LGPLv2.1 or later appears in many other source files, so I
> think this is covered by "patent error" (i.e. "obvious error").


If those files were written specifically for SoX, one may assume the licensing terms used for the package in that time,

> If a release has one statement that "This program is released under license
> FOO," in a central place such as the README file, that makes the situation
> clear for that release.


So the license notice may be added to that file accordingly.

Ineiev <ineiev>
Site Administrator
Sat 15 Jun 2024 09:42:14 AM UTC, comment #4: 

Thanks again.

I've done an analysis of its source code and optional libraries. The optional libraries with which it can link are all GPLv2 or later, LGPLv2 or later, LGPLv2.1 or later, Two-clause BSD, Xiph, Wavpack or Zlib except for two, Opencore and VisualOn AMR, which are "Apache"
https://sourceforge.net/p/opencore-amr/code/ci/master/tree/LICENSE
which I gather is incompatible with GPLv3 or later.

(Two clause BSD)

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

- Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.

- Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.

(Xiph)

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

- Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.

- Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.

- Neither the name of the Xiph.org Foundation nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.

(WavPack)

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

    * Redistributions of source code must retain the above copyright notice,
      this list of conditions and the following disclaimer.
    * Redistributions in binary form must reproduce the above copyright notice,
      this list of conditions and the following disclaimer in the
      documentation and/or other materials provided with the distribution.
    * Neither the name of Conifer Software nor the names of its contributors
      may be used to endorse or promote products derived from this software
      without specific prior written permission.

(zlib)

Permission is hereby granted to use, copy, modify, and distribute
this software, or portions hereof, for any purpose, without fee,
subject to the following restrictions:

 1. The origin of this software must not be misrepresented; you
    must not claim that you wrote the original software.  If you
    use this software in a product, an acknowledgment in the product
    documentation would be appreciated, but is not required.

 2. Altered source versions must be plainly marked as such, and must
    not be misrepresented as being the original software.

 3. This Copyright notice may not be removed or altered from any
    source or altered source distribution.

The sox source code has a blanket COPYING notice of GPLv2 or later and LGPLv2.1 or later but the 197 individual source files are as big a hotch-potch as you could imagine.

141 are free software copyright to one or more individuals with year stamps and with GPLv2 or later or LGPLv2.1 or later notices. A few only say "(c) 2006-2012 SoX contributors" or "(c) SoX Contributers" which I assume are not legally binding copyright notices as they do not indicate a physical person or legal entity, or even the year in one case.

38 are copyright and "freely distributable for any purpose"

2 are both of the above.

8 have no copyright statament or are "Written by" someone with no copyright line.

6 are copyright to someone, usually a SoX developer, but contain no licence terms. Of these, some authors may no longer be contactable.

Lastly there's the included lpc10 library, which has no copyright statements and was published in Fortran in October 1993 by the US Department of Defence, and translated to C in 1996. Its translator still maintains it on giuthub and writes in its README file:

"Because of the history of this implementation, the copyright and license status is still not completely clear to me, for reasons discussed further below. It might be in the public domain, but if the legal answer matters to you in any significant way, I suggest consulting an attorney who specialies in intellectual property law."

but I assume that, as it was published without copyright statements, and long ago, it is in the public domain.

So, to sum up possible problems:

The AMR libraries with which it can optionally link are under an Apache license which is said to be incompatible with GPLv3 or later. Can we either dike their use out (it's a rare compressed speech format) or maybe make "configure" default to not using them unless the user says "--enable-amr" or whatever the runes are?

The 6 source files containing copyright notices but no explicit licensing text say one of:

  • Copyright 2008 Chris Bagwell And Sundry Contributors


  • (c) 2000.04.15 Chris Ausbrooks <weed@bucket.pp.ualr.edu>

 *

  • based on vol.c which is
  • (c) 20/03/2000 Fabien COELHO <fabien@coelho.net> for sox.


  • (c) march/april 2000 Fabien COELHO <fabien@coelho.net> for sox.


and vol.c:

/* Copyright (c) 20/03/2000 Fabien COELHO <fabien@coelho.net>

  • Copyright (c) 2000-2007 SoX contributors


while wav.c says all of:

  • Copyright 1998-2006 Chris Bagwell and SoX Contributors
  • Copyright 1997 Graeme W. Gill, 93/5/17
  • Copyright 1992 Rick Richardson
  • Copyright 1991 Lance Norskog And Sundry Contributors


Of these, Chris Bagwell was the main SoX maintainer from 1996 to 2015 though no one has heard from him for some years. However, his explicit copyright to GPLv2 or later or LGPLv2.1 or later appears in many other source files, so I think this is covered by "patent error" (i.e. "obvious error").

I have written to Fabien Coelho, who is still active, asking him to say something like "I hereby grant permission to use my code that is included in SoX for any purpose" or "I hereby grant permission to use my code that is included in SoX under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version."

At that point I should be able to fix all the source files before importing them into savannah by including the GPLv3 or later in all of them, thus upgrading the existing copyrights, or applying GPLv3 or later to the public domain code, and remove or make configure default to off for the AMR libraries. Does that sound right?

SoX NG <sox_ng>
Fri 14 Jun 2024 07:03:05 AM UTC, comment #3: 

comment #2:
...

> 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.


I don't think it's harder to pass private keys and other credentials to other people (which isn't an ideal practice, anyway) than to make them admins of the Savannah group, I would say the opposite.  At the same time, separating identities definitely has essential advantages.

> INSTALL says that the optional libraries it can use are:
>

...

> AO                http://xiph.org/ao                    GPL
> FLAC              http://flac.sourceforge.net           BSD


This means that you'll have to check what the real licenses are, and update INSTALL (or SoX programs if they turn out GPL-incompatible).  For example, 'GPL' may mean GPLv2-only, making it non-compliant with Savannah hosting requirements.

> 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.


(By the way, GPLv3-only is also incompatible with our requirements.  This point in SoX licensing needs clarifying.)

> I would appreciate guidance on how we could license a hard fork to comply with its current situation and best move forward.


I'm afraid I have to repeat that Savannah admins can't afford effectively becoming part of maintainer team of newly registered packages and keeping them in the right legal shape.  We have to rely on the existing maintainers.

Ineiev <ineiev>
Site Administrator
Thu 13 Jun 2024 01:49:38 PM UTC, comment #2: 


>> 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

SoX NG <sox_ng>
Thu 13 Jun 2024 12:34:20 PM UTC, comment #1: 


> 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?

> == Other Software Required: ==
> None. Well, many, but all optional.


Please list them, with their licenses.

> All the optional dependency libraries are GPL, LGPL, BSD or zlib.


There is no such thing as 'the BSD license'; that name may refer to various licenses, some of them are GPL-compatible, and some are not.

We generally rely on group admins to avoid licensing issues; if you don't care about them, we shan't be able to approve your package.

Ineiev <ineiev>
Site Administrator
Thu 13 Jun 2024 06:30:47 AM UTC, original submission:  

A new group has been registered at Savannah.
This group will remain inactive until a site admin approves
or discards the registration.


Registration Administration


Approving or discarding the registration must be done using the specific
Group administration page, accessible only to site
administrators logged in as superusers.

Registration Details


  • Name: sox_ng
  • System Name:  sox-ng
  • Type: non-GNU software and documentation
  • License: GNU General Public License v2 or later (SoX installs GPL executables and an LGPL library)





Description:

SoX, the "Swiss Army Knife" of command-line sound processing, has not made a release since 2015. I am in the process of stepping up as its release manager and if things do not go as we all hope, may have to make a hard fork to do this, requiring a git repository and two mailing lists. Savannah would be our preferred platform for this because of its greater accessibility in terms of ease of use by partially sighted or blind developers.

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.


Other Software Required:

None. Well, many, but all optional.
All the optional dependency libraries are GPL, LGPL, BSD or zlib.


Tarball URL:

https://downloads.sourceforge.net/project/sox/sox/14.4.2/sox-14.4.2.tar.bz2


SoX NG <sox_ng>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ineiev (Posted a comment)
  • -email is unavailable- added by sox_ng (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-06-13 ineiev StatusNone In Progress
        Assigned toNone ineiev

    Back to the top

    Powered by Savane 3.13-b921.
    Corresponding source code