Hacker News Reader

Comment by eminence32 | Hacker News Reader

Open sourcing is always good, because maybe you can learn some things by reading it. Also, Winamp Legacy is a fairly important piece of software, so having an archive of its source is a great thing.

But the restrictions on the source are interesting. To quote the license file:

    * No Distribution of Modified Versions: You may not distribute modified versions of the software, whether in source or binary form.
    * No Forking: You may not create, maintain, or distribute a forked version of the software.
    * Official Distribution: Only the maintainers of the official repository are allowed to distribute the software and its modifications.

I'm guessing the "No Forking" clause means I can't release my own media player based on this source code, but the language is curious because they explicitly welcome contributions and for a project hosted on Github the standard way to do that is to "fork" the project into your own account.

View on HN

This seems to go against GitHub's own ToS[1]:

> By setting your repositories to be viewed publicly, you agree to allow others to view and "fork" your repositories (this means that others may make their own copies of Content from your repositories in repositories they control).

[1] https://docs.github.com/en/site-policy/github-terms/github-t...

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.

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.

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

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.

IANAL...

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

Different meaning of "forking".

"modified/derived version" vs "copy"

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.

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.

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.

Any public GitHub fork is being distributed.

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

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

I stand corrected

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.

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.

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

It feels like they wanted to make sure that no one distributes a modified "Winamp" that isn't built from the official sources, which makes sense, but they went too restrictive on it. The usual way to go about it is to say "if you want to maintain and distribute your own fork of this product, you must change the name and the logo to make sure it doesn't infringe on our branding". Telegram does this for its client apps, for example.

> ...but they went too restrictive on it.

I bet that they would disagree with you. This is an "all rights reserved" "source available" license. Given the redistribution restrictions, their assertion that it is a "copyleft" license is clearly false.

> No Forking

Amusing; there are already 6 forks on GitHub as of this writing.

Now 52 forks on GitHub. Thug life.

72 now

This is like a park having a sign on the corner telling you to not step on the grass because it is privately owned but people go and make picnic there anyway

The person who set the license is also accepting PR's from forks.

https://github.com/WinampDesktop/winamp/pull/7

The confusion and disorganization is hilarious

IANAL but doesn't that basically show they are OK with forks?

There's already 229 of them, so we will see.

> but the language is curious because they explicitly welcome contributions and for a project hosted on Github the standard way to do that is to "fork" the project into your own account.

It's because techies instead of lawyers wrote it. The first and second restrictions overlap anyway, as it says you can't distribute a modified version in the first restriction, but then can't distribute a forked version in the second restriction. I'm not sure what the difference is, and courts don't like redundancy and will often invent reasons to interpret the phrases as meaning something different.

I got a $15 parking ticket recently and got it dismissed after I contested the ticket on the basis that the way the city regs were written, they used both "parking spot" and "parking area" and thus "parking area" cannot be synonymous with "parking spot," which altered the meaning of the reg they used to ticket me.

Curious if you'd share the language you used in this contention.

Looks like someone just removed 180K lines of plugin source code from the repo too. Checkout from here: 7ce05499ff0508f9eb06f7194407f676de7d72f4

Seems like 37 madlads have already pushed the fork button.

It's not open source. however I like it. I wish closed source licenses were more of a thing. as it is, our software tends to fall under two two extremes very liberal open source. closed build artifact only. with very little in the middle.

I think a "here is the copyrighted(with all that implies) source for you to compile on your machine" software distribution would be a great middle ground. but it is a thing you normally only see on large screwball enterprise contracts. because the normal practice of here is the compiled build artifact really sucks when trying to trouble shoot why it is not working on your machine.

I'm not sure forking the repo would create a forked version of the 'software' if the fork's sole purpose is to develop a pull request. But I guess it's somewhat ambiguous langauge, and better safe then sorry when it comes to lawyers (which I'm not).

I agree; your interpretation is reasonable and plausible. But it's disappointing to have this ambiguously, since the license file has a whole section for "Definitions" and yet it fails to define what "forking" means in this context.

Presumably the prohibition is around creating a forked release, with the language being intentionally a bit vague to cover their bases. Unfortunate that that's how these things are, though.

Interestingly the first line says, even distributing a modified version in source form is not allowed... so a GitHub fork with a tiny modification already violates this line.

In a very specific technical sense, it could be argued that it doesn't — the data for GitHub forks (i.e. their branches and the commits of such) is actually stored within the base repo forked from.

In other words, by forking something on Github, you're not distributing anything; rather, the original org is now distributing an additional thing you made — your fork branch[es].

This is the source of many confusing things about the security of GH forks; and the source of some recent GH vulnerabilities.

Also, if you're curious, this isn't a meaningless "implementation-level distinction", as it has semantic implications for repo management: it means that the branch attached to a PR coming from a fork repo continues to exist in the base repo, even if the fork repo that that branch originated from gets deleted. Because that branch was always "in" the base repo to begin with; the PR just changed the branch's GH ACLs to make it accessible to the owners of the base repo.

(Really, the "fork repo" itself is an illusion — it's like a SQL view. There's only the base repo, which contains both regular branches, and user-fork-namespaced branches. This is in part why forks can't be private; they're just a view of resources in another repo, already security-controlled by that other repo; so they can't have their own additional security logic acting on those same resources!)

This implementation choice has always felt a bit odd to me, almost like premature optimization. Is there a reason to have done it this way other than storage deduplication? Since git is already a content-addressed store anyway, how hard would it have been to have some kind of abstraction below the repo layer that would provide the same deduplication?

At this point there's obviously huge inertia in Github's early architectural decisions, but if you were building Github today, would it still make sense to go this route?

GitHub's fork feature works outside of git itself. It does not utilize the .git directory, and therefore does not utilize git's deduplication.

EDIT: Oh, I see what you mean. It would definitely be interesting to solve this namespace conflict problem from inside git. I wonder how many times meta-branches (or something similar) have been advocated for.

You're not allowed to "distribute" a fork, even in source form. Posting something on Github certainly smells a lot like distributing it.

Yeah the license self-refers as "copyleft" (an unregulated term afaik), and they have been very careful to avoid usage of the term "open source" rather preferring to say things like "the source is open".

Regulated or not the use of "copyleft" still seems deliberately misleading to me - I don't think the restrictions you've listed are in line with the intent of the copyleft movement.

Copyleft just means you lose license privileges and revert to unlicensed copyright rules when violating its terms. There's no reason you can't use that principle in a more restrictive way than GPL.

That's not at all what copyleft means.

https://www.gnu.org/licenses/copyleft.en.html

That's the FSFs spin. Ultimately GPL is a promise not to pursue an entity for copyright violation without the need for a signed contract. That promise is revoked when you disobey the copyleft.

> That's the FSFs spin

This implies your take on copyleft is an adversarial one, in which case implying your definition is canonical is disingenuous.

While I did make the point that "copyleft" is not a protected term & therefore can have many definitions, I've never heard your definition & it's certainly not the widely accepted one.

While "copyleft" is just a word like any other word, and subject to the same descriptivist drift as any other, in this case it is a specific word coined by a specific org, with a pretty specific definition. One that this license does not meet.

Frankly, copyleft is MORE permissive than generic bullshit weasely term "open source" (thanks to corp-friendly ESR). The fact they try to avoid using "open source" but willingly use the more "free as in freedom" word "copyleft" is a bit distressing.

I'm tired of this whole "shared source" movement, it's disingenuous, and ruins the spirit of actual open source (let alone "copyleft").

Boo on Winamp. Shame. I'm still using 5.666 until I die. I won't use their newer stuff, because it's clear they're not doing it with love but just trying to find another captive market of nostalgia nerds.

The language is pretty clear to me. I understand what you’re saying, and suspect that this is an honest oversight on their part, but as it currently reads forks are prohibited.

They may have meant something else, but what it says now is “no forking.”

They know exactly what they're doing. They're open-washing the program to get attention. It worked. As I write this, it's the number one YComb story. But, it's in no way, shape, or form open source.

I am all for reverse Hanlon[0]: don't assume incompetence when people profit from something. I think however that "source available" is a legit business model, and not just a HN hack. They made their source code available after all. Although it isn't compatible with github, as the others pointed it out.

[0] : https://en.wikipedia.org/wiki/Hanlon's_razor

It's not "Open Source", to use the capitalized term the OSI attempts to gatekeep. It fits most non-zealots' definition, though.

How is it zealous to prevent people from co-opting and diluting the meaning, like you have done here? If anything, companies are trying to misuse "open source" for their source-available code.

Well, it's at least slightly more open than e.g. Microsoft's source-available repositories, let alone leaked proprietary source; as you do have the freedom to e.g. read the Winamp source code and then ground-up reimplement a Winamp-alike program, without their lawyers coming after you. (Orgs like ReactOS don't let people contribute if they've ever read code from a Microsoft source-available repos, lest ideas inspired by that code end up in the ReactOS codebase, and Microsoft sue them for that.)

I'm not sure what to call a codebase that only grants you the (implicit) right to not be sued for reading the source and then getting inspired by it, though.

I thought reading closed-source code is a very bad idea, as if you wind up writing something similar, then you're possibly guilty of copyright infringement. If you have one team look at the design, catalog the features, and describe how it works in detail, then you can have another team implement it, and you're on legally much better ground (unless patents):

https://en.wikipedia.org/wiki/Clean-room_design

> I thought reading closed-source code is a very bad idea, as if you wind up writing something similar, then you're possibly guilty of copyright infringement.

The idea is to avoid accidentally copying code, though TBH i think this is some sort of legend that comes from decades ago and not really practical (nor, as the article mentions, required by law). Writing something similar alone won't make you guilty of anything, otherwise people who worked as programmers wouldn't be able to work at a different company on the same or similar field again ever.

I think this is a great license as it allows you to download the code, make modifications, create "pull requests", etc, but you are not allowed to compete, or distribute it with a virus baked in. That way the maintainers have full control and don't have to worry about hostile takeovers, or people making profits without contributing.

Yeah, I wouldn't call that an open source license. It's something like Microsoft's "shared source", as I expected/feared.

This license prohibits maintenance. If the official copy had a single bit that prevents it from compiling on your local machine, you cannot make that change. Only the "maintainers of the official repository" are permitted to do that.

Ianal but the license also prohibits fair use cases, which probably might circumvent the granted license.

Reply on news.ycombinator.com