Round Robin vs SSPL/LGPL

[mischif]

I've been reading the writing about the thought process behind the license and I want to make sure I understand where it's copyleft and when it's permissive.

One article says "the draft applies that strengthened copyleft selectively. In particular, the draft carves out a permissive use case: building applications using the licensed code"; another says "[t]he goal of the license is to scope copyleft selectively, to miss applications, but cover everything else". OK, so what's an application? From the license, an application is "any software that only invokes this software’s functionality through the interfaces this software exposes" unless it exposes so much it becomes a practical substitute.

OK, to make sure I understand I came up with some scenarios where I think the license would be copyleft/permissive, using SQLite as the example:

• Unmodified, used as a data store to a larger project, the licensed code travels with my own (e.g., statically linked): permissive (through the application exception)

• Unmodified, used as a data store to a larger project, the licensed code travels separately from my own (e.g., dynamically linked): permissive (through the application exception)

• Unmodified, used as a data storage microservice in a larger project: copyleft (it's a practical substitute; will include the code around setting up the microservice but nothing else)

• Modified, used as a data store to a larger project, the licensed code travels with my own (e.g., statically linked): copyleft (but only for SQLite)

• Modified, used as a data store to a larger project, the licensed code travels separately from my own (e.g., dynamically linked): copyleft (but only for SQLite)

• Obviously if I try to sell SQLite-as-a-Service I'd have to open-source everything surrounding it.

Do I have the "desired outcome" of these scenarios right? If so, I don't see when the license's proviso that people contribute "all software that invokes this software’s functionality" comes into play. If I'm understanding correctly, it feels like all the permissiveness undercuts the intent to make a plain-language SSPL; this license seems more like the LGPL with a Commons Clause.

Please let me know where my thinking went wrong; I know Kyle has said in the past the SSPL "intentionally permits building nonfree services" which doesn't seem possible to me given how much of it is vanilla GPLv3 so perhaps I have the idea of the SSPL wrong to begin with.

[kemitchell]

Thanks for the notes. Please feel free to share your writing when it's public!

In the SQLite-as-a-service examples you gave, I assume that would require more code "service-izing" or "service-wrapping" SQLite. I would read that code as "additions" to SQLite under round Robin, not qualifying as an "application", so that code would indeed need to be shared alike under Round Robin. So would any changes to SQLite itself, service-ized or not. Those would be "changes" to SQLite.

The decision path looks like:

graph
  Copyleft --> Contribute;
  Contribute --- Scope["these things"];
  Scope --> changes;
  Scope --> additions;
  Scope --> invokes["software that invokes\nthis software’s functionality"];
  Contribute --- Exceptions["but not these things"];
  Exceptions --> Prototypes;
  Exceptions --> Applications;

Loading

I think an analogy to LGPL is fair. You might loosely call Round Robin the missing LAGPL that FSF never wrote: a weak network-copyelft license.

At the same time, I don't think any comparison to Commons Clause makes sense. Commons Clause flatly prohibits "selling" software. Round Robin doesn't say "no" like that. It just requires sharing alike, in some but not all cases.

[mischif]

Kyle,

I may have written my first comment poorly, in most of my scenarios I meant for SQLite to be used as a data store in a larger project like recording the prices of stuff on eBay; I only brought up SQLite-as-a-service for completeness.

In the above scenarios, when the goal isn't to sell SQLite but use it as a small piece of something larger, did I get how you want Round Robin to effect licensing right? I'm trying to get a better grasp on where the application exception ends and the copyleft requirement comes into play - it seems like I wouldn't have to release my hypothetical eBay-price-recording code under Round Robin.

I brought up the Commons Clause because I read the initial purpose of this license was to be a plain-language SSPL, whose purpose was to prevent large companies like Amazon from selling SSPL code (without releasing a lot of supporting code which they would never do); I remember reading you call this license idea the LAGPL somewhere on your blog before but I can't find it now.

[kemitchell]

My goal writing Round Robin was to respond to the desire I kept seeing and hearing from developers to share their code in a way that would clearly require sharing changes and direct extensions, especially libraries and services like databases, without requiring people writing apps with their projects to share all their code. So very much "Lesser Affero GPL", but ideally without all the inherited strangeness of the GPLs' implementation of it.

"Application" is not well defined, and leads inexorably to an edge case: "wrappers". Technically, say, a task-management Web app using SQLite and a thin REST API wrapper around SQLite share a lot of common characteristics. They both likely just call intended, public, versioned APIs of SQLite, without changing any of its code. But the feeling was that the wrapper should really be shared alike, as not really an app but a kind of repackaging or extension of the original project, rather than an application of it to a more specific problem, like task management. Some developers express why in terms of what's fair or what's good for the project. Some express it in terms of defending projects against diversion of mindshare, business opportunities, or charitable support, especially from users who know the name of the wrapper but aren't so aware of the potentially larger transitive dependency.

One way of distinguishing the API from the app is to point out that the API wrapper will likely "expose" a lot more of SQLite's own API than the task-management Web app will. Interacting with the web app will be very different than interacting with the API. Another way is to point out that the API wrapper really substitutes for, or competes with, SQLite itself. Applications could be written either with SQLite the library or SQLite the API microservice, for basically the same purpose.

In terms of the Round Robin License as an implementation of the permissions devs wants to set for their projects, the default rule is "you have to share it". Then "but not applications" is an exception. The definition of "applications" hits both lines of cleavage I pointed out earlier:

You don’t have to contribute any software that only invokes this software’s functionality through the interfaces this software exposes, unless it exposes so much of this software’s interfaces or functionality to users, programmers, or other software that it becomes a practical substitute for this software for any substantial portion of its use cases.

So, as intended, writing a Web app with a Round Robin-licensed database---either library like SQLite or service like MySQL---would not require sharing the Web app code alike. Patching or extending the database would. Wrapping the database in code that makes it available as a service some other way---SQLite-over-REST, phpMyAdmin---would require sharing that code.