kemitchell / api-copyleft-license

an open source license that's copyleft for changes, additions, and wrappers, but permissive for applications
31 stars 4 forks source link

Scope of the copyleft #12

Closed adamhjk closed 5 years ago

adamhjk commented 5 years ago

Copyleft 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. However, you must contribute other software that invokes this software's functionality, as well as any changed or extended versions of this software.

Okay - comparing this to the SSPL section 13:

“Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.

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.

kemitchell commented 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.

adamhjk commented 5 years ago

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.

kemitchell commented 5 years ago

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.

adamhjk commented 5 years ago

Adding a FAQ like that, probably outside the license, would be dope.

kemitchell commented 5 years ago

@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.

kemitchell commented 5 years ago

@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