I'm curious how they expect people to contribute to the project. Section 4 of the license says "Contribution to Project: You are encouraged to contribute improvements, enhancements, and bug fixes back to the project. Contributions must be submitted to the official repository and will be reviewed and incorporated at the discretion of the maintainers." However, the restrictions in Section 5 ban forking the code or distributing modified versions. This means that the standard Github "fork the repo, make your changes in a branch, and send a pull request" workflow for submitting changes would violate the license.
Open an issue and type your patch into the description.
Note that you can't test or debug your patch, because that would mean creating a modified version of the codebase, which is prohibited. Just type that stuff straight in, directly from your fever dreams, unmediated by common practice. If it's good enough for the license, it's good enough for the code.
No, it says: "You are granted the right to Modify the software for private use only. You may make, run, and propagate Covered works that you do not Convey, without conditions, so long as your License otherwise remains in force."
It's clear they don't want you distributing modified versions. The thing people are getting caught up on is "You may not create, maintain, or distribute a forked version of the software." They fail to define "forked" but they don't seem to have meant an undistributed modification.
Because there are two definitions of fork. One is the button that says fork in Github which is really cloning the repo into your account. Then there is fork meaning "fork the project" which is actively developing and distributing an alternative lineage of the project, likely under a different name. You can use Github's PR workflow, it's fine.
Github is the one with the unfortunate naming here that goes against the already established meaning of fork. It really should be clone.
```Any User-Generated Content you post publicly, including issues, comments, and contributions to other Users' repositories, may be viewed by others. 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).```
Section D.5
Whoever the user that is posting the content is agreeing to the terms of service. If they don't actually have permission to agree to those terms with the content, then where that liability falls will likely fall to a court, but I'm sure I would argue as a user who forked the content, that I was given permission via the TOS which has to be followed by the user posting the content.
Pretty much all open source projects on GitHub rely on section D.6 of GitHub TOS (when you submit PR, it's licensed under project license and you have a right to do so).
TOS are not just fluff and paper, but legally binding. Granted, when there is a conflict between two conflicting requirements, it's never clear cut, but it's not just "GitHub will be mad."
Any project I've been involved in has its own explicit license, that allows such things (really allows much more, I don't touch anything closed source).
The implication of this is not what you think. Basically github can go after Winamp and say they violated GitHub terms that is it. Just because winamp violated GitHubs terms of service does not mean they lose their copyright rights
So someone steals my source code and posts it on GitHub, now i no longer have copyright rights?
The duty is on the copier to ensure they are granted a license.
Open source projects on GitHub rely on D6 section of GitHub TOS. That is the part where a user declares that when s/he makes a contribution to a project, s/he does so under repository license. Also that you have right to do so (e.g. when you are on employer clock, your employer must agree).
It's not just a duty of copier to ensure they are granted a license. Legal stuff is never clear cut, but if someone agreed to TOS, it should be generally (that's a funny word that can mean anything) safe to assume that s/he does abide by it.
In this case, there is an obvious conflict and when there are two conflicting clasuses... that's fun for laywers.
That's obviously not the case. GitHub even has their DMCA takedowns public. You can't redistribute copyrighted material unless it's under a license that allows for it.
Forks predate GitHub and have another almost opposing definition that sets up for a confusion here. By that lingo forks go their own way (like a fork in the road) independently of the upstream and clones are copies of an upstream.
Github does some cute things behind the scenes to save space, but for all 'public' or 'internal' repos, what Github calls a fork is (from a Github user's perspective) identical to what happens when you run 'git clone' on your machine.
I guess they mean "fork" in the broader Open Source sense when you fork something to create your own version of it and take it on a different path or do things differently like like NeoVim forked Vim. GitHub uses the term "fork" merely to create a copy of the repo for contributions.
The problem here is, of course, that the definition of "forking" is missing from the license. It is evident that two reasonable definitions for "forking" exist in this context (however you feel about Github's takeover of the term) and will continue to confuse potential contributors until fixed.
Actually this is open source. This is what the term refers to. What you mean is that it's not free (libre) software, which is most certainly is not. They do not respect you and your rights: https://www.gnu.org/philosophy/open-source-misses-the-point....
sigh OSI was established specifically because they just wanted to share code and didn't care about GNU's 4 freedoms, so don't be surprised when the proponents of open source give you projects you can't even fork.
OSI was established specifically because companies got queasy over free software's quasi-religious rationale behind the "four freedoms" and wanted something that sounded a lot more pragmatic while effectively being the same thing.
Don't get facts twisted, it was never "if you happen to peek at the code, it's open"; it's the full freedom backing behind it. That's exactly what the OSD is about, which was linked int the parent, if you bothered to read it.
We're probably just talking past each other. The reason GNU comes off as religious is because they frame the whole issue in terms of human rights and moral imperatives (it is wrong to hide the source and we have the right to share). OSI prefers to frame it in terms of capabilities and transactional relationships (it's a win-win!).
The OSD is compatible with GNU licenses; I've read it before. That doesn't change the reality that by reframing the issue from rights to abilities, the OSI created the very environment where Winamp can be released as "open-source" while making forking illegal.
They are directly complicit in propagating the lie of open-source AI. If you can't inspect how it was made, including the actual training the data, you don't have the ability to understand how the AI was made. The choice of the lumber is part of how a chair is made.
Without the "I have the right to know what my computer is doing", there is nothing backing point 2 of the OSD. Without "I have the right to share", there is nothing backing point 1.
1. Forking:
The license explicitly prohibits forking. Section 5 states:
"No Forking: You may not create, maintain, or distribute a forked version of the software."
2. Making changes:
You are allowed to make modifications, but only for private use. Section 3 states:
"You are granted the right to Modify the software for private use only."
3. Submitting pull requests:
While the license doesn't use the term "pull request" specifically, it does encourage contributions. Section 4 states:
"Contribution to Project: You are encouraged to contribute improvements, enhancements, and bug fixes back to the project. Contributions must be submitted to the official repository and will be reviewed and incorporated at the discretion of the maintainers."
However, there's a potential conflict here. The license prohibits distributing modified versions (Section 5: "No Distribution of Modified Versions"), which could be interpreted to include submitting a pull request, as that involves sharing your modifications.
In summary, this license:
- Does not allow forking
- Allows modifications for private use only
- Encourages contributions to the official repository
- Prohibits distribution of modified versions
Given these terms, you cannot fork the code in the traditional sense. You can make changes locally for private use, and you are encouraged to submit contributions to the official repository. However, the process for doing so is not clearly defined, given the restrictions on distributing modified versions.
If you want to contribute, you would likely need to submit your changes directly to the official repository without creating a public fork. The exact mechanism for this would need to be clarified by the project maintainers.
> If you want to contribute, you would likely need to submit your changes directly to the official repository without creating a public fork. The exact mechanism for this would need to be clarified by the project maintainers.
They probably don't mean it, but the standard, intended mechanism for submitting changes with git is patches sent via e-mail.
There is in other areas of copyright law, like romhacks and action replay codes. Romhacks seem like a very grey area but generally don't get DMCAed when they distribute large binary patch files of the original roms. And "Lewis Galoob Toys, Inc. v. Nintendo of America, Inc." would imply that the dead simple 16 byte[0] "patch files" in the form of game genie codes are legal.
To take a more practical example. Is there no meaningful difference between the dwm multimon patch files[1] and the full forked repo[2]? For context, lots of suckless software keeps extra features/addons in semi-offical out of tree patches files. The philosophy of suckless is generally to hardcode config options in source code and recompile instead of editing .rc files. This reduces the complexity of the code, so you end up with some very minimalistic easy to patch recompile and code. So it's a natural (if very esoteric) way of implementing plugins.
Obviously this is a bit contrived because all the suckless code is actually open source, so none of this matters to them. But I think it's fair to say that distributing the 7 .patch files at [1] wouldn't count as distributing a forked version of dwm. The patch files contain some context lines ripped straight from the main codebase, but not the main repo. Hell I'd even wonder if there's some kind of fair use argument for patch files. After all, often they boil down to a criticism of the codebase, saying that it's bad because it contains all the lines of code starting with '-' signs and really would be better if it had these extra lines of code after the '+' signs.
The license doesn't seem contradictory to me. Counter-intuitive, unclear, and paradoxical (in the most general sense of the word), yes. But not contradictory.
Before the ambiguity of language can get in the way, there has to be a coherent idea that you want to express in the first place.
This license explicitly contradicts itself. It says you are encouraged to contribute changes to the source, and you may not share changes to the source with anyone ever.
It seems like the intent is to encourage giving changes to exclusively the maintainer, and that forking in this context refers to distribution beyond a private communication between the change proposer and the maintainer.
Which, this being a git repo, makes perfect sense, as despite the impression GitHub gave to a whole generation of developers, Git was designed with a different contribution workflow in mind: one of sending patches by e-mail. Cloning the repo locally, making changes, formatting a patch, and sending it to the maintainer, seems to be perfectly withing bounds of both intent and text of the license.
Not really. Legalese is vague on purpose because not every situation can be rigidly defined.
As for English, because of its plain nature, I have little trouble understanding someone who isn't proficient or who has a heavy accent, whereas languages with specific infections or tones might not have that kind of liberty.
Didn't lame do that for years? It was distributed as a patch you could apply to the patent-encumbered MPEG "dist10" reference source code (which as far as I can see, did not even have an explicit license, the distribution only includes disclaimers of warranty)
Winamp existed before piracy was well-organised, or even bandwidth-feasible for many people. A lot of people will have used it to play rips they'd made of their own CDs.
If the permissions on the repo (in GitHub, not git) are such that you lack permission to create branches, then you must first clone (local git terminology) / fork (hosted on GitHub terminology) the repo so that all the permissions are yours.
The best thing we can do for the future of the project is to NOT engage with the project at this time ... Even just cloning the project into your private workspace to review / compile is giving more engagement than their current licensing stance warrants.
I'll check again when an HN post comes out stating they've changed their licensing stance - Until then, closing this tab and forgetting about it ...
The author justin frankel (also wrote reaper the DAW absolute legend) had this to say about it
> Question: Now that WinAMP's source has been officially released, do you have any desire to hack new badass features in?
Answer: If I did have any desire, it would be extinguished by the license terms, lol. The terms are completely absurd in the way they are written, e.g. "You may not create, maintain, or distribute a forked version of the software." So arguably making any changes would be considered "creating a forked version." But even taking these terms as they are likely intended (which is slightly more permissive than how they are written), they are terrible. No thank you.
I remember hanging out in #mpeg3 on EFNet many many years ago and becoming an acquaintance of Justin Frankel while he was working on this. I had made a skin and even a few tray icons for him to use in the app, and some of them are in here. I can't remember 100% which ones were mine, but the punchlabel one definitely was. My name is in the credits too: https://github.com/WinampDesktop/winamp/blob/0695744fd658c42...
They are either going to have to submit a ton of DMCA requests to GitHub and get their own repo taken down by GitHub, or they will be at risk of losing their copyright and will take it off GitHub themselves.
Forking is a fundamental feature of GitHub. Forking policy may only be set on private repos, but this is a public repo. The license doesn’t permit forking. There are already 6 forks.
Typically, copyright is not lost through selective enforcement (unlike trademark), but in this case the rights holder is making license violations both trivial and has full access to the list of violators. I suspect the courts will laugh them out of the room unless they vigorously defend their rights.
In that case, I certainly wouldn’t want to deal with it if I was GitHub. It is a terrible user experience, where a user clicking one of the most popular buttons on the platform suddenly becomes a legal problem.
> In that case, I certainly wouldn’t want to deal with it if I was GitHub. It is a terrible user experience, where a user clicking one of the most popular buttons on the platform suddenly becomes a legal problem.
As others have mentioned, GitHub has already covered that with their ToS. All public repos may be forked.
I have a little history with Winamp. I wrote a popular plugin for it back in the day.
This is the source code for Winamp 3, which is a total rewrite of winamp 2 in C++. In my opinion, it was overcomplicated and over-architected. The original source code by Justin Frankel in C.
What has been "provided" is the stripped down 5.666 source bundle given to radionomy when sold on from AOL & the end result of their iterations up to the 5.9.2 release. So it's made up of the however many years of the 1.x -> 2.x -> 5.x development process & however many different people hacked upon it in that time (aka a mess).
Yes there's a large part of winamp3 in there which was already long since open sourced properly in the aol era (unlike this heavily restricted licensing terms) but from what I remember when making the code deliverable the dedicated winamp3 repository was never provided (assuming my memory from 11yrs ago is still good).
Is Frankel's original code anywhere? I do recall him saying once that he preferred C++ over C but used C++ as simply C with classes. Frankel is a hero of mine.
Back in the summer of 1999 while I was in college, we were the first house to use MP3's at our parties. Most houses used a CD disc shuffler which usually consisted of a bunch of scratched and smudged discs, so their music skipped all the time.
We went all digital. We were ahead of our time.
The parties were in the basement. We'd lock the computer up in a spare bedroom - ran the wires and speakers out to the main basement area.
We used Winamp on shuffle.
Hours of music without a single skip, without us having to babysit the music.
A perversion of the term "open". The licensing terms do not allow redistribution or resale, which is a condition of "open source" (as it's commonly accepted).
Note how the title nor the repository says "open source". I would have called this source available, not that "the source is now open".
The license claims that it's a copyleft license... but it cannot be one with the distribution restrictions demanded by the license.
I hope that they either remove the claim that it is a copyleft license, or relax the distribution restrictions to something like "If you distribute modified versions of this Program, you may not call the modified versions Winamp.".
The license file also says that it's "free" and ensures that we have the "freedom to use it":
"""
The Winamp Collaborative License is a free, copyleft license for software and other kinds of works. It is designed to ensure that you have the freedom to use, Modify, and study the software, but with certain restrictions on the distribution of modifications to maintain the integrity and collaboration of the project.
"""
Looks like there's already pushback in the issues section [1] [2].
The only music player that wasn't annoying. Just did its job with a streamlined interface, without the clutter and clunky graphics that competitors thought was the way to go.
There were winamp3 / modern 5.x skins which were freeform in nature so could be all sorts of shapes or not depending on what the skinner wanted it to be like. With 5.x still supporting the fixed form classic / 2.x skins as webamp & its skin museum support.
My 'favourite' nowadays is Tidal. Those botchers cannot make a stable playback experience, also the UI is full of user hostile elements, approaches, and malfunctions. If I was in the position of hiring, those coming from Tidal had no chance.
Funny, the latest commit is "Removing code which is not open"[0], which means they are infringing on someone else's licensing terms by keeping it in the git history.
llama group / "winamp" don't own shoutcast anymore as that was all sold off a year or so ago to azerion as part of changing audiovalley into llama group.
The history section just above the prior properties section is what's now the case with winamp & shoutcast under unrelated organisations nowadays. Though it's all a bit murky as radionomy & audiovalley were the same top people.
Don't be discouraged by hn folk, people like to think this is better than reddit but we have our own brand of toxic here, if you want to sign your comments go ahead
I didn't see anything wrong with asking about it & I as don't really use HN I'm not sure of what the expectations, etc are on here. So imho its all good from my view point.
Ha! They've been quickly pulling some other things in the last hour or two, like a bunch of files with this header...
* Copyright 2000-2002 Dolby Laboratories, Inc. All Rights
* Reserved. Do not copy. Do not distribute.
* Confidential information.
*
* (C) copyright Fraunhofer - IIS (1998)
* All Rights Reserved
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.
> 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).
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
"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.
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.
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.
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).
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).
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.
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!
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.
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!
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".
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!
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.
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).
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.
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.
> 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.
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.
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.
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.
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.
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.
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
> 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.
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).
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.
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.
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.
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.
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 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.
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.
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.
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.
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):
> 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.
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.
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.
I was a huge fan of Winamp back in the day, but the way they handled the software completely soured me towards it. Winamp 3 was a clusterfuck, Winamp 5 was fine but felt like bloat, and then it was passed around like a hot potato, then abandoned on and off, and then the open sourcing feels like it was also around for quite some time. And now it's not even that, just a meager source-available. I know they don't owe me anything, but I feel disappointed.
You have to place some of the blame for latter Winamp versions on AOL who purchased Winamp from Frankel's team and messed with it so much he eventually resigned.
I think selling it wasn't mandatory, and the consequences of selling are predictable, so some of the blame rest with the original decision-makers as well. But I find hard to care after so many years, if I have to be honest, they just messed with my darling too much, and I have long moved on.
It was either sell it & shoutcast or kill both off since aol in 2013 was changing & there's lots of other projects under them at that time which were killed off instead of what was thought to be a better option to keep it going elsewhere.
Alas going to radionony which has ended up becoming llama group after some funny business stuff going on was a mistake though some of the other options that I was aware of at the time weren't great either.
And I'm not defending aol either as there were things that I didn't like under their almost 15yr tenure of ownership but it was never condescending like this lot have been over the past 11yrs which their licensing terms have reinforced.
This is a weird Easter Egg that's been compiled into real, genuine, uncracked Winamp release builds for a very long time.
The actual compiled binary ends up with the same text you see linked there scrambled using XOR (you can see that on the other side of the #if 0) to avoid it appearing in the binary's strings verbatim.
Weird, how does that even work? Does cracked mean its' been decompiled? It's strange because it includes other stuff like build scripts, etc that wouldn't be in released binaries..
Those names were some of the original devs & they're the ones who put it in the easter egg on the about dialog that it relates to as a hacker-like joke. The source code is what aol sold on as a stripped down copy of 5.666 & then what radionomy/audiovalley/llama group iterated on afterwards. As much as I dislike what now calls itself "winamp", it's nothing nefarious & you can find old 2.x installs with that about easter egg text.
Bizarre license reeks of a company that doesn't know what to do with their own highly regarded software but is desperate for the community to give them free improvements that they can later monetize.
This is a Worms sound effect as well, right? Does it come from a sound library? (I feel like I have watched a video about this at some point, but if there isn't one, there should be.)
Everyone is commenting on the distribution terms. But the Contributions section is just as bizzare.
> Waiver of Rights: You waive any rights to claim authorship of the contributions or to object to any distortion, mutilation, or other modifications of the contributions.
I waive the right to claim that I authored my contributions? Wait, what?
Why would I ever contribute to this project under this license?
With European copyright law, these so called "moral" rights are not transferrable: you can always claim authorship and even revoke a license if it was used in a morally reprehensible way that harms your name as an author.
I have Master of Orion 2, which came out when DirectX was in version 1.0. It technically executes in Windows 10, but the graphics are glitchy.
When they re-released it on Steam along with the MoO remake, they actually packaged the DOS version with DOSBox rather than release the Windows version.
I think this is largely only true with Windows games from the '90s using still-nascent 3D apis. Many of these games were broken on modern versions of Windows by the time Vista came out.
Once you get to the early '00s, you can still find a lot of games that are broken, but the culprit is usually changes in hardware and driver behavior rather than Windows itself.
No, not really. Even if you ignore DRM which practically makes ALL games from the XP-Vista era unplayable (which I ignore since that is often not better in Wine), just search around for the amount of workarounds that are required even when you apply these patches.
I wasn't saying that fewer games from the '00s require fixes, I said that the things that are broken in them are more often caused by factors other than Windows itself. The most common compatibility issues I see with games from this era are caused by changes made to GPUs and/or their accompanying drivers.
Take for example the first two Splinter Cell games. Certain shadows on them do not render on modern GPUs. The root cause isn't any changes Microsoft made to DirectX or Windows, but Nvidia deprecating a feature they relied on in their GPUs and their drivers not providing any kind of fallback. If you play these games on Windows XP with hardware from 2003, they run fine. But if you play them on Windows XP with hardware from 2007, they do not.
Wine fixes a lot of these games because it is already providing its own translation layer for graphics calls, and any GPU vendor-specific DirectX stuff gets translated into hardware-agnostic Vulkan. These same games are often easy to fix on Windows using DXVK (Wine's DirectX translation layer), or wrappers designed for late '90s and '00s games like dgvoodoo2.
The big elephant in the room is DRM, with popular solutions like StarForce being deliberately broken by Microsoft.
They're very unlikely to have that as I don't remember it falling under the remit of things to be collated when things were sold from aol to what now calls itself "winamp" - they primarily got a stripped down 5.666 & what's offered is their iterations though aspects of what was winamp3 would be within the gen_ff plug-in.
This is the license equivalent of a specific automotive spare part for an old car where the dealer asks $1300 for it just to say they don't want to stock and sell those. "Yeah, it's available, sure, but...you don't want it."
Why did people start talking about open source in this thread? This is almost the opposite of open source, and doesn't claim to be open source. It's restrictive to the point where you should just treat it as an official source leak. It's even called "collaborative" by which they clearly mean that if you want to work on the software, you're free to send them a pull request. You're also free to compile it yourself, as long as you don't distribute it (modified or not) in any way.
Nothing wrong with this, but I don't understand why people started arguing about open source. Because you get to look at the source?
I recently wend through the process of selecting a MP3 player software for my Linux laptop and after testing many settled on the Strawberry player. It is actually very good: https://www.strawberrymusicplayer.org/
Ya the one between your ears. Kidding! Maybe Sourcegraph Cody https://sourcegraph.com/cody, or possibly Github copilot. I think Cody might handle the multiple files better, and allows you to pick from multiple models.
Thanks for sharing. Wonder if they've ever heard of color contrast. Dark blue on dark blue is not very readable. Had to highlight the article to read it.
Looks like a bug in their light theme - it's using the dark theme's background. There's a theme toggle top-left to switch to the still-functioning dark theme.
Guessing they probably started with a light theme then retrofitted a dark theme & rolled it out without realising it would regress the existing light theme.
Nah, I'm on my work computer. No browser add ons. Just standard chrome in dark mode. Clicking the light/dark toggle on the page (as some others suggested) does fix it.
That'd mean they'd have to do more work then necessary & there'd at most only ever be what went back to the stripped down 5.666 code deliverable they got after it was sold on from AOL at the start of 2014 (was looked into but determined not worth the hassle when that was being sorted out at the time).
"source code is open" implies "open source", and the License refers to itself as a "copyleft" license, but it's a newly minted license - IANAL does anyone know if this is open source or another Elastic type situation?
Cool, I guess. But WinAmp is in the category of software that is easy to write, but benefits hugely from the network effect. Nobody would care about WinAmp if it weren't for the huge number of skins the community created for it.
Barring the ton of licensing stupidity ongoing (maybe they'll fix it, who knows), as far as I know you could actually do that by forking the repo and then connecting your fork to bountysource. Open an issue for each target OS, set the amounts, and then publicize that fact on as many social media channels as you have access to
However, I wanted to draw your attention to "are you asking the right question" because there's a very real chance that the things you actually love about Winamp would not carry over to any such ports, since it's not "recompile and get the Winamp on Windows experience" - they would be Gnome and macOS apps, behaving similar to other such apps
Eh, here we go again, there's yet-another custom license, "Winamp Collaborative License (WCL) Version 1.0". Quick skim:
> 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.
It's basically "look but do not touch". I don't see why this was necessary for something that's basically abandonware by now, and is mostly of historical interest.
Is there an official announcement or something else that accompanied this? I don't know the current state of their organization and the chain of ownership for the code.
What a load of BS. This is just a poor attempt at open-source-washing.
They rolled their own license but couldn't be bothered to read GitHub's ToS.
"collaborative" license, "opened to the community", "enabling the entire community to participate in its development", "global collaboration" but you have to grant them perpetual rights and waive your own, you're not even allowed to fork lol.
Seems like they're only looking for unpaid workers.
Is there even any development happening on Winamp? What would these unpaid workers do? If they can't touch the code, not even test it, then the only thing this repo could serve is reporting bugs, but will anyone fix them?
I feel like this whole release is just a PR stunt to remind us that winamp still exists. They don't actually want any help, nor do they want to give anything to the community. They just want to get into gossip, so the spectacular chaos with releasing certificates and 3rd-party proprietary code actually helps for publicity.
They dumped the prior dev team over a year ago (the ones that added the nft plug-in & fanzone crap) & it is mostly a ploy to get a free dev team as was speculated when the whole "source available" thing got announced 4 months ago (but they seem to have left it to the night before to do anything hence the complete mess that's been going on).
The license was always going to be restrictive & focused on what only benefits them as they would never want any clones, etc to be able to make use of it. Also the terms when I look at it from an ex plug-in dev stance seem to prevent any new / updated plug-ins from being built with the plug-in api headers which afaict would fall under their license & surplanting the prior one (no idea if they've changed the in-file stuff or not as I cannot look at their code to avoid issues with work my own player).
"You are granted the right to view, access, and study the source code of the software. You are granted the right to Modify the software for private use only."
"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."
Title is "Winamp Legacy player source code is now open". The usage of the word "open" in conjunction "source code" alludes to the long established "open source code" phrase, which implies a set of licenses, and the associated open source culture.
A better choice for the title would have been "Winamp Legacy player source code is now available".
I agree but my statement still holds true. When something doesn't explicitly say "Open Source", it's not Open Source. This is a very old trick that i've learned decades ago..
I find it hard to believe that any serious person would argue that "code that is open to the community" ≠ "open source code".
I think it's realistic to assume that the developers who wrote the README, and the lawyers who wrote the license didn't talk to each other much when making decisions about how much freedom users were going to have with the code.
They've worded it just as they intended imho (ignoring the confusion over fork aspect) as it's how to ensure that they're still in charge & to prevent anything derivative as they really don't like that based on prior experience with them.
It's also mostly about getting that lovely free dev work because with oh so many capable devs out there they're just going to be clamouring to want to give up anything where possible to be able to work on this along with trying to appear to be doing good. Even though they've halted development at least 3 times I'm aware off & ditched a number of dev teams under their 11yr tenure of ownership.
I share the same feelings, and I think that the way they phrased it is intentional. They are clearly capitalizing on the goodwill that is built around open source software over the years. In a "having the cake, and eating it too" kind of way.
And then proceeds to not be a free, copyleft license.
This pretty clearly seems like they're trying to squat on the terms "copyleft" "free software" and "open source" while weasel-wording their way out of it — "open washing", as someone else in the comments called it, seems to fit. This smacks of someone who wants to use the words, and to have you feel like they've used the words, but without having to actually do the things the words would mean, spoken genuinely.
Contract law doesn't really allow for this kind of behavior. If you say over and over again that your software is open source and the community is free to develop with it as they please, and then write your license to say the opposite, you're going to have a hard time enforcing the license given that you're actively telling people to violate the terms in your press release.
