Common and coherent license policy for rust-embedded and drivers?

[getreu]

Drivers should be published under the same license as embedded-hal and cortex-m-rtfm which is:

Licensed under either of

• Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

at your option.

It is important that the ecosystem grows under the same license! If you agree with me, the question arises if and how we could enforce this?

One way to go: We set up an "official repository" to create an incitement for developers to become part of it. License compliance would be the first condition to get a driver accepted. In case we later add quality criteria as acceptance condition, this "official repository" should be managed in a democratic way.

@therealprof Could you consider adapting your license to Apache/MIT?

[getreu]

In a professional environment the license is of utmost importance. When you start a project and choose an ecosystem for embedded development you need to make sure that all code and drivers are released under a compatible license.

A common license policy is not only supporting our vision (To improve the productivity of embedded software development teams) but also constitutes the condition sine qua non for professional suitability. Linux wouldn't have been successful in a professional environment without a common license policy.

[getreu]

@therealprof

Compatible: yes, identical: no.

@MrBuddyCasino

Never had issues with the permissive ones, be it MIT / BSD / Apache / Mozilla or whatever

A license is a legal agreement. Unfortunately "permissive" and "compatible" are no legal concepts. In general when someone assembles code with different licences, he needs to make sure that his usage does not violate any of the licences. In other words, you have to comply with all of them. This needs to checked against the business model that is subject to change. Without a layer next to you, many different licenses becomes a risky enterprise because your attack surface gets bigger with every licence you add to your code base. In doubt professionals will not opt for an ecosystem where the legal side is risky or somehow unclear.

@therealprof

And I absolutely don't get your "Linux" point, are you talking about the kernel or the ecosystem?

Kernel.

[getreu]

If we all agree with:
@dbrgn

yes, the use of permissive licenses

... it should not hurt anybody to chose the same than the Rust language and RTFM. A professional user will always prefer a code base with a coherent, simple and clear license policy.

[dvc94ch]

I prefer the ISC because it is shorter and fits nicely at the end of a README. To my knowledge that allows someone to fork a project I've written, remove the ISC part from the README and add whatever license they like (MIT/BSD/Apache/GPL). From a license perspective there are three target groups: 1. normal people 2. big companies that don't contribute to foss and prefer investing there money into lawyers and patent suits 3. the gnu people with their own weirdness (eg. Linux is not free software) I suggest to focus on 1.

[MrBuddyCasino]

I had to provide Excel sheets of dependency licenses that were used in projects of ours multiple times in my career. Only GPL and LGPL gave us trouble, everything else was fine. So I suggest that unless there is actual evidence that the "Very Big Corporation of America" has an issue with this, this discussion is academic. Yes we need to be business friendly, but if some company decides to be unnecessarily picky about licenses, they can gladly look elsewhere for free (as in beer) code.

Having a single one would be nice because it simplifies things, but why piss off unpaid contributors that may have a strong preference for a certain license?

[thejpster]

Actually I disagree. The Author of a work must always be free to license that work in any way they see fit. We can certainly suggest MIT/Apache 2, for good reasons, but if someone wants to use PD, or BSD, or GPL3, then that's their choice.

it should not hurt anybody to chose the same than the Rust language and

RTFM. A professional user will always prefer a code base with a common simple and clear license policy. Open source is about freedom. We should make a recommendation but accept that it is up to the author to choose who to grant access to their work - work which we are extremely grateful to them for performing and sharing with the world. Yes collecting open source licences is a pain, but having all components under the same licence doesn't help that much as they all have unique copyright strings that be to be included with any documentation supplied with the product. At that point I really couldn't care less whether a component was Apache 2, MIT or BSD - my workload is the same. GPL is obviously typically a barrier to commercial user in an embedded single-image product which also includes proprietary code, but frankly if it's a choice between a GPL, say, humidity sensor driver, or no driver, as a community we should take the GPL one and say thank you! If that's ever a problem for anyone in the future they are very welcome to write their own or buy a commercial licence; if they wish to sell commercial wall mounted humidity sensors, then they probably have the resources to do just that. I almost never come across components that do not have a common, simple or clear license policy. The only cases I do, it's when no licence has been specified. We should obviously discourage that.

…

Be conservative in what you do, be liberal in what you accept from others. - Postel's Law

[nastevens]

I had to provide Excel sheets of dependency licenses that were used in projects of ours multiple times in my career.

Same here. I suggest that it's not as important to limit which licenses can be used as it is to clearly surface the licenses being used. I.e. provide clear instructions on how to show which licenses are being used so that people who need to justify their FOSS usage can quickly gauge if RTFM/drivers/etc. will work for them.

[ah-]

I.e. provide clear instructions on how to show which licenses are being used so that people who need to justify their FOSS usage can quickly gauge if RTFM/drivers/etc. will work for them.

Maybe even a cargo tool? cargo license goes and prints a list of all your dependencies and their licenses?

[Nemo157]

I have an existing cargo sub command for this cargo-lichking, it may have issues with embedded projects currently since it doesn’t support specifying the target for target specific dependencies; but I’m planning to add that soon since I’m starting to work with Rust on embedded projects.

[korken89]

On licensing I would like to point out that in embedded micro controller systems MIT / Apache 2.0 can be problematic as they require the license to be available in the binary distribution. In practice this means that the system must have the license compiled into the binary, and also be available to read out somehow by someone inspecting the system, which is a real problem if used in production.

What we did in the embedded C++ community was to switch to the Boost Software License 1.0 (BSL-1.0) which is similar to MIT but without the requirement on the license being available in the binary.
This is the change which makes the difference in BSL-1.0:

You must include the original copyright and this license
in software unless in the form of “machine-executable
object code generated by a source processor.”

[jamesmunns]

@korken89 Interesting, I had not heard of that interpretation before. Is there a legal precedence that states it must be included in the binary distribution? In my experience, companies include this documentation with the released product, but in paper form/in the rest of the T&Cs/Warranty/etc (not in the binary).

[korken89]

This is a gray-zone in my non-legal-expert interpretation, but if it is in the documents accompanying the product can be fine.
Recalling from the old discussions, the choice was made to simply not be in the gray-zone and explicitly allow it.

For details I think Odin who is leading this project: https://github.com/kvasir-io has it.
I was just listening in on the discussions back then, but I also asked now on their Slack about the rationale behind all this so I can report back.

I just want to make you aware, as this has the potential to be a huge headache.

[Nemo157]

Apache-2.0 specifically seems like it's fine with the license being included in the documentation, it doesn't limit how you provide a copy of the license to the recipients:

You must give any other recipients of the Work or Derivative Works a copy of this License

---

I believe MIT is also ok with it when you read the license as a whole

[...] this software and associated documentation files (the "Software") [...]

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

by the definition of "Software" given in the copyright notice the documentation is included, so including the license file as part of the documentation of the derivative work should cover including the license with a copy of the Software.

(IANAL)

[korken89]

I trust you guys, just to keep it in mind and so that you are aware of the choices other embedded communities has done.

[jamesmunns]

Thanks for the input @korken89, definitely follow up if you hear more information from the organizations you are involved with.

[therealprof]

Hm, what happened to this issue? A whole bunch of comments (including all of mine) are missing...

[hannobraun]

@therealprof: You're probably remembering the discussion from #39. Starts here: #39 (comment)

@getreu opened this issue and copied his own comments. See #39 (comment)

[therealprof]

@hannobraun Right, my bad then. Just a bit weird to read...

[puzrin]

IMHO if you wish to push authors do something - create a convenient automated tools for CI. For example - recursive licence checker for projects. And let users to ask crate authors about the rest. Attempt to enforce authors directly & manually to do something is not nice in OSS.

[ithinuel]

@puzrin like https://github.com/davglass/license-checker ?

[puzrin]

@ithinuel yes.

[getreu]

Any improvement here? it is hight time to conform with the rest of the rust community.

[getreu]

Idea to foster coherent licensing:

add a tag like [compliant license] to items in rust-embedded/awesome-embedded-rust: Curated list of resources for Embedded and Low-level development in the Rust programming languag

[jamesmunns]

@getreu echoing what @therealprof said in rust-embedded/awesome-embedded-rust#24 (comment), defining, policing, and enforcing what a "compliant license" is in the context is probably not something we have the bandwidth for at the moment.

That being said, I would expect any of the crates maintained by the WG to always be something permissive (e.g. MIT, Apache, 0BSD, etc), but I really have no personal issues with individuals using whatever license suits them, as long as it is clearly marked in their cargo.toml. Tools like cargo-license are great for auditing these dependencies.

I'm not sure what you mean by "conform with the rest of the rust community", there are a number of crates that have chosen different licenses across the crates.io ecosystem, and I haven't personally seen any WGs or other official entities attempting to enforce compatible licensing.

[jamesmunns]

I would propose that we state somewhere that all embedded-wg owned crates be dual licensed under MIT/Apache-2.0, and perhaps mention that most crates in this ecosystem are similarly licensed.

Outside of that, I do not believe there is a strong desire (or capability) from the embedded-wg to "require" licensing terms from anyone in an open source space.

Nominating this issue for cleanup.

[jamesmunns]

I am closing this issue, please feel free to open another issue if you would like this discussed further.