1bardesign
commented
3 years ago Yeah some sort of explicit CLA arrangement would be needed; standard forms of that being provided is a good idea but as always with multiple licensing i think there'd almost always be some negotiation going into the big stuff.
A more reciprocal HOOP would be neat, but I don't see how that would work defensively. I'll comment more on the maintainer stuff under the maintainer issue.
With the caveat that I'm not a lawyer and, for legal purposes, I know absolutely nothing whatsoever (just mentally insert "but idk, I'm not a lawyer" before every period in this issue), I think it would be worth explicitly stating how contributions are licensed back to the core maintainer/project owner.
Under the GPL, MIT, etc., contributions are pretty straightforward because there's an inherent reciprocity in the terms. If I submit a contribution and you accept it, then my code is licensed to you, your code is licensed to me, and everything just works. However, with a more restrictive license like the GPL, that also means you're locked in once you accept an outside contribution. Vendors that want to dual license their code under a copyleft license like the GPL and a commercial license have to work around this using CLAs.
However, under HOOP, it's not clear how contributions are licensed. I don't think it can be HOOP itself, because HOOP is non-reciprocal.
For a contrived example, suppose you released a super simple blog app under HOOP, and accepted PRs from me that added comments and a tagging system. If my contribution is licensed to you under HOOP, then it seems as though you would need to negotiate a commercial license from me to offer commercial licenses to anyone else, which would then subvert a major feature of the license. Alternatively, it's probably arguable that contributions are made with an implied license that allows the maintainer to control the work as a whole, but at the point where it becomes an issue, you're looking at costly litigation to clarify what exactly the maintainer is allowed to do.
I think it would be preferable to head this off and explicitly define how contributions are licensed to the maintainer, what exactly the maintainer is and isn't allowed to do, as well as who "the maintainer(s)" are and what distinguishes them from other contributors.
(It might also be worth exploring how HOOP could work if its terms were more reciprocal, but I have some thoughts I'm developing there that I'll save for another time.)