zlacker

>>dredmo+(OP)
I've been finding that the strangest part of discussions around art AI among technical people is the complete lack of identification or empathy: it seems to me that most computer programmers should be just as afraid as artists, in the face of technology like this!!! I am a failed artist (read, I studied painting in school and tried to make a go at being a commercial artist in animation and couldn't make the cut), and so I decided to do something easier and became a computer programmer, working for FAANG and other large companies and making absurd (to me!!) amounts of cash. In my humble estimation, making art is vastly more difficult than the huge majority of computer programming that is done. Art AI is terrifying if you want to make art for a living- and, if AI is able to do these astonishingly difficult things, why shouldn't it, with some finagling, also be able to do the dumb, simple things most programmers do for their jobs?

The lack of empathy is incredibly depressing...

>>meebob+kc
I think the correct way to get empathy is to use an equivalent that technical people understand, like Copilot:

* Can a Copilot-like generator be trained with the GPL code of RMS? What is the license of the output?

* Can a Copilot-like generator be trained with the leaked source code of MS Windows? What is the license of the output?

>>gus_ma+Ue
I don't think that's a road to empathy, because if we're talking about the matter of empathy i.e. "emotional should's" instead of nuances of current legal policy, then I'd expect a nontrivial part of technical people to say that a morally reasonable answer to both these scenarios could (or should) be "Yes, and whatever you want - not treated as derivative work bound by the license of the training data", which probably is the opposite of what artists would want.

While technically both artists and developers make their living by producing copyrighted works, our relationship to copyright is very different; while artists rely on copyright and overwhelmingly support its enforcement as-is, many developers (including myself) would argue for a significant reduction of its length or scale.

For tech workers (tech company owners could have a different perspective) copyright is just an accidental fact of life, and since most of paid development work is done as work-for-hire for custom stuff needed by one company, that model would work just as well even if copyright didn't exist or didn't extend to software. While in many cases copyright benefits our profession, in many other cases it harms our profession, and while things like GPL rely on copyright, they are also in large part a reaction to copyright that wouldn't be needed if copyright for code didn't exist or was significantly restricted.

>>Peteri+6o
It depends a lot of the type of software you are making. If it's custom software for a single client, then probably copyright is not important. (Anyway, I think a lot of custom software is send without the source code or with obfuscated code, so they have to hire the developer again.)

Part of my job is something like that. I make custom programs for my department in the university. I don't care how long is the copyright. Anyway, I like to milk the work for a few years. There are some programs I made 5 or 10 years ago that we are still using and saving time of my coworkers and I like to use that leverage to get more freedom with my time. (How many 20% projects can I have?) Anyway, most of them need some updating because the requirements change of the environment changes, so it's not zero work on them.

There are very few projects that have a long term value. Games sell a lot of copies in a short time. MS Office gets an update every other year (Hello Clippy! Bye Clippy!) , and the online version is eating them. I think it's very hard to think programs that will have a lot of value in 50 years, but I'm still running some code in Classic VB6.