I think it's still cool if there's a message urging people to support the project, so instead of "unlicensed", the message could look something like this:

I think this might just be my favorite. It has a warm and positive vibe that brings the option to pay to your attention without naming the free version as anything. It also just looks really nice and is a perfect fit for the UI.

I think it's still cool if there's a message urging people to support the project, so instead of "unlicensed", the message could look something like this:

I would rather this. I'm a little undecided where I want its placement though. If you put it on the landing page of the user its just there constantly but if you put it behind in the admin settings it will more than likely not be noticed. Not sure. I wish we could go back to Github because I'd rather donate monthly than commit to 1 amount 24.99 or the 99.99.

I would also prefer to donate monthly instead a one-time donation amount of $99.99. With a one-time payment you are always dependent on new supporters. But what if many have already paid the $99.99?

A recurring donation option would be nice but it might be a lot more complicated for the team to implement if they stick to using the license key mechanism they made - either the recurring keys expire (the valid month/year could be part of the key which is protected by the activation code, allowing offline expiration checking) but you have to get a new one every month/year - or alternatively something has to phone home (browser or server) to update the renewal of the existing key so that the same key can be renewed without the key changing (or you could have the expiration be embedded in the activation by implicitly adding the current M/Y onto the key before generating the activation so that only the activation changes when renewed - that would allow offline expiration checking and allow your server/browser to renew the key automatically by refreshing the activation code by re-sending the expired key). But then you need a payment mechanism to renew a key and then they need to also store and update how long a key is valid (or in the case of using the activation key, updating the activation to the current M/Y when a renewal is made).

For reference there are currently IMSV and IMCL keys for server-wide and individual licenses, so they could do one or more of IMSM, ISMY, IMCM, IMCY for monthly/yearly client/server-wide keys depending on what options they want, with the main difference being that the activation server / local immich server adds the year or year month before checking it against / generating the activation, while storing just the key so the instance/browser can update the expiration just by re-fetching the activation. Just spitballing...

If they're up for the task I think it would be neat, as long as it's explicitly a donation for a badge. Signal's badges convinced me to donate for a while.

A recurring donation option would be nice but it might be a lot more complicated for the team to implement if they stick to using the license key mechanism they made - either the recurring keys expire (the valid month/year could be part of the key which is protected by the activation code, allowing offline expiration checking) but you have to get a new one every month/year - or alternatively something has to phone home (browser or server) to update the renewal of the existing key so that the same key can be renewed without the key changing (or you could have the expiration be embedded in the activation by implicitly adding the current M/Y onto the key before generating the activation so that only the activation changes when renewed - that would allow offline expiration checking and allow your server/browser to renew the key automatically by refreshing the activation code by re-sending the expired key). But then you need a payment mechanism to renew a key and then they need to also store and update how long a key is valid (or in the case of using the activation key, updating the activation to the current M/Y when a renewal is made).

For reference there are currently IMSV and IMCL keys for server-wide and individual licenses, so they could do one or more of IMSM, ISMY, IMCM, IMCY for monthly/yearly client/server-wide keys depending on what options they want, with the main difference being that the activation server / local immich server adds the year or year month before checking it against / generating the activation, while storing just the key so the instance/browser can update the expiration just by re-fetching the activation. Just spitballing...

If they're up for the task I think it would be neat, as long as it's explicitly a donation for a badge. Signal's badges convinced me to donate for a while.

Or they could reopen donations again. Or just say "this is for a year" without any enforcement, just like they don't check activation count, it would be up to you to "stop using" when you stop paying.

True, I was mainly thinking if they spent all this effort to make a redemption mechanism for what amounts to a donation for a cosmetic, they might want to use it for reoccurring donations too, and I'm sure some people would want to get a cosmetic for reoccurring donations if that was enabled again. OTOH I'm sure some people also just want to donate and not mess with keys or whatever. I'm not strongly attached to what they decide regarding reoccurring donations / cosmetics.

Agreed, something that shows that you've supported the Immich development but without it appearing as though you have to, or that you are somehow a second class citizen if you don't.

A pop-up would be annoying... don't we have enough pop-ups to deal with these days?

The badges you showed off look really nice though!

The badges are not an original design, they're just sustainer badges from Signal. I used it as an example here.

I think popups can be less frequent as time goes on if a user has no intention or ability to buy a license, but I think it's less intrusive and more transparent than an 'unlicensed' label, while getting the point across.

I would like to note, that if your android app has a pop-up asking for store reviews, you're getting a one or two star review from me – the main differentiator being whether I was able to do what I wanted before the popup showed up or not.
Do NOT get in my way when I'm doing things.

@oddstr13 I don't like those popups either so don't worry about it

@alextran1502 I should have noted that it was a general statement, and not directed at any particular project. :)

Either you did not read through the comments and concerns in the other thread or you still don't understand it. This is NOT a license! The license is AGPL. If there is a (different) license, there needs to be a proper agreement with a clear definition of what this "license" (a) requires a license holder to do (b) allows a license holder to do.

In my opinion, I do not think the naming needs to change. It's not a donation. You are purchasing a license for your use of the product. There is an infinite trial period until you have the means to purchase a license. There is no need to apologize for any wording. Some people just don't understand how an open soruce project can be paid.

Edit: At the time of this edit, there's 39 dislikes. I would like to mention that this wording is used on apps like Grayjay and Futo Keyboard. I'm unsure what makes people think that my take is bad. A lot of the other opinions I see are just trying to say that they want to turn this back into a donation. The developers said it themselves, they made more money in the past 24 hours of the license change than they made with the donation model.

For the record, I don't like this wording on GrayJay and other FUTO apps either.

That's not how the AGPL works though.

That's not how the AGPL works though.

How so? The AGPL is the license for this project. You are never required to pay for the license.

By saying you have to pay for a license they're either:

a) implying that you're denied using the software under the AGPL if you don't pay up (which they implied wasn't so since there wouldn't be a requirement to pay

or

b) that there is another license applicable... which would make you "licensed" or "unlicensed" depending on whether you pay or not.

Since the case appeared to be b), I think it was/is entirely fair to demand a fully written out license text because you're entering into a legal agreement.

I've seen too many people trying to turn popular projects into commercial products for me not to want proper license texts.

The reality is that devs gotta eat, and selling copies of software, even GPL licensed software, is not just ethical but it’s one of the few decent ways to sustainably fund such a project.

Nobody has a problem with their generous pricing model. It’s the language being used.

Purchased copy and free copy is poor word choice as well. Better than licensed and unlicensed though.

Supporter <3 as mentioned above makes the most sense in my opinion. It does a great job of making you feel good for supporting the project without making you feel bad if you can’t for whatever reason.

Licensed, Unlicensed, and Unlimited Trial are all terms that received backlash for good reason. It wouldn’t take much to move the goal post at that point.

A constant immovable reminder to donate would be a real pain for a self hosted service. There are plenty of ways to encourage people to donate that doesn't come across as badgering and taking control from them.

The day I start having to use adblock on self hosted services, just pull the plug honestly.

@colin969 I hope the follow what Futo did with Futo voice/keyboard where you can just press "I paid" and it doesn't check. Or maybe add an env var to hide the donation box (but leave it in the settings so that users can still add their key if they want to). It doesn't seem like Futo are the kind of people to fight and obfuscate to bug us with a banner against our will.

Purchased copy and free copy is poor word choice as well.

But why though? It creates an expectation that you should probably pay for this software, in the gentlest possible way. Supporter <3 doesn't create that expectation.

Purchased copy and free copy is poor word choice as well.

But why though? It creates an expectation that you should probably pay for this software, in the gentlest possible way. Supporter <3 doesn't create that expectation.

First of all, there's nothing gentle about it.

Secondly, you're missing the point of open source in my opinion. There is no requirement to pay for the source. That's (one of) the whole point of the AGPL. By giving away your code under the AGPL (and most other open source licenses) there's no (legal) expectation for someone to pay.

Open Source is essentially volunteer work that hopefully grows enough support to make it a full time, sustainable job replacement in a happy scenario.

However, it is still volunteer work at the end of the day. Volunteers are paid little to nothing, otherwise we'd call it a job.

Granted this is an imperfect world where people need money for their necessities..

So is there a moral reason to (financially) contribute to the project to (help) make it financially sustainable?

Maybe. Probably. Certainly it would've helped my project in the past to survive..

However, language matters a lot here. People are not purchasing copies of the software. They're certainly not under any legal obligation to do so.

Whenever a developer creates an open source project I am always happy and in awe. They are volunteering their time and effort to do so.

However just like the user has no rights to demand anything from the developer, creating the project under the AGPL for example also doesn't magically allow the developer to suddenly demand anything from the user.

It would be a very bad thing in my opinion for a project that was given away freely to the public to suddenly start trying to guilt trip users into paying. Just because of weird naming and wording.

Badges usually are meant to be shown off. I don't quite see how a badge would be nice on a self-hosted copy. I can see how badges for things like signal can have some sort of status behind them.

Well since there isn't really a social aspect to immich it would be very hard to make the individual-level badges shown off anyway, so it's really just for you to feel good about. But the server-wide badge would show all your users that the server owner contributed to immich, which is one way it can be shown off if they make a different name for the server-wide badge (Server Supporter? Super Supporter?)

I like the idea of a custom IOS app icon once connected to a paid server (preferably including a gold/platinum/fancy color)

I believe that's in the works too! They mentioned it in the conversation when joining FUTO!

Apparently FUTO is working on alternative payment methods: #11186 (reply in thread)

calling it a donation creates an expectation that it's completely optional

Exactly, which is why we should not make it completely optional and call it a license. If it's completely optional it should be called a donation.

I can't speak for the immich team, but my understanding is that in order to make the development sustainable, the intention is to create an expectation that users should pay if they want to use immich. Now, they are not obligated to pay, and the code base is still open source, they have all the features, but the implicit social contract between the development team and the users is that users should pay, especially if they are getting value out of the project long term.

Donation model does not create this implicit social contract. It would be nice if it did, but I think the evidence is overwhelming that it does not.

In this sense an analogy to this situation would be tipping in restaurants in the US. If tips were called "completely optional donations to staff", the tipping rates would bu much lower. People tip mostly because they know they are expected to.

I don't think comparing this to tipping is doing it the favor you think it is.

Both this and tipping are similar in that they're technically not required but social norms and expectations push you to do so. The difference is that there is no expected benefit to tipping whereas the norm for licenses is that it unlocks previously blocked features and limits.

So overall I think calling this a tip would probably be much more favorable, because it lines up more with the reality that there is no benefit to doing so.

At the same time, people hate tipping for similar reasons that they hate this license - it abuses social norms to push people to give, and this expectation is codified and evidenced by the lower wages that tipped employees receive - in expectation of tipps filling the gap. Which is why I believe tipping should be abolished as well as calling the donation a "license". Both are deceptive for different reasons. Tipping because it's a way to hide part of listed prices, and this "license" because people are deceived (intentionally or not) that the license is needed to avoid restrictions. And immich team doesn't need to do anything to be deceptive besides using the term license - their intent doesn't really matter because the term license will mislead people even if all the marketing makes it clear that there is no benefit.

And I think the immich team is maybe on the cusp of understanding that "license" is deceptive - I mean really think about it. Is the only reason people are more likely to buy a license just because it feels fair? Or could it be that having a license makes users feel safe against restrictions on the software - restrictions that supposedly are not coming? I think it's a little bit of both, and benefitting from giving users that feeling of safety when the threat (feature restrictions and limitations) does not exist is plainly speaking deceptive.

Again I want to reiterate that I fully believe the Immich team has good intentions, but I do see why people were rubbed the wrong way or felt deceived even if there was no intention of that.

I can't speak for the immich team, but my understanding is that in order to make the development sustainable, the intention is to create an expectation that users should pay if they want to use immich. Now, they are not obligated to pay, and the code base is still open source, they have all the features, but the implicit social contract between the development team and the users is that users should pay, especially if they are getting value out of the project long term.

Donation model does not create this implicit social contract. It would be nice if it did, but I think the evidence is overwhelming that it does not.

In this sense an analogy to this situation would be tipping in restaurants in the US. If tips were called "completely optional donations to staff", the tipping rates would bu much lower. People tip mostly because they know they are expected to.

I think comparing this to the tipping situation in the USA is not healthy since that's a screwed up system to begin with.

tried my hand at making a better-looking mockup

That's really neat!

I like that.

this is the correct solution to this whole controversy.

Best way to implement it

What is this your screensize you normally use for Immich, in pixel?

My screen is 1080px tall and I get a few pixels of scroll too.

I think it's 1680x1050, on macbook pro 13in 2018

Yes, we are working on a mechanism where you can claim that automatically