esp-rs/esp-idf-template

Add LICENSE file

Closed this issue · 12 comments

gindoslaw commented

Bug description

  • Would you like to work on a fix? [n]

Because there is no license file inside repository it make it hard to work with the code legally. Please add LICENSE.txt or LICENSE.rst or LICENSE.md.

You're under no obligation to choose a license. However, without a license, the default copyright laws apply, meaning that you retain all rights to your source code and no one may reproduce, distribute, or create derivative works from your work. If you're creating an open source project, we strongly encourage you to include an open source license. The Open Source Guide provides additional guidance on choosing the correct license for your project
Source: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository

Additional context

Because it is template reasonable will be to make it MIT or BSD.

ivmarkov commented

You want a license to what?:

  • The generated code? I don't think we should put a license for that. It is you who would choose the license of the generated code
  • The code of esp-idf-template itself?
gindoslaw commented

In the repository there should be license file, otherwise it is restricted - by default.
Can't be copied, can't be modified. All content of the repository is protected, with including ... README file.

No license file does not mean that it is open to modify, it means that it is closed. Without license file in the repository your are sending message "I'm the owner of the code and you can't copy, can't modify and can't redistribute it". If you are afraid of adding license file (because code is generated), for same reason you should be afraid of not adding it :-). No license file does not mean you have opt-out from the code - lack of license file means that you are copyright holder.

If the code is generated - add license file, and in the body of the file add information that it has been generated (and computer algorithms outcomes can't be subject of copyrights).

Currently - as I said - formally, whoever owns repository is a copyright holder. Everything else is just a subject of gray area for the lawyers.

ivmarkov commented

OK. Whenever I have time, I might add LICENSE-MIT + LICENSE-APACHE file to the repo, so I'll keep this open. Or you can PR this if this is a big show-stopper for you somehow (just add LICENSE-MIT + LICENSE-APACHE that you can copy from - say - esp-idf-svc's GIT project root).

But I don't think this is a big show-stopper actually and maybe you are a bit too strict for what amounts to be a template generator?

I mean, you can always generate a sample project, then "read" its 10-lines (at most) main.rs, then read the similarly-sized Cargo.toml + .cargo/config.toml files and then apply them "manually" in a clean project you generate from scratch.

The stuff that actually matters (the ESP IDF + the esp-idf-* crates) is already covered with licenses:

  • MIT+APACHE (which is kinda the standard in Rust land) - for the esp-idf-* crates
  • Apache2 - for the ESP IDF C codebase itself
  • Proprietary licenses for the ESP IDF Wifi and BT blobs (but you can still use them commercially without restrictions)
Nyrmburk commented

Not a lawyer but I believe that gindoslaw is correct according to https://choosealicense.com/no-permission/.

Because this is a project generator, I think that the generated files might inherit the license of the template files. Using MIT + BSD could reduce the flexibility of projects utilizing your generator.

Perhaps you can add the Unlicense? I think it would resolve this rather cleanly. https://choosealicense.com/licenses/unlicense/

ivmarkov commented

I'm not adding a unlicense. If you feel the missing standard two licenses (Apache + MIT) are such a big issue, open a PR to add them. But I would reiterate again, that for a measly project generator this topic is really blown out of proportions.

Nyrmburk commented

I am planning on making a project and seeing as how the Rust on ESP book recommends this project generator I'd like to use it.

I think this project is sufficiently complicated (thank you for your hard work) to warrant a license. It's more than just the main.rs file - it's the entire generated repo. Because the files are directly modified rather than linked, generated projects could be considered derivative works. In addition, it brings more clarity to contributors - the choosealicense page seems to indicate that a contributor license agreement is expected for projects without a license.

One of the reasons I suggested the Unlicense is because I want to release my project as "Unlicense OR MIT" just like https://github.com/BurntSushi/ripgrep

Is "Unlicense OR MIT" acceptable for you?

open a PR to add them.

Because non-licensed code is technically not open for copying or modifying, can I consider this as a private license to clone, modify, and open a pull request?

ivmarkov commented

@Nyrmburk

You want a license to what?:

  • The generated code? I don't think we should put a license for that. It is you who would choose the license of the generated code
  • The code of esp-idf-template itself?

I think this comment of mine ^^^ is summarizing my point of view. Basically, we are talking about two different types of licensing here. Perhaps the best metaphor is to imagine that esp-idf-template is some sort of compiler (or rather, a transpiler). Now, if you take some compiler or transpiler (say, the TypeScript transpiler), you also have to deal with two licenses:

  • The license of the TypeScript transpiler itself (which is Apache). For us, it would be Apache + MIT. And the license files I asked you to PR in the repo would cover the esp-idf-template "source code", NOT the "output" it generates
  • The license of the output .JS files, which is usually matching the license of the input .TS files. For us, this is what esp-idf-template generates. Here, we should either NOT impose a license, or put the generated files into the public domain. Somehow.
Nyrmburk commented

Thanks for working with me on this.

For my own uses, I care about the license of the generated code, which I would prefer is provided with full usage rights.

As for the code of the project itself, I think that still needs a license for contributors to legally contribute.

I wasn't totally clear in my original comment, but if the entire project was licensed with the Unlicense, then both of these problems would be solved with the least amount of complication.

I took some time to find some prior work:

Community posts:

Ruby on Rails:
A generated project with $ rails new myprojectname seems like the generated files are explicitly MIT.
https://www.ruby-forum.com/t/what-is-the-license-of-generated-code/60077
They even generate an MIT license for you: https://github.com/rails/rails/blob/main/railties/lib/rails/generators/rails/plugin/templates/MIT-LICENSE.tt
Maybe this is good enough? It's not the most flexible for consumers though.

GCC:
GCC has a "Grant of Additional Permission" that gives permission to propagate the output even if it would violate GPLv3.
https://github.com/gcc-mirror/gcc?tab=License-3-ov-file

GNU Bison:
Has a license exception in src/parse-gram.h
https://en.wikipedia.org/wiki/GNU_Bison#License_and_distribution_of_generated_code

LLVM/Clang:
Has the "LLVM Exceptions to the Apache 2.0 License" which is similar but different.
https://github.com/llvm/llvm-project?tab=License-1-ov-file

endless-sky:
https://www.reddit.com/r/learnprogramming/comments/vc0xiu/comment/icbyql4/
This game has a copyright file that lists per-directory licenses: https://github.com/endless-sky/endless-sky/blob/master/copyright
I found this while trying to see if there's a way to apply a license to a specific directory. Although I imagine you may still want to apply "Apache-2.0 OR MIT" to the template files so this isn't a perfect solution.

AOSP:
There's an external/ git repo as part of their repotool manifest based system. That directory is where all code goes that's not AOSP-specific and therefore can have their own licenses. I don't think this approach really works if there's still a license in the root directory unless the templates are added as a git submodule or use the endless-sky approach. This looks too complicated.

LEMON parser generator:
"The author of this program disclaims copyright."
It's being maintained by SQLite.
https://github.com/sqlite/sqlite/blob/master/tool/lemon.c

SQLite:
Not strictly related to this problem, but they just give a blessing instead of a license.
https://github.com/sqlite/sqlite?tab=License-1-ov-file

Unfortunately I couldn't find any snippet that's along the lines of "The generated project files are provided copyright-free and license-free". Maybe that snippet is good enough to put in the readme?

For us, it would be Apache + MIT

Is this "Apache-2.0 OR MIT" or "Apache-2.0 AND MIT"?

If Apache + MIT is going to apply to the output files out of simplification, then those should probably be copied over to the generated project just like Rails.

ivmarkov commented

I can't keep but wonder if you've ever used cargo new?

It is also a generator, and it might be using templates too, embedded in its binary payload. Who knows?

Yet, it doesn't output any license in the resulting project it generates.
According to your logic, using cargo new might be a "no, no" as well?

Also, I find the idea of esp-idf-template explicitly outputting a license file as part of the generated content dangerous. What if I want my code to actually be proprietary, but I forget to remove the generated "unlicense" LICENSE file? Suddenly, what I have planned to develop as a proprietary code by default would end up in the public domain?

I think, for a generated project, the default (or the only) option must be NOT to generate a license. This way the code the developer does on top of the generated content t is proprietary by default.

What I can do is to put in the README, that the generated content by esp-idf-template is in the public domain (and maybe still have the repo licensed under apache + mit) if that's not a contradiction.

In the end I also feel you are overthinking it a bit :)
You are starting with the wrong premise ("I think this project is sufficiently complicated (thank you for your hard work) to warrant a license."), that what esp-idf-template generates is non-trivial and much more complex than a cargo new generation, while in practice that's just not the case. cargo new generates a whole project as well, but I don't think neither its content nor our esp-idf-template generated content crosses the definition of "trivia" and a copyright infringement case in court around it would stand. I also wonder who would have such a case against you? It is not like I've done a CLA copyright assignment or anything to a commercial entity (say, Espressif) when pushing code to this or the other esp-idf- repositories.

So unless you have a really strong counter argument I've not seen yet, I would be dual licensing the repo itself, and putting a "license" section in the readme that the generated code is in the public domain, but not outputting any license in the generated code (because it is dangerous for the developer). Hopefully that would be good enough for you too.

ivmarkov commented

There's now #240

ivmarkov commented

Is this "Apache-2.0 OR MIT" or "Apache-2.0 AND MIT"?

OR. Dual licensing, as most Rust projects do.

ivmarkov commented

Done now.