How should code produced by automated tools be licensed? Say a tool that does some sort of automatic code generation or modification, like a formatter or linter, is run as a service that automatically creates pull requests to projects on Github. Who owns the copyright of those changes? What license restrictions would it have? Could the tool creator say "all changes made by this tool from now until the end of time are my intellectual property" even though they weren't involved in making the individual changes? How might a more conscientious tool creator properly declare that their tool's contributions can be merged in without licensing and IP problems?
As @amon stated in a comment, copyright requires creativity. If the author of a tool wants to claim copyright on the output of that tool, then that output must contain something that required the creativity of the tool author. For a tool that just re-indents its input, the output is created from the input with a mechanical, non-creative, transformation and the output does not contain any creative content that wasn't already present in the input. For that reason, authors of such tools can't claim any copyright on the output. For a tool like bison, which was mentioned in the comments, the output contains a measurable amount of creative content that was not present in the input, but which was provided by the authors of bison. For that reason, the authors of 'bison' do have a copyright claim on the output of the tool (for which they give a broad permission to use). So, the basic question becomes, how much of the (creative) content of the output can be traced back to the tool itself and not to the input that the tool processed. For linters/formatters, that is likely to be very little. For code generators, it can be anywhere between very little and all of the output. The license restrictions on the code produced by the tool itself are by default the same as the license restrictions on the source of the tool, but the tool author can choose to apply any other license to the tool code that ends up in the output. If the output of the tool is, at least in part, dependent on an input file, then the authors of the input file also have a copyright claim on the tool output (as their creative work influenced the output), so the tool author can not claim exclusive ownership. The usual situation is that for tools that don't add creative content to the output, the author explicitly states that the don't have any copyright claims on the output. For tools that do add creative content, that content might be released under very permissive conditions (like, "you can use the output as a whole for any purpose, but you can only separate out the code that comes from the tool's codebase if you adhere to the &lt;X> license")
Whenever there is a license to share things, the license creator wants the license to be widely used, but absolutely does not want slightly different licenses that could be used to trick people, or that just cause legal problems when used. Normal copyright law applies. And for the reasons above, the GPL license as an example allows you to copy the license verbatim but absolutely doesn’t allow you to make any modifications other than changing who is the person licensing a work. I would be curious what happens legally if someone licenses something with a sneakily modified copy of the GPL and then makes claims against a licensee who assumed it was the original GPL.
A document can be distributed under more than one license. Just because it has been made available under a CC license for free, doesn't mean that IEEE can't negotiate a different license with different terms that allow them to sell the content. (This is similar to the way that a software library can be available for free under a license that permits non-commercial use, but also be made available for a fee for commercial use.) If you want to know whether IEEE is legally selling Aaron Swartz's manuscript, you can contact Morgan &amp; Claypool, the publisher that owns the copyright, and ask them whether this use by IEEE has been authorized by them. For the other documents you mention, contact MIT Press. Etc.
Assumptions Let us assume that the code involved was created during the period of employment, was within the scope of that employment, and was validly work-made-for-hire (WFH). In that case, the code copyright is owned by the former employer.dn the person who wrote it has no more rights than a random stranger would. I am also going to assume US law. Ownership of Ideas Who owns the ideas, the knowledge of how these libraries work? No one does. In the absence of a patent, no one ever &quot;owns&quot; an idea. ]17 USC 102(b)](https://copyright.gov/title17/92chap1.html#102) provides: (b) In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work. Derivative Works Copyright law does prohibit anyone making a derivative work from a work protected by copyright without the permission of the owner. A derivative work is one &quot;based on&quot; the source work. The classic case is a translation. Exactly when a piece of software is a derivative work of another is fact-dependent. Bu several things are clear. If the source work is trivial and obvious, ther may not be sufficient &quot;originality&quot; for the source work to be protected by copyright at all. If the source work is not protected by a valid copyright, nothing is a derivative work of it. A &quot;hello world&quot; program, for example, is probably not original enough for any copyright. A straight-forward implementation of a basic algorithm like quicksort is probably not original enough, either. If there is only one way, or only a small number of ways, to express the ideas of the source work, the merger doctrine applies. This means that the expression of the work is merged into the idea, leaving the expression unprotected. When the merger doctrine applies, there is, in effect, no copyright. If a work copies ideas from a source, but none of its particular expression of those ideas, the result is not a derivative work, and is not an infringement of copyright. If a work is definitive, but is also a fair use of the source work, it is not an infringement. The usual four-factor fir use analysis must be made to determine this. In particular, if a work is highly transformative, it is likey to be found to be a fair use. Issues from the Question What if the new code (presumably, in the case of something simple) comes out exactly the same (even if I rewrite it without looking)? That Rather suggests that the work was too trivial to be original enough to have copyright protection at all, or else that there are only a few ways to express the idea, and the merger doctrine applies. But if neither o those were true, this might be an infringement. [* To be coninued*]
You are creating a derivative work. You are only allowed to do this if the library comes with a license that allows this. If you want to give your derivative work to anyone else, copying it is copyright infringement unless the license allows it. Copying the derivative work and attaching a different license is most likely to be copyright infringement. And if people receive a copy with an open source license that is not justified and rely on it, that’s creating one unholy legal mess for everyone involved and can be massively more expensive than plain copyright infringement. No license means you don’t have permission to do anything with it, not creating derivative work, not distributing it, and certainly not publish it with an open source license.
If you can accurately describe in one license what constitutes the conditions where you wish to let users freely copy the software, and forbid any other uses, then you can also offer a second license that allows specified commercial uses with a second license. Basically, it reduces to being clear (to yourself and to the world) on what you mean by &quot;service&quot;, and what you want to allow vs. prohibit. That SSPL has a section on &quot;Offering the program as a service&quot;, though it does not prohibit it, it just requires the user to make the source code available for free. You could rewrite that section, and then hire a lawyer to give an opinion as to whether your re-write does what you think it does. Pay attention to the fact that you are interested in restrictions on &quot;cloud servers&quot; but the SSPL permissions are broader.
Stack Exchange questions are not public domain, they are protected by copyright. Authors have granted a license under Subscriber Content, specifically content is perpetually and irrevocably licensed to Stack Overflow on a worldwide, royalty-free, non-exclusive basis pursuant to Creative Commons licensing terms (CC BY-SA 4.0) As long as you comply with the terms of the CC BY-SA 4.0 license, you may copy user content.
As long as you own the copyright to the works, you can even publish the source code itself under two different licenses, which can be radically different. For example, MySQL is licensed under both a commercial and an open-source license. Given that you can publish a single piece of work as multiple licenses, it is your choice which one you wish to grant to the book or the code, as long as you own the copyright.