My reading is they were simply trying to comply with regulations. It wasn't about what ideas they believed the religious texts were trying to convey, but whether their content met a certain definition set by law. The law could be poorly written, or it could be poorly and over-cautiously interpreted by F-Droid maintainers. But I didn't get the feeling they were acting on any kind of moral judgement or own belief about what's appropriate for children.
Does the Bible encourage violence or promiscuity? Not really, no. Does it mention and describe those things in some detail? Yes, absolutely. If that's the kind of content you need to remove from your store, then obviously you need to remove the Bible from your store. Whether that was really the case seems questionable at best, but the stated logic seemed pretty coherent to me.
Which regulations? F-Droid seems to be governed by Dutch law (see https://commonsconservancy.org/dracc/0039/ ). Do they have laws prohibiting all apps with any violence or promiscuity?
(As an aside, if they indeed had to follow some Dutch law and remove Bible and Quran apps, maybe F-Droid can be hosted by freedom.gov, US govt's new anticensorship portal..)
> The law could be poorly written, or it could be poorly and over-cautiously interpreted by F-Droid maintainers. But I didn't get the feeling they were acting on any kind of moral judgement or own belief about what's appropriate for children.
If F-Droid were being overcautious, they would have blocked social media apps too. Social media is explicitly the single biggest target of these “think of the children” app store laws after outright porn sites. F-Droid left Reddit and Mastodon clients unmarked. Am I supposed to believe that F-Droid honestly thought the law applied to apps containing only ancient religious texts, and not to social media? Has any other app store interpreted the regulations the same way? And if they truly believed that was a legal requirement, why did they reverse the policy after only a couple days of user complaints?
It’s heavily inspired by both TeX and Emacs, hence why it’s named after both of those. As if the author had added the best aspects of the two and then some.
Why should skin colour be specified at all? Why not leave it as an implementation detail? Yellow is the popular default choice, but it could very well be green, blue, pink, or anything really.
It seems like Taler has been coming along great and the biggest things it’s missing are more interest and adoption. There has been some first ‘real-world’ use recently, but it’s still far from becoming widespread, which would be a dream come true.
They don’t seem to provide a detailed comparison showing how each compression scheme fared at every task, but they do list (some of) their criteria and say they found Brotli the best of the bunch. I can’t tell if that’s a sensible conclusion or not, though. Maybe Brotli did better on code size or memory use?
It seems to me this point of discussion always tends to get way too much focus. Should it really raise concern?
Of all the people who interact with image formats in some way, how many do even know what an image format is? How many even notice they’ve got different names? How many even give them any consideration? And out of those, how many are immediately going to think JPEG XL must be big, heavy and inefficient? And out of those, how many are going to stop there without considering that maybe the new image format could actually be pretty good? Sure, there might be some, but I really don’t think it’s a fraction of a significant size.
Moreover, how many people in said fraction are going to remember the name (and thus perhaps the format) far more easily by remembering it’s got such a stupid name?
Because JPEG XL is the first format to actually bring significant improvements across the board. In some aspects AVIF comes close, in others it falls far behind, and in some it can’t even compete. There’s just nothing else like JPEG XL and I think it deserves to be supported everywhere as a truly universal image codec.
That’s an interesting speculation, but I’m inclined to believe their official reasoning. (That being they just didn’t really care about the format and/or went with whatever Chrome said at first. A year or so later they changed their mind and said they wanted an implementation in a memory-safe language, which prompted the JXL team to work on it.)
I’m not 100% sure on this in the case of AGPL, but I think you don’t need to relicense your project if you include AGPL code; you only need to make sure your project respects all the freedoms the AGPL requires it to (in a suitable way).
So your own code would still be under Apache, and people could follow only the Apache conditions if they only use your code. But combined with the APGL part, the project as a whole would of course have to follow the APGL conditions.
> you don’t need to relicense your project if you include AGPL code; you only need to make sure your project respects all the freedoms the AGPL requires it to (in a suitable way).
GPL and AGPL typically imply that your entire project is licensed under those conditions is my understanding. I find it silly to licensed something MIT or BSD but pull in some GPL code, since now the entire thing needs to comply. GPL is about end-user freedom by force against the developer. Don't get me wrong I love the GPL, but if I want to use a specific license I rather stick to that license.
Does the Bible encourage violence or promiscuity? Not really, no. Does it mention and describe those things in some detail? Yes, absolutely. If that's the kind of content you need to remove from your store, then obviously you need to remove the Bible from your store. Whether that was really the case seems questionable at best, but the stated logic seemed pretty coherent to me.
reply