You're restricting speech whether or not you confine your censorship to only AI-generated images.
Correction: Fortunately, not unfortunately. A rule like that would prohibit any form of public / street photography, news videos, surveillance videos, family photos with random strangers in the background... it's not reasonable at all.
You mean "3. Object Code Incorporating Material from Library Header Files."? That section 3? I think they're using a bit more than just header files. Section 4 "Combined Works" is the one that applies here.
Also even if section 3 did apply they'd need to follow 3.b as well as 3.a and include the full text of both the GPL and the LGPL.
Technically it can be statically linked, but then you would need to provide artifacts (for example, object files for the non-LGPL modules) enabling the end user to "recombine or relink" the program with a modified version of the LGPL code.
Dynamic linking is usually simpler, though. And the DRM issues apply either way.
Section 6 of the GPLv3, which the LGPLv3 includes by reference as one of the required distribution terms in paragraph 4.d.0:
Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
(emphasis added) There is the alternative of following 4.d.1 instead, but that's only if the application links against a shared library already present on the user's computer system—it couldn't be distributed with the program.
GPLv3 section six offers five alternative methods of satisfying the obligation to provide source code. The first (6.a) applies only to physical distribution and must include source code with the physical media. The second (6.b) also requires physical distribution plus a written offer to provide the source code to anyone possessing the object code. The third (6.c) is the one I mentioned that applies only "occasionally and noncommercially" for those who received a written offer themselves under the previous clause. The fourth option (6.d) allows for the source to be provided through a network server:
If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.
The fifth and final alternative (6.e) pertains to object code provided through P2P distribution, with the same requirements as the fourth method for the source code.
Geoblocking in such cases would not be sufficient. For one thing your geo-IP database will never be perfectly accurate, even without considering that "data subjects who are in the Union" can connect to your site via proxies or VPNs with non-EU IP addresses. For another you still need to respond to GDPR requests e.g. to remove data collected on a data subject currently residing in the EU, even if the data was collected while they were outside the EU, and you can't do that if you're blocking their access to the site. For a newspaper in particular the same would apply to any EU data subject they happened to report on, whether they had previously visited the site or not.
They never should have made opt-in an option in the first place. All the legitimate reasons to store data are already permitted without asking permission (required for the site to function, or storing data the user specifically asked the site to store such as settings). All that's left is things no one would reasonably choose to consent to if they fully understood the question, so they should have just legislated that the answer is always "no". That plus a bit more skepticism about what sites really "need" to perform their function properly. (As that function is understood by the user—advertising is not a primary function of most sites, or desired by their users, so "needed for advertising to work" does not make a cookie "functional" in nature. Likewise for "we need this ad revenue to offer the site for free"; you could use that line to justify any kind of monetization of private user data.)
In what sense do you think this isn't following the email standard? The plus sign is a valid character in the local part, and the standard doesn't say how it should be interpreted (it could be a significant part of the name; it's not proper to strip it out) or preclude multiple addresses from delivering to the same mailbox.
Unfortunately the feature is too well-known, and the mapping from the tagged address to the plain address is too transparent. Spammers will just remove the label. You need either a custom domain so you can use a different separator ('+' is the default but you can generally choose something else for your own server) or a way to generate random, opaque temporary addresses.
If you want to talk about non-compliant address handing, aside from not accepting valid addresses, the one that always bothers me is sites that capitalize or lowercase the local part of the address. Domain names are not case-sensitive, but the local part is. Changing the case could result in non-delivery or delivery to the wrong mailbox. Most servers are case-insensitive but senders shouldn't assume that is always true.
Basically, if the personal information required is necessary for the business to actually do the service you're asking them to do for you, it's considered a legitimate interest.
Serving ads—any ads, much less personalized ones—is not "necessary to actually do the service" the end user is asking for. As proven by the fact that there is a fully functional (albeit paid) version of the app without the ads.
It shouldn't matter whether the data collection is necessary for AdMob to work—to serve personalized ads—since the subject of the data collection isn't asking for that.
The most valuable thing is an experienced team who thoroughly understand both the specifications and the implementation as well as the reasoning behind both. Written specifications are great as onboarding and reference material but there will always be gaps between the specifications and the code. ("The map is not the territory.") Even with solid specifications you can't just turn over maintenance of a codebase to a new team and expect them to immediately be productive with it.
Who is enforcing this and how?
Liability would be decided by the courts or another form of binding arbitration. Obviously. Harming someone through action or negligence is a tort, and torts are addressed by the judicial branch. Both sides would present their arguments, including any scientific evidence in their favor—the FDA or similar organizations could weigh in here as expert witnesses, if they have something to offer—and the court will decide whether the vendor acted reasonably or has liability toward the defendant.
If you knowingly sell me a car with an engine about to fail, you are in no way accountable.
If you knew that the engine was about to fail and didn't disclose that fact, or specifically indicate that the vehicle was being sold "as-is" with no guarantees, then you certainly should be accountable for that. Your contract with the buyer was based on the premise that they were getting a vehicle in a certain condition. An unknown fault would be one thing, but if you knew about the issue and the buyer did not then there was no "meeting of the minds", which means that the contract is void and you are a thief for taking their payment under false pretenses.
Anyway, you continue to miss the point. I'm not saying that everyone should become an expert in every domain. I'm saying that people should be able to choose their own experts (reputation sources) rather than have one particular organization like the FDA (instance/community moderators) pre-filtering the options for everyone. I wasn't even the one who brought up the FDA—this thread was originally about online content moderation. If you insist on continuing the thread please try to limit yourself to relevant points.
A smarter system won't just take the mean of the votes from different instances but rather discard outliers as invalid input (flagging repeat offenders to be ignored in the future) and use the median or mode of the remainder. The results should also be quantitized to avoid leaking details about sources or internal algorithms; only the larger trends need to be reported.
Of course you could always just keep the collected data private and only provide it to customers willing to pay $$$ for access, which handily limits instance operators' ability to reverse-engineer the source of the data. And nothing prevents you from using separate instances for public and private data sets.