Hacker News Reader

Comment by ndiddy | Hacker News Reader

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.

View on HN

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.

I believe the parent commenter was being deeply sarcastic with their suggestion

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.

The Github ToS gives users the right to fork any public repos.

On Github. Doesn't give them a license to fork it to their workstation.

One of the many bad things that Github did was to name the button that does the `git clone` action `Fork`.

Like, I get why they did it, but (as we can see) it resulted in this stupid terminology confusion.

A fork is a linked copy, a clone is just a copy. They are not the same.

  Deleting your repository or changing its visibility affects that repository's forks.

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.

I agree it does...

  fork() creates a new process by duplicating the calling process.

Thats similar to what happens on git providers, you create a new repo by duplicating it, and the repo is linked aka child.

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.

Sure, but this only matters for 'private' repos. See <https://docs.github.com/en/pull-requests/collaborating-with-...>.

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.

Fork, then clone. Simple as.

It's not clear that Github's ToS can do such a thing, is it? What gives them the right to overrule the license from Winamp to me?

Because Winamp agreed to the ToS of GitHub by uploading their code to GitHub.

The legal system don't work that way.

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

https://www.law.cornell.edu/wex/third-party_beneficiary

Is the ToS a contract? Even if it is would the remedy to Winamp breaking it be modifying the license Winamp provides?

Yes, every ToS is a contract. As for the most appropriate remedy, that's for a court to decide.

Doesn't that just mean that Github should be mad at them? Doesn't seem obvious that it actually gives me a license to do anything.

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.

A repo's license doesn't overrule GitHub's policy.

Seems a lot like that would be the other way around, copyright law overrules random company's policy.

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.

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.

They expect people to simply ignore the license.

And most people will.

And they won't set their lawyers on any contributors.

And the world will go on.

That’s not good enough. You can’t put out an open source project and expect to control the community around it to that degree.

Well, it's not an Open Source project. So there's that. ;)

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

When people who care about open source talk about "open source", they often mean the Open Source Initiative definition. https://opensource.org/osd

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.

I'm not surprised. In this case, however, it doesn't even meet the OSI definition because it doesn't allow distribution of modified versions.

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.

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.

You might want to read the WinAMP license that you're claiming is Open Source.

Though it sounds like you might be misunderstanding things on purpose. (?)

Google does it with Go, Microsoft does it with VS Code. Open source cosplay, with or without an OSI-approved license, is rampant.

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.

As @rollcat said, I suspect this means that people can contribute modifications, but that they cannot be distributed outside of the official sources.

So, while you can send a patch to add a feature, you couldn't release that modified version on its own.

That still contradicts the license as written.

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

English is a stupid language ¯\_(ツ)_/¯

You can't blame this one on English.

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.

[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

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)

Not sure...

Someone smarter than me can answer that.

Does anyone else notice the irony of enforcing a license on software whose widest use was probably to play pirated music?

Personally, I use Winamp to play FLAC files from CDs I own and to listen to streams from DI.fm

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.

I guess you could format a diff patch file locally and paste it as a text comment in an issue in their repo...? :P

Anybody know whether this would preclude patches that contain none of the project's own source code?

You don't need to fork a repo to create a branch.

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.

Reply on news.ycombinator.com