Are there any gaps in "develop, deploy, monitor, or run"?

[christianbundy]

My intuition is that the words are meant to cover the entire software development (or maybe "devops") lifecycle. If that's the case, it might be nice to compare against something like GitLab's "DevOps lifecycle" and ensure there aren't any gaps. If any of the below software was licensed under Parity, would the software that it interacts with get contributed?

• Plan: git-bug
• Create: vim
• Verify: mocha
• Package: docker
• Release: ssh (?)
• Configure: ansible
• Monitor: htop

Would all of these be covered by "develop, deploy, monitor, or run"? It's worth noting that the above list doesn't cover "run" (or does it?), so it might have other gaps, but I thought this might be useful to double-check that the current language covers the use-cases we care about.

[kemitchell]

Very open to this discussion!

The intent was very much to go broad. If you use this software to benefit from other software, including changes and additions to the licensed coded, contribute them back.

The current list of verbs was not what I started with. Feedback from others has had a lot to do with where it is now.

[kemitchell]

@christianbundy to give you a sense of where my head is on this:

Overall, I share your instinct that lists meant to be comprehensive are usually trouble. I would rather come up with a general description of the class, rather than a list of its elements. And despite publishing a v7.0.0-pre.1, I had in mind to revisit that problem for v7.0.0 proper.

I haven't been able to come up with a formulation that I actually like. But to show a little work, I've tried some sketches like:

Contribute all software that you [create, develop, study, or use] with this software, including changes and additions to this software.

What could replace [the part in brackets]?

[christianbundy]

I'd like to say "contribute all software that this software interacts with", but that's not quite right.

I've been thinking about this in the context of a dependency graph, where you need to contribute everything downstream of the Parity-licensed software, without the obligation to contribute anything upstream. Using the parity-vim example, you'd need to contribute any software you write but you shouldn't need to contribute your operating system, filesystem, drivers, or other dependencies.

There's also a weird use-case I haven't been able to wrap my head around: a Parity-licensed web browser. Should you be required to contribute each website that you visit? I think you'd have to given the current language, but I'm not sure whether that's a bug or a feature.

[kemitchell]

@christianbundy, I’m always leery of “upstream” and “downstream”, since I find so many people understand those terms differently. But your web browser example shows we’re on the same page.

The other examples in that vein that are part of my mental “test suite” for the license are a text editor and a language interpreter. Whether someone should want to use Parity for those kinds of projects is a different question than whether should have the option.

[bradrydzewski]

we started to have a similar discussion in licensezero/temerity#1

[kemitchell]

@christianbundy closing this, but I want to make sure I point out that your feedback here was very influential on the forthcoming version 7 of Parity. If you'd like a look:

https://paritylicense.com/versions/7.0.0-pre.3.html#copyleft

[makkus]

Not sure whether to put my thoughts in here, or open a new issue. I thought about 'develop, operate and analyze' again, and I'm now also seeing an issue related to upstream/downstream, with a slightly different angle.

The thing is: as long as a user runs Parity-licenced code (app A) which in turn actively uses (in some way) other code, it's probably fairly uncontroversial to say one 'operates' that other software (app B) with it.

But what about when a user uses non-free code (app C), which in turn uses app A to do some work (involving only free software apart from app C)? Could one say that a user operates app C with app A? I guess if we understand 'operate with' as 'operate in combination with', then probably yes. But it could also be read as 'use it to control app A', a case that should not be allowed. Am I the only one reading it this way?

It looks like 'run' is removed now, that might or might not close that loophole, not sure. Overall, I think I'm reading 'operate' now as a bit more ambiguous as I did when I first read the new wording. It has an a bit too strong 'control the other software'-smell to it, hard to explain...

[kemitchell]

@makkus excellent comments.

It has an a bit too strong 'control the other software'-smell to it, hard to explain...