Of course I have an opinion

Post #442,967 by drook 4/27/23 11:10:35 AM 4/27/23 11:10:35 AM Reply	Of course I have an opinion Yes, crafting the prompt is both skill and art. But more importantly, knowing what's "wrong" with the first draft and how to fix it is the real skill. I could set up a tripod aimed at a landscape and have it take a photo every second for a week, then go through the >600k images and select the "best" one. No one would deny my copyright. Or would they? I wasn't there when the shutter was triggered. But how is this different from sitting behind the camera and waiting for that second and pressing the shutter release? If I select this collection of elements and put them in this arrangement with this lighting and take a photo of it, that's a still life worthy of copyright. But painters, when the camera was invented, argued that you didn't do any work to create that image. Here's a more practical view: Bob spends a day feeding prompts to Midjourney and publishes the output. Joe - a professional art director with decades of experience - spends a month crating and refining prompts and publishes the output. Does anyone doubt that Joe's collection will be better than Bob's? If so, is that because Midjourney got better when Joe used it? Or is it because Midjourney is a tool - just like a camera is a tool - and the difference in output is the skill of the person using it? If your work can be replaced by Midjourney, your work isn't worth much to begin with. Now, the counter-argument: This hollows out the market for beginners. How will anyone ever get to be an expert if you can't get paid while developing your skill? I've got no answer for this one. -- Drew
Post #442,979 by crazy 4/27/23 1:31:23 PM 4/27/23 1:31:23 PM Reply	I wonder how this applies to code generators? If you're in a gui point and click environment that generates a whole bunch of code and occasionally you have to go in and tweak the code, is that code really considered yours? Has this been litigated?
Post #442,983 by drook 4/27/23 2:07:51 PM 4/27/23 2:07:51 PM Reply	Or compilers You didn't write that machine code, the compiler did. You just told the compiler what you wanted. I guess I can copy that now. -- Drew
Post #442,998 by CRConrad 4/28/23 2:27:57 AM 4/28/23 2:27:57 AM Reply	In my line of argumentation, that's cut and dry: If it's deterministic, i.e. the same points-and-clicks always make it generate the same code, then it's your points-and-clicks that completely define the compiled output. So of course the copyright on that output is also yours. Another angle to look at it from: Not all IDEs work the same way. Some, when you "paint" a UI window for your app, generate a bunch of executable code to create a window, to create a main menu, to create each menu item... And on and on. (Java IDEs, AFAIK?) Others have that code compiled into their class library's "AppWindow" and "MainMenu" objects, and the IDE only saves the properties you specify for your UI nested into each other, generate a single "Application.Start" line of executable code, and then at run-time the "Application" (singleton) object reads its (compiled-in resource) properties, finds an "AppWindow" object so calls "AppWindow.Create" and passes it its sub-properties; the window object's "Create" function reads its properties, finds a "MainMenu" spec, creates a "MainMenu" object and and passes it its sub-properties, the individual "MenuItem"s and their specs... And so on. Not much code was actually generated and saved for you by the IDE, only the compact specs of your UI -- the "actual brushstrokes" of the window(s) you painted, if you will. All the actual code didn't need to be generated as source text, because it was already compiled into your class library. Would that make the code you wrote, using that library, any less copyrightable? No, of course not. Why would it; isn't that exactly what class libraries are for? So, to get back to the first case: Then why would it be any less copyrightable just because it comes in the form of source code generated at (your) build time? In either case, your "brushstrokes" in the IDE determine the output just as exactly; what gets built is exactly what you "painted". NB: The above is all about traditional what-you-do-is-what-you-get IDEs. Once you build CodeGPT into an IDE the code you get isn't the code you wrote anymore, so no, then the copyright to that code can't be entirely yours any more either. Still pretty cut-and-dry, AFAICS. -- Christian R. Conrad The Man Who Apparently Still Knows Fucking Everything Mail: Same username as at the top left of this post, at iki.fi

Welcome to IWETHEY!