4 ms·

You're forgetting the fact that he also went out of his way to strip the git history at first.

by gcr 5y ago

mmastrac 5y ago
I clarified the comment a bit -- I considered that attribution-stripping, but I think you're right that it's more than just that. Tangentially: it's somewhat interesting that we don't consider the source code history in our OSS licenses...
- jraph 5y ago
  > it's somewhat interesting that we don't consider the source code history in our OSS licenses I think it would be too restrictive. It might prevent you from working differently for no clear benefits. However, keeping the history is an easy way to track who contributed what so you probably should keep the history of projects with more than one contributors or you lose precise attribution in practice (apart for the other obvious reasons to keep the history).
- klyrs 5y ago
  FWIW, I don't see anything wrong with stripping the git history. I think it's stupid and short-sighted, but whatever, it's allowed. One use case I've seen, sometimes you want to pull a single file from another project without a bunch of baggage. Your license should cover the history, in that every source file should bear a license header, going back to the first commit.
  - hakre 5y ago
    > Your license should cover the history, in that every source file should bear a license header, going back to the first commit. This is one way to do it. Problem remains when these important parts, even whole files - e.g. COPYRIGHT - are removed from the archived copy. From what the original author reports, this is what happened.
    - klyrs 5y ago
      I fully agree with that. Stripping licenses is a Bad Thing™. When I've imported foreign files from other projects that don't have license headers, I give them license headers and also append their LICENSE or COPYRIGHT file into mine; I like belts and suspenders. Removing history, itself, is not especially problematic. History is for maintenance, merges, and downstream compatibility issues.
- ghoward 5y ago
  > Tangentially: it's somewhat interesting that we don't consider the source code history in our OSS licenses... IIUC, IANAL, we don't have to worry about it. Versions of software can have different licenses, and the license for each version is the license that the repo was under when that version was committed. As far as I know, if you replace every instance of "version" in the previous paragraph with "commit", it still applies. I think this means that every commit is under a specific license, and therefore, the entire history is under one or more licenses.
  - hakre 5y ago
    > Versions of software can have different licenses, and the license for each version is the license that the repo was under when that version was committed. Not particularly wrong, just adding: There can even be additional licensing terms that aren't documented in the git history so they wouldn't be visible there. And there is another sticky detail: So if the original copy would have violated any of the licensing terms of the revision/release being copied (e.g. by removing copyright/authoring information), any more of these copies may become tainted if that resulted in a broken license chain. At this stage it is already regardless which licensing is announced in the new repository (and at which commit). This poses some problems on very public systems like Github as it may not be directly visible any longer. One way to deal with it is to block the violating user on Github. It's not perfect but can help with bookkeeping. And in general you normally should just do Github forks to file pull requests, not to actually fork projects. Not saying that you can't - you can perfectly - but more on the level of day to day operations. For a full fork, you should have actual reasons. Otherwise its ruining the benefits of copying code.
    - ghoward 5y ago
      Yes, I think your comment adds a lot to mine. Licensing of version control history might need to have a legal debate, actually.
      - hakre 5y ago
        You can put it under proprietary reciprocal terms and void the right to copy when history is damaged. Copyright should cover that. You can't do this with lax permissive licenses nor with copyleft as they allow to modify the work, which would mean the right to modify the history.
- hakre 5y ago
  > it's somewhat interesting that we don't consider the source code history in our OSS licenses Developing is in the burden of the single developer/project and which kind of version control system is used to produce releases can hardly be mandated by copyright law. It is only one reason to use a F/L/OS/S license for contributing back, that is taking part in the development project. So on the other hand, it sort of does consider that, but it's merely then in the social interaction. What so hurtfully happened here is that a collaborator tried to break the ties (forcefully) and was powerful enough to do so. Sure, this renders the OSS license less effective, and I guess this can be seen or felt by many developers.

You're forgetting the fact that he also went out of his way to strip the git history at first.

by gcr 5y ago

You're forgetting the fact that he also went out of his way to strip the git history at first.

I clarified the comment a bit -- I considered that attribution-stripping, but I think you're right that it's more than just that. Tangentially: it's somewhat interesting that we don't consider the source code history in our OSS licenses...

jraph 5y ago
> it's somewhat interesting that we don't consider the source code history in our OSS licenses I think it would be too restrictive. It might prevent you from working differently for no clear benefits. However, keeping the history is an easy way to track who contributed what so you probably should keep the history of projects with more than one contributors or you lose precise attribution in practice (apart for the other obvious reasons to keep the history).
klyrs 5y ago
FWIW, I don't see anything wrong with stripping the git history. I think it's stupid and short-sighted, but whatever, it's allowed. One use case I've seen, sometimes you want to pull a single file from another project without a bunch of baggage. Your license should cover the history, in that every source file should bear a license header, going back to the first commit.
- hakre 5y ago
  > Your license should cover the history, in that every source file should bear a license header, going back to the first commit. This is one way to do it. Problem remains when these important parts, even whole files - e.g. COPYRIGHT - are removed from the archived copy. From what the original author reports, this is what happened.
  - klyrs 5y ago
    I fully agree with that. Stripping licenses is a Bad Thing™. When I've imported foreign files from other projects that don't have license headers, I give them license headers and also append their LICENSE or COPYRIGHT file into mine; I like belts and suspenders. Removing history, itself, is not especially problematic. History is for maintenance, merges, and downstream compatibility issues.
ghoward 5y ago
> Tangentially: it's somewhat interesting that we don't consider the source code history in our OSS licenses... IIUC, IANAL, we don't have to worry about it. Versions of software can have different licenses, and the license for each version is the license that the repo was under when that version was committed. As far as I know, if you replace every instance of "version" in the previous paragraph with "commit", it still applies. I think this means that every commit is under a specific license, and therefore, the entire history is under one or more licenses.
- hakre 5y ago
  > Versions of software can have different licenses, and the license for each version is the license that the repo was under when that version was committed. Not particularly wrong, just adding: There can even be additional licensing terms that aren't documented in the git history so they wouldn't be visible there. And there is another sticky detail: So if the original copy would have violated any of the licensing terms of the revision/release being copied (e.g. by removing copyright/authoring information), any more of these copies may become tainted if that resulted in a broken license chain. At this stage it is already regardless which licensing is announced in the new repository (and at which commit). This poses some problems on very public systems like Github as it may not be directly visible any longer. One way to deal with it is to block the violating user on Github. It's not perfect but can help with bookkeeping. And in general you normally should just do Github forks to file pull requests, not to actually fork projects. Not saying that you can't - you can perfectly - but more on the level of day to day operations. For a full fork, you should have actual reasons. Otherwise its ruining the benefits of copying code.
  - ghoward 5y ago
    Yes, I think your comment adds a lot to mine. Licensing of version control history might need to have a legal debate, actually.
    - hakre 5y ago
      You can put it under proprietary reciprocal terms and void the right to copy when history is damaged. Copyright should cover that. You can't do this with lax permissive licenses nor with copyleft as they allow to modify the work, which would mean the right to modify the history.
hakre 5y ago
> it's somewhat interesting that we don't consider the source code history in our OSS licenses Developing is in the burden of the single developer/project and which kind of version control system is used to produce releases can hardly be mandated by copyright law. It is only one reason to use a F/L/OS/S license for contributing back, that is taking part in the development project. So on the other hand, it sort of does consider that, but it's merely then in the social interaction. What so hurtfully happened here is that a collaborator tried to break the ties (forcefully) and was powerful enough to do so. Sure, this renders the OSS license less effective, and I guess this can be seen or felt by many developers.