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

231–240 of 294 posts

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

#231

Post by anshumankmr »

remram wrote: post #210
sangnoir wrote: post #136

If you have a Raspberry Pi wasting away in a drawer[0], I strongly recommend installing Gitea or Forgejo and mirroring all the repos you like (i.e. the ones you contribute(d) to and/or starred, not just on Github too!). You set it up once and it will sync in upstream changes as often as you like (default is daily) 0. Or a homelab, or a cheap 256MB VM, or a NAS that can run docker containers, or an old Chromebook: any…

I wonder if there is an efficient way to do direct incremental git-to-S3 backups, or if you have to do this, run a Git mirror and do regular filesystem-level backups of it.

a cron job ought to do this. Try something like Cloud Scheduler that can automate this for you.( I am not sure what the equivalent is in AWS)

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

#232

Post by jakeogh »

Anyone know why github search seems to be broken? While logged in, if I query https://github.com/yt-dlp/yt-dlp/search?q=exec_cmd no results are returned for any category. But "exec_cmd" exists in a few places in that repo, for example: https://github.com/yt-dlp/yt-dlp/blob/master/yt_dlp/options....

On another note... It's a honest question to ask, does github state anywhere a policy on shadowbanning (treating a repo differently in any way)? It's becoming a law of tech nature that any org big enough starts to do it. Some variation of a warrantcanary (preferably in the form of a contract with the users "we have not done X Y Z") would be cool.

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

#233

Post by donmcronald »

hakfoo wrote: post #225
jefftk wrote: post #187

Earlier quoted context omitted.

Segmenting an enterprise version of a product is generally about finding features that are disproportionately valuable to enterprise (centralized control, policy enforcement, auditing, etc) separating them into a different offering. This lets you charge less to small businesses without having your small business product cannibalize your enterprise business. This seems basically fine to me? If there are a lot of small…

The particular segmentation is a questionable choice. Small enterprises are likely to have small IT/Security staff, and the most likely, therefore, to not notice something awry for a few days, at which point, vital log info has already rolled off the 7-day window.

This is exactly the issue. No one monitors the logs and, by the time they figure out something is wrong, there isn't enough info available to properly assess the scope of the damage.

Another problem is the Business Basic product is too complex for what small businesses need (reliable email) and buying something even more complex to get a couple of extra features like proper logging is counterproductive.

As is, if a small business ends up with a compromised admin account I don't think it's unreasonable to consider migrating them to a different service. It's nearly impossible to guarantee a bad actor hasn't hidden a back door somewhere in all that complexity if your only tools for assessment are the ones offered in the Business Basic subscriptions.

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

#234

Post by MereInterest »

djur wrote: post #188
mattigames wrote: post #148

Earlier quoted context omitted.

That would make sense if they didn't use the word "fork" for it, that words has a specific meaning when talking about repositiories[0] and it doesn't include a automatically propagating deletions or settings of the original repo, it doesn't actually include ANY automatic propagation, therefore GitHub should use a different word for this kind of fork, something like "Crate child fork" or "Linked fork" or maybe a new w…

GitHub coined this particular use of "fork", and it's always been about having an automatically managed relationship between the original repository and the new one. A copy without that automated connection is a clone.

No, it definitely predates GitHub. And git itself, by at least a full decade.

https://en.wikipedia.org/wiki/Fork_(software_development)#Et...

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

#235

Post by eyelidlessness »

shagie wrote: post #228
eyelidlessness wrote: post #217

Earlier quoted context omitted.

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, changi…

The first part sets up the second part that unlike the GPL, the MIT license doesn't require that future contributions to the project be any particular license. Presumably the OP can find the open source project MIT licensed without the company's contributions to it. The only thing that the MIT license requires is: > The above copyright notice and this permission notice shall be included in all copies or substantial p…

> And so, it is possible (and I would dare say likely) that the contributions that the OP made while working on the repo at the company unless specific permission was given otherwise would be considered as work for hire or as part of the work product as condition for employment and completely owned by the company (and not MIT licensed).

This is a radical interpretation of the text if I’ve ever seen one. To the extent any of their contributions were merged upstream, they’re inherently MIT licensed by virtue of being in the same codebase which offers that license. To the extent they have unmerged changes, they may well be works for hire but it isn’t GitHub’s role to decide that between a second and third party.

Again nor do they want to. GitHub is extremely hands off about forks and the licensing implications thereof.

This isn’t a GH posture towards licensing disputes, it’s their posture towards their own authorization model. And that’s fine, but we shouldn’t conflate the two when they’re quite distinct.

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

#236

Post by IncRnd »

kitkat_new wrote: post #142
IncRnd wrote: post #132

Earlier quoted context omitted.

Exactly. That implies that when a person is removed from the selected audience, they lose access to the private code.

to my private repository, but not their own private repository. like it happens when a public repo goes private: I don't loose access to my fork of the repo but access to the original repo

You are trying to construct a scenario, where you have the ability to elevate your own rights to somebody else's repo's contents. Name a computer system that intentionally allows people to do that. That similar to demanding that you can still send emails on a terminated email account from your prior employer.

If you want to continue your access to that private repo's source code, you now need to speak to them. They own it, not you.

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

#237

Post by kadoban »

jefftk wrote: post #181
naikrovek wrote: post #127

Earlier quoted context omitted.

> My private forks are mine Not if you create them using the "Fork" button in the UI. Since this behavior has yet again surprised many people, here is the documentation: https://docs.github.com/en/pull-requests/collaborating-with-...

Which also shows the right way to delete a private repo if you want people to be able to keep their forks: If a private repository is made public, each of its private forks is turned into a standalone private repository and becomes the upstream of its own new repository network. Private forks are never automatically made public because they could contain sensitive commits that shouldn't be exposed publicly. If a priv…

The right way is to make it public first? That's insanity. Making a repo public just to delete it would be a huge information leak even if it was short in duration.

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

#238

Post by shagie »

eyelidlessness wrote: post #235
shagie wrote: post #228

Earlier quoted context omitted.

The first part sets up the second part that unlike the GPL, the MIT license doesn't require that future contributions to the project be any particular license. Presumably the OP can find the open source project MIT licensed without the company's contributions to it. The only thing that the MIT license requires is: > The above copyright notice and this permission notice shall be included in all copies or substantial p…

> And so, it is possible (and I would dare say likely) that the contributions that the OP made while working on the repo at the company unless specific permission was given otherwise would be considered as work for hire or as part of the work product as condition for employment and completely owned by the company (and not MIT licensed). This is a radical interpretation of the text if I’ve ever seen one. To the extent…

Who's upstream?

Open source project and publicly accessible upstream? Yep. They're likely MIT licensed in accordance with the CLA.

Internal company copy of an MIT project? Unlikely unless legal says they are.

If the organization that I worked for made an internal copy of Influxdb ( https://github.com/influxdata/influxdb ), my contributions to the private and internally hosted copy are not inherently MIT licensed too and furthermore don't need to be redistributed.

If those changes were submitted upstream to the influxdata/influxdb repo, and I signed the CLA with them - then yes they would be.

What's more, if I left the organization, then I don't necessarily have a right to the contributions that I made to the private and internally hosted copy's codebase.

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

#239

Post by eyelidlessness »

shagie wrote: post #238
eyelidlessness wrote: post #235

Earlier quoted context omitted.

> And so, it is possible (and I would dare say likely) that the contributions that the OP made while working on the repo at the company unless specific permission was given otherwise would be considered as work for hire or as part of the work product as condition for employment and completely owned by the company (and not MIT licensed). This is a radical interpretation of the text if I’ve ever seen one. To the extent…

Who's upstream? Open source project and publicly accessible upstream? Yep. They're likely MIT licensed in accordance with the CLA. Internal company copy of an MIT project? Unlikely unless legal says they are. If the organization that I worked for made an internal copy of Influxdb ( https://github.com/influxdata/influxdb ), my contributions to the private and internally hosted copy are not inherently MIT licensed too…

It doesn’t sound like we have any substantive disagreement other than potentially what GitHub’s role in it is or should be.

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

#240

Post by voytec »

tux3 wrote: post #7

I think this is under the assumption of "employee has a private fork of the company repo, then leaves, employee should not keep the fork" So when "removed as a collaborator" which apparently includes the original being deleted, you lose access to the main repo and all forks, even yours. As if leaving a company.

OP states that it was "an MIT-licensed open source project". It appears that Microsoft has lack of licensing understanding not only when it comes to copilot.

If they are punishing users just under an assumption that user is doing what they are doing (using someone's codebase with non-permissive licence, possibly unlawfully), it's just silly.

Post reply on HN