Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Licence and use of generated code in a commercial product? Go / No-Go? #620

Closed
jnewcomb opened this issue Apr 21, 2021 · 4 comments
Closed

Comments

@jnewcomb
Copy link

Hi folks,
I like this project - I've played and tinkered and it's been a great help shifting my mindset towards modern C++.
Many thanks to the creators and maintainers. The next step is applying it to the next project that lands on my desk. For me it's fun, but for my boss, it's a commercial product!

My main dev work will be on the generated source code - which I will detach and 'run with' separate from the lbuild / templates directories. This detached code will get fixes and changes specific to my project. I'm happy to feed fixes and relevant improvments back into the template code, realistically my future colleagues may not. I can't open source changes specific to the product without getting slapped by my scary boss.

But - I'm not working on the template code in Github, only the generated code (basically a copy with bits chopped out!)
Where does this stand as far as MPL2?
Is there even an acceptable workflow for a commercial product using modm as a BSP starting point under the MPL2 licence? If so, what would it be?
What are your thoughts?

Again, thanks to @salkinium & all for the many hours of free time put into this project. Its been a great learning experience if nothing else can come of it.

@salkinium
Copy link
Member

salkinium commented Apr 21, 2021

Again, thanks to @salkinium & all for the many hours of free time put into this project. Its been a great learning experience if nothing else can come of it.

You're welcome, I've also learned so much myself and always appreciate feedback!

IANAL, however I've had some basic training while working at ARM regarding copyright:

But - I'm not working on the template code in Github, only the generated code (basically a copy with bits chopped out!)
Where does this stand as far as MPL2?

The MPLv2 license applies to the generated code. The C preprocessor is a code generator too (in fact very similiar to Jinja2 for basic use), and it doesn't change the license terms either of course. In particular, modm adds significant "original work" to the modm-devices data, thus the threshold of originality is met.

Is there even an acceptable workflow for a commercial product using modm as a BSP starting point under the MPL2 license? If so, what would it be?

We chose the MPLv2 specifically because it only applies to the modm files only, and not all project files like the "greedy" GPL license.
That way we can use modm commercially ourselves without having to publish the project code, while incentivicing contributing fixes and features back into modm by those commercial projects.

My recommended workflow:

  1. Add original work in new files, they can have whatever license you want. It doesn't matter where they are located, but I would recommend to separate them from the generated modm files, to avoid accidentally copying MPL licensed code.
  2. Do not copy modm code verbatim and change the license! You can however copy ideas and concepts, those are not copyrightable (only patentable). So you may reimplement parts of modm in a different license but the work must meet a minimum level of "originality".
  3. Trivial changes (fixes to comments, constants, trivial additions or other "unoriginal" changes) don't usually meet the threshold of originality. Unless you add completely new features or do massive refactorings to the modm code you won't need to publish those changes.
  4. Upstream as much as is feasible. This has the advantage of showing us your use-case and therefore getting future maintenance "for free". Since the modm code is so generic, I don't think there's much risk of leaking product secrets tbh.
  5. Publish any changes by forking modm in GitHub, doesn't need to be a company account. This is already true for Pull Requests.
  6. Finally if you refactor or change the generated code, you need to publish it somewhere. But again, only the files you changed. (I think you may even copyright your additions with a different license that is compatible with MLPv2 (like GPL?). But I'm not sure about that…)

Note that the code in ext/ has different MIT, BSD, Apache2 licenses, which are compatible with MPLv2, but don't require publishing changes for.

So basically:

  1. Any original work you add in a new file may be propriatary.
  2. You don't need to publish unmodified modm code, neither templated nor generated.
  3. Trivial changes/fixes to modm code below the threshold of originality do not need to be published.
  4. Larger changes to modm code do need to be published (somewhere).

@jnewcomb
Copy link
Author

jnewcomb commented Apr 21, 2021

Thanks @salkinium for the useful guidance.
I need a simple 'rule of thumb' (for the managers)
I'll probably just suggest publishing 'generated_project\modm'. and referenced as an external in the project (in SVN speak)
..Not a problem for me as no 'business logic' should end up there anyhow.

What to do with these as I'll need to adapt to support a bootloader:
generated_project\CMakeLists.txt
generated_project\Makefile

Can you see any pitfalls? Thank you kindly!

@salkinium
Copy link
Member

I'll probably just suggest publishing 'generated_project\modm'. and referenced as an external in the project (in SVN speak)
..Not a problem for me as no 'business logic' should end up there anyhow.

Yes, that will fully comply with the MPLv2 terms (and the BSD, MIT etc terms in ext/).

What to do with these as I'll need to adapt to support a bootloader:
generated_project\CMakeLists.txt
generated_project\Makefile

Hm, that's a good point I haven't considered before. These files are supposed to be adapted for the specific project, it's a bit dumb to have licensed them with MPLv2 🤦‍♂️. I'll check if I can relicense these files to BSD (but I'm not the sole author).

  • The CMakeLists.txt isn't very original, you can reimplement that yourself.
  • The Makefile you can move into generated_project/modm/Makefile and include that from your own custom top-level Makefile (perhaps prefixing the PHONY targets with modm-{target} so that there are no conflicts).

I want to point out that #568 has a new CMake implementation, that better than what we have right now, with more IDE integration (written by someone who actually knows how CMake works). It needs some minor polish before merge, but it's basically done.

@salkinium
Copy link
Member

All top-level build scripts are now BSD 2-clause licensed, incl. the new CMake generator.

@modm-io modm-io locked and limited conversation to collaborators Sep 29, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Development

No branches or pull requests

2 participants