Immich is changing its license from MIT to AGPLv3 | Hacker News Reader

Immich is changing its license from MIT to AGPLv3

github.com

61 pointsthunderbong46 comments

Big fan of the AGPLv3 for the health of open-source web applications, good on them!

For people who still haven't tried Immich, I urge you to do so. If you self-host anything at all, which in 2024 you should, as a technical person, it's literally half an hour worth of work to self-host this full blown Google Photos alternative under Docker Compose, and much of that time will be spent setting up Nginx reverse proxy and downloading packages. The only thing that I miss from Google Photos is landmark recognition (a lot of my photos do not have GPS tags), but that can be added later I'm sure. I'm just blown away that someone just went ahead and rolled something this full featured for free and with no strings attached.

I agree. It's an incredible clone. Flawless.

Doesn't seem to support encryption at rest nor object storage, i will stick to Nextcloud for now.

I also self-host NextCloud, and if we're honest, its image hosting is pretty underwhelming in comparison. I moved it to Immich. If those issues are critical to you, however, that is a valid concern, but I'd venture to say they aren't critical to most self-hosters, whereas good mobile sync, AI integration (intelligent search and facial recognition), and ease of use are. Immich excels at all three.

I didn't know that. I self host this on my own hardware in my office. If I wanted encryption at rest, I would just do it at the hard disk level I suppose.

Setup is easy, the problem is local storage as opposed to cloud storage for the photo library

Is that a problem? That's kinda the whole point. It's docker, so you can make a cloud drive mountpoint with rclone on the host, then mount that path inside of docker if you really wanted to

I imagine most people running immich also have a good amount of local storage

Setting it up in a way that is sufficiently robust is non-trivial. It's not unworkable but we shouldn't underestimate it.

Setting things up in cloud in a way that prevents some proverbial NSA analyst from beating off to the naked pictures of your wife without you knowing, on the other hand, is impossible. Why this learned helplessness? Is this “hacker news” or “layperson news”?

With selfhosting, the problem was never really the software, but everything around it. Getting an openly reachable web address, securing it, the storage, making backups etc. There are some nimble projects to simplify some parts of this, but there are huge gaps still. Some important OSS celebs still trumpet that "users will never self-host". But if and once this vertical problem is solved, I'd expect a landfall, and we would all look back at this intermittent "cloud era" as some dead-end temporary dark age.

I gave up on making services openly reachable and instead just put Wireguard on my server and then connect into that and access things via their IP:port as though they were local. At some point I might set up a reverse proxy so I can give services names, but this has been fine for the past year, so motivation to change it is low.

All of that is super straightforward in 2024. The problem before Immich came along was that software sucked in one way or another. Take Photoprism - the leading solution (imo) before Immich. Poor AI and search, poor mobile uploads, user management requires CLI. Immich absolutely nails all of those things and more. It’s a nearly 1:1 Google Photos replacement with total privacy, unlimited storage, and very similar user interface. Thanks to Docker Compose all of this can be brought up locally (to try out) in one minute flat, and exposed remotely in half an hour. Or don’t even expose it remotely, and do what I do - set up WireGuard such that it automatically connects when you’re not at home and you get access to your home network. That way you don’t need to worry about maintenance as much. An occasional update is all that’s needed since your audience is now “trusted”.

As a software engineer who cares about privacy but does not have much experience in security, ops or much time in constantly patching servers, I trust Google more than myself in not getting hacked, messing things up or unintentionally leaking my own pictures to the public.

The solution is simple: install it behind WireGuard and trust yourself more than Google. Google has repeatedly betrayed your trust over the years.

How can a project with 260 contributors and no CLA change their license? Wouldn’t they have to get approval from all of those contributors or remove all that code?

Apply it only to be contributions?

The MIT license allows re-licensing, so not in this case.

This is the whole point of permissive licenses - the restrictions on what you do with it are minimal.

It is common for permissively licensed software to be redistributed under proprietary licenses too.

>The MIT license allows re-licensing, so not in this case.

That's absolutely NOT true, you can "sub-license" it, but not re-license. If a contributor wrote a file you cannot change the license from the file:

https://opensource.org/license/mit/

>>The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

>>including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software

You can't relicense the original material, true.

But you can create a new version with changes and a different license. The new license only applies to the new changes, but if users use the software as a whole, users must comply with the new license (as well as the MIT license, which continues to apply to the unchanged parts).

As an oversimplification, if you combine 2 components with 2 different licenses into 1 work, the recipients have to comply with both licenses. MIT has few requirements and I believe the AGPL includes all of them. So while technically the MIT license still applies to the old code that did not change, from the point of view of a recipient of the combination, the results looks like a relicense.

Exactly! Very well explained.

But:

>MIT license still applies to the old code that did not change, from the point of view of a recipient of the combination, the results looks like a relicense.

That's again not true, you cannot delete the MIT license from that file, it's not important if you changed it, the original license is still there plus your license that don't contradicts the MIT license like "our license allows to delete all prior licenses" yes your added code is exclusively under your license but the whole file is MIT+ that was partially confirmed with the BSD and AT&T lawsuit (when AT&T took BSD code deleted the license and lost because AT&T "stole" more code as Berkley hmmm f're'e-licensed ;)

That sounds very arbitrary but if that's the case, instead of changing the MIT-licensed file you can just create a new one and put the changed code there. Eventually the MIT one will just be empty, or all of its functions unused and it can be deleted.

>instead of changing the MIT-licensed file you can just create a new one and put the changed code there.

Yes do that...even in the same file and put your License above or under the MIT one's...no problem (sub-license).

I don't get it, what are you trying to say? MIT gives you the right to do nearly everything. Just don't take the copyright and license from the work and the people who made it. It's not viral.

I'm not a lawyer, I just read the copyright lawyers who post here, but I don't think this is all that complicated? Once a literal, specific, concrete file is released MIT, you can't "take it back". That specific file will always be MIT. But you can, on a forward-moving basis, license all your own changes to that file however you'd like. The changes (and the changed versions of the file) have, absent some binding contract that says otherwise, their own copyright status.

This is why there is, for instance, OpenSSH: it's the version of SSH that started when the SSH company decided to use a restrictive license on a forward-moving basis. The community just forked at the last permissive version and took over development themselves.

That's how it's supposed to work?

>That's how it's supposed to work?

Yes your are on point.

>That specific file will always be MIT. But you can, on a forward-moving basis, license all your own changes to that file however you'd like.

Exactly, that file is then MIT+YourLicense but one can never take the MIT license away (except the copyright holder).

Take away a (not owned) Copyright would be called stealing.

Even the BEER-WARE LICENSE has this sentence:

>As long as you retain this notice you can do whatever you want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return. Poul-Henning Kamp

I think the original author (or their heirs) can take away that MIT license during a special “copyright termination” window 35 years after granting it at least in the USA.

Right, you switch from MIT to GPL, but not the other way around

I don't know for this project specifically, but previous contributions to this project perhaps have turned "author rights" over to the project, then the project relicensing is within their rights. Projects often do this because these license issues have come up before.

You can do this when you publish software under the GPL, and then the FSF will take care of enforcing the license for you. It's a popular thing to do because if you don't, you'd have to get your own lawyer, etc.

the parallel comment about MIT licenses allowing relicensing is also valid, just rounding out the explanations.

The FSF doesn't even enforce the license for its own projects, let alone any random GPL project. Please don't give people false ideas.

I'm talking about what is published on the GNU and FSF sites. Whether they still actively do it is an interesting question and I welcome your feedback, but I'm not spreading false ideas, and my comment is "education" about various aspects of licensing.

source?

What you're talking about is called a CLA, a contributor licensing agreement, and is precisely what the project is boasting they are not doing. This prevents the company from ever changing the license from AGPL to something else from now on, since they wouldn't own enough of the copyright.

Not quite. The previous commenter was referring to how the FSF handles contributions—copyright assignment—not a CLA. Your conventional CLA doesn't transfer copyright ownership to the upstream project. It just permits them to do a lot more with the contributor's work (including e.g. arbitrarily relicensing) than other recipients/participants get to do, without actually making the original author give up ownership.

Hypothetically, if 95% of code is from the company and 5% is from community, would it be possible for company to remove commits made by community, reimplement affected parts and move the project from AGPL to closed source?

MIT license is permissive; that's the whole point of it. You can use MIT-licensed code to create AGPLv3-licensed derivative works same as how you can use MIT code in proprietary software.

It's simple. Let's say that for some software version 21.37.1 is MIT, but version 21.37.2 is AGPL (which is permitted, as other comments already explained).

You can use any data from 21.37.1 under the MIT license, by definition.

You can also use data from 21.37.2 that were not changed since 21.37.1 under their original MIT license (they are the same file, so the original license carries over!).

However, all data that was changed in 21.37.2+ is now AGPL. Using code that contains any of these changes (including version 21.37.2 as a whole) requires you to relicense your code under AGPL.

Despite the claims of other replies that this is fine, I actually wonder if it is. Let's examine the MIT license and the effect on the software before and after:

> Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction,

Ok, so if I grabbed anything before the license change I can do whatever I like with it.

> including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so,

So, the relicense is allowed, but...

> subject to the following conditions:

> The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

So the new software even when AGPL-licensed is still MIT licensed right? It just has another license that also applies. So I think realistically, from a legal perspective I could still do whatever I want with it.

"to deal in the Software without restriction"

AGPL applies a set of restrictions that apply to the dealings that you have with the software. These restrictions hence do not apply to any parts of the software that are still MIT licensed.

To make this effective, the AGPL-licensed software would specifically have to call out the pieces that are not the MIT licensed software and are only AGPL-licensed. That seems like a lot of effort and would be difficult to maintain.

To demonstrate the absurdity, let's take a stupid hypothetical change - add an extra set of parentheses to a variable assignment. `i = 42;` becomes `i = (42);`. What is the license that applies to that line? - It's a substantial copy of the the software, that has been sublicensed. I'd say it's still MIT licensed (but IANAL).

My personal perspective on this is to avoid the GPL in any form in software __that I write__ (though I'm happy to consume it) and stick with MIT/Apache when possible. I'm still trying to understand if this perspective has merit, but it works for me for now.

To the downvoters, which part of this analysis do you disagree with and why?

I tried NextCloud + Memories but multiple hosts said the facial recognition app wouldn't work. Face recognition is important. I tried Librehost for Nextcloud, seemed great until face recognition didn't work and support said it wouldn't.

I can't self-host hardware, my home internet is shat.

I really want to run a managed-host instance of Immich (or NextCloud) but am struggling. This is for family photos shared by 3 siblings. 100GB+ of storage is ideal, cpu and connections isn't as important since at max it will be 3 users.

All these programs looks great and have easy Docker setups, but I can't figure out Docker storage. Docker seems to be more about running the app, not storage. If I install Immich on a Docker instance, do I have to connect it to external storage? If so who and how?

I'm more familiar with kubernetes for running production-grade apps and that's what I went with. I run ubuntu's microk8s, and the volume management is in kubernetes-land which I understand well. Finally helmfiles deploys my Postgres and immich helm charts. Perhaps "overkill" to some, but it's tooling I'm very familiar with, and feel comfortable running in "production" for my personal server.

Worth noting that immich itself recommends not using immich for the single source of your images and videos from how active development it is, so I also run nextcloud + crunchydata's postgres also inside microk8s/kubernetes.

Appreciate the response. Wow, not going to happen. I am a (self deprecating) script kiddy. This is overkill for me. Everything you said was over my head. On a positive note, I don't feel bad for failing to figure it out.

Business Idea- I would pay 10-15 dollars per month for a managed hosted Immich (or similar) instance. (I "own", you manage) Minimal processing, minimal sharing (no social), but big storage.

>Languages

>TypeScript 50.9%

>Dart 28.4%

>Svelte 16.2%

Seems like the mobile app is flutter and the website is js? That actually makes sense as flutter web isn't there yet in terms of performance. I wonder if they will switch when wasmgc is supported by major browsers.

I hope not. Flutter as I've experienced it on the web is absolute trash.

It's bad anywhere were you would need control f or need SEO. Otherwise the main issue is performance and load times. In an app like this you don't need SEO and search is built in presumably. So if performance is fixed it looks quite compelling to drop the seperate web version. You would have to test load times vs. the current web implementation though. I think flutter on web currently makes sense for <1% of websites but this may be one of them.

Very nice. I especially like that there's no CLA.

That's a good idea!

Reply on news.ycombinator.com