Relicensing software under GPLv2+ without all contributors I have software licensed under GPLv2, which I would like to relicense under GPLv2+. Unfortunately, I an unable to contact some of the contributors. Can I proceed, or am I stuck?
Since licensing can only be done by the copyright holder, you generally need individual permission from each copyright holder to change the license of their code. (If the project is being re-licensed to the GPL from a compatible license, then no re-licensing from the copyright holder is necessary; however, versions 2 and 3 of the GPL are not compatible with one another.) Ways around this are: Remove or replace all code written by the unreachable contributors. Have contributors assign copyright to a person or legal entity that controls the project, so that there is exactly one copyright holder. (This is a preventive measure. If you have not done this already, it's too late when you cannot track down a contributor.) But if you can't do either of those things, what do you do? Historically, re-licensing of software without explicit approval from all contributors has been done before, under the advice of legal professionals. However, the legal mechanics of it are unclear and have never been tested in court. The two prominent examples appear to be: Mozilla relicensed from the MPL to a triple-licensed MPL/GPL/LGPL scheme The Dolphin emulator relicensed from GPLv2 to GPLv2+. The Dolphin project produced a report about the process, but it lacks any specifics about how the legal mechanics of the switch work. They say (emphasis mine): Out of all [200 contributors], we managed to contact all or take care of the code of all but 10 of those developers. Considering that many of those accounts are now dead and the people seemingly vanished from the Internet, finding the rest is akin to squeezing blood out of a stone. That's when research provided us some much needed relief when it seemed as though relicensing was an impossibility. In 2003, Free Software lawyers consulted for Mozilla's relicensing project and stated that relicensing with the permission of just 95% of contributors was fine, as long as there were no objections in the remaining 5%. [...] [...] Instead of simply asking all of our active developers and relicensing, we made a very strong effort to get a hold of every single developer. Despite this, it simply wasn't feasible to make contact with every single person who worked on Dolphin. [...] We definitely would love to hear support from those that we were unable to contact, and if there are any concerns we will gladly address them in a prompt fashion. That posts links to a post from Ciaran O'Riordan: Someone who works with many lawyers on free software copyright issues later told me that it is not necessary to get permission from 100% of the copyright holders. It would suffice if there was permission from the copyright holders of 95% of the source code and no objections from the holders of the other 5%. This, I’m told, is how Mozilla was able to relicense to the GPL in 2003 despite years of community contributions. There is no information available about why Mozilla's lawyers believed it was acceptable to re-license without each copyright holder's permission. It's also unclear if any factors apply to Mozilla specifically that might apply less strongly to anyone else in a similar situation. In sum, we know only that: You need the permission of every contributing copyright holder to re-license a work Mozilla's lawyers believed (for unspecified reasons) it would be acceptable for Mozilla to make a good-faith effort to contract all contributors and then re-license, even if 5% of the contributors were unreachable (and none of the contributors disapproved).
What happened is that you created a legal mess. You are obviously on the hook for copyright infringement. The maintainers of the project will scramble to replace your code with newly written code. They will likely ask your company which code they are complaining about - that puts your company into the problematic situation that they shouldn't identify code that isn't theirs, that it will be hard to sue for infringing code when they didn't give the project maintainers a chance to fix it, and that everything they identify will be replaced. Since it is your actions that caused the trouble, anyone suffering damages from your actions can sue you.
You can replace the software on the device The supplier does not have to help you to do so You are correct that because you own the device, you can do what you like with it. That means you can install whatever firmware or other software on it that you like. However, the supplier does not have to provide this to you or assist you in any other way.
It depends on the warranty itself. Here is one warranty, which only protects against manufacturing defects and excludes any software issues (whether pre-installed or user-installed). I'm a little surprised that a manufacturer is willing to include someone else's software under their warranty. This also excludes failure or damage resulting from misuse, abuse, accident, modification, unsuitable physical or operating environment, natural disasters, power surges, improper maintenance, or use not in accordance with product information materials failure of, or damage caused by, any third party products, including those that X may provide or integrate into the X product at your request This does not say &quot;If you change the OS, you void the warranty&quot;. But, if you change the OS and that causes hardware damage, that voids the warranty. The next question is, what evidence do you have that the problem is a manufacturing problem rather than a consequence of changing the OS. They would have to answer the same question in court. It is legally absurd to claim that you have to prove that it is logically impossible that you contributed to the problem, you only have to prove by a preponderance of evidence, when you take them to court. The burden of proof rests on the person who makes a claim. You claim that the product was defective, now you must prove it. But you don't have to prove it to the standard of absolute ccertainty.
Your GPL example detracts from the question: see this recent answer. Setting aside GPL-specific conditions, the legal underpinning of software licensing is copyright law, whereby copying source code or an executable is only allowed with the permission of the copyright holder. There are two partial exceptions: "fair use" (generally not relevant to software), and a specific statutory permission to copy software in particular ways (making a backup, plus the act of executing software which requires copying from disk to memory). The latter permission only applies if you have legally acquired a copy of the software. Which explains why nobody sells copies of software, they sell a license to use software (a subtle, legalistic distinction, which is essential to modern software qua business). The terms of the license say what you may and may not do: if you violate the terms, you do not have permission to copy the software, and are liable for copyright infringement. One limit on the terms is that they cannot take away a right that you already have by copyright law (e.g. "fair use" cannot be negated by a license term). Another limit is that the terms have to be consistent with contract law, hence the license cannot include a human centipede obligation – or, "all your stuff belong to us". When a contract is ambiguous, the ambiguity is construed against the writer, and that is also so with software licenses. Also like the situation with contracts, the terms have to be legal, that is, cannot deny some right or requirement encoded in law. There is a legal requirement that disclaimers have to be "prominent", and that holds of license terms. As for "tricking" a person, that's not supposed to happen, with a proper license. If you put stuff out there and say nothing, nobody has been given permission to copy the item. You can make it available to a specific named person, but that is limited to one person, thus a license includes language allowing anyone to copy, but also requiring that the license be retained with any subsequent copies. Hence B copies from A, and sees the license; B may share with C (assuming a decent license) but must include that or substantially equivalent license; and so on. A problem arises if B redistributes without original license, substituting a bogus license. When C copies, that copying is not done with the permission (implied or express) of A, and C could be open to legal consequences. B is also clearly open to consequences, since re-distribution with the self-perpetuating license is a violation of the terms of A's condition grant of permission. Ignorance of the true ownership of copyright is no excuse, and there is no general innocent-infringement exception to copyright law in the US. However, the part of copyright law that talks about remedies for infringement, 17 USC 504(b)(2) lessens the burden on the innocent infringer: In a case where the infringer sustains the burden of proving, and the court finds, that such infringer was not aware and had no reason to believe that his or her acts constituted an infringement of copyright, the court in its discretion may reduce the award of statutory damages to a sum of not less than $200. Still, not zero. I don't see how adding some NOPs would make it impossible to prove that you have a copy of someone else's IP. Perhaps it's not a trivial, but still quite possible.
As far as I can tell, whenever GitHub redistributes code, it adheres to all of the requirements of the GPL/BSD etc. For example, it never gives away code without including the license text, and it doesn't claim to add unpermitted restrictions to the code. The section you're concerned about is this: That means you're giving us the right to do things like reproduce your content (so we can do things like copy it to our database and make backups); display it (so we can do things like show it to you and other users); modify it (so our server can do things like parse it into a search index); distribute it (so we can do things like share it with other users); and perform it (in case your content is something like music or video). That section isn't worded very precisely, but I understand this to mean they want to reproduce your content in full, not just the code without the license text attached. They want to display your content in full, as you provided it. They want to modify it internally (i.e. they are not redistributing this modified form) in order to allow searching. To the extent that they display code-snippets as search results, that is likely defensible as fair use (search engines are frequently cited as examples of successful fair use defenses). GitHub appears to be acting consistently with the GPL when it reproduces, displays, modifies, and distributes code that you upload. If I'm correct about these facts then nothing that GitHub does with the code goes beyond what the many contributors to a GPL project have explicitly permitted, or what is otherwise permitted by fair use law. If you had some code with a more restrictive license, you might not be able to simultaneously comply with that restrictive license and GitHub's License Grant. Consider the scenario where you have some code that is licensed exclusively to you, and you are not given permission to reproduce or distribute it. In that scenario, the code's license prevents you from agreeing to GitHub's request for a license grant.
In Germany, there is no concept that corresponds directly to public domain. You automatically hold the Urheberrecht (~ copyright) for all creative works that you make, and it can't be given up or transferred (§29 UrhG). The work only enters the Gemeinfreiheit (~public domain) 70 years after your death. You can however license Verwertungsrechte (economic usage rights). When you make creative works in the course of employment (see §43 UrhG), your employer automatically gets the Verwertungsrechte necessary in the context for the work, which is typically an exclusive right (no one else, not even you, can use the work). Your are not in an employment relationship with your school, so it has no rights to your works and cannot prevent you from publishing them on copyright grounds. When you see advice on the internet to check with your school first, that is U.S.-specific advice. Since you're still a minor (7–17), you only have limited capacity to enter contracts or legal transactions (bedingte Geschäftsfähigkeit). While you are able to make transactions involving your own means (e.g. buying something with your pocket money) or make transactions that are only to your benefit (such as accepting a gift), other transactions are schwebend unwirksam (~ pending ratification), until your parents agree. The relevant law is in §107 and §108 BGB. This is a problem with open source licenses. If you publish software under a license, this license is schwebend unwirksam. Someone might start using the software under the license. But then if your parents refuse ratification, the license would be invalid, and everyone would have to stop using your software and destroy any derivative works they made. This is a bit of a problem, especially since open source licenses are otherwise assumed to be irrevocable. So if you want to offer a license (including open source licenses), please give legal certainty to the recipients of the license and ask your parents for their consent first, possibly even in writing. Per §107 BGB, the license you offer with their consent will be valid.
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.