Live data from Hacker News

Commons Clause

redislabs.com

461–470 of 496 posts

Re: Commons Clause

#461

Earlier quoted context omitted.

> However, today’s cloud providers have repeatedly violated this ethos by taking advantage of successful open source projects and repackaging them into competitive, proprietary service offerings. Cloud providers contribute very little (if anything) to those open source projects. Instead, they use their monopolistic nature to derive hundreds of millions dollars in revenues from them. Already, this behavior has damaged…

Josh Berkus, member of the OSI license review committee here. License Zero was rejected because it's not open source. It is, in fact, a business model for a specific startup (and, I'd argue, not for the writers of the code either). Kyle had some other interesting ideas for licensing that could have been approved as open source, but was uninterested in pursuing them if they didn't support License Zero the business.

Howdy, Josh.

The last draft of License Zero Reciprocal posted to license-review works perfectly well on its own, without any dual licensing, and without any relationship to the business I formed. Its language wasn't any more coupled to a particular business model, or any business model at all, than AGPL's. If someone told you otherwise, they told you wrong.

I released the source code for licensezero.com itself under a successor to L0-R, without offering to sell any private licenses whatsoever. Anyone could use the terms similarly.

"License Zero was rejected because it's not open source" is tautological. And, alas, that's mostly in line with my experience of the license-review process. Some great folks offered back-and-forth, and were willing to explore. But that was largely drowned out by bare conclusions, and the drama that flared up whenever I tried to probe them.

Re: Commons Clause

#462
post #148

Earlier quoted context omitted.

Not even dark-ages Microsoft tried to prevent users exchanging knowledge about their products for money ("consulting", or frankly, "employment"). Such a suggestion is preposterous and should kill any company adopting it immediately.

At it's core, this is fundamentally about property rights. The owners of the Redis copyright are well within their right to license their property in any way they see fit. It's preposterous to you , but you're not the one who has spent the time creating Redis. It's preposterous to me that they wouldn't have the rights to govern their creation's use. You could go build your own infrastructure software, of course , tha…

Man, you are a smart guy. I know this, your posts are generally awesome. How in the hell do you think it's okay for them to try to ban consulting about a product? That isn't "property rights", that's just...fuckery.

Re: Commons Clause

#463
post #431

Earlier quoted context omitted.

This is splitting hairs. Of course there is no restriction on use, but in order to produce a derivative work I will want to eat my own dogfood. If my company's legal department says that our product must remain proprietary and closed-source, then it stands to reason I will not be able to build it on a GPL base. Those people will likely have to choose not to use GPL software, at least to some extent. (If they have a g…

No it's not splitting hairs. Using a piece of software and distributing a derivative of that piece of software are two completely different things. Nobody chooses not to use a piece of software because it's GPL. If people choose not to distribute derivatives under restrictive terms then that's great because that's exactly the reason I licensed it to them under the GPL .

You do what you want when you publish software! But if you take the entire class of people that produce derivative works, and count them as "not users" you are making a set error. Derivative works producers are also users.

GPL licensing will not stop me from using your software. It will stop some people. I do not say that I agree with those people and their decisions. I could not have built my career without GPL software, and it does not stop me.

Re: Commons Clause

#464

Earlier quoted context omitted.

You start your career later than your siblings. You land your first real job. You scrimp and save to buy your first real set of Christmas presents. Comes the day, and everyone seems grateful. You feel established, for a moment. The others exchange presents, but oddly, not with you. In the end, your hands are empty. Everyone else is okay with this. They make out great. Giving OSI money isn't giving Redis Labs money. I…

Why should the success or failure of VC-funded startups be a concern for open source? If Redis Labs folds, that's sad for them and I'm sure I'll end up writing some references for people. But it's only a concern for open source if Redis stops being maintained as a result. Which I seriously doubt would happen; Salvatore built Redis before Redis Labs existed, and I'm sure would land a job at one of those "established e…

For the same reason that the success or failure of other companies doing open source should be of concern. Company funding and structure get a lot of open source made. Industry involvement supercharged the open source community. But if it won't make money, industry won't do it. Industry will decide whether to do it based on past performances.

VC-funded startups produce a substantial amount of open source. If what we see at the tail end of this funding boom is a bunch of startups doing open source fail structurally, rather than merely by falling short of numbers, VCs will notice. There will be less funding for startups on any kind of open source model. And therefore less open source.

When we look at projects and define success only in terms of project continuity, and not individual outcomes, we dodge the question of why folks should get involved in the first place. Some baseline motivation will always be there from the bottom, from hobbyists, activists, and the obsessed, and the top, where enterprises use open source for cost reduction and cost sharing. Whether anyone shows up in the middle has a huge effect on what open source achieves, as a movement. And to what extent open source represents a viable opportunity to proprietary products and services.

Re: Commons Clause

#465
post #300

Earlier quoted context omitted.

> Given how long she has been doing this, I would simply not believe that she missed any of the issues I mentioned (the ambiguity, the AGPL/GPL/etc issues). Agreed on that, based on just reading one of her books. I wonder why didn't they choose AGPL.

It looks like they were using AGPL before, but now they are switching to Commons Clause. See the history of the RedisSearch license, for example. https://github.com/RedisLabsModules/RediSearch/commits/maste...

Yep, now I see this vague explanation on https://commonsclause.com :

> Why not AGPL?

> The AGPL was drafted in a different era where Cloud ecosystem was not nearly as well-developed. After deep legal analysis, many of the AGPL’s features were determined to be insufficient towards some of the requirements modern projects face.

> For example, much of the value for cloud-based software comes outside of the actual code (i.e. hosting) thereby nullifying many of the incentives to enforce source-availability. In addition, many of the AGPL's features can be more restrictive towards an end user that wishes to incorporate software into a new work, which makes a source-available license with additional grants more permissive.

Re: Commons Clause

#466
post #460

Earlier quoted context omitted.

> The emergence of cloud providers + hosted solutions and the ongoing disappearance of on premise computing means its increasingly hard to figure out a business model for infrastructure tech. The fact that open source works to the benefit of the largest providers of software-related services by commoditizing software itself is not new with the rise of the cloud as a new and popular domain of software-related services…

Licensing choices dont exist in a vacuum, they are made with a business climate in mind. I think many projects picked liberal licenses in a climate where the assumption was that you could make your money selling integration / consulting on top of the software. I think we are no longer living in that world. In this new cloudy world we need to find a way to fund the development of infrastructure software (databases / d…

> I think many projects picked liberal licenses in a climate where the assumption was that you could make your money selling integration / consulting on top of the software. I think we are no longer living in that world.

The anti-consulting provision in th Commons Clause license pretty clearly indicates that it's crafters do think that we are living in that world, and that (as numerous people have observed for at least a couple of decades) the advantage in that market with open source isn't necessarily with the developer but often with the entity with the most developed professional services organization and relationships.

> In this new cloudy world we need to find a way to fund the development of infrastructure software (databases / debuggers / libraries etc).

I don't think that's actually a problem, nor do I think that, to the extent it is a problem, the Commons Clause really addresses it in any general way. Software with such a clause ab initio simply would not get wide adoption in “the cloudy world” you refer to; what the Commons Clause aims to solve is the problem of ”how to capture revenue via technical lock-in after first building broad adoption through the attractiveness of open source when you as a development firm haven't developed the capacities that would leave you well positioned to capture associated services sales with open source”. But it doesn't seem all that likely to be successful in more than the short term, since it incorporates the main problems of classic proprietary software in the cloud domain.

Re: Commons Clause

#467

Earlier quoted context omitted.

At it's core, this is fundamentally about property rights. The owners of the Redis copyright are well within their right to license their property in any way they see fit. It's preposterous to you , but you're not the one who has spent the time creating Redis. It's preposterous to me that they wouldn't have the rights to govern their creation's use. You could go build your own infrastructure software, of course , tha…

Man, you are a smart guy. I know this, your posts are generally awesome. How in the hell do you think it's okay for them to try to ban consulting about a product ? That isn't "property rights", that's just...fuckery.

[deleted]

Re: Commons Clause

#468
post #302

Earlier quoted context omitted.

git is a good example. It's GPLv2, but that hasn't prevented it from being used to form a near-monopoly (github) for F/OSS, now bought by MS. Linux: used in the world's largest spynet (Android). Your joy and enthusiasm being taken advantage of for nefarious purposes.

>git is a good example. It's GPLv2 Is it a good example? I'm not very firm with licensing. As far as I understand it git is not a library or a programming language, which means that even if you use it commercially you're not really modifying or repackaging it in your software, so there's really no duties arising out of it even if you use it on your servers. Your software is just communicating with git. Please correct…

You probably have the term linking in mind to draw the conclusion that if you're merely exec'ing an external binary, this exempts you from GPL restrictions. But that term is used in the L(!)GPL to state an ok method of bundling your code along with the licensed lib. AFAIK, that GPL code is ok to bundle with proprietary software whenever GPL-ed code is invoked in a separate process, though heard frequently, has yet to stand in court, especially when said proprietary software is just a wrapper or web interface.

Edit: IANAL

Re: Commons Clause

#469

Earlier quoted context omitted.

At it's core, this is fundamentally about property rights. The owners of the Redis copyright are well within their right to license their property in any way they see fit. It's preposterous to you , but you're not the one who has spent the time creating Redis. It's preposterous to me that they wouldn't have the rights to govern their creation's use. You could go build your own infrastructure software, of course , tha…

Man, you are a smart guy. I know this, your posts are generally awesome. How in the hell do you think it's okay for them to try to ban consulting about a product ? That isn't "property rights", that's just...fuckery.

I made several comments without fully understanding the situation. I regret making those comments, but I don't regret my comments from being permanent now. When I'm wrong, I'm wrong.

I know someone who have had their life ruined by having their projects monetized out from beneath them by others; there is emotion behind those comments that shouldn't have been there. It happens to the best of us. I apologize for disappointing, and understand if I've lost your respect.

Re: Commons Clause

#470
post #406

Earlier quoted context omitted.

> There's the reflex (here and elsewhere) to dismiss reciprocal licenses such as GPL, AGPL as "uncool", pretentious, and show-stopping. They aren't uncool, they just have terms that lots of people have good reasons not to want to deal with, and which many devs don't want to impose on downstream (in part because lots of people don't want to deal with them.)

Who are those people that don't want to deal with a reciprocal license? Are they paying customers? Good, GPL and commercial dual-licensing is a thing, and thank them for their business! Are they people who would like to just use the software for their benefit, modify it to their taste and distribute , and keep the improvements concealed from everyone who made it possible? Tough luck, nobody promised them a free ride…

> Who are those people that don't want to deal with a reciprocal license?

My theory is: the HN crowd that hates reciprocal licenses are developers who dislike that they can't easily use that code for work - that is, their employers makes it hard for them to do so vs. BSD-type code. They care more about developer freedom (to integrate various pieces they feel entitled to), more than user freedom (to modify the resulting software).

Post reply on HN