When including libraries licenses, do I need to include the libraries&#39; dependencies&#39; licenses too? So I am building a project with SDL2_image, and I noticed that it includes libpng, jpeg, libtiff, and other dependencies. If I want the code to be closed sourced, do I need to include the dependencies' licenses too, or would just the base license (SDL2_image in this case) be enough?
You will need a license for any library that you are including in your product. Including libraries that you didn't really want to include, but which are needed by another library that you intentially include. And you will have to agree to all the licenses simultaneously, which may be difficult. If several libraries have conflicting licenses (that is you cannot possibly respect A's and B's license at the same time), then you must remove one of the libraries until no conflicts are left.
The software being free and open source has no impact on whether it infringes any patents or violates any copyrights. Copyrights attach to fixed representations of creative work in a tangible medium (e.g., the actual code and graphical elements of the software in question). As long as you aren't copying the copyrighted work of someone else, you should be in the clear. So, if you write your own code from scratch, or rely on code that you're allowed to use (e.g., "free" software with a permissive license that allows it to be used freely), you should be fine. On the other hand, if you copy a chunk of code that you aren't allowed to use, and then change the variable names so that it's superficially different, you're likely violating someone's copyright. Patents are a much more difficult question. To determine whether you would infringe any patents, you would have to read the independent claims of every patent that might be related. If you perform all the steps of any one of those claims, then you are infringing that claim (and therefore, the patent in which it is found). Unfortunately, this is much easier said than done. First, it may be difficult to search for all the potentially relevant patents, and once you've found them, there may be far too many to read. Second, claims are written in a type of language that is specific to patents, and someone without experience in patent law may not understand them correctly. Finally, the terms in the claims may not take on their plain English meaning, but rather may have been defined by the language in the rest of that patent, so it's possible that you might incorrectly think you were in the clear based on a misunderstanding arising from that. All that said, it may be best to go ahead with implementing an idea and then waiting to see what happens. Chances are that the implementation will arguably infringe some patent in some way, no matter what's done. But chances are also high that there will never be any worrisome enforcement action taken against it by a patent owner, simply due to the difficulty and expense associated with enforcing patent rights.
The MIT license is non-exclusive. If S is the sole copyright holder, S can issue any other non-exclusive license in parallel, and can also stop offering the software under the MIT license. However, open source licenses such the MIT license are generally understood to be irrevocable, so S cannot prevent other people from using the software who already received it under the MIT license terms. But: only if S is the sole copyright holder. There is no particular reason to believe that S would be the sole copyright holder. One does not gain a copyright ownership just by supervising other people, although an employer might gain copyright ownership over works created by employees (e.g. the US “work for hire” doctrine). That the copyright notices only mention S's name is an indication that S might be a copyright holder, but that's neither sufficient nor necessary for showing that S holds sole or joint copyright in the software. This leaves three relevant scenarios: S might be the sole copyright holder, in which case, yes, S can effectively discard the MIT license. This might be the case e.g. if there was some other copyright assignment, outside of the MIT license. What copyright transfers or assignments are valid depends on the local laws, e.g. some jurisdiction do not recognize copyright as transferable and at most allow the assignment of economic aspects of copyright. S might not be the sole copyright holder, but have additional permissions to the work. For example, there might have been extra licensing agreements, outside of the MIT license. Or S might have special rights for a work of joint authorship, if and only if the jurisdiction recognizes such additional rights. S might not be the sole copyright holder and not have any agreements outside of the MIT license. Then S has no additional rights, and is bound by the terms of the MIT license. This doesn't have to be a problem: S can still pretty much do whatever S wants with the code, as long as S fulfils the license terms. These are pretty simple: just keep a copy of the copyright+license notice with any copies of the software the students created.
Choice 2 is what the writers of the license have in mind. You own the physical media on which the copy is delivered, such as a DVD or floppy disk (if there was physical media). But you do not own the copy of the software, you merely have purchased a license to use it, which may be revocable under specified circumstances. This is different from the law in the case of a book. Why you buy a book, you own a copy of the book, although you do not own the copyright to the book, and may not make additional copies. The license model was adopted by commercial software distributors for several reasons, but largely to avoid the "first sale doctrine". When you buy a copy of a copyrighted work, you have the right (under US law at least) to lend, rent, sell, or give-away that copy. You do not need the permission of the copyright holder to do any of these. Those in the commercial software business did not want customers to be able to do those things legally. By making the software subject to a license, which is a contract, they could write that license to restrict or prohibit those rights. Sellers also wanted to prohibit reverse engineering of the software, and to restrict use of the software. (For example, to limit the user to installing it on a single computer.) There was at first much dispute over the enforcability of such license agreements. But most US courts now accept them as valid and enforceable, and copyright law has been modified to take account of them. Specifically, 17 USC 109 (2)(b)(1)(A) seems to include a legislative acceptance of this rule.
To use an API over a network connection (as opposed to, e.g., the Windows API), a user communicates a request to the API host, or server, and awaits a response. The host of the remote API can refuse to serve requests from users for probably any reason. Such services often require users to accept a license as a condition of using the service, and they may charge a fee as a condition of the license. A license to use a service is obviously not necessarily bound to a license for the use of its source code, just as the ability to reach the service is not dependent on the ability to see (let alone use) the code in any format, whether it be the source code or some compiled form of the code. In essence, source licenses and service licenses have different primary goals, at least inasmuch as the source license seeks to restrict someone who has actual physical access to compiled code, and possibly source code. Service licenses do not have that concern, though I have seen service licenses that also prohibit decompiling. This is probably the result of a CYA attitude among lawyers: the language is already in the standard software license text, and it doesn't hurt anything to leave it in, and it could help if a service user somehow managed to download the program code.
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.
For the GPL &quot;family&quot; of open source licenses, the answer is no. The GPL FAQ answers a closely related question: I'd like to license my code under the GPL, but I'd also like to make it clear that it can't be used for military and/or commercial uses. Can I do this? (#NoMilitary) No, because those two goals contradict each other. The GNU GPL is designed specifically to prevent the addition of further restrictions. GPLv3 allows a very limited set of them, in section 7, but any other added restriction can be removed by the user. More generally, a license that limits who can use a program, or for what, is not a free software license. I'd also recommend looking into &quot;Why programs must not limit the freedom to run them&quot; (the page linked by the FAQ). Stallman there argues (among other lines) that copyright is about limiting, well, copies rather than running the program. Similar to limiting the production of copies of a book as opposed to restricting what you are allowed to do with the information contained in the book. (I may add: or restricting who is allowed to read it.) Also, &quot;Imagine selling pens with conditions about what you can write with them.&quot; (So this is basically the FSF's position) The OSI definition of what requirements a software license must meet in order to be considered open source by them has relevant clauses: Free Redistribution (though this says that anyone can distribute the software, it does not directly talk about restricting to whom the software may be given) No Discrimination Against Persons or Groups No Discrimination Against Fields of Endeavor The OSI has a newsletter post &quot;Open Source responds to the Russia-Ukraine war: First thoughts from the Executive Director&quot;, which links to a further discussion on the topic. This is more about politics and ethics than legal questions. However, I think it's relevant in 2 ways: For the situation at hand: They point out that while the open source definitions do not allow the license to have such restrictions, there is nothing that forces you (or a repository provider) to serve &quot;customers&quot; from all regions worldwide. I.e., geoblocking downloads is not prohibited by the FOSS licenses. It does show that there is a discussion on licenses that are somewhat more restrictive than the current open source definitions. As David Siegel points out, there's nothing to keep you from putting such restrictions into a proprietary license. And if there are sufficiently many people who want to do that, we may see &quot;more restricted open source&quot; licenses in the future. (IANAL, but I'd expect there may be limits to what can be restricted in a boilerplate license wrt. anti-discrimination laws.) Independently of what the license allows, people are anyways bound by general law, e.g. sanctions.
IANAL, just a programmer with an interest in legal rules. Due to the very permissive nature of the MIT license, no, it does not appear that anything illegal has been done. Specifically, the section to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software (emphasis mine) grants everyone the right to modify your code and share those modifications, provided one includes the license. Since this person has included your license (including your copyright notice), they have followed the conditions of the license and are able to share your stuff. Legally. Ethically, I still think its ****. This might be a good starting point in selecting a license (note the Modification column). https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses The CC-BY-SA license family, as mentioned by Ron Beyer in comments is on this list, for example. TL;DR: You unfortunately granted a more permissive license than what you wanted/needed to. This was a BadThing(TM), analogous to giving too broad of access rights to a method or class. Determine your desired permissions, then select a license that matches what you'd like to grant.