Thanks for the links Michael.
I think the first article makes an important point:
"I suspect that projects that have an ethical commitment to software
freedom will prioritize the GPL over other licenses, but for businesses
where there needs to be the balance we discussed earlier, I suspect the
MIT and Apache licenses will continue to grow in popularity."
This commitment to a software that is free and stays free, which allows
everyone to access and organize their private photos is exactly how I
understand the "Why this has to be free software" text:
https://github.com/photoprism/photoprism/wiki/Open-Source
The trust in this kind of freedom is fostered by the AGPL.
Unfortunately, the second article makes a really poor point about
security through obscurity in hardware and software licenses allowing
this bad practice. Yes, upgrading means more work. But this work is for
the immediate benefit of the end users. In fact Nextcloud (AGPL) is
shipped on millions of routers and open sources all features, no "Open
Core" or dual licensing.
https://nextcloud.com/blog/how-nextcloud-protects-your-business-from-license-uncertainty/
"Designed to protect the recipient of the software rather than the
vendor, [...]"
Software targeting end (home) users is having great success with the
GPL like Darktable, Nextcloud, LibreOffice (as opposed to OpenOffice
which is under Apache) and
https://sr.ht which recently made it to the
front page of hackernews. PhotoPrism itself is not a library but the
final solution incorporating many other tools. With a license like
Apache, other GPL licensed tools (like Darktable, gphoto) cannot be
included directly.
I think shipping those tools in individual containers and using the CLI
is no problem at all - a single binary however won't be possible.
On the upside an Apache licensed tool can always be used in A(GPL)
software.
https://dwheeler.com/essays/floss-license-slide.html
> 1. We rely on a lot of permissively licensed code and tools like Go
> itself, which uses a BSD style license. AGPL means we can take but
> don't give back (unless they change their license to A/GPL too).
Apache code cannot be to contributed to MIT/BSD projects either.
Developers can decide on their own if they want to contribute to those
projects upstream, but yes, the project itself wouldn't be able to do
that. Is that a bad thing?
> 2. Using AGPL can effectively prevent developers - like those working
> at Google - from contributing:
After some research I found that Googles aversion to AGPL is pretty
unique to them and went as far as banning other peoples AGPL projects
from Google Code (the "GitHub" of that time). But to free oneself of
the regulations of corporations is one of the purposes of PhotoPrism.
https://www.cnet.com/news/googles-festering-problem-with-the-agpl/
https://joeyh.name/blog/entry/prove_you_are_not_an_Evil_corporate_person/