In general, e.g. to place the files and their metadata like checksum, access rights, image previews, foreign keys right next to each other.
In the authors use case, it might also be easier to drop the executable and one big database file on a random shared file store in the company network instead of many small files and a database file for metadata.
Cool, thanks. The nice thing about the Pi one is that it (used to, at least) support Spotify and various streaming services. After a quick look I can't see that feature on those microcontroller versions.
Very fun to build, highly customizable and good for both beginner plug n play options. I enjoyed taking the old Fisher Price music box record player apart and turning it into an NFC based record player.
Lots of other great examples in the yearly showcase threads
For me, it is mostly about "sharing the code" as in: I put it somewhere and anyone who wants can use it. But if they adapt or remix it, they should also use a free license (ideally contribute back to my project).
> in the sense that it does not prevent tivoization?
I'm not sure, but I guess it does not protect against tivoization because if I were to distribute an executable or library, that could be used on a blackbox with proprietary code without them requiring to open their own code.
> For me, it is mostly about "sharing the code" as in
Sure, I did not express it correctly. I really just wondered about the tivoization.
> But if they adapt or remix it, they should also use a free license
I think that the code has to stay EUPL, but if you merge it into, say, a bigger GPL project, then the whole project can count as GPL. But the EUPL code inside stays EUPL, right?
You are right, there is a "double coverage". The EUPL just states that the compatible license (applied to the combined derivative work) will prevail in case it conflicts with the EUPL.
But none of the listed compatible licenses (i.e. GPL-v2 or GPL-v3) prohibit, for example, the coverage of remote/SaaS distribution: they may not impose it (SaaS loophole) but allow it. So the EUPL code inside the combined derivative will stay covered by essential EUPL obligations, including the modified code sharing in case of remote distribution, even when the combined work is globally distributed under the GPL.
If I understand you correctly, your advice is that EUPL is an unknown/obscure license and you would not choose it for that reason?
Thanks for the good luck wishes, but I don't intend to throw money towards enforcing the license at all. I mostly don't want to be liable for code that I open source.
And restricting it to EU would solve the problem that e.g. WTFPL or UNLICENSE have with countries that don't acknowledge public domain.
This is more a question out of curiosity for me, and many people react allergic to viral licenses, GNU or RMS so I was looking for alternatives because I also heard there were issues with CC-share-alike.
1. The bad actor case: On my side of the equation there is no practical difference between licenses. Enforcing one or the other has the same legal costs…either I lawyer up and enforce whatever license I used or I don’t.
2. The good actor case: When users are unfamiliar with a license they are less likely to use it (or in a business context less likely to be allowed to use it).
By the way, CC-0 is an alternative to the public domain.
> 2. The good actor case: When users are unfamiliar with a license they are less likely to use it (or in a business context less likely to be allowed to use it).
Businesses typically don't want copyleft because they don't want to share anything (even if that is counter-productive). If more codebases used copyleft, I'm convinced that more businesses would know how to deal with it.
My second thought here is that I don't like this "people won't use is" blackmail. I write software that I share for free, I am entitled to choose under which conditions you can use it. If you can't be arsed to spend the time needed to understand my conditions (and the EUPL is not exactly a 200-pages long license), then don't use it. It's not like you were going to pay me anyway, right?
Sorry, I didn't want to sound aggressive at all :-). Of course that's your choice. I was just sharing my preference.
In my experience, many developers tend to prefer the licenses that are better for their company. And I don't get that. They should prefer the licenses that are better for themselves. If my company is forced to use a GPL library because there is no alternative, then I get to open source my code. That's great for me personally! Conversely, if I get to publish code I wrote in my company, if I manage to do it under a copyleft license, it helps other developers open source their code.
I understand that GPL/LGPL maybe scary in some situations (how do you deal with LGPL in a proprietary iOS app?), but I haven't found a single example where MPLv2 doesn't work. I don't see a reason to use a permissive license, MPLv2 is always fine.
As a developer, it's never good for me to help a company get permissive code for free.
There are a bunch of other options/workarounds/hacks depending on the need. E.g. using getters or creating proxy objects https://github.com/anmolitor/intl-proxy, or event listeners, or postprocessing of the generated JS code, but those shouldn't be the first idea to reach for.
> So I made a package that wraps native RegExp. When 0.19 was released, I couldn't upgrade because of those 5 lines. The regex package eventually got regex.fromstring(). So I could've upgraded.
So it seems like by the time of the official release you could have replaced your five lines with `Regex.fromString`.
But the missing Intl API is definitely a huge pain, and I understand that you were switching away if you needed it extensively. Or expected to want other sync APIs wrapped.
A common way to solve something like this is with proxy objects like in https://github.com/anmolitor/intl-proxy but it does not give access to every feature in a nice way.
I went the route of least resistance and built the Elm compiler without the Kernel code check. But in the past few years I hardly needed that anymore.
To me it looks more like the elm-haters are out in force and the Elm users don't participate anymore on this site.
Many hateful comments here below a historic post prompted me to create a new account after a detox phase of >10 years.
So far I try to correct a false statement in the (as of writing this) top comment [1] or add a more neutral view [2].
And maybe I will add more of my personal opinion in the future - or participate in other interesting topics depending on my mood.
For anyone new to Elm, please know that you have a stable language with no major changes since 2018 and no official release since end of 2019, see https://iselmdead.info and decide if that is a bad or a good thing for you.
And if you are thinking of starting now, you should not focus on what undocumented feature (or hack) was taken away in 2018 that allowed injecting arbitrary JavaScript code that easily broke all guarantees of the language https://discourse.elm-lang.org/t/native-code-in-0-19/826 but rather if Elm fits your current (and maybe future) needs.
If it does not, keep looking for alternatives.
In the authors use case, it might also be easier to drop the executable and one big database file on a random shared file store in the company network instead of many small files and a database file for metadata.
And it might be faster to read files from db than from fs https://sqlite.org/fasterthanfs.html