I wonder how this applies to code generators?

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.

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!