So if you simply use something without modifying it, you have nothing to do.
It's pretty well understood that non-GPL software cannot link to GPL-licensed libraries, which is why the LGPL exists. This is true even though most software doesn't need to vendor or otherwise modify upstream libraries.
Or does AGPL have a special carve out for this, different from the GPL?
But in the section that is the difference from GPL (section 13, "Remote Network Interaction"), it clearly states: "if you modify the Program, your modified version must ..." [emphasis added]. So the extra stuff that differentiates AGPL from GPL applies only for modified versions of the software.
For the rest, usual GPL stuff applies: if you distribute the binary, you must make the sources available, etc.
Vitality comes from the way you combine this AGPL code with other code and how you can’t change the license of modified Plausible CE, or the thing you build using Plausible CE.
If you modify Plausible, you distribute the modified version. If you build something using Plausible, you distribute the thing, and with AGPL license. That’s it.
This doesn't make your site as a derivative of Plausible, but you're installing Plausible as a different tool, independent from your site.
Like installing a GPL binary doesn't make all BSD licensed binaries switch to GPL license on your system, running an AGPL licensed service on your server which communicates with your site doesn't make your site AGPL automatically, because you're not deriving Plausible, but you're installing and using it.
Now, if you want to build a service/website by directly modifying the Plausible CE source code, you have to open that derivative codebase with AGPL, only if you're redistributing the modified code (i.e. making the modified website available to other people). If you modified the code, but you're not distributing it (i.e. Only you're using it yourself), you can keep it to yourself.
No, you don't. Folks pick AGPL because of the FUD/uncertainty around it while still appearing "FOSS". In reality these companies don't have the legal teeth to back the bark, otherwise they'd go BSL and make their intention known.
Before folks reply with whataboutism, no one has ever successfully proven the AGPL infectiousness to other web applications in court. Positing about it on hear is pointless.
Or alternatively, they still want to be FOSS, which AGPL is, but BSL isn't.
This gets exploited all the time when companies use FOSS licenses to get traction, then pull the rug and switch to a more restrictive license once customers are locked in.
On the flip side, if a company tries to be honest from the beginning by using BSL (or similar) they get endless grief from religious zealots.
AGPL is the magic unicorn license that is just restrictive enough to protect you from your competitors, while still passing the FOSS religious purity test.
We trust Free Software not because of the license, but because of the ecosystem and number of eyeballs. Go tried to pull something similar by forcing telemetry on everyone, and they were almost burning everything down. Almost.
People/companies get vilified when they change licenses because of the way they do it. They don’t openly say that they need the money, did some mistake and need to change things to keep company afloat, but they also change their tone after license change and vilify the past contributors and become aggressive themselves.
There are many friendly open core or closed source companies out there, and I trust them with my code, data and secrets, and pay them without any hesitation.
Software ideologies are something, so the real world. While I’d love to see everything as Free Software, we’re not there yet, we might never be, and that’s OK. I’m writing Free Software and try to use Free Software as much as I can to show my colors and do my part in the thing I believe. But I’m never a mindless zealot spewing things.
What? I can't think of any examples where they don't quote money and the lost revenue from hyperscalers just taking their software and reselling it without contributing. InfluxData's CTO and co-founder even wrote a blog post on open source monetisation and how hard it is. Elastic, Mongo even explicitly pointed the finger at Amazon. Many others smaller ones did it preventively, like Sentry and Sourcegraph.
I've also never heard any vilifying of past contributors, outside of bickering about the meaning of open source (I think it was Mongo that claimed they're still open source with the SSPL license?).
Will the code for these features be in the same repo, or be kept separate? If the former, is it easy to remove them to create a fork that is fully open source? Or does the community edition actually contain proprietary code that is disabled?
> if you want to contribute to our codebase in the future as an external contributor, you’ll need to sign a Contributor License Agreement (CLA)
What are the terms of this CLA? Does it mean that Plausible could change the license to something that isn't FOSS in the future?
Sadly, yes.
Edit: However, they might also need this to integrate the contributions back to the managed version, which is not AGPL licensed to begin with.
- include in the terms of the CLA that Plausible will never change the license of any part currently licensed as AGPL to another license without the consent of all contributors, or make the CLA conditional on the code modified continuing to be available under the AGPL
- limit the license rights of Plausible to very specific uses which wouldn't allow relicensing the entire repo
- have the contributor agree to dual license their contribution with a license like the MPL to Plausible, which would allow combining with separate enterprise code, but wouldn't allow them to relicense the source files modified by the contributor. I think the GPL would also work for that, unless Plausible starts distibuting an enterprise self hosted version.
Plausible definitely took a different approach though. Interested to see how it works out.
[1] https://futo.org
Don't licences normally explicitly bar this? Tough over-sight for Plausible unless there is an actual reason for letting other businesses pretend to be you. Perhaps they figured it would act as a bit of marketing?
I do sometimes worry that Plausible's more relaxed session tracking is making it harder for me to understand my true user count.
(I know they wouldn't get updates, security improvements, etc)
These new ones preach they are better than Google Analytics (also another evil tracking system) yet some how these ones still track you anyway and you're paying for analytics which is useless and you're punished for growing.
It might be best to save money and not use any analytics system, it's just noise at this point.
Am I missing something?
They don't set cookies. They're effectively the same level of tracking as a web server log file... except Plausible don't even collect and store IPs (unlike the server log).
That feels very different from cookie-based analytics platforms like Google Analytics.
More in their docs here: https://plausible.io/vs-google-analytics
Not really oxymoron if they don't track your PII like IP address, email etc. Don't know how Plausible works, but usually these systems track page views, etc without the associated visitors' data. They either anonymize the visitor metadata or just aggregate the site data like what urls are visited, etc.
So except for self hosting it doesn't seem that this is any different to GA.
- Due to how the FISA (e.g. 702) laws in the USA are incompatible with GDPR, GA4 is illegal is much of EU (and EEA).
- Plausible actually collects less data on the visitor, making it more ethically sound.
There is tracking and tracking.
Google Analytics tracks you across the internet and collects all sorts of private and public user data and metadata, analyses behaviour, correlates with other metrics and sources of information (like ad campaigns), etc.
Plausible and co tell you there were X users with an average of 30s spent on page Z. Which Google Analytics also does, on top of the other things.
Yes, it's technically "tracking", but if you thing it has much to do with the first one you're fundamentally misunderstanding analytics and tracking and thinking in FUD terms.
Related discussion just two days ago:
Plausible Analytics: GDPR Compliance w/o Cookie Consent Banner
I sympathise with the problem of re-sellers abusing their hard work but they are also creating two different classes of product with this change.
Community edition with enough features for small businesses.
Once you reach a certain size, you'll need the other features but you now have the money to pay for it and as you've used the community edition for some time, you know that you want this products. (and if the product is deep into your workflow, the cost of change is high that you'll rather pay than switch)
As I'm currently building the stack for my startup, I'm more interested in that model than into a "full features 7 days trial" that then turns into a 19$/m/user.
This is a team of eight people that tried to do everything „right“ by changing to a FOSS license (which happened four years ago) and the changes announced here sound very reasonable (changing branding and removing undocumented APIs). But all comments are dunking on them as if they haven’t even read the article.
I don't think it's bad intentions though. Just grab the pieces you need, assemble, add the missing parts and start a project, and earn money.
xGPL (which I strongly support) prevents this building model by forcing license inheritance, release of changes and limiting license interoperability, preventing creation of technical secret sauces, and many people think that all secret sauces are technical.
OTOH, the harder (but better in the long run) way to create value with FOSS and Free Software particular to have stellar support and reliability. i.e.: Your code can be deployed, compiled, or built upon, but you're the best source to get the software in the first place. Your presence, human relations and knowledge about the product is the secret sauce you have, but this needs more effort, is a more of a soft skill and grows like a sequoia (i.e. roots first for a decade, then start to get taller).
This is not a quick buck, but an old school proper business building, but many people don't have time for that, and since everyone wants to build fast and consume fast, this more healthier mode of making business is frowned upon.
Sometimes you need to move slow and break(through) things, but as the meme says "ain't nobody have time for dat!", which is shortsightedness in my perspective.
...It's not obvious to me that the person who originally wrote the software is necessarily better positioned to support the software. Everyone has the current source code, so from that standpoint it's a level playing field. Another party could come in and build a business as the premier support consultants without most of the original developer's startup costs.
Now, I'm not sure if this has ever actually happened. If it hasn't, maybe I'm wrong. I would like to be wrong.
They do not accept outside patches, which is not against Free Software, it's more like a cathedral, but it's not "not open source".
> ...It's not obvious to me that the person who originally wrote the software is necessarily better positioned to support the software.
Let's take an example. Scientific software. Something like OpenFOAM, or some simulation code. Open it with GPL, everybody has the source code, but only the developers know the intricacies of material simulation, the fragile math of it, how to optimize it, how to test it. You can fork it to infinity, but unless somebody has the expertise to understand the science of it, nobody can do anything with it, maybe besides breaking it in subtle ways making things worse.
> Another party could build a business as the premier support consultants without most of the original developer's startup costs.
When you have good enough product with tons of implicit knowledge buried in its source code (see above), it's not easy as it sounds.
Many people write CRUD software, and CRUD software has no effective moat. It's just DB dressing and some automation. Start to blend in domain specific knowledge into it, and now we're talking.
I don't doubt that it's hard. But I'm not convinced that it's harder than writing the software in the first place, so that is still a major savings for the competitor (which they could then use to undercut in terms of rates, etc).
As a point of comparison, let's say that SQLite's development team all died in a plane crash. Would a new team throw out SQLite's codebase and start from scratch, because they could never hope to understand the old code as well as something they wrote themselves? No—they'd review the code and documentation and bring themselves up to speed. Maybe they're never 100% as good as the first team, but they'd be quite capable.
That's the thing. They won't have the same shared vision and abstract model and roadmap of SQLite to begin with.
Let's take more examples: Audacious, GIMP, Darktable, DigiKam, Inkscape, KiCAD, Blender... Why these programs are not forked, or forked successfully? These are not niche programs. They are standard tools for some people. The thing is, all of these tools require very deep knowledge about some obscure and hard subjects. Some groups may take them over, but they can't just continue them as is. They will break things, or need to relearn tons of theory and their numerical versions which can be applied in programming languages.
I did my Ph.D. in SWE, writing a material forming simulator. Boundary Element Method more specifically. You can't expect a group of people just to say "Meh, let's fork something like this and just be better". You can't. You need to know deep numerical math, theory of BEM, need to build the formulae, and know enough CS + numerical linear algebra to transform that math to computer code.
I spent 7 years to build one from scratch. Not all applications can be transferred to a new team in two weeks flat. KiCAD is in development for 30+ years, for example.
It has. As a popular example, Percona are among the best consultants on MySQL/MariaDB/MongoDB/databases in general, and they are not related to any of those projects (one of the founders of Percona used to work at MySQL decades ago).
I think a real world example for this would be https://www.collaboraoffice.com/about-us/. And looking at it from the outside a positive example as well. At least I could not find any public beef between collabora and the document foundation (as the organisation behind libreoffice).
One example is that the Matrix project recently took a budget hit when the core team apparently lost a big bid to a "large system integrator" who seems to have used their own open source code to bid against them.
A better approach would be if the purchaser mandated that the upstream project has to participate in the deal rather than being disintermediated by the SI, but we've seen very few instances of that happening.
Personally, I believe there are several "valid" business models that include open source contributions. Microsoft, Facebook, Google, Amazon and even Apple all contribute to open source software. Redhat, Canonical, Suse are all companies that have open source software at the heart of their products. Blender and Godot have found viable paths as nonprofit foundations. Linux, OpenStack, Eclipse and others are all foundations that work on a different level, combining contributions from many different companies and individuals, and support multiple projects.
There are open core companies like Gitlab that are also "valid", while I personally don't prefer the open core model.
Automatic sponsors WordPress development, and makes money providing hosting and related services. Automatic competes in a very competitive market with other companies providing hosted WordPress, but they survive.
Releasing code as open source is not an automatic mint. Business is hard. Businesses that don't release a single line of open source code fail all the time. It should not surprise anyone when a company that contributes to open source fails, because companies fail all the time.
1. Just don't. Work on open source on the weekends, etc.
2. Do it as part of a "commoditize your complements" strategy.
3. Work at a company that is so large they can fund open source development as part of their advertising strategy.
4. Gather together some expertise in existing open source projects and sell consulting. Crucially, you'll probably need to build on top of some existing open source install base or name recognition. Redhat didn't start the linux project or the gnu userland, Percona didn't write mysql, etc. In some sense you are now one of the leaches that posts such as this one complain about.
The fundamental piece in common here is that the open source bit isn't the main value driver for the business.
If you are concerned about your livelihood then don't hinge it on the viability of open source projects to underpin your business model.
I've said it before, I will say it again.
sustaining a small company offering commercial licenses or hosting or support or consulting or whatever for an open source product is not going to be that much more difficult than sustaining any other kind of small company.
the issue that I see most often are OSS devs not approaching the problem like a company would and startup founders looking to build a unicorn while also keeping some kind of purity wrt open source.
not everything needs VC investment with valuations measured in the tens of millions but everything does need some level of formal business development (even if that business is of the non-profit variety).
Cool, and what is your proposal to people who both believe in open source, build on open source, but would also like to be able to put food on the table and enjoy their work?
You can get a job at a company like Google, Amazon, Microsoft, or hundreds of others where they pay folks to write open source code, too.
Don't try to sell software, sell your expertise. Basically variations on consulting.
I don't understand why people think they can stop others from commercializing their open source project. You can give something to the world. You can hold onto IP to stop others from cashing in. You can't have it both ways.
Given enough eyeballs and persistent people, this moat started to be passed with relative ease, allowing big(ger) corporations to deploy intended-for-your-eyes-only, open codebases to production.
Naturally, people didn't like that, and started to move back to xGPL licenses to force modified copies to be open. This forces the parent company which started the project to keep the code open (or make people sign a CLA or don't accept PRs, etc.), but prevents their code from being cannibalized, and makes more sense on the long run because the added value is the service itself rather than the code. CE versions allows deployable open-core versions for the tech savvy.
[Actually Plausible says "A stronger moat for hosted Plausible", so the plan is exactly it].
So, Plausible at least, is returning to the root of Free Software, not OpenSourceWashed software. This is a good move in my book, and makes me happy that I was right about BSD/MIT in the long run.
You're right, but you're applying idealism to a concept that was popularised 35 years ago to the current landscape. If you want free-as-in-freedom software developed without restrictions with corporate backing, that ship has sailed.
What is your suggestion for how to run a business that offers an open source product that isn't going to have their lunch eaten by AWS/Azure/GCP once it becomes popular? If your answer is "well that's not open source", then I think you need to take a look at the reality of software in 2024.
Without going too deep into semantics, the original nature of open source is counter to business interests. If we're using that term for source code that's kinda open for some people some of the time, we risk virtue signalling.
Using the original intentions for Open Source is well and good, but do you think Richard Stallman foresaw IBM being the primary funding mechanism for GCC in 1989?
Off the top of my head, Imgui[0] is an example of an open source project, widely used, developed by a small group with a main contributor. AssetCooker [1] is a project that I discovered recently which is clearly a passion project from a single developer who shared it with the world. CNCF [2] is an odd one, but in my mind it's a 21st century Apache foundation - they have a bunch of core projects which are complete open source projects, used widely in production and sustained through different models.
I think imgui (of the bunch) is probably closest to the GCC-of-the-early-90's idea.
[0] https://github.com/ocornut/imgui
Why shouldn't I? I created a product and I should be able to choose who do I give it to.
I want it to be as open as possible while restricting some types of usage I don't like, or that would be detrimental to the continuation of the project itself.
I don't see anything outlandish in my statement.
I can understand why people would prefer FAANG & Co. weren't re-selling their FOSS, but I don't see how you can pick and choose who has access to and is allowed to run your code, and still be open source. Maybe you could have an application process, where you decide to give a license on a case-by-case basis, that can be rescinded later. But I'm not confident you'd get much traction.
The OP's point is that product owners want the benefits of being open source, but are frustrated with the downsides. You can't have one without the other, they are two sides of the same coin.
But it's technically not open source since there are usage restrictions, and considered "source available" which isn't descriptive enough IMO.
I think the sunshine and rainbows idealism of some of the licences and OSS gatekeeping was fine 20 years ago, and works fine for certain kinds of software and mature, well-established projects (compilers, Postgres, MySQL etc) but these days, no longer fits the reality of the software landscape.
Marko frequently posts on social media about Plausible's revenue growth, currently at over $1M ARR with a tiny team and little overhead.
They are doing great financially. Yet in this post he tries to gain sympathy by focusing on "we only make $300/mo in donations".
Frequently moving the goalpost on what it means for your product to be open source betrays a lack of integrity and will have me, and probably others, looking for an alternative.
$1M ARR with an 8 person team is by no means "doing great". Assuming 20% of income goes to overheads (such as hosting, marketing, legal, accounting), that leaves a salary of $100k for each staff member. Even if they had 0 overhead, this is still only $125k each -- that's hardly big money.
Also, in reading the post - I find little to object to. They're not changing their license. They're not doing anything to prevent self-hosting.
They're making it clear they're not offering support to people who don't pay (completely reasonable), and gatekeeping a few features that add value - while still giving away a huge amount for free. That's a fair deal to ensure the company remains viable, which is in everyone's best interest. In practice, this decision is unlikely to materially impact anyone.
Open source is a gift, not a right, and certainly not an obligation - and from what I can see, they're not doing anything here that undermines the Open Source-ness of their offering.
FWIW, I'm not sure you'd find an alternative analytics offering that's both commercially viable, and "more open" than what Plausible are offering today.
That works out to be about $10.5K (9.7K EUR) per month, pre-tax. I'm not sure where you're from/at geographically in the world, but in most places where I have lived that would be considered a large salary for just software development.
Outside of the major cities in the US, wouldn't that also count as a fairly large salary?
$1M ARR is not very much when you have almost 10 employees. This would be considered rather modest. Generally the rule of thumb for me has been that each €100k ARR is an absolute minimum to hire an additional employee, thus €1M ARR would be an absolute maximum of 10 employees.
You're talking from the perspective of the company, I was specifically replying to the "this is still only $125k each -- that's hardly big money" part, which I thought was very clear since that's the part I quoted.
Besides, parent already went through those, their back of the napkin guessestimate is after other expanses. Click the "parent" link next to the timestamp if you're having troubles finding it.
I still think the way they've done this stinks though.
What would you do in their position?
This seems like on of these things, just like changing the design of your product where you will never be able to make everyone happy and there will always be a small group complaining.
The $300/month is absolutely ignoring the free marketing they get, plus the fact that many users such as myself only use their paid product because it is open source.
Additionally though I signed up to support an open source company, because I think open source is better for society. I like giving money to open source projects. I would rather give money to an open source group than use a free product like Google Analytics. I like being able to support open source companies, and I get annoyed when they do rug pulls like this.
"That license change has helped us build a sustainable open source project with 8 core team members and several paid external contributors at the time of writing. We don’t have any investors, so all this is solely funded by the fees our 12,000+ subscribers pay us."
Then later on while talking about the self-hosting option:
"We make $300 per month from donations from our self-hosted users. It would take us more than ten years of donations to pay one month of salary for our small team."
That's only misleading if you skim the article. They clearly differentiate between the 12,000 paying subscribers who fund the operation compared to the $300 in donations from self-hosters.
No, that one line without the entire preceeding part of the blog post makes it sound like that. However when the blog post opens with
> That license change has helped us build a sustainable open source project with 8 core team members and several paid external contributors at the time of writing.
It's abundantly clear that they attribute that success to their open core model.