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.
Like, I get why they did it, but (as we can see) it resulted in this stupid terminology confusion.
Deleting your repository or changing its visibility affects that repository's forks. fork() creates a new process by duplicating the calling process.
Many forks do go their own way. You can choose to pull from upstream or completely ignore it.
Deleting your repository or changing its visibility affects that repository's forks.
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.
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.
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."
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.
So, while you can send a patch to add a feature, you couldn't release that modified version on its own.
Someone smarter than me can answer that.
> 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.
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...
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.
Github is the one with the unfortunate naming here that goes against the already established meaning of fork. It really should be clone.
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.