dbhi / qus

qemu-user-static (qus) and containers, non-invasive minimal working setups

Home Page:https://dbhi.github.io/qus

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

License

oxr463 opened this issue · comments

@oxr463, while I understand your request as a general one, this project is not licensed explicitly. That is because the main purpose of this repository is raising awareness about a technical solution that exists. I'm not sure about which content am I entitled to actually copyright:

  • Docker and QEMU are explicitly licensed.
  • qemu-binfmt-conf.sh is part of QEMU. The customizations I made have been proposed upstream. So, if/when accepted, the same licensing will apply.
  • register.sh is based on some previous unlicensed script.
  • run.sh might be some original content subject to be licensed. But it's nothing else than a build script and a series of tests. Is that actually "protectable" as being "software"?
  • The documentation itself can be quoted/copied for fair-use and cited in academic contexts.
  • I believe that neither CI workflows nor Dockerfiles are subject to be copyrighted.

Would you please let me know which specific pieces you want to reuse, extend or contribute to?

The summary provided in your reply would be a great addition to your README.md file.

* `register.sh` is based on some previous unlicensed script.

This is uncopyrightable then.

* `run.sh` might be some original content subject to be licensed. But it's nothing else than a build script and a series of tests. Is that actually "protectable" as being "software"?

Yes.

* The documentation itself can be quoted/copied for fair-use and cited in academic contexts.

👍

* I believe that neither CI workflows nor Dockerfiles are subject to be copyrighted.

I would disagree. If I copied your files elsewhere, what would protect me in case you changed your mind in retrospect?

Would you please let me know which specific pieces you want to reuse, extend or contribute to?

The Python code under cli/, the CI files, and the shell scripts.

I must say: thanks for being so inquisitive! Let's sort some differences out and I will definitely add a section in the readme.

WRT, the shell scripts and the code under cli, I did write those from scratch, so I'll add a permissive free software license for those. Need to check/decide on one, tho.

Documentation might be CC0 or CC-BY. Need to decide too. Yet, I think this is less prioritary than source code.

Regarding workflows and Dockerfiles, the point is that for something to be copyrightable it needs to be possible to achieve the same result in different ways. On the one hand, Dockerfiles as such don't exist, because they are defined in the run shell script: https://github.com/dbhi/qus/blob/main/run.sh#L172-L186. On the other hand, each of them is 3-5 lines. As a result, it is very difficult to argue that the Dockerfiles in this repo are anything other than the most obvious implementation. The same applies to the Actions workflows. I believe that any other user doing a clean room implementation would achieve a virtually equivalent solution. Hence, there are very few chances for me to win any case, even if you (or any other) did actually decide to copy and modify those "without consent". The only "creative" part is https://github.com/dbhi/qus/blob/main/.github/workflows/docs.yml#L28, but that was told by a maintainer of actions/checkout in a public issue.

So, I think I will let the Dockerfiles be implicitly licensed as part of the script, but I will leave the licensing of the workflows undefined. Note that this is in regard to Dockerfiles and workflow files in this repo only, not a general solution.


Licensing aside, may I know what do you want to use the Python code under cli/ for? Note that it is currently unrelated to building or using the docker images and/or QEMU. The CLI provides utilities for internal usage (checking the latest packages available upstream, checking if releases were uploaded succesfully, etc.). I'd like to migrate run.sh to Python, but that is not done yet, and I cannot do it ATM. Hence, IMHO the only useful part of the CLI is the fact that pyAttributes is used for defining it. Of course, if any of the other features is useful for you, I'd be so glad. It's just for you to be aware about why I didn't take it into account yet.

I added COPYING.md, along with headers to shell scripts and Python sources.