Skip to content
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

Encourage common license policy with a "divergent special license" label in list #24

Open
getreu opened this issue Apr 19, 2018 · 5 comments

Comments

@getreu
Copy link

getreu commented Apr 19, 2018

Contributions to the Embedded Rust Ecosystem should be published under the same license as Rust itself, embedded-hal and cortex-m-rtfm which is:

Licensed under either of

at your option.

Why? 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 compatible licenses. To ease this process I suggest that all code released under a divergent license should be labelled divergent special license.

At the same time the new divergent special license label will encourage code writers to join our common license policy. A common and coherent license policy constitutes the condition sine qua non for professional suitability. It supports our vision (To improve the productivity of embedded software development teams). Linux would not have been successful without its a common and coherent license policy.

In order to encourage a common license policy for Embedded Rust, I suggest that contributions are only fully accepted in this list, when they comply with the above licenses. Contributions published under divergent licenses can be listed, but should have a divergent special license label.

@therealprof
Copy link
Contributor

We had this discussion before, will need to find where that was.

I don't have any interest in bringing such issues here because I don't want to be responsible for:

  • verifying that supplied licensing information is correct
  • censoring crates

This list is supposed to be a resource and overview for people who are interested in doing something with Rust and MCUs and to them the specific license could not matter any less. Just because a chosen license doesn't suit a commercial purpose (and yes commercial != professional) does not mean it is not a useful resource. And vice versa: If someone wrote a killer commercial product every Rust user should know about, why would I not want to mention it? Not everything Awesome is necessarily also free.

@chrysn
Copy link
Contributor

chrysn commented May 27, 2018

I'd strongly recommend against limiting this list to crates that are published under the same license terms as Rust.

While it is true that licensing is important in professional environments, it is the responsibility of the (professional) user to evaluate the licenses themself; no level of carefulness on the side of the list maintainers can spare them that. Users of the cited Linux ecosystem are well aware that they ship more components than just the kernel, eg. Linux plus a variously licensed glibc. Especially on the side of microcontrollers, things can be messy (though on the particular crate I think that this license formulation is overly careful).

Many different licenses are around in the free software ecosystem. None of them preclude commercial use in general, and while some commercial entities prefer not to link against works licensed under the AGPL or similar, others can well use those licenses as well, or contact the authors for alternative licensing options.

If something needs to change in the awesome documentation, we could annotate the links with a short tag of the license they are published under (typically "Apache2 or MIT", otherwise "GPL3+" or "proprietary non-OSI-approved"), but given that links either go to git repositories or cargo pages, and that both prominently display the license of their content, I don't see any need for action.

@getreu
Copy link
Author

getreu commented Oct 11, 2018

What about a tag like [compliant license]?
it is hight time to conform with the rest of the rust community.

See discussion in Common and coherent license policy for rust-embedded and drivers? · Issue #57 · rust-embedded/wg

@therealprof
Copy link
Contributor

@getreu Who defines what a [compliant license] is? If anything we could show the license(s) and let the users decide whether that's compliant with their intended use or not. However I do not see any interest both having and maintaining that so without a volunteer to write that up and to maintain whatever people would agree on this is not going to go anywhere...

@getreu
Copy link
Author

getreu commented Oct 14, 2018

@therealprof Cf. header of the The Rust Standard Library in std - Rust -- source

// Copyright 2012-2014 The Rust Project Developers. See the COPYRIGHT
// file at the top-level directory of this distribution and at
// http://rust-lang.org/COPYRIGHT.
//
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
// option. This file may not be copied, modified, or distributed
// except according to those terms.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants