3 ms·

AppGet is open source, under the Apache 2.0 license: https://github.com/appget/appget https://github.com/appget/appget. That means basing a new project off AppG

AppGet is open source, under the Apache 2.0 license: https://github.com/appget/appget https://github.com/appget/appget. That means basing a new project off AppGet - including using its source code - is legally permissible. edit: This is explicitly not a judgement of ethics.

rectang 6y ago
Forking is permissible, but you still have to adhere to the terms of the Apache License 2.0. You can't remove copyright notices, you must provide attribution, if you release source you must indicate what you changed, etc. That Microsoft didn't do any of that indicates that they do not believe that WinGet is a derivative work of AppGet under copyright law, so the copyright license granted by the Apache License is not needed. ETA: That is, Microsoft believes they don't need a copyright license. My personal position is that I would have liked to see a proper fork under the ALv2 with attribution, which would have avoided all this mess.
- scott_s 6y ago
  WinGet is open source under the MIT License, which I believe keeps them in the clear: https://github.com/microsoft/winget-cli https://github.com/microsoft/winget-cli. In practice, I've never heard of any legal problems when a derivative project is also open source under a similar license. (Yes, the licenses are different. But I also believe they are considerable compatible.)
  - rectang 6y ago
    No, that's wrong. You can't just slap a new license on top of code you've copied — that's illegal! You have to adhere to the terms of the copyright license granted in this case by upstream License. If you do not, you lose the copyright license and the ability to redistribute under any terms. Maybe you're thinking of license subsumption? That's when (say) a project under a more restrictive license (e.g. Apache License 2.0) bundles a dependency which is under a more permissive license (e.g. MIT), yet the package is advertised as being under "Apache License 2.0" even though the licensing is polyglot. But even under subsumption, you still don't get to do things like removing copyright notices or declaring unilaterally that somebody else's work is now under some new license they didn't grant. The license headers in the bundled dependency's source files don't get modified, it's just that you summarize the terms of the complete package because fulfilling the terms of the ALv2 suffices to fulfill the terms of the MIT license. (Sort of. License subsumption is a complicated issue.)
    - scott_s 6y ago
      As I said, I'm unaware of any actual projects getting into trouble in a situation like this, as the licenses are mostly compatible. Are you?
      - rectang 6y ago
        Yes. Plenty of projects have gotten "in trouble" for copying code and illegally changing the license, either inadvertently or deliberately. The punishment is generally a complaint, and the remedy is that they fix the attribution. Examples: - https://github.com/Lutando/Akkatecture/issues/19 https://github.com/Lutando/Akkatecture/issues/19 - https://github.com/Grover-c13/PokeGOAPI-Java/issues/490 https://github.com/Grover-c13/PokeGOAPI-Java/issues/490 - https://github.com/dsiguide/dsiguide.github.io/issues/14 https://github.com/dsiguide/dsiguide.github.io/issues/14 Such problems do not end up in court for two reasons. First, it costs very little to bring a project into compliance with a permissive license — all you need to do is give attribution. It's not like GPL enforcement, where you have to choose whether to open source your proprietary code or to purge the GPL'd code from the project in order to achieve compliance. Second, the culture of permissively licensed open source communities is such that they don't generally want to foster a litigious environment which would frighten business users.
        scott_s 6y ago
        If your point is that all they need to do is make the appropriate attribution, then we're in agreement.

rectang 6y ago

Forking is permissible, but you still have to adhere to the terms of the Apache License 2.0. You can't remove copyright notices, you must provide attribution, if you release source you must indicate what you changed, etc. That Microsoft didn't do any of that indicates that they do not believe that WinGet is a derivative work of AppGet under copyright law, so the copyright license granted by the Apache License is not needed. ETA: That is, Microsoft believes they don't need a copyright license. My personal position is that I would have liked to see a proper fork under the ALv2 with attribution, which would have avoided all this mess.

scott_s 6y ago
WinGet is open source under the MIT License, which I believe keeps them in the clear: https://github.com/microsoft/winget-cli https://github.com/microsoft/winget-cli. In practice, I've never heard of any legal problems when a derivative project is also open source under a similar license. (Yes, the licenses are different. But I also believe they are considerable compatible.)
- rectang 6y ago
  No, that's wrong. You can't just slap a new license on top of code you've copied — that's illegal! You have to adhere to the terms of the copyright license granted in this case by upstream License. If you do not, you lose the copyright license and the ability to redistribute under any terms. Maybe you're thinking of license subsumption? That's when (say) a project under a more restrictive license (e.g. Apache License 2.0) bundles a dependency which is under a more permissive license (e.g. MIT), yet the package is advertised as being under "Apache License 2.0" even though the licensing is polyglot. But even under subsumption, you still don't get to do things like removing copyright notices or declaring unilaterally that somebody else's work is now under some new license they didn't grant. The license headers in the bundled dependency's source files don't get modified, it's just that you summarize the terms of the complete package because fulfilling the terms of the ALv2 suffices to fulfill the terms of the MIT license. (Sort of. License subsumption is a complicated issue.)
  - scott_s 6y ago
    As I said, I'm unaware of any actual projects getting into trouble in a situation like this, as the licenses are mostly compatible. Are you?
    - rectang 6y ago
      Yes. Plenty of projects have gotten "in trouble" for copying code and illegally changing the license, either inadvertently or deliberately. The punishment is generally a complaint, and the remedy is that they fix the attribution. Examples: - https://github.com/Lutando/Akkatecture/issues/19 https://github.com/Lutando/Akkatecture/issues/19 - https://github.com/Grover-c13/PokeGOAPI-Java/issues/490 https://github.com/Grover-c13/PokeGOAPI-Java/issues/490 - https://github.com/dsiguide/dsiguide.github.io/issues/14 https://github.com/dsiguide/dsiguide.github.io/issues/14 Such problems do not end up in court for two reasons. First, it costs very little to bring a project into compliance with a permissive license — all you need to do is give attribution. It's not like GPL enforcement, where you have to choose whether to open source your proprietary code or to purge the GPL'd code from the project in order to achieve compliance. Second, the culture of permissively licensed open source communities is such that they don't generally want to foster a litigious environment which would frighten business users.
      - scott_s 6y ago
        If your point is that all they need to do is make the appropriate attribution, then we're in agreement.