Closed kemitchell closed 4 years ago
It's not clear to me what "providing any good or service that competes with the software" covers. I guess it is intended to cover providing the software as a service, but that seems like an economic substitute for someone else (another provider, or user self-hosting) providing the software as a service, not a substitute for "the software".
I did read https://github.com/polyformproject/polyform-licenses/issues/32#issuecomment-505204787 and understand the concept of an economic substitute, but still am not clear on effect of the language in this PR.
Further, what if the licensed software is not an application, but a library?
@mlinksva in your view, would the rule be clearer without the clarification that competition means economic substitution?
I'm not sure whether clarifying that competition means economic substitution is helpful or not, but my confusion precedes that. What isn't clear to me is what situations the license means for software to be the object of competition/economic substitution that would rely on the license. The language in master, though it also contains that concept, is a bit more clear that the object of competition is the licensor: don't compete with the licensor in whatever markets the licensor uses the software in -- note this also makes the library use case make sense.
@mlinksva I think the preference of drafters and potential adopters so far is to focus on the software, rather than the licensor. Focus on the licensor requires monitoring the licensor. Focus on the software requires understanding the software.
The effect is to align more with, say, weak copyleft. Use. Share. But don't turn around and use against the project itself.
Compare to, say, the latest master
of the API Copyleft License I've been working on:
You need not contribute any software that only invokes this software's functionality through the interfaces this software exposes, without exposing this software's interfaces or functionality to users or other software to such an extent that it becomes a practical substitute for this software.
Interfaces exposed by this software include all the interfaces this software provides users or other software to invoke its functionality, such as command line, graphical, application programming, remote procedure call, and inter-process communication interfaces.
The focus on an economic definition of competition back here on Polyform was @heathermeeker's, floated largely to address concerns from others that "competes with" alone isn't clear. I happen to think it was clear, and the courts would reliability apply as intended without a call to apply economic concepts. But this is largely uncharted drafting territory, and there's no familiar formulation that "looks right" to anyone.
OK, is offering the software as a service competing with the software? Seems highly dubious to me -- rather it is increasing the software's market share.
@mlinksva That's the rub. It is the intention of many would-be licensors to prohibit many SaaS offerings.
I guessed that was the case. It'd be crazy to not make the language totally unambiguous and clear on that point, and it isn't.
If you wish to focus on the software, I'd suggest language about not offering the software or a service based on the software, effectively freeing the licensor from those forms of competition from others using the software.
I think it would be better to use the term noncompete for a license focused on protecting the licensor's business(es) from competition, analogous to employment noncompetes, rather than the software. Monitoring can be worked around a number of ways: first, who cares, the first priority of a restrictive license isn't to make things easy for licensees; second, the prior uses exception could be more expansive; third, something about licensor ceasing to be in a line of business, noncompete could no longer apply, making it an open license (and making cost of monitoring have positive benefits). Idle paragraph, as I understand this isn't the direction of this license. 😄
I had similar questions with regards to libraries (and microservices). I am still trying to wrap my head around how I might use such a license, and I may be misunderstanding, but I started to consider the following scenario:
project A (core) -> Polyform Non-Compete microservice B (frosting) -> Polyform Free Trial microservice C (frosting) -> Polyform Free Trial
I find it interesting that the licensor could license project A under [what I consider] a permissive variant of Polyform, and license addons under more restrictive variants of Polyform. It is similar to the core and frosting analogy except the core is not an open source license. However, as I understand the license, one could swap the frosting with clean room implementations (and publish as substitutes) and still comply with the core project's non-compete license.
Just food for thought.
Personally, I'm going to back up on this, and revisit my check list of hypotheticals---service, application, library, framework, and so on---as well as how they should play out when used in various ways.
@mlinksva we're definitely of a mind that the service/hosting issue should be clear, but we also want to make sure we release a license that's usable for more than just services.
This was merged as part of #64 after a rebase.
Separate work continues on the Noncompete license.
This is by no means final, but represents current thinking. It's essentially a composite of what's on master and what's in #35.