What happens if a project mixes different licenses? If I have an open source project that includes both BSD and GPL licenses as well as my own license, what will the overall license be or would different licenses apply to different parts of the code?
That depends of the combination of licences, up to the point that there may be no solution valid for all of the components and you have to rework your project. The terms from the different licences must be evaluated to see which terms are appliable to the final product. For example, the GPL licence affects all of the source code of your project, and not only to the GPL licenced components1. So, imagine that you get one component under a licence which does not provide the source code (not even to you, even less for distribution) and a GPL licenced component. Incompatibility! Keep in mind also that usually there are several "flavours" and versions of BSD and GPL licences (with some BSD licences being compatible with GPL while others at not), so there is no general rule. That said, BSD licences are usually pretty open, so if you have a mix of (GPL-compatible) BSD licences and GPL licences, you usually can redistribute this with any licence that meets the GPL licence restriction. And, since the GPL forbids adding any additional restriction to GPL licenced code, that is pretty much it. 1That is why GPL is sometimes called a "viral" licence, because it "infects" all the code of your project.
Are licenses not required to explicitly state Nah, not at all. Licenses state whatever they want. There is no authority to compel license writers to include any particular statements. In case a license you wanna use does not make sense, you either seek clarification or do not use it.
Your client is confused about how copyright law works (at least in the United States and virtually every other country I've ever heard about copyright in). If I were guessing, they read something like this from the United States Copyright Office: The copyright in a derivative work covers only the additions, changes, or other new material appearing for the first time in the work. Protection does not extend to any preexisting material, that is, previously published or previously registered works or works in the public domain or owned by a third party. and figured that because it's a derivative work, the copyright only covers the additions and changes they make, and there's no copyright protection for the original work. This misunderstands the law: the original work still has its own copyright (assuming it hasn't expired), and permission from the holder of the copyright on the original work is required to create that derivative work in the first place*. The copyright on the derivative work is separate—that is, both copyrights exist in parallel. * Some exceptions, such as fair use, exist, but would be unlikely to apply to the situation you describe.
The GPL that covers the OpenJDK certainly allows you to write and distribute your own Java implementation. On that point, your reading is absolutely correct. However, if that implementation is a derivative work of the OpenJDK, then the GPL requires you to make your derivative implementation available under the GPL as well, per the GPL's copyleft rules. If you follow the rules of the GPL, you can do exactly what you propose. Note that the Supreme Court ruling in Oracle v. Google found that using only API structure and names, without copying any underlying implementation, constitutes fair use, and therefore doesn't require copyright permission. If you hold your implementation to that standard and use/look at only interfaces while authoring your new implementation, then your new work is broadly allowed under copyright law, so you do not need to rely on the GPL's permissions (and therefore neither do you need to follow its requirements). Google didn't want to have to abide by the terms of the GPL, probably because due to concerns that the any GPL terms that applied to their Java implementation might also apply to other components of their system, which they wished to keep closed-source. In other words, if Google had claimed their acquired their right to use the APIs under the GPL, then they would have been required to put potentially the entire operating system under the GPL, which they had not done nor wished to do. For this case, the GPL has been largely ignored because Google has not followed the requirements of GPL in licensing their Java implementation (and operating system that uses it), so there's no point in Google trying to claim that their right to use the API came from the GPL. Furthermore, Google claimed that they didn't use any of Oracle's copyrighted material, so it's not possible for them to say their use of Oracle's material was licensed under the GPL, as they claim there was no use whatsoever, licensed or otherwise. This is explained at length on fosspatents.com's article &quot;Q&amp;A on the Dec. 4 Oracle v. Google Android-Java copyright hearing before the Federal Circuit&quot;: 2. Q: Does this litigation involve Google's rights to use certain Java code under an open source license? A: No. Google could have incorporated Java into Android on open source terms, but chose to eschew the GNU General Public License (GPL) because of its &quot;copyleft&quot; feature. [...] If Google had ever claimed in this litigation that Android's incorporation of Java was authorized under the GPL, this would have been inconsistent with its claim that it didn't use any copyrightable material (you can only license something, on whatever terms, if it's protected) and, far more importantly, a blatant violation of Rule 11 (truthful pleading standard) resulting in sanctions for Google and its counsel. The GPL affords you four freedoms: it allows you to use software without paying for it (freedom 0), to modify its source code as you please (freedom 1), to redistribute copies (freedom 2), and to distribute your modified versions to others (freedom 3). But once you exercise freedom 3, you're subjected to the copyleft rule: you must make your modified version available under the GPL. As a result, Google would have had to publish Android under the GPL. But it did not. [...] [...]Google seeks to exercise as much control over Android as possible. If Android had to be released under the GPL (and only under the GPL, or at least a compatible copyleft license), Google would have a hard time keeping a growing number of core Android components like its Mail and Map clients or even the new on-screen keyboard (again, more about that in the next section) closed -- and Google's hardware partners would have to release their proprietary enhancements such as Samsung's Touchwiz and HTC Sense under the GPL, which would run counter to their objective of differentiation because their competitors could then use the same code.
The whole purpose of a patent is that the contents of the patent becomes public knowledge, in exchange for a time limited monopoly. Therefore you are allowed to do anything, since you are not just allowed but expected to examine the patent in order to improve on it, except that you need a license to sell or give away products implementing the patent as long as it is valid. The only thing to be careful about is that by publishing source code, you might be enticing others to infringe on the patent, so I'd recommend not to do that without advice of a lawyer. PS. With software, the interpretation of "making" software in patent law may be a bit surprising. There was a major case between Microsoft and AT&amp;T about that. The software developer isn't "making" the software. The build engineer putting everything together isn't "making" the software. The CD manufacturer making a million copies isn't "making" the software. The person installing it on their computer is the one who makes it.
You Own The Code To answer your question on whether or not it is copyright infringement: Yes, you do own the rights to the written code but posting it on Github gives Github the right to store, archive, parse, and display Your Content, and make incidental copies, as necessary to provide the Service, including improving the Service over time. This license includes the right to do things like copy it to our database and make backups; show it to you and other users; parse it into a search index or otherwise analyze it on our servers; share it with other users; and perform it. To simply put it, no matter what license you use, you give GitHub the right to host your code and to use your code to improve their products and features. This license does not grant GitHub the right to sell Your Content. It also does not grant GitHub the right to otherwise distribute or use Your Content outside of our provision of the Service, except that as part of the right to archive your Content. So with respect to code that’s already on GitHub, I think the answer to the question of copyright infringement is fairly straightforward. Things aren’t quite as clear-cut in a scenario where Copilot is trained on code that is hosted outside of GitHub. In that situation, the copyright infringement question would hinge largely on the concept of fair use. If Copilot is being trained on code outside of GitHub, we accept that at least some of what they’re looking at is copyrightable work. So, the question then becomes if it’s fair use. Now, you ultimately can’t conclude definitively that something is fair use until you go to court and a judge agrees with your assessment. But I think there’s a strong case to be made that Copilot’s use of code is very transformative, a point which would favor the fair use argument. There is precedent for this sort of situation. Take the case of Google Books, for example. Google scanned millions of books, provided people who were doing research with the ability to search the book, and provided the user a small snippet of the text that the user was searching for in the book itself. The court did in fact find that was fair use. The use was very transformative. It allowed people to search millions of books. It didn’t substitute for the book itself. It didn’t really take away anything from the copyright holders; in fact, it made it easier for readers to access the work and actually opened a broader market for book authors. And, it was a huge value add on top of the copyrighted corpus. In the latter scenario, a lot depends on the thoroughness and the length of Copilot’s suggestions. The more complex and lengthy the suggestion, the more likely it has some sort of copyrightable expression. If a suggestion is short enough, the fact that it repeats something in someone else’s code may not make it copyrightable expression. There’s also the question of whether what’s being produced is actually a copy of what’s in the corpus. That’s a little unclear right now. GitHub reports that Copilot is mostly producing brand-new material, only regurgitating copies of learned code 0.1% of the time. But, we have seen certain examples online of the suggestions and those suggestions include fairly large amounts of code and code that clearly is being copied because it even includes comments from the original source code.
I would argue that no, there is no copyright for the restored work. Independent copyright is only possible for any original material added, as previously discussed on this site. In this case, the added work was a technical process rather than a creative process, and technical processes cannot be protected by copyright. Copyright licenses would therefore be ineffective. However, I believe one could still impose a license based on owning the copy as opposed to the copyright (contract might be a better term in this case). However, if a third party managed to obtain a copy through some other avenue, any such contract would not be binding on them and nothing could be enforced against them unlike with copyright laws. Another way a license might be imposed is through patent protections, as technical processes can be protected via patents. However, I'm not as familiar with patent law, and this doesn't appear to be the claim being made.
In practice, it is abundantly clear to which entity the “Free Software Foundation” refers, even if the FSF were to change its name, even if there are unaffiliated organizations with the same name. Version 3 of the GPL also contains a link to the FSF website, making it clear which organization this referred to in 2007 when the license text was published. If there are doubts about the identity of the FSF in the future, it will be possible to trace the identity back to the 2007 FSF e.g. through public filings that the FSF is required to make available as a non-profit. Previous versions of the GPL contained an address for the FSF, which similarly disambiguates the identity of this entity at the time of writing. The FSF also holds a trademark for the brand &quot;Free Software Foundation&quot; in the US and EU, preventing an unaffiliated organization from using this name in an international context. Of course this doesn't affect an organization in Uruguay, but it's very clear that such an Uruguyan entity is not the FSF that wrote the GPL. The interesting questions is what happens if the FSF is dissolved. Can it assign its responsibilities and rights as the GPL license steward to someone else? I assume it can, and that the subsequent license steward would be able to produce sufficient documentation to substantiate this claim. If not, those are likely to be some interesting court cases.