Closed adamhjk closed 5 years ago
@adamhjk Thanks so much for this!
I'm loathe to coin "superstructure" if I can avoid it. But it was right on my mind to consider adding the examples from my first draft back to "Copyleft", as test cases.
I'm not yet sure whether this license needs or wants to cover situations like backup tooling. I could see it covering that work as an "extension". But I'm not sure that's necessary to get the effect that Commons Clause and SSPL adopters seem to want. It may be enough to require release of any code for offering the software as a service to other applications, even if it doesn't reach backup code in particular.
Right - from my reading of the intent of SSPL, the only reason they care about backup software is because it might be a thing that a competitor creates in order to run a service. Somehow drawing a sharper distinction. Maybe something like:
You need not contribute applications that only invoke this software's functionality through the interfaces this software exposes, without exposing this software's interfaces and functionality to other applications, or that is used to support exposing this software's interfaces and functionality to other applications.
There's tension between addressing the Mongo use case of SSPL and generalizing the hybrid approach to other kinds of software.
One goal of this license was to work for other kinds of software. For example, these terms as designed would work plenty well with a library, too:
Patch the library? Copyleft.
Extend the library? Copyleft.
Use the library in your app? Permissive.
Wrap the library in server code, to offer it as an API? Copyleft.
Adding a FAQ like that, probably outside the license, would be dope.
@adamhjk I have a TODO (#2) to flesh out a "test suite" using well known projects as hypotheticals: what if they were licensed under these terms?
At the same time, I don't want to use side materials to clarify the license, as we've seen from Mongo under AGPL, and now again under SSPL. I'd rather make the license clear on its own.
@adamhjk I'm just waiting on the language to settle down a little bit more before I dive in and do this. I've begun getting the example test cases together, but don't want to do "run" them against language that may change.
PS: A lot of recent changes have affected the copyleft rule language. For the latest, start here! https://github.com/kemitchell/shared-component-license/blob/8f103662110802982ae814e5d6b7d43df69354c9/license.md#copyleft
Okay - comparing this to the SSPL section 13:
As I read Shared Component it:
In the SSPL, they draw the distinction between an application and the things required to offer it as a service. I wonder if you need to say something similar - for example, I could easily write (say) backup software that uses only published APIs. Under the SSPL, if that backup software was written without the intent of offering the software under the license as a service, the copyleft provision isn't activated, as far as I understand.
In reading Shared Component, it seems like you have similar intent - if you're an application using the software for it's main purpose (say, using MongoDB as a database), you don't have to contribute it. But if you're writing ancillary software (management tooling, backups, etc.) then you do, because they aren't "applications". If I wasn't already familiar with the context, I'm not sure I would get that from the language.
In the draft on your blog post, you solve this by distinguishing "superstructure", which I think was better. Without it, it's harder to see the intent.