Can I be prohibited from fixing bugs in a licensed software? I have purchased software product, which the company claims is licensed to me, and it contains an EULA that says that I am not allowed to reverse engineer or modify the software at all, and a violation of this would allow them to revoke my license. Now, I'm an experienced software developer who has built a business around using said software product. I rely on it, and have done so for over 15 years now. Losing access to it would be a serious blow to my business, hence I like to avoid losing the license, of course. More than once in the past it has happened that I run into programming errors of said product, hindering me to use it as intended. And while the software lives up to its expectations in general (i.e. I cannot claim that it's useless to me), certain bugs limit its provided and documented functionality. Now, being an experienced developer, I am usually able to figure out the cause of the error by just observing how it behaves. And while I am often able to "work around" the bugs, sometimes the only way to solve the issue is to modify the product's code or interfere with it in some way that requires me to look at the code, i.e. reverse engineer parts of it. (Note: The code in question is not encrypted nor protected in some other way.) By doing that, the company claims I am in clear violation of their EULA. I initially argued that the purpose of their "no reverse engineering" rule is to prevent harmful hacks, such as trying to disable their product registration and copy protection, and the company agrees with that. However, they argue they cannot make exceptions to their rule at all (which I believe they confuse with enforcing trade mark violations, where too much leniency could make them lose the rights to their claims). Which leaves me almost no options: I am not allowed to fix their bugs myself, even if only for my own use of the software. Neither are they willing (or able) to fix them. Which leaves me to to simply not use parts of their product due to the bugs in them, even though these buggy functions are provided for my use. So it's not something hidden I'm trying to exploit here - it's part of their documented feature set. Are they in their full rights to revoke my license when I violate this particular rule from the EULA? Bonus question: I am in the European Union, while their company is in the USA. Does that make a difference, i.e. are their laws in Europe that help me with arguing for my case? (Let's ignore the often-heard argument that shrink-wrapped licenses are not enforcable - instead I like to focus solely on the issue of defects in a product.) Sure, even if the company is in the wrong, they could still then disable my license, but I'd like to understand if I am in the wrong here by expecting that they're liable to either fix bugs or let me fix them myself. If there's some good arguments in my favor, I may also want to make this case more public, or at least suggest that to the company if they remain uncooperative.
It is likely that the law applying will be both that of the USA and your country. If you went to court this would be one of the things you argued over. For example, Australian Consumer Law applies to any goods or services sold to a customer in Australia irrespective of where the vendor is located. Your jurisdiction may have similar laws. At first blush you must comply with the term of the contract preventing reverse engineering. They would be within their rights to terminate the licence if you don't. However, they probably have an obligation under your equivalent to the ACL to supply a product that: is merchantable is fit for purpose does what it says it will do If it doesn't then you have a right to terminate and get your money back, sue for damages and your country's government may prosecute.
This can't be right. If I modify open source code as part of the work done, by nature of the open source license that code can not become intellectual property of the client. Certainly it can. That which is "developed or produced" would be the modifications to the pre-existing code, i.e the copyright on the derivative work so created. If the base code was under a share-alike or copy-left license, then the client can only distribute it under the same license (or a compatible one, perhaps). But nothing compels the client to distribute it, and for the client's use, the client owns the copyright, without fear of any future claims by the contractor. If I have my own code/scripts/settings/templates/etc that I use as a contractor, and I modify those in the interest of coding efficiency in the interest of serving the client, it hardly seems correct that these assets become property of the Client. Those are your work, and you can choose whether to sell the copyrights to the client or not. Again, only the work done for that client would be covered under the wording quoted above, unless there is another provision that grants the client a license to use the pre-existing work which you modified for the job, which there probably ought to be. Or I suppose the agreement could assign copyrights in pre-existing work to the client, but that seems an odd choice, and the language in the question would not do that. You and the client could agree on a different provision such as: The contractor grants to the client a fully-paid, non-exclusive permanent license to use all intellectual property developed under this agreement, and any pre-existing works that may be incorporated therein. The contractor warrants that s/he is entitled to grant such license, without infringing on the intellectual property of any other person or entity. That wording would have the contractor retain all copyrights and other IP, but provide a license to the client to use it without further payment or expiration. Many other ways to structure such a provision are possible, dividing the rights up however the contractor and client can agree. The price for the work might vary depending on what rights the client obtains. Both forms, and many others, are perfectly legal, it is just a question of what the contractor chooses to sell, and what th4e client chooses to buy.
You can write anything you want (basic First Amendment protections): the question is whether one would be liable for damage that arises from what you're written, or whether you can distribute what you've written. Distribution may be restricted, thanks to the Commerce Clause (hence FDA regulations, which figure prominently in the analysis). Most software writers are not medical practitioners, and vice versa, and what the software writer does is implement something described by a competent medical practitioner. It is logically possible that a med. practitioner might also try to write software (no problem) and distribute it (possibly a problem); or, a software writer might read up on something on Wikipedia and try to implement it (again, no problem) or distribute it (possible problem). Damages can be sorted into two categories, implementation errors and scientific errors, and having ruled out deliberate sabotage, we are left with negligence. If the software writer failed to use suitable care in writing code that sums a set of numbers, the software writer has been negligent. If the person purporting to have the qualified scientific knowledge mis-states the formula, that person has been negligent. It is possible for many parties to be negligent (the programmer failed to be diligent in understanding the software requirements; the medical professional failed to adequately explain what was required of the program). The FDA does regulate medical devices, and "device" is construed pretty broadly (condoms are non-exempt class 2 medical devices). There is FDA guidance on medical software which makes it clear that the device manufacturer shoulders the regulatory burden. Anytime you manufacture a tangible thing (which is within the scope of FDA regulation for medical devices), you have to have the thing approved. Many (most?) medical devices implement software, and are thus within the scope of FDA scrutiny. It is not illegal to write software that ends up being implemented in an unapproved medical device, but the unapproved medical device itself is illegal. It is reasonably likely that purported medical software (not a gadget with software build in) would be held to be a non-exempt device. To know if something is exempt, you would look at the exemptions list, and determine that your program (or thing) is not on or implied by anything on that list. The visual acuity eye chart is a class 1 exempt item, as is the manual toothbrush. There is no way to specifically look for things that are only software, or that contain software, so the search through the list would have to be guided by knowledge of the subject area. Canada is helpful in explaining when software is a regulated medical device. This is non-probative w.r.t. US law but gives you an idea what is likely to be considered a "device". Under Canadian law, the software would be clearly a regulated medical device. The FDA has a power-point that attempts to say something about the matter which warns you that you are on your own and "You will need to go back to study and use the source regulatory documents" to make the determination. Eventually, slide 13, they hint that if you intend the software to be used in diagnosis, prevention, or treatment, then it is a device (so, yes, the aforementioned software would be a device, and probably not exempt from regulations). General purpose software (word processors, web browsers, communications software, etc.) are not indented to be used for a regulated purpose, although they can be so used, and thus they are probably not subject to FDA regulation. There is a murky relationship between regulatory approval and liability. Being approved by the government does not convey immunity to negligence suits (see Wyeth v. Levine), but being approved can have weight in determining whether a party was negligent, since regulatory scrutiny ostensibly filters out errors that could have been caught. Federal approval does not preempt state tort law, as the court ruled. Regulations pertaining to medical devices hold for anything that qualifies as a device, and is not defined (negatively) in terms of disclaimers. If you sell a medical device but label it saying "this is not a medical device, it is not created by a competent medical practitioner", that doesn't make it not a medical device. Unfortunately, what counts as a regulated device is based on intended use, and there is an obvious connection between disclaimers and intentions. Taking MS Word as an example, MS does not as far as I know say that "Word is not intended to be used as a medical device". It can certainly be used to diagnose, teat, and prevent medical conditions, but so too can a screw driver or pretty much anything else. The number of non-medical uses vastly outweigh the medical uses, so it would be deemed not to be a regulated device. A program which prescribed a set of prayers to be uttered in case of illness would be subject to First Amendment override of any FDA regulations. Quack medical devices are prohibited (that's why there is regulation of devices in the first place), but discerning the fine line between permitted actions based on nutty beliefs and forbidden actions is not easy. The FDA also has guidance on the distinction between "Complementary and Alternative Medicine", which does not clearly state that, for example, a software reading of your cakra-energies based on a computer program's questions is not a medical device. They do say of mind-body medicine (mentioning yoga, biofeedback and tai chi as examples) that "CAM practices in this domain would not be subject to our jurisdiction under the Act or the PHS Act", but then say "any equipment or other products used as part of the practice of mind-body medicine may be subject to FDA regulation, depending on the nature of the product and its intended use" (hence a yoga-enabling program may be subject to regulation).
You need to know two things about the GPL: The GPL is a license which requires that when you distribute binaries, you distribute the source code with them (binaries being the things you can directly run) The GPL is copyleft - any project using something licensed under the GPL must also be licensed under the GPL The easiest way to comply with the first point is to simply make the software open source by making it available to all online. Many, if not all, large projects licensed under the GPL do this. The other way of complying is to simply give anyone else who has a copy of the binaries, or who makes use of them, a copy of the source code. In your case, all you need to do is send your friends a copy of the source. As long as no one else uses this project, I think you satisfy the requirements of the license. You must, however, also license your code under the GPL. This means, as mentioned in the comments, that you must somehow make your friends aware that if they redistribute your code, they must also do so under the terms of the GPL. This can be as simple as including a file called LICENSE in the root directory of the source code, containing a copy of the text of the GPL. This further means that your friends will be able to share your code with other people without letting you know. You could politely ask them not to, but you can't stop them. (That said, you have no reason to be worried - only big breaches of license misuse by large companies ever tend to get chased up. However, it's great that you want to be careful about this! Software licensing, especially FOSS licensing, is very important.)
I'm assuming that you are not seeking to change the license, and so it will remain GPLv3. As long as you've built on the original software, that license still applies. You also need to keep the previous copyright notices, including the names of the original people. Assuming that, everything you're doing is legal, which is what's on topic here. There is some etiquette around forks (which is what you're doing), which would be on topic at the Open Source Stack Exchange. I'm puzzled by your desire to have a different license text. You can't change the license from GPLv3, so that has to stay the same. (If the original has GPLv3 "or, at your option, any later version", you can drop the any other version text if you like.)
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.
Germany may be different, however in the United States this would be considered work-for-hire and the employer would be the rightful owner of the source code. Regardless of jurisdiction, and from a more practical point of view, you are better off not having a copy of the source code. Using it as reference or example in the future could easily turn into (unintentional) copyright infringement. If, in the future, you write code you would like to be able to freely keep and reuse in any project, make sure the owner/employer licenses it using something like the BSD, MIT, or ISC license.
If you use the reviewer's code, or code derived from it (e.g. if you just changed a variable name) then they own the copyright on that part of the software. If the reviewer describes a solution which you implement, or if you re-implement the code from scratch while taking ideas and methods from the reviewer's code, then you own the copyright on that code. However if there are only a few ways to implement something in code then the code is not creative and hence cannot be copyrighted. For example the regular expression in the question you link to is (as far as I can tell) the only correct solution to the problem: any programmer addressing the problem will have come up with that RE. In this the position is akin to a database of phone numbers: while the collection may be copyright (depending on whether selection or arrangement required creativity), the fact that Alice Jones has the number 012345 is not copyrightable, and neither is the alphabetical arrangement of names. Where it gets messy is the boundary between the two. The requirement to detect 4 or more repeated digits in a credit card number could be implemented in a number of ways, but whether there are enough of these to qualify any particular solution as "creative" would be a matter of fact for a court to decide.