Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tell HN: GitHub will delete your private repo if you lose access to the original

news.ycombinator.com

Post reply on HN
Print view View original

211–220 of 294 posts

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#211

Post by sshine »

Alupis wrote: post #135
benatkin wrote: post #72

Earlier quoted context omitted.

[flagged]

That is an awful lot of contortions you are doing here, to seemingly justify a word change that has had well-cemented meaning within the tech community since it's inception. We all know why this change exists, and why some people will attempt to persuade others of it's superiority. It is, however, just silly virtue signaling, and it's exhausting to hear and read. It would require some very irrational and underdevelop…

> no one is safer or feels better

Clearly some feel better.

I personally like the name “main” better.

But it is truly a pain in the neck that different pieces of software and even different distributions of the same software now disagree about the default.

I’ve got a handful of active projects that go together that differ on master/main because they were created by different softwares.

I’d prefer “hitler” if everyone could just agree to always pick that. GitHub are the big pushers of this culture change. If they succeed, I salute them.

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#212

Post by barco »

Given the nature of super forks in GitHub, if you are no longer a contributor, but keep your fork, you would be able to see the commits that happen in the original repo and all its forks.

There used to be a way to bypass the deletion, which was to clone into a organization. That way, GitHub would not delete your fork. I am not sure if it is still the case.

I reported all this to GitHub a few years ago, but they said it was a non-issue .

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#213

Post by shagie »

pxc wrote: post #207
shagie wrote: post #174

Earlier quoted context omitted.

The original code may be licensed MIT. The MIT license allows for the project to be relicensed, closed source and it is also possible for a proprietary contributions that aren't MIT license to be added to it that are protected as any other closed source code. The MIT license is not "viral" and doesn't require that everything following from it is. The person may be able to find the original code that was MIT licensed…

OP wrote > That was an MIT-licensed open source project I worked on years ago. which to me implies that OP also received the code under the MIT license and not some other license.

However, the work done while at the employer may not have been done under the MIT license unless permission to license it and distribute it under the MIT license was given by legal.

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#214

Post by sshine »

benatkin wrote: post #186
Alupis wrote: post #175

Earlier quoted context omitted.

> I'm willing to go out of my way to use a different word if it makes people feel better Which is just the thing, really. It makes no one feel better. It makes the privileged speaker feel better, with a false sense of virtue. It's a "look at how great I am" signal, nothing more. No one is harmed or made to feel bad by using the word master. Sometimes the adults have to be present in the room, it seems. Saving 2 chara…

It's because main is a goldilocks word for something like a default branch name. It isn't too long and isn't too short. It also isn't shorter in terms of syllables. Good design :)

> main is a goldilocks word

I totally agree.

> Good design

Having one default instead of two is better design.

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#215

Post by [deleted] »

benatkin wrote: post #186
Alupis wrote: post #175

Earlier quoted context omitted.

> I'm willing to go out of my way to use a different word if it makes people feel better Which is just the thing, really. It makes no one feel better. It makes the privileged speaker feel better, with a false sense of virtue. It's a "look at how great I am" signal, nothing more. No one is harmed or made to feel bad by using the word master. Sometimes the adults have to be present in the room, it seems. Saving 2 chara…

It's because main is a goldilocks word for something like a default branch name. It isn't too long and isn't too short. It also isn't shorter in terms of syllables. Good design :)

[deleted]

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#216

Post by Alupis »

sshine wrote: post #211
Alupis wrote: post #135

Earlier quoted context omitted.

That is an awful lot of contortions you are doing here, to seemingly justify a word change that has had well-cemented meaning within the tech community since it's inception. We all know why this change exists, and why some people will attempt to persuade others of it's superiority. It is, however, just silly virtue signaling, and it's exhausting to hear and read. It would require some very irrational and underdevelop…

> no one is safer or feels better Clearly some feel better. I personally like the name “main” better. But it is truly a pain in the neck that different pieces of software and even different distributions of the same software now disagree about the default. I’ve got a handful of active projects that go together that differ on master/main because they were created by different softwares. I’d prefer “hitler” if everyone…

There was zero disagreement about what to call the default branch in git prior to this linguistic crusade.

GitHub practically invented the exact situation you're experiencing now by changing to main for all new repos.

Git itself still defaults to master. Everything else is not the default and is the root cause for the uncertainty.

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#217

Post by eyelidlessness »

shagie wrote: post #174
pxc wrote: post #163

Earlier quoted context omitted.

Did you forget the part where this code is MIT-licensed? Yes, they don't own it, but the code is still 'theirs' to keep forever as they see fit.

The original code may be licensed MIT. The MIT license allows for the project to be relicensed, closed source and it is also possible for a proprietary contributions that aren't MIT license to be added to it that are protected as any other closed source code. The MIT license is not "viral" and doesn't require that everything following from it is. The person may be able to find the original code that was MIT licensed…

IANAL but…

> The original code may be licensed MIT. The MIT license allows for the project to be relicensed, closed source

… this is less compelling to me than this:

> and it is also possible for a proprietary contributions that aren't MIT license to be added to it that are protected as any other closed source code. The MIT license is not "viral" and doesn't require that everything following from it is.

AFAIK, changing the licensing terms of an MIT project isn’t retroactive to prior licenses. A quick search seems to confirm that.

The possibility of more restrictive or revocable licensing of subcomponents is more compelling as a rebuttal to “mine” at a philosophical level, but it’s not compelling from the perspective of GitHub revoking access. They’re welcome to comply with relevant legal actions, but they’re not actually the police of your licensee status and don’t even attempt to be.

Ultimately it’s the person who maintains the private repo who is responsible for and to any license challenges. GitHub isn’t a party or privy to those agreements, and again doesn’t have any pretense of such except compelled by legal action. And I give them the benefit of the doubt that this isn’t their motive.

This behavior is part of their own permissions model, and their own model of the relationship between “forks” and “private”, as defined by their own use cases. It’s a surprising one, but it needn’t have anything at all to do with their view of any given user’s repo’s license compliance.

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#219

Post by charcircuit »

jzb wrote: post #98
charcircuit wrote: post #26

Earlier quoted context omitted.

Github knows the license of projects. It knows if you forked an open source project.

It knows the license applied to the repository. For a private repo it may not be "released" under that license but planned for release. If AcmeCorp is planning to release - but hasn't - a project under MIT or whatever, they may have the license declared in the repo but that's not a guarantee it's ever going to be released. If it's a private repo, and your access has been under your status as an employee, then I don't…

Software can be open source and not released. Employees can legally release it themselves since it is open source.

Re: Tell HN: GitHub will delete your private repo if you lose access to the original

#220

Post by [deleted] »

fragmede wrote: post #12
csteinbe wrote: post #6

This is documented at: https://docs.github.com/en/pull-requests/collaborating-with-...

“But the plans were on display…” “On display? I eventually had to go down to the cellar to find them.” “That’s the display department.” “With a flashlight.” “Ah, well, the lights had probably gone.” “So had the stairs.” “But look, you found the notice, didn’t you?” “Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Bew…

[deleted]
Post reply on HN