5 ms·

A good practice when firing off an email to a list like this is to do a git blame on nearby code, identify the maintainers, and come up with a list of people to

A good practice when firing off an email to a list like this is to do a git blame on nearby code, identify the maintainers, and come up with a list of people to Cc directly on the email. If you can get the git repo, you don't need the list to contribute. It helps, for sure, but you can work without it pretty easily. And as I said in the article, I don't think it would be necessary to turn off the list in the event of a DMCA request, at least not on SourceHut. On GitHub the git repo is the single source of truth, so when a git repo is pulled, so too go the issues, pull requests, and so on. Not so on SourceHut.

zaarn 6y ago
Why would these things remain on sourcehut if they get a DMCA filing? If you do not take the offending material offline, you open yourself to a lawsuit and if you do, new contributors have no way of accessing this data. Open issues and similar will likely also get lost unless restores, unless you count "exists in someone's inbox/archive" as "the issues and pull requests continue to exist". Because in my opinion, that's barely better than having no backup as all relational data in regards to these things is lost.
- ddevault 6y ago
  Because it does not contain offending material.
  - zaarn 6y ago
    Now just supposed it would (someone includes it in the mail text body) and someone would file a DMCA against the mailing list? I can't imagine it would be too unlikely, considering that the mailing list also contains patches and part of YT-dls problems was that the source code and/or documentation included such things. If they popped up during development in a mailing list, it would just as much be a target. "No it doesn't" isn't a valid DMCA defense.
    - ddevault 6y ago
      Then removing the offending material can be done without shutting off the mailing list entirely. I mentioned this in the article. On GitHub, everything - bugs, pull requests, wikis, code - is baked into one thing, your repository, which is taken down as a whole. On SourceHut these features can work just fine independently of one another, and if not all of them contain offending material, there's no reason to turn them all off.
      - akerl_ 6y ago
        This seems like a weird distinction to make. GitHub could equally delete single issues or single PRs or wiki pages or even single files in a repo. They don’t, but that they don’t isn’t because your GitHub repo is “baked into one thing”, it’s because they’ve chosen to apply the DMCA at the repo level rather than playing whack a mole with your content. Using a mailing list archive instead of an issue list doesn’t change that dynamic. What changes it is that you’ve decided to use more targeted DMCA compliance for SourceHut, which is noteworthy. But the delta here is a policy delta, not a technological limitation on GitHub’s part.
        ddevault 6y ago
        But on GitHub, the PRs and issues cannot exist independently of the git repository. They'd have to make substantial software changes to support this approach. Sure, they could do that, but - have they? No. SourceHut has.
        akerl_ 6y ago
        I’m not sure what you mean. GitHub has gotten a ton of (justified!) criticism because the issues/PRs are not stored in git (either in the main repo, like gh-pages branches, or in an associated repo, like GitHub repo wikis). The “changes” they’d need to make beyond their current DMCA implementation would be to restrict the “Code” tab, the Readme preview, and the git/ssh endpoint for that repo. Which would likely be a new feature, but given they already have the ability for a repo’s owner to totally disable PRs or issues, certainly wouldn’t be the kind of groundbreaking change you’re pitching it as.
deleted 6y ago
[deleted]

zaarn 6y ago

Why would these things remain on sourcehut if they get a DMCA filing? If you do not take the offending material offline, you open yourself to a lawsuit and if you do, new contributors have no way of accessing this data. Open issues and similar will likely also get lost unless restores, unless you count "exists in someone's inbox/archive" as "the issues and pull requests continue to exist". Because in my opinion, that's barely better than having no backup as all relational data in regards to these things is lost.

ddevault 6y ago
Because it does not contain offending material.
- zaarn 6y ago
  Now just supposed it would (someone includes it in the mail text body) and someone would file a DMCA against the mailing list? I can't imagine it would be too unlikely, considering that the mailing list also contains patches and part of YT-dls problems was that the source code and/or documentation included such things. If they popped up during development in a mailing list, it would just as much be a target. "No it doesn't" isn't a valid DMCA defense.
  - ddevault 6y ago
    Then removing the offending material can be done without shutting off the mailing list entirely. I mentioned this in the article. On GitHub, everything - bugs, pull requests, wikis, code - is baked into one thing, your repository, which is taken down as a whole. On SourceHut these features can work just fine independently of one another, and if not all of them contain offending material, there's no reason to turn them all off.
    - akerl_ 6y ago
      This seems like a weird distinction to make. GitHub could equally delete single issues or single PRs or wiki pages or even single files in a repo. They don’t, but that they don’t isn’t because your GitHub repo is “baked into one thing”, it’s because they’ve chosen to apply the DMCA at the repo level rather than playing whack a mole with your content. Using a mailing list archive instead of an issue list doesn’t change that dynamic. What changes it is that you’ve decided to use more targeted DMCA compliance for SourceHut, which is noteworthy. But the delta here is a policy delta, not a technological limitation on GitHub’s part.
      - ddevault 6y ago
        But on GitHub, the PRs and issues cannot exist independently of the git repository. They'd have to make substantial software changes to support this approach. Sure, they could do that, but - have they? No. SourceHut has.
        akerl_ 6y ago
        I’m not sure what you mean. GitHub has gotten a ton of (justified!) criticism because the issues/PRs are not stored in git (either in the main repo, like gh-pages branches, or in an associated repo, like GitHub repo wikis). The “changes” they’d need to make beyond their current DMCA implementation would be to restrict the “Code” tab, the Readme preview, and the git/ssh endpoint for that repo. Which would likely be a new feature, but given they already have the ability for a repo’s owner to totally disable PRs or issues, certainly wouldn’t be the kind of groundbreaking change you’re pitching it as.

deleted 6y ago

[deleted]