Detach from audacity's repository

[trickypr]

Is your feature request related to a problem? Please describe.
This fork as got a lot of traction over the past few days, gaining enough stars to put it on the trending page. However, it has not appeared on the trending page. I suspect that this is because it is a fork (I cannot find any GitHub documentation proving or disproving this theory).

If this fork creates a new brand image (#33) or makes major changes to the code for audacity (#8), it may be beneficial to detach from the audacity repo to reduce confusion.

Describe the solution you'd like
I would recommend sending a fork detach request to GitHub to turn this into an independent repository. This has its downsides, most notably that it would become harder to pull features and bug fixes from the main audacity code base.

Describe alternatives you've considered
Don't detach. Not being able to pull features and bug fixes from audacity easily could make it harder for this fork to continue to exist with one or two developers. Note that git has features to pull changes without being attached and the CLA may (but probably wont) prevent us from pulling changes.

[fugidev]

Is including new code from upstream even a option, since that's CLA licensed from now on?

[rezidentvx]

Please also update the original post with links to comments here that mitigate/promote/etc the different thoughts. Helps aggregate/track.

[Sciss]

Is including new code from upstream even a option, since that's CLA licensed from now on?

Yes, this direction is no problem, because the project is still under GPL. That the contributors give up their rights to WSM Group has nothing to do with the fork. The opposite would be impossible - downstream changes cannot be used by WSM Group if there is no corresponding CLA signature for their terms.

[dlight]

The CLA by itself doesn't prevent this fork from merging changes from upstream, because Audacity is still released as GPL v2. They would need to change the license into one incompatible with GPL v2 (like GPL v3) to prevent merges. At this point this fork needs to decide whether they want to stay GPL v2 (and stop merging changes from upstream) or follow upstream and relicense to GPL v3 as well.

But if upstream changes license to GPL v3 as they announced it's very easy for this repository to immediately relicense to GPL v3. GPL v3 is a better license overall (more importantly, it's compatible with the Apache license so this opens up adding Apache-licensed dependencies) so it would be a good change by itself.

In order to do this, this repository should request any new PR to be licensed as "GPL v2 or GPL v3", or even "GPL v2 or later". This doesn't require a CLA and makes a future license change almost automatic: the code is currently GPL v2 but as soon as upstream changes license to GPL v3, this project can just merge the commit with the license change and update LICENSE.txt to state the code is GPL v3 now (with portions "GPL v2 or GPL v3" and, likely, new code from upstream that is GPL v3 only).

Requiring "GPL v2 or GPL v3" for new contributions wouldn't force the fork to eventually relicense to GPL v3 either: it would still be possible to keep GPL v2 and stop merging upstream changes. So IMO this is a no-brainer.

[dlight]

And yep, upstream can't easily merge improvements made in this fork because the contributors may not have signed the CLA. That's one reason GCC dropped its CLA requirement.

[emabrey]

I think we should detach. If we really need to move code over we can cherry-pick patches and push them as commits using git cherry-pick -n <commit> (which supports non consecutive commits so with some care we could exclude any commits with objectionable code) and setting audacity/audacity as a git remote other than origin or upstream. That makes it not a fork, but it still lets us fetch+merge/pull. Does that sound reasonable to people who are or potentially may contribute? Only thing is we would want this remote to be on a separate branch other than master, that way any code we theoretically might move from them to us has to move onto master from a branch we already control, and so master can not have them as a direct upstream remote at all.

[EricBright]

If we ever want to establish a foundation (suggested here #28, a big if, I know), and if copyright reassignment to the foundation becomes a thing, then detaching would be the most logical step. So, I 2nd that too.

[jesec]

I am not familiar with audacity (and its community). I just saw the news, and I would like to put my two cents in:

Github severely limits the capabilities of a Github "fork". There is no code search, the repo not listed in search results by default, will prompt every committer to open a PR to the root repo (the "bad" one now I assume) whenever there is a push and features like Actions and Discussions are limited.

Technically, Github forks are just a non-default and invisible branch of the root repo. To demonstrate:

audacity/audacity@ced144b

The Github "fork" function is a convenient method to contribute to a project but is an awfully bad idea if you wish to maintain a permanent fork.

and Github does not provide a convenient way to "detach", and AFAIK the only way is to delete and recreate the repo, losing all data (stars, watchers, issues, PRs, comments) in the process. If you wish to maintain a permanent fork, for the sake of the project, you should not use a Github fork, and you should "detach" the project ASAP (to limit the damage).

Edit: Apparently, now it might be possible to contact GitHub support to ask them to detach the repo.

[peepo5]

Wait, I second it, but what do I say now? I third it?
Anyways, I support this detachment idea.

[emabrey]

@cookiengineer I am submitting the detach request on behalf of the organization.

[ghost]

There is a small issue with this: In my attempts today, to figure out the current state of the various forks, I tried to use a tool to find the most active forks of the original project. Of course, this project was not among them.

[Semisol]

Most good forks have detached from the original repo.

[ghost]

Most good forks have detached from the original repo.

So I see, and I understand why... I hope you can suggest a solution to the issue this creates, where users can't easily (or, at all) find out what their options (including this one) are?

[Semisol]

You should be able to find them via:

• searching "audacity fork", where this fork comes up
• the wikipedia page for Audacity
• Twitter and other platforms

[ghost]

So "just search, and hope you find them all" is where this is at? I've done that and more and I'm 90 minutes in and it is still entirely unclear what the state of things is, as a result of 'unknown unknowns'.

Just to be clear, I'm not blaming or arguing with you, I totally get why you did this. I'm just not sure how to resolve the situation. Actually, at this point I'm pretty sure it can't be resolved.

[Semisol]

There is nothing we can do, detaching has been done. I hope we could have easier discoverability for all forks, but if you are wondering the major forks, they have been listed here: https://en.wikipedia.org/wiki/Audacity_(audio_editor)#Derivatives, note that DA isn't a telemetry removal focused fork

[ghost]

Thanks mate :)