There is no conflict here. The quote from Github's ToS means you allow others to copy the source code you've made public, it cannot and does not give you any rights regarding what you do with the code beyond that. Points one and two of the Winamp license quote are essentially one and the same, just worded in a different way for clarity.

The GitHub ToS states:

> If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking). You may grant further rights if you adopt a license. If you are uploading Content you did not create or own, you are responsible for ensuring that the Content you upload is licensed under terms that grant these permissions to other GitHub Users.

It would be weird to have a license that lets me create a fork in my own repo, but doesn't permit me to distribute it. If I create a fork of a public repo on GH, I require a license to distribute it because a public repo can be forked or downloaded by anyone. I can't them doing doing it. Therefore permission to further distribute is required for participation on GH.

> If I create a fork of a public repo on GH, I require a license to distribute it because a public repo can be forked or downloaded by anyone

Why?

The users that clone or fork your fork of the original repository are covered by the original repository's "license" GitHub grants itself, not yours.

Because if I didn't have a license then that would mean I would be liable for infringement every time someone downloaded it from GH. That's exactly why GH has the TOS that it has - so that nobody can be sued for just using GH when a rights holder uploads their own work to a public GH repo.

Time to report it to GH then.

Interesting to see how would this play out in case of a lawsuit against an user who doesn't honor their license because it clashes with GH one. Anyway, that code has already been swallowed by some AI that will reorganize it, split in functional blocks and regurgitate it elsewhere someday, so too late for them to complain.

The GitHub ToS is not a software license. It is the terms for using the GitHub service. The penalty for breaking it is that your GitHub services might be terminated, not that they can somehow relicense your software.

This part of the ToS explicitly does grant such a license to other GitHub users.

> If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking).

As written, this says that you can fork a repo but can’t then clone it and work on it on your own machine. Isn’t software licensing fun?

Interesting. I guess you could just stick to the Github web editor to stay compliant? Really a terrible way to go about things though

You also can’t run the code.

Hmm, it says not to distribute the source or the binary. What about WASM or LLVM IR?

If GH provides they capability I suppose.

I was thinking that. The language seems not quite clear, at least to a non-lawyer like me:

> you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking)

So, on GitHub, we can "use", "perform", and "reproduce". Does editing/modifying fall under any of those verbs?

Cloning is part of GitHub's functionality, so therefore we can clone it but can only commit those changes back to GH. We are permitted to do anything that is part of GH's functionality.

It would seem that Github's TOS is superior to their license. They could have chosen other way to host their code

Different meaning of "forking".

"modified/derived version" vs "copy"

It is interesting that in a hypothetical scenario if someone did fork it and then thes goes to court. Which licence would take precedence here?

Seems to me that it's up to you which license you use, so if one grants the right to fork then there's nothing Winamp could do to prevent that.

At best they could invalidate the one license they control, but even that seems iffy

> Which licence would take precedence here?

Whichever one runs up the attorney's bill the highest.

> Which licence would take precedence here?

There is only 1 license, and it is issued by the WinAmp copyright holders. No additional license is created by hosting a repository on GitHub. The only (extremely theoretical) issue would be between GitHub and the WinAmp folks, if GH believed that WinAmp is violating its TOS.

IANAL...

By creating an account on GitHub, you agree to this license. That seems like a pretty strong precedent for precedence.

I guess they mean with "fork" a rebranded or self-compiled version. So unmodified source code, but different logo or name. Or compiled with different settings or for an unsupported platform. Something along that line. But calling this fork, after they are already forbidding modifications in point 1 is really strange phrasing.

There are two distinct meanings of fork and you are conflating them I think. I suspect winamp's license is using the sense of the (pre GitHub) idea of creating a distinct version of a project maintained by a different group, and the GitHub ToS specifically refers to forking within the GitHub platform.

Let's say you are hallucinating "two distinct meanings of fork". Unless you are referring to tableware, a fork is a fork, it's any distribution of a software, based on the software in question. The fact that most forks on GitHub serve only operational purpose, nobody actively maintains them and nobody normally uses them instead of the parent project, doesn't change what they are: a distributions for (potentially, and unless PR is accepted, actually) distinct software projects, based on a project they are forked from. You are just so used to the button and the process, you lost track of what the label on that button actually means, why it's called "a fork". And the answer is, well, because it's a fork. In no way it is different from starting a MariaDB project. As soon as you press that button, you are distributing your own software, based on that parent software. If the parent project disappears, or moves on, or never accepts your PR, which somebody really likes, other people can (and probably will) use your fork in a way that isn't any different than, well, any larger and "more obvious" fork.

So, essentially, winamp license means nothing. They already forfeited their right to deny you forking by posting it on GitHub.

Just an aside, but really hope "maybe you're hallucinating..." doesn't catch on in human to human speech.. Its great for the models, kinda too flattening for real discourse.

“…maybe you’re hallucinating…” and “…I must be hallucinating…” Have been part of human to human communication since the 60s, when people in fact could very seriously have been. It continued on for acid flashbacks and other surreal moments

Thats certainly true, and at least in philosophy similar discourses go back much farther than that!

But the senses are importantly different right? In the former, we are talking about clearly psychological assertions, in the form of skepticism, within an otherwise shared world.

Here it is clearly rhetorical though, right? Talking to GP as if they were LLM. Using it for a not-so-shorthand for "I believe you to be wrong about this".

Its really not a big deal. It's just interesting, I guess, how much the tools tend to master us and change us while we lie to ourselves that its the other way around.

Also, hadn't heard "acid flashbacks" in a long time.. Still waiting for mine!

I've used LSD a few times, but to my knowledge never had any "acid flashbacks". Maybe that's for the best... but seems like it might be fun if one was in a safe environment.

"Maybe you're hallucinating", let alone "let's say you're hallucinating", is a really weird take on someone thinking of a reasonable semantic distinction even if you disagree about its existence or relevance.

Perhaps you can say that to a friend as banter or in a tongue-in-cheek way, similarly to how you might say "I must be hallucinating" about yourself. But as an argument in a discussion with a stranger, it seems rather dismissive and inappropriate.

And it does reek a bit like something stolen from LLM terminology.

Any public GitHub fork is being distributed.

Is forking a well defined term? Doubt it will hold up in court.

They don't give permission, so the lack of definition doesn't really matter.

If they were trying to grant a narrow permission and then enjoin someone they thought was outside of their definition, it would matter (But they just aren't giving permission to distribute modified versions).

Anything the owners of the Winamp code can find in order to take legal action on will be distributed. Rule 2 (and 3) is always superfluous in practice.

You can't have a private Github fork

Yes you can; it's set at the organization level

https://docs.github.com/en/organizations/managing-organizati...

I stand corrected

You can, but only private forks of a private repo are allowed. Private forks of public repos are not allowed by design (modulo some weird bugs that were discussed on a past post).

What is the other meaning of fork?

When you click "fork this repo" in GitHub, that clones the repository, and re-publishes it under your username.

When you clone a repo to your system privately, that does not involve publishing. If this is their intended meaning of "fork", then this license must explicitly disallow cloning the repo!

> What is the other meaning of fork?

The older, still in use today meaning is what happened when Oracle bought MySQL and ruined it. People forked it and now we have MariaDB. Basically, it means a fork in the code base and now there are two separate projects.

Yes.

Until Github came along, "Creating a copy of software for your own personal use" had never been widely-accepted definition of the word "fork" in the context of software development. Forking a project has always involved independent publication and maintenance of said project.

The typical way of copying a project for your own personal use on GitHub involves publishing that copy on GitHub. So, it is a real fork—maybe not a well maintained one, or one that the author is particularly excited about, though!

OK, but that's still not different.

When you fork a project on GitHub, that literally creates a parallel working history, and publishes it under your username. That's what GitHub means by "fork".

So what's the other definition?

Many years ago I would have called that "mirroring", which is definitely not forking.

OK, but a mirror only exists to share an exact (hopefully up-to-date) copy of the repo. So we are just moving the goalpost from the moment you create the fork to the moment you edit it. Did that really change anything? I don't think so.

You can Zeno's-paradox-away the distinction between a bathtub and a kitchen sink, but that doesn't make them the same thing.

This sort of argument change how people understand words, and it also doesn't change how lawyers interpret laws nearly as often as people think. It's still fun, though!

> Oracle bought MySQL and ruined it

By "ruined" you must mean "solved decades-long issues and turned it into a real database", or we're talking about two different projects.

https://dev.mysql.com/blog-archive/the-complete-list-of-new-...

https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html

Do note that the largest users (like GitHub and Facebook) still use the original MySQL, and AFAIK have no plans to abandon it.

In particular I think you may press the fork button on the github repo as per github rules. However, you are not allowed to make any commits to this new repo.

A fork is a copy of a repo at a certain version. A copy of the files of the repo without the .git folder is effectively a fork. Either way, their terms contradict what GitHub allows.

You can fork it but not commit to it? LOL