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.
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.
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.
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.
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.
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.
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)
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.
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.
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).
```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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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
> 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 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.
> 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.
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.
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.
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).
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.
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.
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):
> 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.
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.
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.
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.
> 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.
"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?
"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.
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/
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.
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.
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.
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].
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.
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.
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 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.
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
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).
344 comments
[ 2.6 ms ] story [ 377 ms ] threadHere is a screenshot of what I see if you're curious: https://imgur.com/a/eRchEn7
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.
Hopefully one day they'll actually Open Source it. I mean, they're trying to pretend it is, so why not just do it properly?
So, while you can send a patch to add a feature, you couldn't release that modified version on its own.
> No Forking: You may not create, maintain, or distribute a forked version of the software.
There is no meaningful difference between the words "patch" and "fork"; and the act of creating an edited codebase is explicitly disallowed.
If that isn't what they want, then they had better write more clearly.
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.
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.
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.
[0] Looks like the longest codes are 32 digits of hex long: https://archive.org/details/GameGenieSNESCodebookProgramming...
[1] https://dwm.suckless.org/patches/multimon/
[2] https://github.com/garybgenett/.dwm
Someone smarter than me can answer that.
Github is the one with the unfortunate naming here that goes against the already established meaning of fork. It really should be clone.
Like, I get why they did it, but (as we can see) it resulted in this stupid terminology confusion.
Many forks do go their own way. You can choose to pull from upstream or completely ignore it.
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.
That ToS is between wimamp and GitHub, not you.
You have to do the due diligence to get the permission from winamp.
You might be able to get away by suing GitHub and have them sue winamp. ..
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."
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.
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.
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.
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.
And most people will.
And they won't set their lawyers on any contributors.
And the world will go on.
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.
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.
If you want a good look at OSI's commitment to the OSD, take a look at their Open Source AI initiative: https://opensource.org/deepdive https://opensource.org/deepdive/drafts/open-source-ai-defini...
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.
Though it sounds like you might be misunderstanding things on purpose. (?)
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.
They probably don't mean it, but the standard, intended mechanism for submitting changes with git is patches sent via e-mail.
> 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.
But the restrictions on the source are interesting. To quote the license file:
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.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!)
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?
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.
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.
https://www.gnu.org/licenses/copyleft.en.html
This implies your take on copyleft is an adversarial one, in which case implying your definition is canonical is disingenuous.
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.
Amusing; there are already 6 forks on GitHub as of this writing.
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
> 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...
At best they could invalidate the one license they control, but even that seems iffy
Whichever one runs up the attorney's bill the highest.
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.
> 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 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?
By creating an account on GitHub, you agree to this license. That seems like a pretty strong precedent for precedence.
"modified/derived version" vs "copy"
> 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.
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.
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.
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?
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!
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.
https://docs.github.com/en/organizations/managing-organizati...
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).
So, essentially, winamp license means nothing. They already forfeited their right to deny you forking by posting it on GitHub.
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!
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.
They may have meant something else, but what it says now is “no forking.”
[0] : https://en.wikipedia.org/wiki/Hanlon's_razor
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.
https://en.wikipedia.org/wiki/Clean-room_design
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 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.
https://github.com/WinampDesktop/winamp/pull/7
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.
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.
https://winamp.com/press/winamp-open-source-code
"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."
EDIT: looks like the title’s been corrected!
https://winamp.com/press/winamp-open-source-code
A better choice for the title would have been "Winamp Legacy player source code is now available".
>its source code was opened to the community
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.
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.
https://winamp.com/press/winamp-open-source-code
> The [license] is a free, copyleft license
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.
What you're complaining about is free source code, which this probably is not.
Nice. Wonder how long will this version work?
If Winamp is broken on Windows N+1, it's Windows that is broken. If Winamp is broken on Wine, it's Wine that is broken.
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.
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.
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.
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.
Winamp has announced that it is "opening up" its source code
https://news.ycombinator.com/item?id=40383029
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.
As others have mentioned, GitHub has already covered that with their ToS. All public repos may be forked.
Note how the title nor the repository says "open source". I would have called this source available, not that "the source is now open".
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].
[0] https://github.com/WinampDesktop/winamp/blob/community/LICEN...
[1] https://github.com/WinampDesktop/winamp/issues/16
[2] https://github.com/WinampDesktop/winamp/issues/6
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.
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).
-dro
This is more significant (to me) than the iPhone 16 launch, I'll pay for people who can port this to Linux (Gnome) and Mac OS.
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
https://github.com/WinampDesktop/winamp/blob/community/LICEN...
I was personaly hopping a much more ordered and clean codebase.
-dro