We already have laws covering close derivatives - in this case it might not be clear who is the inspiration but there is no novel creativity... everything these networks produce is derived from artists - there is no added novelty.
I think that's exactly the sort of flawed analysis these copyright trolls do. They see something they never would have had a hand in and count it as "theirs", and then greed kicks in. It's like the old MPAA/RIAA calculations of lost revenue that assume someone would have bought a CD if they didn't download a song. Only worse because at least in the downloading case, they are a 1:1 substitute.
In almost all cases I'd guess that artists whose style is being copied by many genAI users are getting way more exposure than in some alternate universe where midjourney didn't exist. But nobody looks at it that way, they just see somebody else making profit and think they deserve some.
it's derived from the original and competes with the original
if it was parody or commentary or otherwise found a new market, it might be allowed under fair use, but the fourth factor of fair use concerns the effect on the market value of the original
Having a waitlist was a smart approach for Bluesky. Gives them an opportunity to scale and polish the user experience while building hype for people without an invite.
It's not clear why it would need to be if it runs as a online service. I would say this is analogous to a search engine index. Google for example likely has lots of GPL code in it's index in some transformed form and yet there is little dispute that this is legal.
> I would say this is analogous to a search engine index. Google for example likely has lots of GPL code in it's index in some transformed form and yet there is little dispute that this is legal.
I'd disagree with the comparison, pretty vehemently. Copilot can generate new code. It isn't just some storage mechanism.
Interesting, so your argument is not about parroting but specifically about the novel code Copilot generates. My sense is that it would be fine for all licenses except for AGPL as this is an online service and is not "distributed" per say. That is if you don't buy the argument that machine learning is a transformative work so it doesn't matter what the license is, which is the position of current US caselaw.
No, my argument is that Copilot is specifically _not_ a storage mechanism, but is producing verbatim GPL'd code, meaning that as a piece of software, it is not exempt from the GPL.
> When Jeff and I were talking about the initial design of Stack Overflow, I told him about this popular Usenet group for the C programming language in the 1980s. It was called comp.lang.c.
> C is a simple and limited programming language. You can get a C compiler that fits in 100K. So, when you make a discussion group about C, you quickly run out of things to talk about.
> Also. In the 1990s, C was a common language for undergraduates who were learning programming. And, in fact, said undergraduates would have very basic problems in C. And they might show up on comp.lang.c asking their questions.
> And the old-timers on comp.lang.c were bored. So bored. Bored of the undergraduates showing up every September wondering why they can’t return a local char array from a function et cetera, et cetera, ad nauseum. Every damn September.
> The old timers invented the concept of FAQs. They used them to say “please don’t ask things that have been asked before, ever, in the history of Usenet” which honestly meant that the only questions they really wanted to see were so bizarre and so esoteric that they were really enormously boring to 99% of working C programmers. The newsgroup languished because it catered only to the few people that had been there for a decade.
The modern equivalent would probably be sorting StackOverflow questions by votes.
That blog post really hits hard how much Stackoverflow has become hostile to such users.
"please don't ask things that have been asked before, ever, in the history of stackoverflow" is the mantra the moderators now follow and it's maddening for the same reasons that Spolsky talks about in this post.
The modern equivalent is just stackoverflow itself. It has been very hostile to new users. Questions when allowed are incredibly esoteric and therefore hard to answer or over-specific and therefore not helpful to others.
In fact I'd say that now research by new users is punished. If they research and work on forming an abstraction for their problem and ask about that instead, there is a good chance the question will be closed as a duplicate or trip up some other issue.
If they just go ahead and "post their code" and focus on the very specific issue, there's a better chance it gets past moderation and gets answered.
Now part of that is deliberate on stackoverflow's part, they want people to post the actual problems they have and not post generic or general problems, but it does feel like an odd incentive at times.
There's a lot of blinkered and self-serving historical revisionism in that account. Two problems, just for starters: comp.lang.c didn't invent FAQ postings; it wasn't even Usenet that invented them. And frequently asked questions were and are not necessarily novice questions. So do not take it as gospel.
I would bet on AWS in this case as they will also likely have the support of anyone who wants to make a hosted service of those products. It will be interesting to see if eventually AWS starts making new APIs that diverge from the Elastic or if they chose to keep the product maintenance mode.
I understand that this is not what you meant, but AWS ES service has a different API than the one in the official Elastic documentation already - mainly that it’s a smaller subset of it. What may seem like a good decision for “aaS” product in general, is a real pain with ES specifically, because of how delicate it is for tuning.
It's also not that uncommon to see people go from Amazon go to Microsoft especially in teams like Azure. There's more difference between teams within the two of them than there is between the two as a whole. Although, people generally go to Microsoft for better work life balance and benefits. Going from Microsoft to Amazon to boomerang back to Microsoft is also quite common.
For me the thorny ethical issue is not so much working on directly evil stuff like missile targeting software for the military but software that has both military and civilian use. For example, consider a company that develops and RTOS that is used in both cars and missiles, where does that stand morally? Even the most benign technology can be used for evil so it's worth asking the question to what culpability individual bear for who their company sells their software to. In the case of SpaceX, I’m sure much of the code is the same between the military and the NASA use cases.
I've asked myself this question about even more abstracted/lower-level things, like - is it good to improve Kubernetes, knowing that this makes things better for big businesses and the military (cf. https://thenewstack.io/how-the-u-s-air-force-deployed-kubern...) and not really directly for individual people?
While it's tempting to say that there's no moral dimension this far out, I think that's not quite true - there is a moral dimension to making technology work more smoothly. It increases the ability of anyone with some power to do things at scale. On the one hand, it gives ability for anyone with tiny amounts of power to make use of it (consider the effect of, say, typewriters in the Soviet Union, or even farther back, the printing press in the hands of Luther's supporters). On the other hand, it absolutely increases the ability of people with massive amounts of power to use that power more efficiently (like the "war cloud"). My own view here is that, for those of us whose day job is in improving infrastructure / technical leverage, this increases how important it is for us as members of society to make sure that power is distributed equitably and justly. Since it's indirect, we don't have to advocate for this through what we choose to be directly employed on (the way we would if we were literally working on missile targeting software), and it's often difficult to do so, but we should advocate for this through how we engage with the political process (broadly defined) in the rest of our lives.
There's also a question of what sort of improvements you make to it. Security improvements are generally a thing you can feel good about: people with small amounts of power are much more likely to have security flaws exploited than to use security flaws offensively, so even if there's an argument that hardening some software makes it harder to attack evil businesses or evil governments, it also has the much more practical effect of making it harder for those entities to attack dissidents' personal devices. And similarly for what you choose to do: working on Signal helps the low-power individual much more than working on SELinux, even though both are conceivably dual-use.
