On the AGPL license and the idea to move away from it

Feedback
41

I stated facts, debunked myths about AGPL and in the end everyone agreed that there are zero risks in using a desktop app like Logseq, while the risks are all about using Logseq source code to provide a service.

Agenda? As a user it doesn’t make any difference to me if Logseq is released as AGPL or MIT. The AGPL is meant to protect the team’s work. I am arguing in the sole interest of the team. Just the fact that one could think I have an agenda means this whole thing about licensing is not clear at all, sigh.

It doesn’t matter because it doesn’t apply to using a desktop app like Logseq as opposed to using Logseq source code. As already said many times, a company can simply forbid downloading AGPL source code but not binaries.

I am the one that suggested the dual-licensing as a solution but some people, instead of appreciating that, started a controversy that lead to nothing, since they have no alternative solutions and their arguments turned out to be myths or don’t apply to a desktop app like Logseq.

The Logseq team can relicense thanks to the CLA that every contributor must sign before their contributions are accepted. The request by Logseq team to sign the CLA is what triggered this discussion. That and the reason the Logseq team wrote made me thought that it’s not clear to them how the AGPL works and how they would shoot themselves in the foot by adopting another license. You can read more in my original post.

There are famous leaked documents by Microsoft about this and I don’t understand why it’s so surprising, most IT companies takes advantage of artificial scarcity and FOSS could make more people realize that you can have good enough products without a business based on artificial scarcity.

I have not to make it clear because it’s already clear if you read my original post. Another user already tried this strategy, sorry but it doesn’t work against me. Use your energy for real arguments.

1 Like
42

In many ways he is. I do think Alex has good intentions. He is looking at this from the perspective of the legal implications of the license itself, where my points (and others) have been from a usage perspective.

I do believe this is the best approach, and one I have mentioned before. The challenges and implications of AGPL would impact the total “potential” number of users who can use the software, while the commercial license would significantly reduce that impact, if not entirely.

This is fundamentally about presenting all the relevant facts regarding the situation, to ensure that the Logseq team has access to these critical data points when deciding which approach to adopt for their sustained functionality, protection, successful monetization, and ongoing development.

43

Long-time user, mine is just one more point of view. I still wanted to share it.

I work for a big company which fears AGPL. Lawyers are educated about one or two scary scenarios from many years ago, and they do not allow AGPL at any cost. The nuanced - and absolutely correct - view that Alex presented, that so long as people don’t download and mess with the code, we should be fine, falls on deaf ears with many legal teams in the industry. It’s a battle worth fighting which some of us have been fighting for years, and keep doing so.

And yet, while all that happens, and despite how dumb it is (my personal opinion), many tens of people who wanted to use Logseq can’t. We have a vibrant PKM group who would jump on this - and still is sour about the ban we got a while ago.

Anyway, all I meant to say is there is a good solution - convince the powers-that-be that AGPL is not a monster (a valid battle which will continue and perhaps be solved one day) -, and a pragmatic solution for those who are stuck in that limbo - alternative commercial licenses. The earlier would preclude the need for the second, but alas here we are, with no timeline for fixing the first one. I still have hope, but many have given up trying to reason with those who are not allowed to only operate on reason.

Both of these approaches are useful, but they have different timeframes. If we decide to simply go for the first one, then all the willing users who are stuck without the tool will likely be stuck without it for years more - and it is unclear if they will ever have it.

I think Logseq has as part of its goals to contribute to normalizing AGPL. It probably also has as a part of its goals helping as many people as possible organize knowledge.

Both of those are true, but they are at conflict here and their relative priority needs disambiguation.
In the end this is a decision for the Logseq team, and I don’t think there is a wrong answer. Both are defensible, reasonable positions.

I remain an avid user, a big fan of the product, and very grateful to every one of you for bringing it to life and evolving it.

I would happily pay from my own personal pocket to be able to use this tool at work. That is the amount of appreciation and need I have for the tool.

3 Likes
44

Dual licensing is my original proposal but there is a third alternative: making Logseq Web version fully functional.

At the moment the new “DB version” works well in the browser and they specifically choose to adopt SQLite-WASM as DB to keep the Web version available.

They plan to make the DB version synced with the content of local text files, just like now. But the new architecture suggest me they want to make the Web version working fully as a cloud application by using Logseq Sync and no local file. This would make Logseq just as usable for some people as e.g. Notion.

By fully functional I mean it has to support all the features of the Desktop version, like plugins.

2 Likes
45

I see that third alternative, that is a solid product direction (though personally, I would always want to have files too, that I can checkpoint, periodically backup, etc).

However, I can offer some more context, since I don’t think that approach would solve the specific need that drove me to comment. A strong principle in our company - and it’s the same for other ones - is that any company data/information/knowledge cannot leave corp property. So the fully online option would not be viable.

To share a little more, a while ago, before the ban, and while we had an authorization to use the software (which would ultimately be revoked, because AGPL), we were specifically instructed that our authorization did not cover using the web version even with local files nor allow the offline version to sync anywhere off corp.

I will support the decision of the team here, whichever way this goes ultimately.
My hopes are on dual licensing in the nearish future, while we keep fighting the good fight in the mid- to long-term.

1 Like
46

This is why Logseq Sync is already end-to-end encrypted; Logseq team can’t see the synced data.

Also, the DB Web version currently work without files nor Sync. It just uses the browser local storage, so the data doesn’t leave your machine. I don’t know if the browser storage is limited. And a way to save a backup as a file would be helpful I think.

47

This makes absolute sense, but without a verifiable chain of trust, the fact that a service is end-to-end encrypted or that the web version only uses local storage cannot be verifiably enforced. Code can be changed, and deployed versions can be tied to unpublished branches, for example. A different - but meaningful example - was that Skype comms were peer-to-peer and at some point they were silently changed to go through a centralized hub, which is a different contract that might not serve everybody equally well. Mid-to-large companies end up focusing on repeatable, ideally automatable, processes.

For comparison, something that might work would be to secure a license for the use of a snapshot of the codebase at one point in time, fully vet it, then run their own copies of the servers, etc. by and for themselves. Then they can have all their signed verifiable builds, and everything that goes with it. (While this is technically imaginable as an example, I’m not sure this mode of operation would get much uptake - or at all.)

48

I don’t know Logseq implementation but on the Web there is an API to ensure the data leaves you machine e2e encrypted; it is what Element, the Matrix client, uses I think. This doesn’t guarantee the implementation doesn’t change, but if it happens it would be discovered and the company would lose all its credibility.

But it would be way better to just have a local application and reproducible builds available to check that the published source code is used.

49

I followed this discussion for quite a while now and I am impressed this is still going on.

I can understand that the CLA signing can have good intentions but at the same time it is a huge red flag for possible contributors.

2 Likes
50

In the Plone Community we use still GPL2 for the Python Core and decided explicitly against GPL3 that is either a successor or upgrade or better. The new Volto Frontend based on React has different constraints and a different license.

These insight were made around 2004 after a big funding and investing this in the legal consulting to set everything up for a now 20 years success story.

I am Plone Foundation member since 2004.

The basic idea behind the Plone Foundations ownership of the code is called conservancy model and simplified it is giving your code completely to the foundation, so nobody can get a grip at the main IP. Then the Foundation gives you back an unlimited but non exclusive right to do what you want on your side, except making it proprietary. More can be found online. This just as a hint where to look for.

1 Like
51

Thank you, it’s always a pleasure to heard this kind of stories and it sounds almost like KDE or GNOME.

52

The viral nature of AGPL and other licenses are by design and should be adopted across the board. The reason Big Tech fear AGPL is obvious: they want their closed source software to benefit from OSS without being required to contribute. Big Tech is a malignant cancer, a blight on our freedoms, and seeing people justify the decisions of abusive companies and even spread misinformation about AGPL would be funny if it wasn’t so sad. People need to sit down and learn what the AGPL says rather than parroting what FAANG lies about what it says.

Regardless, my vote is in for dual licenses; however, isn’t that already the case? Apple is notoriously hostile to *GPL software (see the above mention of “cancerous growths”), and requires non-GPL licenses because they apply arbitrary restrictions that are hostile to *GPL licensing. If it’s the case that Logseq is using their AGPL code on iOS then they are breaking the App Store ToS, and that could be trouble.

If it isn’t, then I suggest discussing with OSS-literate legal counsel your options for a dual license (possibly even closed source) and charge an added fee for those who use it. Personally I would opt for permanent individual licenses with X years of upgrades and a subscription-based multi-user organization license. This provides stable revenue and an option for the devs to earn some kickback from the aforementioned cancers.

2 Likes
53

Exactly my thought and to add on that, Synapse and other server-side projects developed by Element for the Matrix ecosystem adopted AGPL and a CLA to sell the exceptions (and not to eventually relicense like Logseq wanted to do):

A new home and license (AGPL) for Synapse and friends
November 06, 2023LICENSING
Update Dec 13th 2023: Synapse is now AGPL - see Synapse now lives at github.com/element-hq/synapse for the details.

We believe in open source because it encourages innovation, ensures transparency and puts end-users in control. It’s why we created Matrix as an open source project, and ensured a well-defined open governance model around it through the Matrix.org Foundation, to ensure the protocol will always be guided by its original manifesto.

As founders of Matrix, we created Element as a for-profit open source company to hire the core Matrix team to be able to work on Matrix, develop a flagship Matrix-based product, bootstrap the Matrix ecosystem, and help fund the underlying core Matrix projects. As a commercial entity, Element has driven the bulk (more than 95%) of core Matrix development for the last seven years, and maintains the largest Matrix homeserver (matrix.org) on behalf of the Matrix.org Foundation. That has helped drive Matrix adoption, and stimulate a wonderfully vibrant community.

Over the last year or two Matrix has evolved from ‘explosive growth’ to being a ‘category’ in its own right. In other words, ‘Matrix-based’ is now specified as a requirement in massive public and private sector tenders - in which multinationals compete to provide Matrix-based products and services.

That’s fantastic, and a huge achievement. A competitive open source ecosystem is a powerful multiplier. It triggers more innovation, encourages transparency and gives end-users more independence.

The road ahead
Element has always put the growth and success of Matrix first. We have daily discussions about which choices best ensure that Matrix thrives, with Element simply needing to stay on a path to success.

Today we have arrived at a crossroads. We have succeeded in making Matrix wildly successful, but Element is losing its ability to compete in the very ecosystem it has created. It is hard for Element to innovate and adapt as quickly as companies whose business model is developing proprietary Matrix-based products and services without the responsibility and costs of maintaining the bulk of Matrix. In order to be fair to our customers, we need to be able to put more focus on them and their specific requirements.

So it’s time for us to get back in the game by establishing a level playing field and ensuring we can continue to support Matrix, whilst delivering the services our customers are requesting. This took us to reconsider how we license the open source code we develop.

After considerable thought, and taking particular inspiration from Grafana, we’ve chosen to pursue future development of Synapse (the main Matrix server), Dendrite (our second generation Matrix server) and associated server-side projects (e.g. sydent, sygnal) under the terms of the Affero General Public License (AGPL) v3 - maintaining the code in new repositories in the Element GitHub org, forked from the Apache-licensed repositories in the Matrix.org GitHub org (originally donated by Element). This is still the same team of developers who have been working on Matrix since it began in 2014, still developing and releasing Synapse as open source - and in fact, arguably even more Free and Libre than before thanks to the AGPL. Client-side code developed by Element, including projects donated to the Foundation, is not affected.

The benefit of switching to AGPLv3 is that it obliges downstream developers to contribute back to the core project - either by releasing their modifications as open source for the benefit of the whole Matrix ecosystem, or by contacting Element for an alternative license. Future code contributors to Synapse will need to sign a contributor license agreement (CLA) based on the Apache Software Foundation’s CLA, giving Element the right to license the contribution commercially to third party proprietary forks so we can use it to help fund Matrix core development in future. (EDIT: to be clear, the sole reason for a CLA is to allow Element to dual-license the software as per Selling Exceptions to the GNU GPL - GNU Project - Free Software Foundation - not to give Element the ability to relicense to a non-OSI license in future. After all, Element already had that ability with the Apache license, and has not used it.)

We believe this is the fairest approach possible: preserving the Free and Open Source nature of these Matrix implementations under an OSI-approved open source license (AGPLv3), while encouraging proprietary forks to contribute to the development costs of the underlying project.

3 Likes
54

A few disclaimer upfront:
I am not a lawyer
I am working for a big company’s legal department
And what I am writing is my personal opinion, I am not writing representative for that company.

So first of all, what you wrote about the measures to take when using AGPL FOSS, that is not the wording of the license. It is your personal interpretation of the license terms and I assume you are not an lawyer either. So in the end what matters is, how a court would decide this to be.

Now what I am here for?
I came across this topic, since I currently have to evaluate logseq to be used in our company.
(spoiler: we will have to ban this software due to the AGPL license. But with a paid version my company gladly would take it I suppose)
Having read all that had been said here, I just wanted to also share with you the perspective of one of these legal guys claimed to not having understood how FOSS licenses work.

So in theory, what you had written is, how one could understand that license.
But as there are predatory companies, there are also predatory FOSS orgs.
I was quite some time ago involved in a case, where we had been using a FOSS that was monitoring a applications performance. We permitted the use of that FOSS despite being under AGPL, since we are just using it, as you just said before, that shouldn’t be a problem.

But then, the AGPL softwares organisation approached us, claiming that embedding the binaries of their monitoring app triggers the network clause of AGPL. And even despite we were not publishing anything of their software, by the nature of the AGPL license, we would have to publish all our products that had been tested with their software under the AGPL terms. (edit for clarification: that AGPL FOSS was part of the build pipeline for the testing. The final product was not interacting with that FOSS in any way)

So they prepared a lawsuit claiming that they had a loss by the broad usage of their FOSS, given they were planing to commercialise their FOSS soon, demanding indemnification in the range of a single diget billion amount.

I am not sure if you would consider this case as intended by the AGPL design. But my company had not expected it to be like this. Before it went to court, we agreed on a settlement, it was like a 3 digit million amount. It wasn’t clear who would have won that case. But we did not want to risk loosing it. So in the end we had to pay a lot. And all what we got for that was enough permited time, to remove that “FOSS” again from our processes it had been implemented before.

So while you interpretation of what AGPL is about is in theory correct. The problem about AGPL is, its terms are rather vague. And this invites to come up with a lot of crazy ideas what could already be triggering the network clause. And hence just on a general policy banning AGPL software is not about not understanding that one still can use the binaries. But rather about what exceptions could be seen in that wording AND how would a court decide about that?

And having had a loss of a tripple digit million $ due to that AGPL license in the past.
I find it reasonable that a company bans AGPL. Even if most FOSS projects are having good intends, you can’t know who plans to just make advantage of you. And where even the project team might hand over a project and the new team has different opinion on it.

So high risk of financial damage due to AGPL isn’t just a theoretical thing.
And as long there are FOSS orgs, trying to take advantage on the rather vague network clause to make profit, as long comapnys will rather avoid using AGPL software.

1 Like
55

You didn’t specified the most important detail: did you modify the source code before building and using it? If not, there couldn’t be any violation. If yes, well what did you expect? You can use tons of FOSS for free but you need to invest some time to understand licenses once and for all. It’s your company that is predatory: pay developers to develop your own software or pay a lawyer: 100% of the times FOSS is the most convenient option for you and I can’t believe you had the courage to call FOSS devs predatory.

That is the most important detail because here we are saying that Logseq users (that just download binaries) can’t violate the AGPL in any way. Remember that this is a discussion about Logseq and its use as a desktop/mobile app. There are better places to discuss AGPL in general.

I once again stress that Logseq users can’t violate AGPL in any way: just don’t download, modify and use the source code and you are fine.