1. 14
  1.  

    1. 16

      Moreover, we have been the single significant contributor of the source code. Our ecosystem tools have received a healthy amount of contributions, but not the core database. That makes sense. The ScyllaDB internal implementation is a C++, shard-per-core, future-promise code base that is extremely hard to understand and requires full-time devotion. Thus source-wise, in terms of the code, we operated as a full open-source-first project. However, in reality, we benefitted from this no more than as a source-available project.

      I’m assuming since they’re making this move they had all contributors to their AGPL-licensed repo sign a CLA. Makes sense nobody would want to invest at least a year learning to contribute to a codebase where their work could then be yanked away, as it was here.

      Anyway it’s fine, this is just businesses doing business things. Revenue in the FOSS world is a strange game. Maybe they’ll succeed enough to then eventually use a viral FOSS license again, although unless they then get rid of the CLA nobody will want to contribute to it.

      1. 7

        I don’t know that CLAs are much of a deterrent to outside contributors. It feels like many FOSS projects have CLAs, even if they have no associated business. The stated justification is usually to avoid relicensing problems from one FOSS license to another, if the need arises, since you don’t have to track down dead/missing contributors.

        Ultimately, I think the solution to free-riding at all levels is something like Attribution-Based Economics, where monetary payouts are distributed based on repo contributions, regardless of whether you’re an employee or not. But that’s a huge undertaking, and afaik, nobody outside of a few people in the Racket community have ever tried building something like it.

        1. 25

          CLAs completely undermine the GPL. It’s like encryption with a backdoor. It’s only a matter of time until it’s exploited, every single time. The stated justifications don’t matter because they are completely detached from what actually happens. People who develop GPL code and license it under some entity’s CLA need to be aware that they perform unpaid labor for that entity. Their code can and likely will end up in unfree software. If you are okay with that, it’s fine. Just don’t be surprised.

          1. 7

            This situation, repeated again and again, is why Pieter Hintjens put the following into his C4 (Collective Code Construction Contract) standard:

            2.2. Licensing and Ownership

            1. The project SHALL use a share-alike license such as the MPLv2, or a GPLv3 variant thereof (GPL, LGPL, AGPL).
            2. All contributions to the project source code (“patches”) SHALL use the same license as the project.
            3. All patches are owned by their authors. There SHALL NOT be any copyright assignment process.
            4. Each Contributor SHALL be responsible for identifying themselves in the project Contributor list.

            That 2.2.3 is critical — an RFC 2119 SHALL NOT, a hard requirement of C4. Pieter wrote, in the ZeroMQ guide:

            Here we come to the key reason people trust their investments in ZeroMQ: it’s logistically impossible to buy the copyrights to create a closed source competitor to ZeroMQ. iMatix can’t do this either. And the more people that send patches, the harder it becomes. ZeroMQ isn’t just free and open today–this specific rule means it will remain so forever. Note that it’s not the case in all MPLv2/GPL projects, many of which still ask for copyright transfer back to the maintainers.

            I have been turning a related problem over in my mind for some time — I have aspirations to write something that needs to remain Free Software so that it can participate in bootstrapping chains, but the experiments I’m looking at might also make it attractive in its own right. Such a project seems to have the greatest chance of success if the number of external contributors is maximised, and a strong licence like the AGPL may scare away too many.

            I can’t think of a licensing scheme that gives the project a way to offer ad-hoc licenses for the good of the project (e.g., to fund further development) that does not also make the project weak to the relicensing rugpull. Maybe an actual lawyer could invent some clever scheme, where some separate legal entity holds the copyright (including copyright assigned by contributors) and certain individuals are allowed to direct that entity to create and re-licence snapshots of the source tree. But I don’t know enough to dare try.

            I am currently thinking that GPLv3+ and “no copyright assignment” is the best balance of external understandability, likelihood of attracting contributors, and ease of compliance for a project like the one I alluded to. GPLv3 does not look to me like it goes far enough in its anti-anti-circumvention provisions but it’s something, and AGPLv3 seems to scare a lot of people away. Having capabilities that are only available to the Free Software ecosystem makes it attractive to participate in, and I don’t think a BSD/MIT/X11/ISC-style licence would achieve that.

            1. 3

              I am currently thinking that GPLv3+ and “no copyright assignment” is the best balance of external understandability, likelihood of attracting contributors, and ease of compliance for a project like the one I alluded to

              I worry that in the future, there will be a hostile takeover of the FSF, which would open the possibility of a much weaker GPLv4 which all GPLv3-or-later licensed code could be “upgraded” to. Especially after all the Stallman-bullying that has been going on over the past couple of years, I have lost confidence that the organization and indeed the free software community itself is equipped to deal with the pressure in the long-term or can be trusted as a steward of this kind of power. I think this is a much bigger threat than being stuck on a particular GPL version. Hence, it might be wise to license GPLv3-only.

              1. 3

                You can specify an alternate license steward when using or-later

            2. 5

              You can always fork without a CLA. Open source is a do-ocracy. People who do the work have power. See what happened with the forks of TerraForm (OpenTofu) or Gitea (Forgejo). People used their power there. Users don’t have power in open source unless they pay money.

              1. 2

                Sure a fork is possible based off the final AGPL release, but that requires a knowledgeable development community to have already formed around the project or for the value proposition to be truly unique (there are a good number of FOSS databases already). And the formation of such a community will be hindered by the presence of a CLA, because the community cannot control when the rugpull happens. If it happens before the community reaches critical mass then it just gets killed.

              2. 4

                People who develop GPL code and license it under some entity’s CLA need to be aware that they perform unpaid labor for that entity.

                Ironically, this is the same rationale many (formerly) FOSS companies give when moving to source-available licenses. They paid to develop it, but AWS treated it as unpaid labor for their competing service. Just a hierarchy of exploitation.

                Regardless, I suspect that if devs became allergic to CLAs, more companies would choose going proprietary over FOSS.

              3. 2

                The stated justification is usually to avoid relicensing problems from one FOSS license to another, if the need arises, since you don’t have to track down dead/missing contributors.

                That’s the point, the non-CLA-covered contributors form a durable distributed network preventing the rugpull.

                If it’s just some kind of trivial project then a CLA doesn’t matter, I’ll contribute to it to get a feature I want for however long the project is open source, whatever. But some codebases are just very complicated and take a huge amount of time investment before even minor changes are possible - you can’t just do the thing you want to do, you usually have to do a bunch of smaller warmup tasks to learn how things work first. That’s where you start caring about a CLA and whether you’re just being taken advantage of.

                1. 1

                  Maybe I should have put “stated” in quotes to indicate that I don’t believe in that justification. Too late to edit.

                  1. 1

                    Alas it did override the second part of your post! I had never heard of attribution-based economics.

                    1. 2

                      Ah, well, chalk it up to a lesson in textual communication.

                      ABE is a really interesting idea! Here’s links:

              4. 4

                I’m assuming since they’re making this move they had all contributors to their AGPL-licensed repo sign a CLA. Makes sense nobody would want to invest at least a year learning to contribute to a codebase where their work could then be yanked away, as it was here.

                Do we think this is a significant cause of non contributors? It seems to me that even if there weren’t a CLA, the number of people skilled enough and willing to invest that much time into contributing would be vanishingly small (barring some sort of pay through their employer).

                1. 3

                  Building a community of FOSS contributors is very difficult. It requires substantial investment; companies can do things like:

                  • Do as much development in the open as possible, on the public mailing list or issue tracker
                  • Hold monthly virtual community meetings/office hours with the core dev team
                  • Timely response to questions and PRs by contributors by the core dev team
                  • Serious investment in documentation, conceptual tutorials, and other written onboarding materials
                  • Creation and broadcast of mentorship programs
                  • Cultivate a contracting ecosystem where contributors can make some money through occasional contracts with companies that use or want to use the project
                  • Actual cash development grant programs

                  Without these, for complicated projects like a database you’re basically just waiting and hoping a senior-level semi-retired software engineer wanders past all the other FOSS projects pining for their time and stops at yours then perseveres (for free!) through the development process through sheer force of will or some kind of passion for the project.

                2. 5

                  I honestly don’t understand why anybody would contribute to a corporate owned open source product, unless they were getting paid to do so for work. Especially not for a backend product like a database. “Let me help you make money, while I work for free,” doesn’t make any sense at all.

                  I can see why people would contribute to something like VSCode, because they can use their changes themselves, but even then I’d rather work on a hobbyist project like Lem.

                  1. 7

                    I think the ideal copyleft state is something like Linux: several corporations who want the software to work, each of which with specific needs driving their contributions (e.g. they manufacture their own hardware, they need to support the software). In this case, copyleft ensures a fair playing field for everyone.

                    But yeah, working for free for a corporation who can one day decide to close up your contributions seems silly.

                    This is why we’re hoping that jujutsu drops its Google-mandated CLA. Personally, I would like it to be on the GPL like git itself.

                    1. 2

                      Doesn’t really apply here and I’m certainly no fan of CLAs, but “I spent 3 days investigating this bug, might as well spend another couple hours to contribute the fix” is a thing. I suppose that’s how most people who are averse to CLAs still end up contributing small things, and then maybe once the bureaucratic hurdle is gone…

                      1. 2

                        I just don’t contribute my patch if I’d have to sign a CLA. If it really is trivial sometimes I’ll try to find someone on IRC who has already signed it, and assign ownership of the work to them so they can submit it as their own.

                    2. 7

                      This write-up seems to carry the implication that “open source” projects are not a source of revenue, as a fact of the universe. The financially-successful free software projects out there disprove this implication. It’s hard to see this as anything but a company that paid lip service to software freedom getting bored of doing so, as has happened so many times.

                      1. 12

                        Are there so many? When I think about this, the most successful OSS projects “financially” IMHO are indirect, like services, long-term support, etc.

                        The bait and switch that these companies do bothers me. But I kinda think that companies being straight about CLAs and “source-available” instead of “open source” is fine. I will still avoid source-available software if there’s OSS alternatives, but I don’t mind signing some CLA occasionally to send a small fix, even if I’m doing some work “for free”, I do still get some value from that source-available software. (And this is more true at work; it might make more sense for my employer to use and contribute to source-available software.)

                        1. 1

                          I moreso mean that it seems like there was not even an attempt made here to monetize the “open source”ness of the product, it’s implied that their business was structured with proprietary code in the revenue-making column and “open source” code elsewhere.

                          If that’s how one chooses to structure a business it isn’t the nature of free software’s fault when eventually the suits decide to cut the free use out of the model.

                        2. 11

                          Can you please list a few of these successes, because in my experience there are not many. I was once employed to work on OSS full-time and while I really liked it, the company ultimately failed because the people that succesfully used our stuff saw no reason to send us any money. Making money with OSS is really hard.

                          1. 2

                            Making money is hard. OSS doesn’t really make it easier or harder (it may do either, depending on context, overall it’s a wash.)

                            Conversations.im is a well known example of a very “direct” business model (sell the app), but I don’t think companies like JMP or sourcehut are less legitimate because the main thing they sell is “a service” since after all most nonfree stuff makes money by being saas these days also…

                            1. 2

                              Conversations.im is a well known example of a very “direct” business model (sell the app)

                              Looking at the repo this is a company and product with a single developer. Successful or not, this is literally the smallest possible software company, as it has a single programmer. Sourcehut also afaik has a couple (handful?) of programmers only.

                              That does not mean there’s anything wrong with these companies of course, but surely you can’t use them as examples of “the big successes of the open source model”.

                              1. 2

                                I guess it depends on the kind of success one is looking for?

                            2. 1

                              SourceHut is the premiere example these days.

                              1. 4

                                A company employing a handful (less even?) of people is the premiere example?

                                1. 1

                                  Sure, if you’re looking for quality.

                                  If you’re looking for quantity then I guess Mozilla, Wikimedia, Red Hat are some of the common examples?

                                  1. 1

                                    Wikimedia is not a for profit, Redhat is IBM and Mozilla is also not a classical company

                                    1. 3

                                      Maybe it would be easier to find an example that meets your criteria if you could describe your criteria a bit.

                                      1. 1

                                        How about a company that makes a product and sells it and/or services, that does not live off of donations or advertisement deals and employs more than a handful of people. You know, like any other company outside of IT

                                          1. 1

                                            that is a good example, indeed

                                2. 2

                                  I’m not super familar, but I thought the business model of SourceHut was selling the service itself, or is it something else?

                            3. 3

                              It makes sense given where Scylla operates. Like it’s a great tool, but it is a tool for a pretty specific workflow. You need:

                              • massive scalability with high read/write throughput
                              • don’t care about complex relational queries
                              • are comfortable with tunable ACID compliance
                              • multi-region workloads to start

                              If that’s you, an OSS product is probably not bringing a ton of value outside of being able to see the code to help debug problems. Like you are already running a pretty complicated stack and are unlikely to migrate to an enterprise product for support. So a license change makes sense to me.

                              1. 7

                                If that’s you, an OSS product is probably not bringing a ton of value outside of being able to see the code to help debug problems. Like you are already running a pretty complicated stack and are unlikely to migrate to an enterprise product for support. So a license change makes sense to me.

                                Yeah, I’d prefer a source-available license over totally proprietary. I don’t care to compete with you, I just need to fix it when your product breaks.

                                1. 1

                                  You don’t need massive scalability, multi-region, or comfort tuning consistency (only) to benefit from it, it’s also just a good DB.

                                  For example it can traffic handle spikes far better than something like Postgres, and it will keep way lower single-region latencies than other DBs as well, esp when tail latencies matter.