Not all jurisdictions are the US, and not all jurisdictions allow fair use, but instead have specific fair dealing laws. Not all jurisdictions have fair dealing laws, meaning that every use has to be cleared.
There are simple algorithms that everyone will implement the same way down to the variable names, but aside from those fairly rare exceptions, there's no "maximum number of lines" metric to describe how much code is "fair use" regardless of the licence of the code "fair use"d in your scenario.
Depending on the context, even in the US that 5-second clip would not pass fair use doctrine muster. If I made a new film cut entirely from five second clips of different movies and tried a fair use doctrine defence, I would likely never see the outside of a courtroom for the rest of my life. If I tried to do so with licensing, I would probably pay more than it cost to make all those movies.
Look up the decisions over the last two decades over sampling (there are albums from the late 80s and 90s — when sampling was relatively new — which will never see another pressing or release because of these decisions). The musicians and producers who chose the samples thought they would be covered by fair use.
I have just started adding DCO to _all_ of the open source code that I maintain and will be adding text like this on `CONTRIBUTING.md`:
---
LLM-Generated Contribution Policy
Color is a library full of complex math and subtle decisions (some of them possibly even wrong). It is extremely important that any issues or pull requests be well understood by the submitter and that, especially for pull requests, the developer can attest to the Developer Certificate of Origin for each pull request (see LICENCE).
If LLM assistance is used in writing pull requests, this must be documented in the commit message and pull request. If there is evidence of LLM assistance without such declaration, the pull request will be declined.
Any contribution (bug, feature request, or pull request) that uses unreviewed LLM output will be rejected.
---
I am also adding this to my `SECURITY.md` entries:
---
LLM-Generated Security Report Policy
Absolutely no security reports will be accepted that have been generated by LLM agents.
---
As it's mostly just me, I'm trying to strike a balance, but my preference is against LLM generated contributions.
> any issues or pull requests be well understood by the submitter
I really like this phrasing, particularly in regards to PRs. I think I'll find a way to incorporate this into my projects. Even for smaller, non-critical projects, it's such a distraction to deal with people trying to make "contributions" that they don't clearly understand.
In practice, investigations tend to find the results for which the investigation was started. At the beginning of the article, it was also suggested that such investigations in Amsterdam found no higher rate of actual fraud amongst the groups which were targeted more frequently via implicit bias by human reviewers.
In North America, we know that white people use hard drugs at a slightly higher rate than non-whites. However, the arrest and conviction rate of hard drug users is multiples higher for non-white people than whites. (I mention North America because similar data exist for both Canada and the USA, but the exact ratios and which groups are negatively impacted differ.)
Similarly, when it comes to accusations of welfare fraud, there is substantial bias in the investigations of non-whites and there are deep-seated racist stereotypes (thanks for that, Reagan) that don't hold up to scrutiny especially when the proportion of welfare recipients is slightly higher amongst whites than amongst non-whites[1].
So…saying that the goal is to avoid penalizing people for [innate characteristics] is more correct and a better use of time. The city of Amsterdam already knew that its fraud investigations were flawed.
Each of those has tradeoffs compared to Dockerfiles (I have no need for bazel, but if I did, then adding `rules_oci` might be a win-win, rather than using a Dockerfile). If I used Nix, then the Nix dockerTools would be a huge win (I don't use Nix). If I were shipping Go programs, `ko` would likely be a good baseline.
Buildah is the only serious alternative in my opinion.
You lose automatic layer caching, but in exchange you can use the same tools (RUN, ADD, etc) within a much more powerful shell environment.
I wrote a Buildah wrapper that uses a shell script harness to polyfill the familiar Dockerfile syntax while adding several extra goodies - mainly the ability to bake runtime arguments (mounts, ports...) into the image. Very handy!
Buildah's ability to mount the container in an unshare environment is pretty magical for copying stuff in and out of it.
That said, in the end I'd still rather build containers with something other than an imperative sequence of commands, so my heart is going to be forever with nix2container and bazel's rules_oci.
He won 49% of the votes cast. He did not get a majority, but a plurality. The turnout was ~64%, so he got ~30% of the possible votes. His main opponent got about ~28% of the possible votes.
He doesn't have the mandate he thinks he does, but he's a megalomaniac led by his nose ring by the psycopathic megalomaniacs behind Project 2025, which ~90% (more?) of Americans said that they didn't like when they saw it.
Sorry, but I don't think these percentages, turnouts, and other technicalities matter, at all.
This is how the American people has chosen to represent themselves. The American people created the system, and the Americans knew their own system. The system produced this guy.
Now, why does it matter which percentage did he get? He got enough, did not he? And obviously he does have the mandate, because he is able to do things his way.
Looks neat, but I won't use it or recommend it to anyone because it's built with Flutter.
I understand your reasons for choosing it, but that does not change that Flutter apps feel completely _wrong_ on any platform except Android, but most especially on iOS/macOS and the web. (This is unsurprising because Flutter is essentially a modern day implementation of Swing complete with personalities, and it's just as incorrect in its styling as Swing was. It's worse for the web because Flutter explicitly eschews standard web technologies in favour of either one big canvas or lots of little canvases.)
You’re welcome to think that, but it's not a dumb take — it is an aesthetic and technical take (you know, de gustibus non est disputandum).
My attention is valuable (at least to me and those around me), and I choose not to waste that attention on applications that are built with a framework that quite deliberately disrespects the platforms I choose while presenting a badly drawn version of the thinnest layer.
On macOS and iOS, Flutter pretends to conform to platform standards, but it does so very badly (I can always tell if I'm using a Flutter app; it's just off…and my battery life suffers because Flutter is such a bad citizen). Honestly, I probably wouldn't hate Flutter on iOS if it didn't pretend to conform to iOS standards while missing the mark (just like every Google app misses the mark on what an iOS app should look like; it's just wrong).
On the web, Flutter is even worse by pretending that there's only one HTML tag, <canvas>, and throwing away _all_ of the rest of HTML to do everything else that HTML does, but worse and less accessibly. That, ultimately, is unforgivable and a waste of everyone's time.
Regardless of how useful gioazzi's project may be, the technical choices made put it well outside of the boundaries where I am comfortable recommending its use to anyone — and that's fine. I posted a similar take about someone who did a Show HN about a project they made which required a Google login; I was interested in seeing what they had done until I saw that requirement. That technical choice, while a valid one, put it well outside of my "I will try this thing at all" zone.
I shared this stance because I know I’m not alone, and people need to know if their architectural choices put them outside of the market they are targeting. I might or might not be in their market, but it's still a useful thing to know that there's this one asshole in Toronto who won't use it because they took the "easy" way out for pseudo-cross-platform support. (I do not have the same reaction to React Native, but that's because it ultimately doesn't try to emulate the platform.)
Well of course as any technical choice this is a compromise These are all very valid points, that we did consider, but I think the alternatives were just not as good.
I feel less strongly about apps not looking like system apps; in fact, I kind of dislike apps that try too hard to look like the settings page: I like when they bring some variety, some personality, something that makes them stand out. Though I agree that broken interactions are unbearable, e.g. apps that break the "swipe back" gesture.
It could have been a web app as well (in fact, the initial version was), but some offline functionality was needed, and service workers messing up caching and iOS not being a great player with PWA, it just ended up being more painful than it should have been.
Or we could have built 3 apps, which I would have loved (but we are a team of 3, and working on a bunch of other things at the same time). Flutter does have a fairly good developer experience (its hot reload cycle is unmatched in my opinion), but of course native development, with all the support libraries you get from the platform, is on a different level.
(What even is native though? Is UIKit "more native" than SwiftUI? Is Safari native? And how about the web apps you open in Safari? It's JS code, but at some point it's compiled to ARM instructions, now running from the very same memory pages as Safari, does that make the web app native?)
Having said that, it's not like I need to convince you to try out our app, it's good that we have options and probably Apple Invites is what works best for you!
But out of curiosity, when is the last time you did try out a Flutter app?
Because they have been improving a lot, in fact for quite some time they ran better on iOS than on Android thanks to the new Impeller rendering engine (now default on Android as well)[1]
They did some work for accessibility on Web, too.[2]
BTW it's funny you mention React Native, I last built something with it a long time ago... and it wasn't that good - but I just realised I do use some React Native apps right now, so I guess they also improved a lot; I should give it a shot again!
It's been a while since I knowingly tried a Flutter app. Most of the ones that I have used even temporarily are Google garbage, and they are so bad that I will not give any Flutter app another try. I also fundamentally think that the technical approach of Flutter is wrong and should be resisted. You now not only have the "build platform lagging system platform" problem (something that happens to all non-native development options), but you have to trust that the Flutter people understand the target systems well enough to make the "draw" work (I think they fail every single time, just like Swing with its "windows" or "mac" personalities did).
But platform appearance is the thinnest layer (and Flutter can't even get that right because of its model). Design is about how something works (and a little about how it looks). Flutter apps don't look like iOS/macOS apps, but more than that, they don't feel like iOS/macOS apps. Flutter apps on the web will never feel like a proper web citizen, because they aren't — they're either a single canvas or a lot of canvases that have to have accessibility hacks instead of building on the platform.
If Flutter as a system decided to take the Swing approach of having its own "native" look and feel (https://www.geeksforgeeks.org/java-swing-look-feel/), I would not expect Flutter apps to conform to the high standard that I’ve expressed here. But the moment that they said "we can do better than Apple with the Cupertino personality", they failed — and IMO so does everyone who uses that.
(We had someone at work try to push Flutter as a cross-platform, including web, engine a couple of years ago. It was a complete disaster because he didn't know Flutter, didn't know Dart, and wasn't actually very good at architecting anything in the end, either. His React apps were nearly as bad. It took someone less than three weeks to rewrite the demo app from Flutter — which took 2 people ~6 months to build — to React Native and it did more, more smoothly.)
> Flutter apps feel completely _wrong_ on any platform except Android [...] Flutter explicitly eschews standard web technologies in favour of either one big canvas or lots of little canvases.
I think you're confused about how Flutter works on Android. It's not native to Android, it uses canvas with custom drawn implementations of most components there too – same as it does for iOS/macOS/web.
Oh, I’m not confused; there is no "native" for Flutter. I just don't think that Android has a meaningful platform aesthetic‡ and most people who use Android tend to expect nothing to necessarily make sense (these are the same people who use Windows).¶
‡ I periodically try Android devices and bounce off them because I find the UI to be obtuse or deliberately built for dark patterns. I was helping a neighbour with his new-to-him Pixel 8a and to see the pictures he had taken with his camera on the phone, he had to sign in with a Google account — and then we disabled the backup because he didn't actually care to back up the photos (they are ephemeral for his purposes). It took 45 minutes to figure this out because the settings and controls can only be set when you have already signed into the damned account.
¶ I am not saying that the people who expect nothing from Android would find iOS any better; they have just been trained through decades of bad UI/UX in Windows and Android (because they're cheaper) to understand that they have to fight with their computing devices to get anything done, so they don't expect anything better … and is it ever delivered to them, in spades. Flutter, here, does not help — but at least it doesn't clash with the fifteen different "platform" styles on your typical Samsung Android device.
The official statement from the White House calls out increased fentanyl production in Canada as the reason - but doesn't say that it's the majority of imports, you're right. The twitter summary says "There is growing production of fentanyl in Canada, and enough fentanyl was seized at the northern border last fiscal year to kill 9.8 million Americans.", though, and that seems like a lot.
This is an excuse, as an "emergency" is (effectively) the only way that such tariffs can be applied without input from Congress at all.
It's also likely a lie, given the number of lies told by Trump and his supporters. The two groups which should not be believed on this are the DEA (whose entire raison d’être is predicated on making things far scarier than they are so they can increase their power — I believe they are behind the proven lie that "touching fentanyl can kill you", which it can't) and the Trump administration (because the volume of lies spewed daily would overwhelm the New York City sewer system).
A "super lab" that used "cartel" processes was discovered in Canada a few months ago with almost 100 million[0] lethal doses of Fentanyl. It was only 11 miles from the border. The group was linked to a Khalistani transnational crime network; the same group of people (Punjabis) have also taken over our trucking industry[1]. Our border is the longest undefended border in the world and Canada is now taking in more than 1.5 million people per year[2], not including the 5 million on 'temporary permits'[3], mostly from India and China[4] and mostly un-vetted[5]. They get H2B visas with their Canadian passports and can travel across the border with ease. 1 billion doses worth of precursor chemicals were found in the port of Vancouver over a period of just 3 months last year[6], all coming from China. Halting immigration and shutting off the precursor chemical supply from China via the port Vancouver is all my clown show of government had to do to avoid this trade war. Stopping the flow of these brutal new drugs will do more to save both our economies than any amount of 'USA owned' tar sand ever could.
I will simply point you to the iTerm2 AI kerfuffle (https://news.ycombinator.com/item?id=40458135) as proof that some in open source _are_ in a mad rush to bolt on completely unnecessary "features".
It was a bad choice that never should have been implemented as "enabled but not configured", and I have moved away from iTerm2 as a result. I am sure that others have as well. (The grudging move to make it a separately downloadable plugin was good, but too late IMO.)
And it might be that next month there's a different homepage with more details. For a launch where all "marketing" has been via blog post, discord, and discussions across various nerdy social media sites…I'm more than happy for them to have some fun to celebrate this.
There are people who have been watching this for a few months waiting for it to go 1.0 — and, at least on day 1, "if you know, you know."
There are simple algorithms that everyone will implement the same way down to the variable names, but aside from those fairly rare exceptions, there's no "maximum number of lines" metric to describe how much code is "fair use" regardless of the licence of the code "fair use"d in your scenario.
Depending on the context, even in the US that 5-second clip would not pass fair use doctrine muster. If I made a new film cut entirely from five second clips of different movies and tried a fair use doctrine defence, I would likely never see the outside of a courtroom for the rest of my life. If I tried to do so with licensing, I would probably pay more than it cost to make all those movies.
Look up the decisions over the last two decades over sampling (there are albums from the late 80s and 90s — when sampling was relatively new — which will never see another pressing or release because of these decisions). The musicians and producers who chose the samples thought they would be covered by fair use.