MongoDB not FOSS

[Beanow]

MongoDB is used as an example for dual-licensing. However since their license change to SSPL they are no longer open source. We should comment this example is about the earlier AGPLv3 versions.

[Beanow]

See also: https://www.geekwire.com/2018/open-source-companies-considering-closed-approach/

And #42

[vsoch]

So you are saying that if "equivalent" software is provided under two licenses (perhaps coinciding with different levels of support) the software overall can't be considered FOSS? That seems reasonable.

I'm wondering - my understanding of AGPLv3 is that it requires all implementations to (if they change anything) also make the code open source. I also thought that once the license was set to that, the code couldn't just arbitrarily be changed and made some other license / closed source. Is that what mongoDB did, but justified it by keeping the original license (and creating a second?)

[Beanow]

The reason I'm saying MongoDB is not FOSS right now though is because of the SSPL for it's open source counterpart. It's a license they've created themselves, with stronger copyleft notions than AGPLv3 and submitted to OSI for review, but was rejected.

Most commonly, to be considered FOSS means using a license either the FSF or OSI approved. So using the SSPL would mean it's not FOSS by that definition. Whereas the AGPLv3 license is.

The dual-licensing model I think is not helping to create a Sustainable Free and Open Source Community. But that is my opinion, long comment with my train of thought here

A business built around a dual-licensing open source model and community may be a sustainable business. But a community relying solely on dual-licensing revenue of a founding company is not a sustainable community.

@adamhjk in the same thread seems to feel the same way in that PR discussion:

I don't have a bone to pick with dual-licensing as a business strategy: it has proven itself to be effective multiple times. I do think it's fundamentally incompatible with building a sustainable free and open source community, at least as I've defined it (because it fails both equal opportunity and the difference principle).

When it comes to changing licenses, from my understanding you're always allowed to change, so long as you hold the copyrights. Which you can hold by either being the original author, or having some kind of legal agreement to grant someone else copyrights. You can use a contributors agreement for this purpose. MongoDB requires that you sign one of these: https://www.mongodb.com/legal/contributor-agreement so they will have copyrights over all the source, and are allowed to change the license. It's also why they can do dual-licensing at all. Because they would need this capability to switch license to give paying customers a copy with a different license.

[vsoch]

When they announced the server license, my take was that it was a move to protect themselves - industry was making profit off of their software, and is that fair? There seems to be a contradiction between open source sustainability (how would you define this? Is it about finances or the community?) and open source culture. A "true" project might maintain FOSS but be widely appreciated enough to receive sponsorship. The community is sustainable given a large number of developers, and healthy culture. What happens when there is FOSS that doesn't get sponsor, and maybe is valued by many academics / other individuals? Is it like natural selection that the project is doomed to fade out and get replaced by something that figures out a better sustainability model?

It seems like industry is playing a role to change these (originally "true" FOSS) projects to protect themselves ("beat 'em") or follow lead ("join 'em"). I'm curious about three things:

1. how it could be possible for a project to be FOSS without doing something like MongoDB
2. why we are quick to label the move as "bad" - what if the landscape is changing and it's not something we can control?
3. How do we create definition and incentive to maintain the model we perceive as "good" ?

[vsoch]

Not entirely related to licensing, but here's an interesting related thing - https://it.slashdot.org/story/19/05/11/048233/mongodb-database-containing-over-275-million-personal-records-exposed-and-hacked

[themightychris]

I think that "good" in regards to dual-license FOSS should be centered around how practical the right to fork is.

I maintain a number of open-source projects that relied on the dual-licensed Sencha javascript framework. I never needed to fork the framework while the company was run by people who might have been supportive of it. Now it's owned by Idera, who recently bought out Travis CI too. Their actions thus far to me indicate no understanding of open source and no interest providing value to users beyond control of IP rights. It seems prudent to me and many others in the user community now to fork, as we have patches to merge into the framework's GPL version and there has been no indication Idera plans to make any more GPL releases.

The GPL supposedly grants me the freedom to fork this framework, but in reality the only freedom I actually having is throwing out all the work that depends on this framework and starting over. There is no legal precedent or statement from the owners I can rely on in regards to fair use of the trademark or APIs. Every extension and integration that touches this framework uses their trademark product names, and the Oracle v. Google hangs a cloud over mimicking an API. A community fork isn't economical if it can't be a drop-in replacement, and the community doesn't have the collective legal resources to resolve how to exercise their FOSS freedoms without any individual being exposed to liability they can't absorb.

So from my perspective, dual-licensed FOSS was a complete bait-and-switch. By merely doing nothing and staying silent, the new copyright/trademark owners effectively strip all users of their FOSS rights. Knowing more now I might insist that any dual-licensing scheme include a legally-binding guidance on how to fork and maintain drop-in compatibility within fair use. But even with that, under the shadow of Oracle v. Google is it even possible to be protected from a future IP owner blocking the practical path to forking?

[vsoch]

Gosh, that sucks. :( I knew about the acquisition of TravisCI (and the layoffs) but I didn't look further to the history of Idera. To what extent has this become something that looks like survival of the fittest? It seems like fittest / survival depends on being able to summon resources (people, legal and money) to sustain a project, and without that kind of backing, the ultimate fate of many FOSS are to fade away or get ingested by a company. It feels like a losing game, tbh, because success (a lot of times) looks like gaining users/community, getting corporate interest, and then being enveloped by it.

[Beanow]

With that experience in mind, what do you make of #42?

[vsoch]

I've been thinking about this - it's just a gut feeling, but my sense is that the future of (some) open source software is highly involved with business, and it will be both sustainable in community and resources via being commoditized. It might be the case that small (academic / science) projects would grow to a size to get attention by community and industry, and then naturally be integrated into one of these business models (dual license an option). The argument is that the commodization means that the software is maintainable but not the community, but maybe that's not the case. Maybe the maintainers and originally community are happy to have their work feed into a monetarily sustainable thing, and one that has enough eyes so that it can be served production across industry. It's like open source software starts as tiny fish, makes it so some worthy size and gets into an academy (one of these foundations with corporate support) and then graduates to production (and into a business model). Is that so bad?

I want to ping my colleague @brainstorm to comment on this - he has good real world experience.

[brainstorm]

I would argue that indeed is not so bad. I want that my work on infrastructure for genomics pipelines for cancer research get absorbed and used to help as many people as possible, for a profit or not is subject to political/ideological choices and I choose to just let go and move on.

A bit OT, but while reading your social contract, I also do not agree with one of the "in order to ensure a long (...) life for the software": Some software and practices do not deserve such a long life. Sometimes it should be killed with fire because it's legacy nonsense that holds research back, consumes time unnecessarily for many people, doesn't integrate well with modern systems or it just has excruciatingly poor performance.

And when I say software, I also say people and orgs holding on to "no, we don't want to change 10 y.o software because, meh, it just kinda works, right?"... just move on and let the industry pick up, optimise and commercialise what is inefficient because researchers are too busy and/or money-strapped to do that RSE work.

[Beanow]

Welcome @brainstorm :smile:

You're right we're going a little OT on several points here, my original idea for this issue was as a todo, we should mention MongoDB under the SSPL license is not free anymore. That became a broader debate on dual-licensing. Which is alright by me as it's an important discussion to be had!

You also raise an interesting point on longevity. But let's move that one to it's own issue. #74

Getting back to earlier points @themightychris

I think that "good" in regards to dual-license FOSS should be centered around how practical the right to fork is.

I think this makes for a good indicator that comes up more often, like https://github.com/sfosc/sfosc/issues/5#issuecomment-485144478. Maybe we should write about this topic. "The cost of forking" as a heuristic?

@vsoch I agree, a lot of current and future susainable foss communities will likely involve businesses. And don't think that's bad. I think the challenge is to make this a mutually beneficial relationship and not one that is great for the business, but very costly for the community. And currently I'm unconvinced the dual-licensing model offers that sort of relationship.

From the community perspective. it just appears beneficial for as long as the IP holding company feels like being a benevolent dictator to the community. When the waters change, the community gets the shorter end of the stick as if they're a byproduct instead of being an important relationship.

From the business perspective they may feel they've got their backs against the wall. This is the only route available to them that will satisfy the stakeholders and executives, while giving the community FOSS. I feel like most arguments defending the silver linings of dual-licensing are about that. This is something a business can actually work with and make viable.

[vsoch]

@brainstorm thank you for your perspective, it's (as I expected!) interesting and insightful. Political correctness says that I should not, but I can think of many projects that would best well go away. One might argue that they could do a flip and have drastic change, but it also seems like being "set in their ways" (even if it's no longer best practice) is a part of their culture that isn't likely to change. Arguably, these projects won't last because of both community and the software itself. Survival of the fittest is helpful here.

From the community perspective. it just appears beneficial for as long as the IP holding company feels like being a benevolent dictator to the community.

It's a bit like a promise, or creating trust between the community and company, isn't it? I don't think (outside) developers would devotedly contribute if they felt that the trust was broken. I think if a company sat around a table and talked about it, they wouldn't want to break the community trust. Actually, this is something we can inspect. In the case of MongoDB, in that the dual-license could be costly for the community, have there been obvious consequences (or does the community not realize it?) Has it even been long enough?

@Beanow what if we are in the middle of great change, and we just aren't at a point where we've even figured out how to do this. For example, we can discuss the dual-license up the whazoo, but only time will really tell how it will influence the community. The result will be used as a lesson to drive future decisions. Are we trying to predict the future and change it, or use known lessons from the past to direct it?

[Beanow]

Yeah, maybe I move too much into projections and rhetoric.

I don't know what side of history MongoDB Inc. will end up on. Or foss in general, or dual-licensing. I'll be watching with interest as it unfolds.

Though I will say, it's starting to look like I renounce MongoDB because of trading in liberties. Yes I'm worried about what it trades in, but it's also a bold move. Putting in massive resources to write the SSPL (which they say anyone is free to adopt), facing off with cloud providers and the flack of some of the open source community at the same time. And it already had me thinking about how the successes they've had with it so far could be applied for the greater good.

Then again I worry.

About VC tensions with foss.

Because this is MongoDB Inc. stock  And this is Elastic N.V. stock  MongoDB switch to a less free license in October 2018 and won revenue sharing deals with Google, _announced_ in April. The later result made a pretty impressive leap when you're a VC. Elasticsearch got forked by Amazon in _March_ when the open-core model got in their way. The os community now has great new Apache 2.0 licensed replacements for proprietary plugins to have at. But the company chart doesn't look quite so spunky.

About the liberties SSPL strips away. Specifically:

13. Offering the Program as a Service.

> If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version. > > “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available. As I'm not a legal expert I won't comment too much on the implications, but this looks like a very scary clause to me, designed specifically to make as-a-service infeasible without paying the company. A far cry from the empowering of others to solve their problems without nasty catches that I signed up for.

About,

The sort of trust dual-licensing with a for-profit, asks of the community

> It's a bit like a promise, or creating trust between the community and company, isn't it? Yes, I think that's right. In the tech world, the blockchain and decentralization communities show there's plenty of room for approaching trust in different ways. Seems to me, the way that trust is set up with dual-licensing, is that the business gets an _exclusive carte blanche_ to use the copyrights, including behind closed doors if they so desire. While the community is asked to get behind a belief it will be used in ways that will benefit all, most of the time, and if not, the license will preserve your liberties. A benevolent dictatorship, with the license as fail safe.

[fpesari]

Hello,

I personally don't think we can say that MongoDB is not FOSS if the "F" in FOSS has not spoken, the Free Software Foundation. I contacted them about the license and I hope they will be able to provide an official answer soon.