@vermaden EUPL is a copyleft license, while BSD a permissive one. So they are very different.
EUPL is similar to a merge between LGPLv3+ and Affero GPL: like in Affero, if you use an EUPL library in a cloud service, you had to release improvements to the EUPL library under EUPL; but like in LGPL, you can maintain your product code propietary.
It is a rather clear license to read (simpler than the GPL), except the the differences between derivative-work and distinct product.
I'm writing this, because up to date EUPL is may favorite license :-)
@emilianosandri it is unrelated to the original suggestion, but I found very inspirational this blog post
@qwertz I agree.
In particular, I think that OSS suffers the lack of a user-community-way for funding the projects, i.e. an OSS-friendly way to support them with money. The developers are at risk of burnout, without economical benefits.
Hence, commercial companies, that have the money, can have a lot of influence (too much in case of hidden agenda) into many projects.
OSS was extremely successfull, but in real life, we need also money, not only code.
@stefano one of the best distro supporting ZFS is surprisingly NixOS. It can boot directly from a ZFS pool (I used in this way for at least one year, now I'm switching to FreeBSD).
BTW, the nix-store is similar to FreeBSD and OpenSUSE snapshots.
A problem of NixOS and FreeBSD on the desktop, is the fact that web browsers are not protected enough. Major Linux distro prevent the access to sensitive home directories, using AppArmour or SELinux or Flatpak.
FreeBSD could use Capsicum, but there are no current patches. A not isolated web browsers is scaring to me.
@contrapunctus I'm sorry. I have no words.
Maybe, you can also wear a bib/vest with the logo of openstreetmap and/or some informative material/depliant.
In this way people will know in advance what you are doing, and as side-bonus, they will know that openstreetmap exist.
@freemo imagine having a tree of messy private commits. You can: merge them; split them; reorder them; branch them; move commits into different parts of the tree; improve their name or description; undo/redo some of these private operations; and so on.
You work in complete freedom because it is a private tree of commits. The structure of the tree is a first class citizien of the tool, and it is an ever changing structure.
When a commit is in good shape and ready to be published, it become a public commit, and you cannot anymore change it.
The public commits are a linear order of high-quality commits. The last public commit become the new root of the messy tree of your private commits.
I'm a software developer. I live in Italy.