IMO, it's not really open source if its run by a company that will eventually use its position to squeeze its users for cash.
I know it's not as popular or sexy as it used to be, but the whole point of a foundation like Apache was to avoid these situations, even more than the way the Linux Foundation is setup. Apache _explicitly_ manages projects to avoid these downsides.
- Single corporation ownership. Projects cannot get out of the Incubator unless they demonstrate a diverse and healthy community. That doesn't mean popular, it doesn't necessarily mean best-in-class, but it means that there shouldn't be just one entity backing a project.
- Membership in Apache is _personal_ not a seat for a given company. If you're a committer on an Apache project and you move jobs, you're _still_ a committer on that project
- The Foundation owns the trademarks. There have been fights about this in the past, but the whole idea is that the _community_ owns the name, so some corporation can't claim to be the sole or official owner by naming their company or product after the open source product.
The core premise of the Apache Software Foundation is community over code, that healthy, diverse communities have a better chance of standing the test of time than open source projects backed by a single individual or company. That's the thesis at least.
The is starkly different from several other foundations, notably the Linux Foundation or Eclipse Foundation which are modeled more around industry consortiums.
Both models have their place, but I believe Apache better models the core values many of us feel strongly about when it comes to free and open source software.
And when was Apache more popular? I thought it was the uncool place where stuff was written in Java, that became popular because people's conception of Java (and the language/ecosystem itself) changed.
I also think the popularity of the Apache license is part of what makes Apache popular.
> I thought it was the uncool place where stuff was written in Java
They have lots of projects running on the JVM, but “written in Java” isn’t a requirement, nor is “running on the JVM”. See https://projects.apache.org/projects.html?language
it's all volunteers/open source, but this isn't an ASF project.
I'm gonna go embarrasingly delete this thread tail between my legs...
I actually prefer the approach of LF, EF or CNCF where it's transparent where folks work for and your affiliation is disclosed upfront. In the CNCF for example, we separate out technical project decisions (maintainers) from funding decisions (members). That is healthier than blending it all in one at the ASF imho and having no idea where person is working for imho.
I can see it has some disadvantages for companies incorporating GPL software in their products, but none for companies merely using GPL 3 software.
If I had to guess - The patent rights clause weirds out a lot of lawyers. Obviously anyone who works with hardware doesn't like the anti-tivoization clause. Another possibility is the AGPL (which IS lethal for obvious reasons) is often conflated with GPLv3.
All I know is GPLv2 is fine, GPLv3 is usually not, and AGPL is never possible in corporations that I've worked for.
> I can't say for certain why they can't use GPLv3 - just that no company I've ever worked for (n=4 since GPLv3 came out) - will allow it on premise
So they do not allow the use of things like Bash or GNU coreutils? That seems quite restrictive and difficult.
Apple is different as they produce their own OS. I am asking about non-software companies avoiding GPL3 which would be necessary for (as the comment I responded to earlier in the tread claims) the use of GPL3 providing a motive to pay for licenses for dual licensed software in a way GPL2 does not.
In the context of the thread (the claim GPL 3 provides more of a motive for people to by paid licences for dual licensed software) I think that "small refinement" covers most of what we are talking about though.
I feel out of touch
Why?>
The AGPLv3 is exactly the same as the GPLv3, except with the added clause that connecting to a server counts as distribution for the purposes of triggering the right to obtain source code.
That means all the usual GPL copyleft rules apply: if you include an AGPL library in your server binary, the entire binary becomes subject to the AGPL. And being subject to the AGPL, you are obligated to provide access to the source code for your entire server binary to anyone who connects to and interacts with your service across a network.
Quoting from https://www.fsf.org/bulletin/2021/fall/the-fundamentals-of-t... :
> Simply put, the AGPLv3 is effectively the GPLv3, but with an additional licensing term that ensures that users who interact over a network with modified versions of the program can receive the source code for that program...
> These terms cover the distribution of verbatim or modified source code as well as compiled executable binaries. However, they only apply when a program is distributed, or more specifically, conveyed to a recipient...
> The AGPLv3 does not adjust or expand the definition of conveying. Instead, it includes an additional right that if the program is expressly designed to accept user requests and send responses over a network, the user is entitled to receive the source code of the version being used.
It is "dual licensed". AGPL and proprietary license according to Wikipedia
I am unsure how that works...
Oracle
From the FSF’s licensing FAQ:
> Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
Eben Moglen wrote a little about the intent here [0], I'll excerpt a little:
"This form of explanation was unfortunately unhelpful. It led to years of fruitless discussion about the role of “derivative works” doctrine (a US concept) in software (where US courts have largely failed to provide any guidance). So in GPLv3, we and our clients at the Free Software Foundation decided to drop all illustrative reference to US “derivative works,” returning to the base concept only: GPL covers the licensed work and all works based on the work, where “based on the work” is defined as any modification or combination with the licensed work that requires copyright permission to make."
I don't know if that broadens or narrows, but I think that's the point: case law on "derivative works" was pretty vague (I'm unfamiliar but I'll take Moglen's word). But, to me it sounds like an effort to be more concrete rather than an effort to broaden the conditions under which you have release obligations.
> From the FSF’s licensing FAQ: ...
A couple things.
First, this FAQ entry is about aggregation; the paragraph above what you quoted is this:
"An “aggregate” consists of a number of separate programs, distributed together on the same CD-ROM or other media. The GPL permits you to create and distribute an aggregate, even when the licenses of the other software are nonfree or GPL-incompatible. The only condition is that you cannot release the aggregate under a license that prohibits users from exercising rights that each program's individual license would grant them."
This isn't some kind of "I run a Kubernetes cluster" situation, it's a "I ship a Linux distribution on ISOs" situation.
Second, I was in a different GPL thread [1] discussing some similar things, but all contracts, licenses, statutes, and founding documents have ambiguity in them. I listed a couple reasons (authors can't/don't want to exhaustively enumerate every scenario, human language is imprecise) but I realized I omitted a third reason: times change. You generally want whatever you're authoring to last a little while, not only because legal fees are expensive, but also because relicensing isn't always easy (GPLs have clauses in them letting you additionally license them under any later version, I would assume this is why).
And finally, there's a real double standard--or at least cargo culting--when it comes to the GPLs here. Here's some ways other licenses are ambiguous or potentially unbounded in their coverage:
- Apache License version 2: refers to "derivative works", also: "'Object' form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types." (i.e. does minification count?)
- BSL: also refers to notoriously vague "derivative works"
- SSPL: defines propagation partially with the phrase "in some countries other activities as well."
It's true the GPLs are more complex and ambitious than something like the ISC license (the favorite comparison around here, I think) but that license is something like 100 words. It's not comparable.
[0]: https://softwarefreedom.org/resources/2014/SFLC-Guide_to_GPL...
AGPL is not a problem for server-side software if you don't need to modify it. Your application (talking to the server) doesn't become infected by AGPL.
My limited experience with IP lawyers at big software companies is that they have zero understanding of software licensing and patent law. They just seem to parrot some line they learned in college 10 years ago, even when the plain text of the license or law sitting in front of them proves them wrong. It's honestly baffling how they get these jobs.
Otherwise it works great for end-user adoption.
Richard Stallman himself doesn't seem to make money from any software he made directly, but from various grants and such, for example:
https://web.archive.org/web/20220123032418/http://tech.mit.e...
I thought he was on the payroll for FSF, but his reportable compensation has been zero from 2002 to 2022 according to:
And is also subject to survivorship bias. For every OSS project that makes it, tens of thousands do not.
As a developer, I don't want to rely on code from a project that "seems particularly profitable", because one day it's 100% certain they're going to start making their profit off me.
I'm _extremely_ wary of any "open source" projects that're VC funded, because the entire VC industry exists to make rich people richer at everybody else's expense, throwing a few bones at a few of the founders and a vanishingly small portion of the startup employees. As soon as they think that can get away with it because they have enough "free" open source users locked, they're gonna turn all the screws to chase the "100x or bust" exit strategy the VCs rely on. At the expense of everybody who foolishly built something on to of that project without an easy way to replace it.
As an alternative to working on a second job to fund their passion, we are seeing developers trying various things to make their one passion job pay, such as licensing tweaks or VC funding. These don't seem to work out very well, I think it's best explained here:
https://apenwarr.ca/log/20211229
"So it is with free software. You literally cannot pay for it. If you do, it becomes something else."The problem is that these conditions do not always prevail.
I used to think this was fixable: https://pietersz.co.uk/2009/11/fix-capitalism
I now think it is more complex and we need a mixed economy.
Eventually, on the free market there are winners, and these winners form a monopoly. See Nestle, Tyson foods, Apple. The big corps, having cornered the market, then squeeze the hapless users (and the ecosystem, in Apple's case) into exorbitant prices, because there is no competition. You started with your beloved "free market", ended up with a monstrous monopoly. Surprise, this is how any "free market" story ends.
If you want to avoid the trash situations that we are in today, you need to regulate the shit out of companies with antitrust, breaking them down when they become too big, not allowing them to acquire others under certain conditions and forcing them to treat their workers and customers well. This is the opposite of "free markets", and is the only way if you want a stable society.
you're just seeing survivorship bias.
Plenty of them would've also disappeared, because their core contributor no longer wanted to give out free labour and moved on.
He resigned in 2019 following allegations of inappropriate behavior towards women (https://news.ycombinator.com/item?id=20990583).
In my opinion, Stallman has been proven right many times over.
However, increasingly more and more services which could've been an on-premises deployment become SAAS. This includes games (live services they call it). It is _designed_ to end, and designed to not be able to run locally.
Tell me who's the greedy one.
- Prevent piracy
- Extract more money per user (subscriptions, repeated purchases in-game)
Look, you can live perfectly fine without all of those services, there are indie games and there are old games and, according to some, they're much better than any online crapware from today.
Make it a point not to buy Free to play online crap, forbid your kids from playing that crap. Absolutely don't give them any money for this crap.
If enough people stop buying the we'll see a shift to the DRM & no hassle approach of indie games. I'd also prefer giving my money to a small team of devs than some corporate ladder who happend to purchase the latest AAA game built by a studio of overworked and underpaid devs.
2. Need revenue to pay for the Cloud services.
3, Charge mouse users for the Cloud services.
It's the (stupid) circle of life.
https://arstechnica.com/gadgets/2024/07/logitech-has-an-idea...
Probably would only delay the move to the cloud a little bit, and perhaps make AI less capable.
An example of a project making it optional is GCC itself: https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html
I highly doubt that the FSF, who developed the GPL licenses and values free software above anything else, would change the licensing of their projects like "these companies" do.
It will be even worse after the GPL developer generation is gone.
Sure <VC funded editor company> can have people spend years of their life working on something, but release it as open source because VCs are paying for it, and that leads to more mindshare, but it leaves a bad taste in my mouth. Similar reasons to not use VSCode (commoditizing the complement by using billions of dollars from other products).
The "must be open source (I think they actually mean free as in $$) at all costs" crowd baffles me because the money to support the humans creating the software in the real world doesn't just magically appear.
Many c/C++ libraries are not open source - even more .Net ones
But if you open source your revenue-generating parts, and only charge for support/managed version/enterprisey features you'll end up with quite weird incentives, particularly with infrastructure tools, in which the big cloud providers will happily compete with you, using the version you open sourced and providing and ecosystem to their customers that one simply cannot compete with
There are still native shops that rely on very little open source, though at this point probably only in niches like gamedev or defence.
Defense is a weird place, but open source is used quite a lot there, it's often required to do so and to record the open source consumed to produce a product. And often times, it must be commercial open source where you can get engineering support for the lifetime of the product's existence.
EDIT: as another commenter wrote below, OSI is driven by massive cloud vendors, who have a vested interest in having their freedoms to take projects and monetize them. Perhaps a somewhat restrictive license isn’t a bad thing.
[1]: https://www.apache.org/foundation/license-faq.html#IsItFree
[2]: https://www.apache.org/foundation/records/incorporator.html
It seems a little short of the claim in their FAQ though, but it's something:
> The purpose of the Corporation is to engage in any lawful act or activity [...] including the creation and maintenance of "open source" software distributed by the Corporation to the public at no charge
The reason for the "any lawful act" language is to allow the ASF to do things like run a conference, accept donations, sell t-shirts and other activities. If the statement was only "develop open-source software" there are all kinds of important activities that support open source development that would be impossible.
The fact is, however, that certificates can be changed by the people who can vote. IN the case of the ASF, the members are the ones who vote. Getting those ~800 members to radically trash the traditional goal of the foundation is not going to be possible as long as the current membership is active.
Their FAQ says "all software free no exception" and this document says something weaker.
> anytime you see a CLA, you see the true intentions of the project. A project that will always be FOSS won't have a need for a CLA.
If there are conditions to the statement, it isn't "anytime you see a CLA".
Many CLAs are just a hassle (basically, DCO that has to be reviewed by the legal department). But a lot are asymmetrical in a substantial way and the original developer gets to play by different rules than the rest. CLAs in the second category tend to be problematic.
Even that is not a completely clear indicator because in some cases, the asymmetry is only intended to help with potential future relicensing in alignment with the project's goals, and not to enable commercialization (either today or at some point in the future). Some organizations have resisted direct commercialization of the code they have been entrusted with for decades, so that can happen even with an asymmetrical CLA.
CLA = Contributor License Agreement
For many contributors, they're ok giving full ownership of their contributions to a project owner on the owner's terms. Some contributors may not be ok with that of course, but it doesn't mean that every project owner has nefarious plans with said code ownership.
And that's why "open source" is a really bad term that no one should use unironically, unless they want to confuse the hell out of people.
There are protective (copyleft) licenses, and there are permissive licenses - and they're very different beasts. And it's, like, software licensing 101.
> that want to go from LGPL to MIT or something
I find this extremely weird.
In a sane world, picking a copyleft license must mean that you care about user freedoms and want to make sure they're respected no matter what happens. Because that's the whole point of picking a copyleft license - not about letting people peek or tweak some code, not about social brownie points, and most certainly not about marketing campaigns - but about granting users their freedoms.
Either people get confused about "open source" and pick... I don't know, whatever looks cool, without even understanding what they're doing; or they're giving up on their principles when they smell the money.
I can understand wanting to go from, say, GPL to AGPL, or GPLv2 to GPLv3[+] - it would make sense, as it all goes in line of protecting freedoms. But LGPL to MIT is truly a weird one.
Copyleft licenses were the default choice at some point in time, but then in the '10s most big projects seemed to pick a permissive license, and many switched.
However, I thought about it and I think I can get the cases where monetary opportunities started to outweigh what's essentially are political ideals. Happens all the time, heh. I guess I can imagine person not being honest with themselves until the temptation really comes. Especially if it's about casual developers trying to have some money to live comfortably (as opposed to lowering their standards of living), rather than getting rich.
I can only hope it's that and not a simple ignorance.
This is a personal bias and disregards others' definition of true do-whatever-you-want freedom. Different project owners may think differently on what free means and alter the license to respect their principles (and may consider copyleft to be the restrictive/anti-free mistake made early on based on these same kinds of personal biases).
And many contributors don't really care what the project owner does with their code and the CLA lets them delegate responsibility.
People who value attention over principles are known as "pick mes" apparently.
unless the corp owns the rights, they cannot "close it", nor take away everyone else's freedom. The old version that was open source licensed is always going to be available.
Unless you're talking about the additions these corporations made, which they keep closed, and charge you for it. But if they are able to charge for it, they deserve it.
This is an extremely black-and-white view. If I make a competing product to you and it’s superior to yours, then yes, I deserve profits (though of course consumers may still choose yours for a litany of other reasons). If a trillion-dollar corporation becomes a competitor, that’s not exactly fair. They can, if they want, spin up an entire team dedicated to the product, and by sheer numbers, they will win. Is it legal? Yes. Is it ethical? That’s subjective.
Someone who is has a strong preference for copyleft licences may not want to contribute to a project with a permissive license.
The intent may not be for the project owners to use the code in proprietary software, but it would be to allow someone to do so.
However that would also mean that the core project couldn't accept your changes without the CLA since that would also bind them to never switching the license or relicensing your contributions for an enterprise license.
... I think. My head hurts when trying to consider the implications for CLAs and AGPL and the endless debates that lawyers could have over this.
There's this balance between being a project forever run out of someone's garage and actually growing into a larger and more used system. I'd say the line is dilineated by many factors: who is the project's primary user? Enterprise? Devs? How much money is changing hands? What's the business model? Is there investment involved? How restrictive is the primary license? How restrictive is the CLA?
I think any open-source project that has aspirations to actually make money for the creators is shooting themselves in the foot without a CLA. And it's fine to judge them for this, but we live in a system where people have to extract value out of this shit even if it's against their ethos.
If people truly and ultimately believe in open-source, then the most logical conclusion is that capitalism does not allow for open source and that must be changed. Fighting things at the license level can only delay the inevitable. But people want to have their cake and eat it too: "I want the system to stay the same AND I want open-source creators to keep pumping out stuff for free forever."
Good examples are React from Facebook, and TypeScript from Microsoft. Both require a CLA. But these projects are never going to go closed-source. They are complements to the companies' core business strategies.
What you say is true in that you shouldn't view a VC backed opensource offering as 'permanently' opensource by the same group.
Many things would have to be re-added from scratch in a fork.
CCL, BSL = "source available"
Apache = open source
Parts of CockroachDB under CCL that do NOT transition to Apache OSS: https://github.com/cockroachdb/cockroach/tree/master/pkg/ccl
> the sub-tree under pkg/ccl is under a different license (CCL) that does not transition to APL2 after a set duration.
They are still pretty limited compared to what's in the enterprise version, but it's not right to say basic backups are closed source and have never been there.
CCL, BSL = "source available"
Apache = open source
Parts of CockroachDB under CCL that do NOT transition to Apache OSS: https://github.com/cockroachdb/cockroach/tree/master/pkg/ccl
> the sub-tree under pkg/ccl is under a different license (CCL) that does not transition to APL2 after a set duration.
> Source code in this repository is variously licensed under the Business Source License 1.1 (BSL), the CockroachDB Community License (CCL), the MIT license, BSD-style licenses, and other licenses specified in the source code. Source code in a given file is licensed under the BSL and the copyright belongs to The Cockroach Authors unless otherwise noted at the beginning of the file.
Is the caveat in this part (that I didn't catch before)? "Source code in a given file is licensed under the BSL and ..." That is sucky.
[0] https://github.com/cockroachdb/cockroach?tab=License-1-ov-fi...
If cone entity does the development, they can change direction or licensing and it is hard for anyone to fork.
If you have more of a bazaar form of development with many contributors neither is as easy (even less so if you do not have a CLA). Even if you have a small core team of developers, a really bad direction is likely to lead to a split.