Stefano Russo (Oct 07 2021 at 11:49): Stefano Russo (Oct 07 2021 at 11:49):Good day.
I just discovered your projects yesterday, and got very excited to start working with modern web technologies again, after many years.
Similarly, I launched on a quest to understand software licensing models, as I mostly neglected them until now.
So, I apologize for inevitably looking like a troll; stirring up concerns in the heat of the moment.
My intention with this post is to solely exchange ideas that don't seem to be addressed often enough, in my opinion.
Apache-2.0 is a great license, and was a great pleasure to read and sympathize with, personally.
It covers some things that I'm sure most developers care about, which aren't covered, or explicitly stated by the MIT license.
However, it feels like it still potentially allows coorporations to "swallow up" the combined community effort for monetary gains,
and provides grounds for unethical practises while doing so. This is often addressed by the copyleft GPL license.
Yet the GPL, as a purely viral license, seems to raise a lot of concerns in common Business Models that
might be used by small and medium companies, who try to make an honest living through their work.
But there seems to be a middle-ground, namely the Mozilla Public License (MPL), a file-based copyleft license.
From what I gathered, using the MPL-2.0 would allow downstream crates to similarly embed wasmtime
in their applications, choosing their preferred licensing model.
But it would additionally require that any changes made directly to files within wasmtime must be made
openly available under the MPL-2.0+, which I see as a be a big plus for the user, for two main reasons:
Adoption by big coorporations will more likely enhance the product,
by ensuring that modifications can be implemented upstream
Changes may be audited to find possibly unethical use within them.
Here, things like tracking, spyware or censoring/banning targetted applications come to mind.
I was addressing wasmtime directly here, but I'm sure could be relevant to some underlying projects aswell.
Changing this throughout the codebase would probably turn out to be a tremendous effort.
My question here is: might it just be worth it?
Dan Gohman (Oct 07 2021 at 14:39):I'm not a lawyer, and this isn't legal advice. My understanding of the MPL-2.0 is that if proprietary extensions are written in separate files, the MPL-2.0 is ok with them being linked in. As such, it wouldn't meaningfully stop anyone from doing anything.
Dan Gohman (Oct 07 2021 at 14:48):For encouraging people to contribute enhancements back, one observation is that the actual code at any moment in time is just one part of a much bigger picture of what Wasmtime is all about. It's also about ongoing platform evolution, security processes, community relationships, and ecosystem. Maintaining out-of-tree changes as the platform and ecosystem grow has ongoing costs.
Chris Fallin (Oct 07 2021 at 17:07):Also worth noting is that we don't exist in a vacuum, and others' policies and preferences are sometimes relevant; for example Cranelift is possibly going to be distributed with Rust (as an alternate backend) in some possible future, and for that to happen, MPL is not workable without policy changes, as I understand it. Similarly, Bytecode Alliance has a policy that our code will be APL-2.0: https://bytecodealliance.org/#project-licenses . (I learned about all this when I ported some regalloc algorithms from IonMonkey, which is originally MPL; we're working on relicensing so that it can fit in with the rest.) The philosophical merits of one or the other may very well exist and I don't claim to have any informed opinion on that; just noting other constraints that may make the choice for us :-)
Stefano Russo (Oct 08 2021 at 10:31):Thanks for your input!
Dan Gohman said:
My understanding of the MPL-2.0 is that if proprietary extensions are written in separate files, the MPL-2.0 is ok with them being linked in. As such, it wouldn't meaningfully stop anyone from doing anything.
I still imagine that there would have to be situations, where the restrictions of the MPL could indeed be used to tighten down parts of the program. They could be intricate and apparently small. I'm short of concrete examples, but I shall be on the lookout for them :3
Dan Gohman said:
It's also about ongoing platform evolution, security processes, community relationships, and ecosystem. Maintaining out-of-tree changes as the platform and ecosystem grow has ongoing costs.
My lack of experience with OSS communities may prevent me from recognize these concrete costs, at least in relation with software licensing.
Apart from someone like me hogging your time right now, because there seem to be a lot of unfamiliarity and unresolved questions in this area :*)
Chris Fallin said:
for example Cranelift is possibly going to be distributed with Rust (as an alternate backend) in some possible future, and for that to happen, MPL is not workable without policy changes, as I understand it.
I would assume that the MPL is well-suited for this case, as rustlang's team would just need to mention the inclusion of cranelift as a MPL licensed dependency, and refer to the GitHub repository. Thanks to version control, a user could then single out the exact version that was used when building their version of rustc. Referring to this FAQ entry (Q8): https://www.mozilla.org/en-US/MPL/2.0/FAQ/#distribute-my-binaries
I might however have a wrong impression about what exactly the meaning of "sublicensing" is (as mentioned in the MPL-2 under 3.2 b.)
https://www.mozilla.org/en-US/MPL/2.0/#distribution-of-executable-form
Chris Fallin said:
(I learned about all this when I ported some regalloc algorithms from IonMonkey, which is originally MPL; we're working on relicensing so that it can fit in with the rest.)
I see. What is current plan of action to make this work?
Off the top-of my head, I can see a few options, that themselves raise concerns.
1) Build a FFI Rust wrapper around IonMonkey, responsible for exporting the required functions.
- One might not be allowed to build such a wrapper, since the API definitions themselves are technically
licensed under the MPL, and one can't simply e.g. #include "algorithms.h" as one would from C, but
instead have to copy some of the licensed Work to even embed it.
- The performance of going through such a wrapper might not match the desired speed that could be
achieved through directly embedding the algorithms.
2) Use a tool like bindgen to generate compatible FFI headers
- This still feels like a grey area. The MPL-2.0 FAQ has an entry for minified JavaScript (Q16),
which states that they are considered an Executable rather than Source Code as defined by the license.
But that seems to be mainly because it is not "the preferred form for modification",
which it potentially would be when converting a C-Header to Rust.
https://www.mozilla.org/en-US/MPL/2.0/FAQ/#minified-js
- (same performance concerns as above)
3) Convince the IonMonkey team to relicense the algorithms under a permissive license
- As the code in question now lies inside of (probably multiple) MPL licensed files, the matter might not simply be that
of finding the author of that single algorithm, but to get all contributors of that file to agree.
(I am not a lawyer; this isn't legal advice.)
I would appreciate if you have anything to add to this, as I'd like to forward some questions to Mozilla, as to possibly reveal options that make collaboration more enjoyable in the future. Eventually, I'm hoping for a version of MPL that is able to address these kinds of collaboration issues once and for all.
bjorn3 (Oct 08 2021 at 21:08):regalloc-2 is a rust implemenetation of a register allocator. It is sufficiently based on spidermonkey's register allocator that several files of it have to be MPL licensed.
Chris Fallin (Oct 11 2021 at 00:11):Stefano Russo said:
[ ... Cranelift potentially distributed with rust-lang in the future ... ]
I would assume that the MPL is well-suited for this case, as rustlang's team would just need to mention the inclusion of cranelift as a MPL licensed dependency, and refer to the GitHub repository. Thanks to version control, a user could then single out the exact version that was used when building their version of rustc. Referring to this FAQ entry (Q8): https://www.mozilla.org/en-US/MPL/2.0/FAQ/#distribute-my-binaries
Possibly, I'm not sure; though as a purely pragmatic matter, that's a much bigger lift than "just relicense the code to fit policy" (see below for more; that approach is already in motion), and may have other downstream implications we're not aware of.
Stefano Russo said:
[... regalloc2 ... ]
I see. What is current plan of action to make this work?
Your option 3 (get a relicensing signoff from Mozilla) is already in-the-works; while I appreciate the thought you put into this comment, I don't think there's any need to get involved -- it should resolve soon!
(For maximal clarity, as @bjorn3 mentions, the new register allocator is from-scratch code, which is derivative at the algorithmic level; we aren't and aren't planning to actually link to IonMonkey code.)
Stefano Russo said:
I would appreciate if you have anything to add to this, as I'd like to forward some questions to Mozilla, as to possibly reveal options that make collaboration more enjoyable in the future. Eventually, I'm hoping for a version of MPL that is able to address these kinds of collaboration issues once and for all.
I am really only involved from the PoV of an author, and one who built a derivative work, and my interest is mainly just in advancing the software, so I can't claim to have any sort of legal opinion or thoughts in general that should weigh in.
I would ask that if you're hoping to get involved in this manner, at least if you're going to be arguing from the perspective of anything Bytecode Alliance-related, that you coordinate with @Till Schneidereit first, as he has been the driving force in the above licensing (MPL vs APL-2.0) discussions, BA IP policies, is in active contact with Mozilla, and in general is the right person for this sort of thing. Having a passion for these issues is a great thing but I also want to make sure that we don't complicate matters by trying to pull in too many directions at once :-)
Till Schneidereit (Oct 11 2021 at 14:28):Hi Stefano, and welcome! :wave: It's great to hear that our projects got you excited! :party_ball:
And thank you for looping me in, Chris!
Stefano, thank you for sharing these thoughtful considerations regarding licenses. The TL;DR of my answer is: we deliberately and carefully chose APL 2.0 + LLVM Exception as the default license for all Bytecode Alliance projects, and don't intend to change it anytime soon. The key reason is that we think it provides the best basis for successful collaboration by providing the combination of solid indemnification (to protect the author) and a a strong patent grant (to protect others from the author), while not introducing constraints on which organizations and projects can make use of the code.
You're right that the MPL would make it harder to take our code and integrate it into proprietary applications without making positive contributions to the shared code. In practice, however, we've come to the conclusion that trying to use licenses to enforce collaboration isn't really worth it, and focusing on enabling and facilitating collaboration is more fruitful.
If there were no downsides to it, we'd probably still use a weak copyleft license, and I personally think the MPL 2 is a pretty excellent compromise. However, there are real downsides, which is why we very deliberately chose the license we're using, and don't intend to change it*.
For various reasons, there are a lot of organizations and projects that have tight constraints on the kinds of licenses they accept for any dependencies. As Chris mentioned, the Rust compiler doesn't accept MPL dependencies. It's possible that that constraint could be lifted (I don't know the reasons, since this was before my own involvement in Rust), but I don't know how likely that'd be. And that's just a single project; there are as I said quite a few of these.
I could write much more about this, but unfortunately I'm running out of time before a meeting, so I'll end here.
*: which would in practice be all but impossible, because we don't do copyright assignment, so we'd have to explicitly ask permission to relicense from all contributors. There are successful examples of this, but they're rare.
Till Schneidereit (Oct 11 2021 at 14:29):Oh, and as Chris says, the relicensing for ra2 is well underway, based on excellent and enjoyable collaboration between all involved parties! :smile:
Last updated: Nov 22 2024 at 16:03 UTC