Change our license?

[goodboy]

I'm not sold on GPLv3 (it was a hip shot to get things going with what little I knew). I want to open discussion on this.

One thing I do want to enforce is that any corp trying to use this project for profit pays back into it; if you're using it for free and sharing what you add then 100% it's acceptable and we should propagate that use.

With that very naive principle in mind here are some options that others have pointed me to:

• AGPLv3 used by the Genode project

  • we're now adopting this in piker.

• ~license zero which has an interesting public-private approach more along the lines of Qt or MongDB~ Never gonna happen, they're paying off stripe underneath which is in antithesis to pretty much all the projects built on this one.

• the sentry blog post on relicesning and an accompanying changelog podcast interview episode talking about sentry's licensing strategy (thanks @parity3)

• the new BSL (business source license) approach being considered by cockroadDB (thanks again @parity3).

I'm of course open to other suggestions (even for moving to looser more well known options) with good arguments for why.

[parity3]

I don't have any opinions on this but thought I'd add a couple recent references to software licensing I've come across:

sentry blog post changelog podcast interview episode talking about sentry's licensing strategy

Obviously, this does not pertain directly to tractor, but if you're trying to find out where this segment of open source is going, particularly if you ever want to run a SaaS on any of your FOSS in the future (which probably is not the case), I think it's a good data point.

[goodboy]

Sweet. Thanks for the input @parity3 :+1:

[ryanhiebert]

It doesn't meet your stated goal "to enforce is that any corp trying to use this project for profit pays back into it", but since you allowed for looser ones with arguments of why, I prefer MIT. Its minimal, simple, and free-free.

The reason that I prefer MIT is because copyright law, it seems to me, is fundamentally broken. Copy-left licenses like GPL simply would not work if software copyright were eliminated. Combine that with the minimal, simple, and well-known nature of the MIT license, and that establishes my preference, even though my thinking on copyright isn't quite so simple as "it needs to be abolished."

I do think that the recent changes to Sentry licensing, as well as that license zero link (which I'd never seen before) make for interesting thinking, and I'm interested to see what novel and more ethical business models may come as a result.

I am concerned that requiring for-pay organizations to pay for a license to tractor would have the effect of limiting the ease by which they may adopt tractor, and that it may end up backfiring with regard to overall adoption of tractor. In my company, for example, we'd have to go through some management overhead to start working with tractor, while a free license would not require any approval from management to adopt.

That's not to say that it would be a clearly bad idea necessarily, but that it concerns me. By way of an example, I was very interested in what is now called Hedera Hashgraph a while back. I haven't been following it, so I'm not entirely sure what has become of it, but it doesn't seem like its taken everything by storm, even though I found the core algorithm very promising to potentially be able to do just that. My concern was that, because of its patent encumberance, that this very promising ledger resolution strategy may be hamstrung, and not be used as widely as it could be. Maybe I'm overthinking it, but I'd hate to see a really good idea or project be wasted for lack of adoption.

[goodboy]

@ryanhiebert I appreciate the feedback and I'll add a "loose" license section for voting, though I'd appreciate some PRs before we get too many votes :wink:

and that it may end up backfiring with regard to overall adoption of tractor.

I'm not sure that corporate adoption is a goal of the project at this point though. In my experience it is, what I call, compelled individuals who contribute the most value to a code base when compared to employees of companies that need something for their job. This is of course entirely anecdotal so don't put much weight on it. As an example I've already had 2 people from large financial corporations ask about changing the license and have effectively turned them away because I don't need these corporations to adopt this project. tractor isn't being built for corporations, it's for people who want to make better distributed Python software.

I do understand the argument though of looser license -> wider adoption, supposedly. There's always exceptions: Qt is an excellent example imo. My problem with this argument is there also needs to be the premise that the project is actually good/novel enough to be adopted in the first place. It's also easy, assuming all contributor's agree, to change to a looser license later after an incubation phase.

In my opinion if the merit of the project is high enough then corps should have no choice but to contribute back if they are generating a revenue stream because of it. A company's extra paperwork isn't really enough of a downside I would imagine if a project is really great enough that they can't release their derivative work for free. I don't think it's really asking that much: you either join the ranks and make the world a better place or you lookout for yourself and pay a fee :wink:

I would rather see the group of core developers who work on tractor be compensated for that work by others who refuse to share their derivations/use cases then it be used by some company everyone knows. Also, let's say tractor isn't that good of an idea, it's probably better then anyway that a bunch of people didn't adopt it in their proprietary code bases.

I also don't want to be an extremist, pushing back on these thoughts is very good :+1:

[ryanhiebert]

One thing I do want to enforce is that any corp trying to use this project for profit pays back into it; if you're using it for free and sharing what you add then 100% it's acceptable and we should propagate that use.

I think that this line is unfortunately a bit fuzzy, and it depends on exactly what you're trying to accomplish. GPLv3 would be fine for me, as that allows me to use the software in my SaaS without having to release my SaaS itself (that's my company's main product). Not that I'm actually using tractor yet, but that's an eventual goal.

Now, if we get to the place that tractor is a great solution for us, it could be acceptable to require my SaaS company to pay for it, but I can tell you that it would certainly be a harder sell for us, and it would certainly require that we could trust that the project would be maintained for the money, which is no small commitment. On the other hand, free use means that we can put it in our product, and part of what we're taking on is that responsibility to help maintain it, by fixing it when we have issues with it (or finding an alternative). If getting us to maintain it to our needs is all that we're wanting to do, then a totally permissive license works fine as well, at least for the particular case of my company.

AGPLv3 tries to close the SaaS gap, so that if you're using it in your service, and make improvements that you don't need to release the source code for, you actually still are required to by the license. But in my case that's a really tricky line. tractor is, for us, a library. We have a great deal of code, that I'm not at liberty to release, but if there are improvements to make to the library itself, then I have both the ability and some amount of a moral mandate to do that. The AGPL, by its nature, doesn't seem to be able to give us a line that would be acceptable to us. Is "monkeypatching" allowed? Overriding some modules? Am I even allowed to build a service on top of this library without releasing my source? These are all questions that have difficult, or bad, answers, but are very important to have a clear answer on.

[ryanhiebert]

Also, to make sure I'm clear in my intentions, I'm not trying to force any particular choice on you as far as the license. I'm just engaging the conversation, and communicating my thoughts, in the hopes that they help you make the best decision.

[goodboy]

in the hopes that they help you make the best decision.

@ryanhiebert this is exactly the kind of pushback/challenging I'm after, particularly like the example you've provided with your employer :+1:

I still need to think on this much more but it's good to hear your perspective for sure!

[ghost]

I am with @ryanhiebert on this one. I vote for MIT as well. There is little to be gained (if anything) with more complex licenses - most likely they will just throw people off (perhaps of even trying the project). On a personal level I would like us (or just you, @goodboy ) to reach a final decision asap. Ps: if we claim that we proudly build on top of trio, let's not forget that trio is available with both Apache and MIT licenses, and IMO that is the ideology that tractor should perpetuate.

[parity3]

Regarding this BSL-rollover trend (mentioned in my sentry comment above) (ie firmly in the more-complex direction, but honestly not OSS purely out of technicality), cockroachdb has a blog post summarizing their rationale/intent. My guess/prediction is this will start to standardize over the coming years as the new default, and thus will not be considered complex/surprising to the average user.

That said, you, as these other places have done, can change licensing in the future if needed.

[goodboy]

@parity3 sweet, that was a good little read.

It's somewhat comforting to see others have this same thought process. My main concern is that if a corp is going to make $ they pay it back if they're not contributing back code and at the very least they must announce use in any form.

The more I go on runs and think about this the more I'm convinced my original thoughts are correct.

[ryanhiebert]

Are you thinking you're going to stay with GPL, then? If I build a library for doing celery-type stuff on top of this one, will it need to be GPL? Or do you want to provide some means for dual-licensing in some situations? If this is only GPL, that means that any software built using it would NOT be able to use BSL, IIUC.

[goodboy]

Are you thinking you're going to stay with GPL,

No, hence the issue :wink: But, as mentioned, I will likely in the very very near term until some basic feature set gets pushed out.

the more I'm convinced my original thoughts are correct.

Those thoughts being about being wary of using too loose a license from the outset for a project of this nature.

[goodboy]

Speaking of weird ones: https://github.com/darklang/dark/blob/main/LICENSE.md

[goodboy]

@ryanhiebert sorry, just coming back here due some queries about this.

Now, if we get to the place that tractor is a great solution for us, it could be acceptable to require my SaaS company to pay for it, but I can tell you that it would certainly be a harder sell for us, and it would certainly require that we could trust that the project would be maintained for the money

You present an inverted dilemma here imo. You're not paying for maintainer-ship you're paying to not have to release the code for free ostensibly because if you did you wouldn't make as much money. How can you be making money on something if it didn't work in the first place? Do companies just decide to use something before they've tried it? I don't think so.

If it wasn't maintained how does that change anything? If you're making money off an unmaintained project why do you think it's ok not to share some of that with the people who built the thing that's making you money. It doesn't matter whether or not it's "maintained" what matters is it generating value and can you fix it if you need to and can you continue to make profit. This is the only distinguishing property of corporations, to make profit, or else they'd probably be a different kind of entity.

I'd love to hear a good argument for why a free lunch should exist for a corporation who profits off work by a group of people without compensating the authors in some way. Especially when they're not really asking that much: do what we did or pay up what you made from it. This is a very simple everyone-uses-the-same-rules philosophy. In no world do corporations operate on their own "argument" (really fallacy) whatsoever; there is always some value they extract from whoever uses their thing otherwise they'd go bankrupt.

It's merely operating under their own rule set, nothing more.

On the other hand, free use means that we can put it in our product, and part of what we're taking on is that responsibility to help maintain it, by fixing it when we have issues with it (or finding an alternative).

The problem is that if there is something wrong there is no responsibility on your end to maintain it either, nor contribute back your supposed improvements, but you may however be making money off it either way. AND if you can fix it, and make money off it you're arguably double dipping because being able to fix something, because you have the manual, is not a hindrance that the creator should have to pay you for to make more money off it, it's a feature of any good product or technology proprietary or not.

Final assertion: there is no free lunch.

Last time i checked not being able to contribute something back has more to do with greed and margin printing on balance sheets then anything todo with whether something is more maintainable or not; awful proprietary software you can't fix (or worse have to pay to have fixed) is the most obvious example of this and if your company is fine with such things they can't warp the logic into a fallacy that somehow makes a free lunch exist.

My apologies if this seems borderline ranty but if you understand how the money system works at the backend, there isn't much of an argument for we should be able to use things for free and make money off them just cuz.
Pick one or the other, stop pretending like the world isn't a better place exactly because people build cool things because they want to, not because you can make a profit.

[ryanhiebert]

You present an inverted dilemma here imo.

The dilemma I suggested and the one you countered with are not exclusive. People may well choose to pay for a license to avoid having to release their proprietary code. But just speaking for myself, even if I wanted it for that reason, I would not use a library that was not maintained, for the same reasons I won't use a free library that is not maintained.

It doesn't matter whether or not it's "maintained" what matters is it generating value and can you fix it if you need to and can you continue to make profit.

A company that thinks only this way will die. This is definitely part of the equation, but not all. You're building not just for the present, but for the future, and you're taking a risk by choosing one path (or library) over another one. You might find that your choice was the wrong one, and that your business will fail because of it. These risks have to be managed.

The problem is that if there is something wrong there is no responsibility on your end to maintain it either

This is only correct if you misunderstood what I was saying. It's only the case if by "maintain" you mean "release it back to the author". I merely meant it in the sense of "do what I have to to keep it working for me". As you described above, that is essential, regardless of other things. The commitment to even that much maintenance is indeed a commitment, a risk, and a cost, that needs to be weighed in with all the other competing factors.

Fwiw, I expect that any paid software maintenance model would have to subscription-based in some way. For me, that's pretty much a given at this point, so if any one-time cost was ever in your head, you can perhaps understand why maintenance (keeping the library working) being included is essential in my thinking.

Especially when they're not really asking that much: do what we did or pay up what you made from it.

This is necessarily a very tricky question to answer. Two answers that it can't mean, if everyone want to get paid, are everything that you wouldn't have been able to get without this library and nothing. There should be some kind of equitable split of the generated profits between the two parties. The library author is bringing their work to the table. The library user is bringing a whole lot to the partnership as well, and I'd suggest in general they are likely bringing a much more significant part of the combined value of the partnership. Ultimately, there's no substitute for negotiation in finding the right balance between these parties.

---

The Darklang model is novel and interesting. I'd like to see some model that worked well to provide a good, ethical, and paid contract between library authors and library users that both find worthwhile and sustainable. Remix Run is another interesting example that I'm aware of, and they've just gone full-blown paid for that. I think I saw something that wanted to be library-as-a-service type thing, where you'd pay to run the library code.

I'm somewhat skeptical that there's a way to square the circle in your favor, at least in the case of tractor. Every price has an opportunity cost, so if you want maximum usage, you'll want to release it for the minimum price. A higher price will price some out of the market. Often, as you rightly note, that price may not be entirely rational, but then the market isn't a solely rational place, and you have to consider the human element as well. I suspect, and find it unfortunate, that any price is likely to have outsized negative effect on the overall adoption and success of the library.

But then, I'm also skeptical that Darklang's experiments and remix run are ultimately going to find the success they need either. I hope I'm wrong, because a culture of successful paid libraries would, I think, benefit the software world as a whole. There are big challenges to overcome, especially around maintenance, risk assessment, and adoption, but I'd love to see there be a good way to deal with it.

So, my suggestion of MIT is out of a desire for tractor to see adoption, thinking that corporate adoption, while not a particular goal, would assist in overall adoption, and because of a skepticism that alternative models will actually provide a good balance for you, plus some general disapproval of the copyright system. My reasons for that suggestion may not be a good match for where you want the project to go, and that's just fine. Maybe it's worth the risk that you choose a novel or restrictive model, and the possibility that it may cost more than you hoped it would in the areas that I'm particularly thinking of. Those are risk assessments that are yours to make, and I'll be interested to see how whatever choice you make ultimately affects the project, whether positively or negatively.

[goodboy]

@ryanhiebert great response yet again 😎

I want to dissect and analyze this all a little more (which also means letting it bake in the subconscious) before I come back with an attempt for some more rigorous arguments.

Overall great presentation from the other side though.

[goodboy]

Interesting find that pertains to our previous few comments called the Big Time Public License.

Particularly interesting is trying to solve the problem of How can a license say what “fair” is ahead of time?.

There is a small blog novela: https://writing.kemitchell.com/series/big-time-license.html