7 ms·

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

by tux3 4y ago

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.

chrisfosterelli 4y ago
Yeah I understand how this is unfortunate but for 99% of cases this is what you want to happen when you remove someone's access to a private codebase. It seems like this is an unusual use case that OP had an MIT-licensed open source project whose source only exists in a private repo.
- cma 4y ago
  Is this scenario possible? - you fork a public repo - it's visibility is changed to private but you have access through the org - they delete it - you lose your fork, which was only ever of the public repo
  - kitkat_new 4y ago
    no, in this case it works as expected; "GitHub will detach public forks of the public repository and put them into a new network. Public forks are not made private." https://docs.github.com/en/repositories/creating-and-managing-repositories/about-repositories https://docs.github.com/en/repositories/creating-and-managin... But better be safe than sorry...
nly 4y ago
What's the point? You can always clone locally and push to a new repo without forking on GitHub. Repos will be unlinked and history will be intact.
- chrisfosterelli 4y ago
  It's for the same reason that you don't leave ex-employees with access to other intellectual property. Just because they could make their own copies during their tenure doesn't mean you shouldn't try to reduce your exposure.
charcircuit 4y ago
Github knows the license of projects. It knows if you forked an open source project.
- jzb 4y ago
  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 know that counts as distributed to you under that license. If AcmeCorp later decides to change licenses or not release the software as open source, then it makes sense for GitHub not to let someone continue access. There are a LOT of holes in the system, but I'm not sure GitHub is in the wrong for deleting access to a private repo if you lose access to an organization or whatever.
  - charcircuit 4y ago
    Software can be open source and not released. Employees can legally release it themselves since it is open source.
    - jzb 4y ago
      Really no. The employee doesn’t have that right, it’s not theirs to release unless the employer gives permission.
    - funcDropShadow 4y ago
      No, the software becomes "Open Source" or "Free Software" the moment someone licenses it to somebody else under such a license. Simply copying a file named LICENSE into some private directory has no legal relevance. As an employee, you usually don't get a license to the work artifacts you are working on.
jiggawatts 4y ago
Microsoft does this a lot, where they assume that rules that apply to their own organisations apply to all organisations in precisely the same way. If a Microsoft IC leaves, they should lose access to all Git repos, including forks. If Joe Random open-source contributor is removed from an open source repo's access list, their fork shouldn't be wiped. But Microsoft has One Rule To Rule Them All, so they won't make exceptions for unimportant people like their customers. I see this a lot. A good example is Azure Active Directory, which is basically "Microsoft 365 Authentication" that they rebranded and sold to developers for their own use, i.e.: Azure AD Enterprise Apps, App Registrations, and B2C. There are many aspects of the AAD design that make zero sense until you pause for a second and realise that it is not designed for you. It's designed for Microsoft 365! For example, auditing. My customers are typically government agencies or banks, and they have strict auditing requirements, especially related to data access. All user authentication MUST be logged, including client IP address, and everything else. Most access is by their own staff, or by other orgs that have signed various contracts or agreements, so there is no expectation of privacy. This is basically impossible with many configurations of AAD. It just refuses to collect meaningful audit logs. Why? Because GDPR applies to Microsoft 365 and they don't care about the data hosted on services such as SharePoint Online. That's not Microsoft's data, that's their customers' data, so its up to the customers to enable logging "on their end", in their individual AAD tenants. There is no way to centrally collect logs as a service provider using AAD in a multi-tenant scenario. When I asked Microsoft about this, they waffled on about GDPR and privacy regulations -- which apply to them, but not us. Another example is Microsoft Teams, which hides the name of the organisation people are coming from. In large multi-org meetings this is infuriating, because you have no idea where anyone is from. Microsoft does this because they use outsourcers like MindTree for support, and they don't want their customers to see this in Teams meetings for Azure support tickets. No-one is allowed to see where people are from so that Microsoft can bullshit their customers.
- donmcronald 4y ago
  > There are many aspects of the AAD design that make zero sense until you pause for a second and realise that it is not designed for you. It's designed for Microsoft 365! Business Basic accounts being limited to 7 days of login logs is a huge middle finger to the entire small business sector. Of course they think everyone should just buy Enterprise subscriptions. It's nothing more than a corporate version of "don't be poor".
evouga 4y ago
This doesn’t make any sense to me. My private forks are *mine* and I most certainly do not want GitHub guessing at whether and when to permanently delete them without my consent. Companies of course have the right to manage access to their proprietary source code, for example by only giving access to corporate accounts under their control and reclaiming those accounts when an employee leaves.
- naikrovek 4y ago
  > 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-pull-requests/working-with-forks/what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility https://docs.github.com/en/pull-requests/collaborating-with-...
  - jefftk 4y ago
    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 private repository is made public and then deleted, its private forks will continue to exist as standalone private repositories in separate networks. But I agree this is confusing.
    - kadoban 4y ago
      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.
      - Ennea 4y ago
        Just force push something very empty to it before making it public. One more step, yay..
irjustin 4y ago
It really sounds like the forking and access should be "license aware" which sounds like an absolute nightmare to manage but that would help in this specific scenario? I can see it simply creating more worms than helpful.
- funcDropShadow 4y ago
  It really sounds like users of Github shouldn't trust Github to keep their forked repositories for them.
voytec 4y ago
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.
- b1nj0y 4y ago
  agree

by tux3 4y ago

chrisfosterelli 4y ago

Yeah I understand how this is unfortunate but for 99% of cases this is what you want to happen when you remove someone's access to a private codebase. It seems like this is an unusual use case that OP had an MIT-licensed open source project whose source only exists in a private repo.

cma 4y ago
Is this scenario possible? - you fork a public repo - it's visibility is changed to private but you have access through the org - they delete it - you lose your fork, which was only ever of the public repo
- kitkat_new 4y ago
  no, in this case it works as expected; "GitHub will detach public forks of the public repository and put them into a new network. Public forks are not made private." https://docs.github.com/en/repositories/creating-and-managing-repositories/about-repositories https://docs.github.com/en/repositories/creating-and-managin... But better be safe than sorry...

nly 4y ago

What's the point? You can always clone locally and push to a new repo without forking on GitHub. Repos will be unlinked and history will be intact.

chrisfosterelli 4y ago
It's for the same reason that you don't leave ex-employees with access to other intellectual property. Just because they could make their own copies during their tenure doesn't mean you shouldn't try to reduce your exposure.

charcircuit 4y ago

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

jzb 4y ago
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 know that counts as distributed to you under that license. If AcmeCorp later decides to change licenses or not release the software as open source, then it makes sense for GitHub not to let someone continue access. There are a LOT of holes in the system, but I'm not sure GitHub is in the wrong for deleting access to a private repo if you lose access to an organization or whatever.
- charcircuit 4y ago
  Software can be open source and not released. Employees can legally release it themselves since it is open source.
  - jzb 4y ago
    Really no. The employee doesn’t have that right, it’s not theirs to release unless the employer gives permission.
  - funcDropShadow 4y ago
    No, the software becomes "Open Source" or "Free Software" the moment someone licenses it to somebody else under such a license. Simply copying a file named LICENSE into some private directory has no legal relevance. As an employee, you usually don't get a license to the work artifacts you are working on.

jiggawatts 4y ago

Microsoft does this a lot, where they assume that rules that apply to their own organisations apply to all organisations in precisely the same way. If a Microsoft IC leaves, they should lose access to all Git repos, including forks. If Joe Random open-source contributor is removed from an open source repo's access list, their fork shouldn't be wiped. But Microsoft has One Rule To Rule Them All, so they won't make exceptions for unimportant people like their customers. I see this a lot. A good example is Azure Active Directory, which is basically "Microsoft 365 Authentication" that they rebranded and sold to developers for their own use, i.e.: Azure AD Enterprise Apps, App Registrations, and B2C. There are many aspects of the AAD design that make zero sense until you pause for a second and realise that it is not designed for you. It's designed for Microsoft 365! For example, auditing. My customers are typically government agencies or banks, and they have strict auditing requirements, especially related to data access. All user authentication MUST be logged, including client IP address, and everything else. Most access is by their own staff, or by other orgs that have signed various contracts or agreements, so there is no expectation of privacy. This is basically impossible with many configurations of AAD. It just refuses to collect meaningful audit logs. Why? Because GDPR applies to Microsoft 365 and they don't care about the data hosted on services such as SharePoint Online. That's not Microsoft's data, that's their customers' data, so its up to the customers to enable logging "on their end", in their individual AAD tenants. There is no way to centrally collect logs as a service provider using AAD in a multi-tenant scenario. When I asked Microsoft about this, they waffled on about GDPR and privacy regulations -- which apply to them, but not us. Another example is Microsoft Teams, which hides the name of the organisation people are coming from. In large multi-org meetings this is infuriating, because you have no idea where anyone is from. Microsoft does this because they use outsourcers like MindTree for support, and they don't want their customers to see this in Teams meetings for Azure support tickets. No-one is allowed to see where people are from so that Microsoft can bullshit their customers.

donmcronald 4y ago
> There are many aspects of the AAD design that make zero sense until you pause for a second and realise that it is not designed for you. It's designed for Microsoft 365! Business Basic accounts being limited to 7 days of login logs is a huge middle finger to the entire small business sector. Of course they think everyone should just buy Enterprise subscriptions. It's nothing more than a corporate version of "don't be poor".

evouga 4y ago

This doesn’t make any sense to me. My private forks are *mine* and I most certainly do not want GitHub guessing at whether and when to permanently delete them without my consent. Companies of course have the right to manage access to their proprietary source code, for example by only giving access to corporate accounts under their control and reclaiming those accounts when an employee leaves.

naikrovek 4y ago
> 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-pull-requests/working-with-forks/what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility https://docs.github.com/en/pull-requests/collaborating-with-...
- jefftk 4y ago
  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 private repository is made public and then deleted, its private forks will continue to exist as standalone private repositories in separate networks. But I agree this is confusing.
  - kadoban 4y ago
    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.
    - Ennea 4y ago
      Just force push something very empty to it before making it public. One more step, yay..

irjustin 4y ago

It really sounds like the forking and access should be "license aware" which sounds like an absolute nightmare to manage but that would help in this specific scenario? I can see it simply creating more worms than helpful.

funcDropShadow 4y ago
It really sounds like users of Github shouldn't trust Github to keep their forked repositories for them.

voytec 4y ago

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.

b1nj0y 4y ago
agree