> 1/ No, Redis isn't proprietary. It's only some enterprise modules. The Commons Clause is mostly used to temporarily transition enterprise offering counterparts of OSS projects to source-available.
Redis itself remains under BSD. From the article:
> The Redis core is, and always will remain, an open source BSD license. Certain modules, however, are now licensed as “Apache 2.0 modified with Commons Clause.”
I think the parent agrees with you, explicitly referring to those modules as "proprietary" and "source available".
> Therefore, the no-sale restriction imposed by Commons Clause means that any software under this new license is non-open source by definition.
TFA plainly says that it isn't, "at least not by the official definition set forth by the OSD."
> I'm sure you can make up another word other than "proprietary" to call it…
TFA also answers this:
> "Applying the Clause to an open source project will transition the project to 'source-available'."
Also, the FAQ was added after I posted. Look at GitHub commits :)
That's worse because Heather would have certainly warned them of these issues, and it means they did it anyway.
She is neither good nor bad IMHO. Though depending on your viewpoint, she's lawful neutral, true neutral, or chaotic neutral :P.
She has both defended accused open source license violators and helped open source foundations defend against baseless lawsuits.
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). She's too good to have not advised them of these issues, and in fact, also probably advised them that the kind of response you have seen in this thread is a high probability.
But like any lawyer, when she is paid to advise, she advises. What people do with that advice is up to them.
Agreed on that, based on just reading one of her books. I wonder why didn't they choose AGPL.
https://github.com/RedisLabsModules/RediSearch/commits/maste...
> 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.
That is when you hire the lawyer!
They seem to be ready to go closed source, which they should have just done in the first place instead of behaving like they did. Adding the commons clause is just the tip of the iceberg - there is a very entertaining story behind everything that is happening. A single person, not a huge corporation, is behind this.
I will write a blog post about what happened/is happening in the upcoming months - complete with supporting documents such as FOIA requests, etc.
Granted, I think it's safe to say Commons Clause wouldn't meet the old definitions you mentioned, or please the people who wrote them. But I don't think it's my place, as a lawyer, to tell coders what "open source" should mean.
As for the old definitions, I've consistently overestimated how much devs care. Frankly, I've overestimated definitions focusing on license terms as a general proposition. Partly as a result, I've reassessed how I channel those projects, and my desire to belong among those invested in them, through my practice. Clients assume what I say is legally grounded. My job is to hear them and help them. Not to cite them under someone else's client's PR program, or scare them straight with the hiss of a hot "proprietary" brand.
Like anything, I do actually think it's reasonable to say "i understand the history of why things are the way they are now, but i want to see if they still should be that way"[1].
It may even be a reasonable time to see if that's the case given how much people have forgotten. It's been 20+ years since the last go around.
However, i do think ATM we will arrive at the same outcome we have in the past - after all the kerfuffles, i don't see things like the commons clause sticking. I also personally wish they would try innovative things, instead of old, tired things, but such is life.
Otherwise, yeah, i agree that pretty much no business gives a shit in the end about the licensing term difference between open source/free software/what have you.
I also agree that your job is to advise people. I do feel comfortable complaining about what they do with that advice, however ;)
[1] I don't believe most of the folks involved in this understand the history, but that's secondary.
I don't have great hope for Commons Clause, either, at least at the moment. But I've had a few think-throughs, and I've yet to hear from those whose views I really need to feel complete on it.
As for old, tired things, I imagine some still await their time, with a bit of adaptation. Changed circumstances and all that. But I will also hold your comment on "innovative things" in my pocket. Should the HN beast come lumbering after any more of my own little licensing experiments, I may need it!
I am all for that. Do you have examples of what you are thinking of here?
DISCLAIMER: Views expressed in this post are my own and do not represent my employer in any way.
Believe it or don't, no license, no matter how clever, will allow you to be financially successful if you blow the business execution.
Let's turn this on its head: what was the business plan that RedisLabs re-invented itself under? Was it a good business plan? Is is vulnerability to Amazon/MS that made it fail, or was the plan flawed from the start?
I've read messages on OSI's mailing list that if you have to ask how your're going to make money making open source, you're the wrong person to make open source, and ought to make proprietary software, instead.
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. And the source available and free non-commercial and selective commercial use, but negotiate a separate license for commercial use that we want to monopolize model is not an innovative solution to that problem, and generally isn't all that successful of a solution, especially as a switch for software which already has open source versions available that third parties can fork and commercially exploit even after the change.
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.
Granted: OSD, or rather the OSI-approved license list, rules in enterprise procurement at a particular and fairly common level of sophistication. At the same time, I've had conversations with sponsoring companies, prolific contributors, investment types, and others, mentioned OSD, received blank stares, explained, and then heard they don't care. Not relevant. Does not resonate. Different experiences.
I have never seen any good evidence to back your claim of a quiet OSI majority, except if you count open source consumers as an inevitable majority over open source producers, and ascribe the former to OSI. My own direct experience of open source licensing news and work has been a constant drumbeat of interest in refining and expanding licensing models. HESSLA. Fair Source. Now Commons Clause. Experiments. They're coming faster and faster.
Many of the folks advancing those proposals, like the one linked here, are also creating relevant software. From their point of view, claims that their work is "destructive" ring hollow, since they're constructing lots of code for others to use. They're especially irked by criticism in consumer-centric terms, like those of the OSD. After all, the OSD isn't a _license_ compatibility guide, but an _institutional_ compatibility list. It doesn't tell you which code you can get into an open project. By corporate handbook fiat, it tells you which code you can get into your company.
HESSLA and Fair Source both clearly state they are not open source, so I don't see how they go against rectang's point; the problem is not the existence of different models, but muddling the language to conflate them with the preceding one. That's essentially an EEE attack, and it's no wonder that existing OSS developers refuse to participate in it.
The push and pull between what doing open source is and what open source is supposed to mean has always gone two ways. If the status quo serves your needs, it's natural to cast "open source" as a rigorously bounded definitional category in the vein of "copyleft", and to downplay its social aspects. From a frustrated developer's point of view, it's natural to cast "open source" as a community first and foremost, and elide theory.
One point of view says, "We have this great definition to reference and rely upon, and you're trying to skim value and prestige off it." The other says, "We have all these people to celebrate and work with, and you're trying to claim their support while ignoring their needs."
Two extremes.
No restrictions on fields of endeavor and no discrimination is a pretty basic tenent that goes back a long long time (the DFSG were published in 1997, there are other things saying the same thing that pre-date it).
I also know this is what other open source lawyers are saying as well (in fact, i haven't seen one who believes it is anything else).
I'm sure you can make up another word other than "proprietary" to call it, but ...
As for questions: The main commons clause page makes the claim "Initiated by a coalition of top infrastructure software companies to protect their rights"
Care to list them?
Additionally, even ignoring the significant vagueness in the clause, there are plenty of combinations of licenses with which this clause makes literally no sense. It seems there is no guide or policing of these. Truthfully, this all does not feel well thought out. Who actually participated in the drafting?
Here is one that exists in practice:
neo4j is commons clause + AGPLv3
AGPLv3 section 7: If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term.
...
GPLv3 is identical in this respect, and LGPLv3 is a set of permissions on top of GPLV3 that does not revoke this clause.
This seems to make commons clause incompatible with a lot of software.