heathermeeker
commented
5 years ago I take it that your intention here is to excise the idea of an market substitute (regardless of how that concept is described) and focus on functionality. I don't think that avoids the complexity we were struggling with, but let's hope so.
I start with the premise that these terms will only be tested for imperfect substitutes. Licensee products that are identical or nearly so are easy cases.
There seems to me no objective measure to assess whether one piece of software (services etc) contains the same functionality as another, as a general matter. If we were to do that in a one-on-one contract, we would identify a specific test for the functionality we cared about. In other words we would take a black box approach and use a compatibility test kit. Should the licensor be obligated to identify the core functionality here, in order to adopt the license?
I think the only way to identify the functionality that is important in a product is to let the market set a value on it. But if anyone disagrees, please explain how this line can be drawn by examining function, rather than prices and demand.
It doesn't matter to me whether we use the word "economic." Your writeup implies that economists say what a substitute is and I disagree with that. Markets are natural behavioral phenomena that are both intuitive and pervasive. Economists only study what substitutes are. They don't set what they are -- well, not in a free market. And ultimately, companies that adopt this kind of license restriction want to stop competitors from free riding. They care less about function than loss of sales.
I note that we have also not used the concept of requiring value add. This is a very common concept in software licensing. The feedback I have gotten is that it is too vague, though I am skeptical about that. If we want to lay that concept aside, OK, but let's do that intentionally rather than by omission.
I do not understand "both functionality pass-through and different functionality" -- please clarify.
This is not an API copyleft license -- it's completely different. The two are substitutes for each other. :) I am not disagreeing with your writeup, but I do not want to burden this process with discussion of copyleft. Any discussion of that should be in a different forum.
kemitchell
mlinksva
bradrydzewski
This PR builds on #60, but takes the language for the Noncompete in a new direction.
Economics
Relying on the economics concept of substitution created a lot of confusion. I'm particularly concerned that it took the license away from plain language. Instead of making it possible to apply the license in most cases without professional help, appealing to economic authority introduced the need for economic expertise, on top of legal expertise. For those who can't run out and hire economic consultants, which is most of us, invoking their jargon invites lay confusion about their field, in addition to any lay confusion about the legal concepts.
Writing on economic substitutes that I've reviewed, from economists and courts, tends to split the definition of substitute goods in two. There's a formal definition: positive cross-elasticity of demand. But the definition I think we actually want is the more intuitive idea of consumers picking or replacing one offering and not another. The fact that there is a formal economic definition of substitution lent a certain sense of specificity and rigor. It made the language feel precise, to those accustomed to thinking of economics as precise. But we're actually relying on the intuitive definition riding sidecar with formal theory. The intuitive definition can only be stated very generally, which is fertile ground for all kinds of arguments.
New Approach
This PR stands for the idea that we should accept that we're really after the intuitive idea of substitutes, write that intuitive definition into the license in plain terms, without appealing to economic authority, and do what we can from there to make it possible for non-lawyer-non-economists to apply on their own.
One option would be to simply drop "economic" from the front of "economic substitutes". That would avoid appealing to authority, but wouldn't do much for clarity. It would produce lots of arguments about the meaning of the single word "substitutes", which isn't much to go on. Substitutes to who or how many? How easy is it to substitute?
This PR instead mixes in a few new ingredients, to help structure the question a bit more, without specializing the license to one kind of software, or one kind of competitive offering.
Functionality Pass-Through
The idea of a product or service passing through the functionality of the software comes most directly from my work on the API Copyleft License, particularly its copyleft exception for applications. The basic insight there was that software is really about functionality, and competition is really about what others---not the licensor, not the licensee---see on offer.
@laughinghan was absolutely pivotal in refining that part of the API Copyleft License, and might find this new effort interesting.
Value Add
The idea of additional functionality of a different kind comes in part from API Copyleft, but more so from typical value-added-reseller and system-integrator agreements. The fundamental idea there is that end-user customers come to the VARs and ISVs primarily for the value added or integration, not for the generic functionality of the software they're building upon and reselling.
@bradrydzewski has been a welcome bug in my ear about some of these issues, and I'm sure will want a look at this PR. @heathermeeker has brought more traditional VAR language up as an alternative.
Kind of Software
If there's been one specific point of repeated feedback, it's that we should make explicit that licensees can't offer the licensed software as a service. I've personally been reluctant to take that and run with it, because I feared the result would be a niche license tailored especially for database and other cloud-native service vendors, stamped with Polyform's imprimatur, rather than a truly general purpose license that could see adoption by a broad enough licensor base to develop real name recognition and other network effects.
I've responded to that here by adding a clarification making clear that simply delivering or packaging the software in a different way doesn't earn the licensee a free pass. But I've also taken pains to make clear that any such change to the type of the software has the same problem. Not just software-to-service.
Drafting-wise, adding that kind of examples list to a general rule always creates some risk, even when it's left open-ended. Courts may read it to restrict the general rule, using the items that got included as hints about what the more general terms meant. The specific examples given may also go out of date. Software as a service wasn't new when we started calling it "software as a service". But we'll be surprised by another, parallel development in software delivery in the next few decades, I'm sure. The wheel is ever turning.
I'd like to call @tieguy out for thanks here. He and I have been cooking up a kind of "test suite" for public software license analysis that proved the perfect tool to hand for this. We really ought to get that published.
Open Questions
Can folks improve the language? This PR isn't my first formulation, but it's the result of my first push since #60. It needs other eyes, and likely some polish.
Is using both functionality pass-through and different functionality redundant or complementary? I tend to see those limitations as drawing the circle closer from two sides, but other might see them as redundant.
Are we really trying to back our way into an exception for applications? If so, should we state that explicitly, as does API Copyleft?
There is a structural difference between API Copyleft and Polyform-Noncompete. Under API Copyleft, the rule is sharing back (copyleft), and the exception is applications. Under Polyform-Noncompete, the rule is that you can't use the software, and the exception is that you can do so for a permitted purpose. But any purpose is a permitted purpose, except providing goods or services that compete with the software. Reminds me of Wikipedia: Everything which is not forbidden is allowed.
Thanks so much to everyone for thought and attention. This license was feeling a bit stuck a week ago. I'm feeling much more optimistic now.