GPL: Does changing makefiles and configurations considered as &quot;modifications&quot;? I know that editing GPL source code is considered as a "modification", which means all the copyleft rules apply. However, most software includes configuration files and makefiles which you can tweak before rebuilding. Does that count as modification? For example, I am using the swupdate package through Yocto. I override the meta-swupdate layer to specify specific configurations (e.g. CONFIG_LUA_PARSER=y to enable LUA parser), and then build swupdate.
Section 1 of the GPLv3 states: The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source. So Makefiles are clearly included if they exists. The point of the GPL is to let the user be free to modify the code. A lot of projects are very hard to modify without the scripts used to fetch dependencies &amp; build the executable so not providing means to build the code would go against the license spirit.
All the CC licenses permit anyone to use the licensed content, and to make copies of it for others. Some of them permit using it for commercial purposes, others (the ones including the -NC- clause) do not. Some CC licenses permit creating modified versions of the original work (derivative works), others (the ones including the -ND- clause) do not. I do not know of any standard license which allows users to create and distribute derivative works, but not to distribute the original. The license used by Project Gutenberg permits re-use and re-distribution, but if a fee is charged beyond recouping expenses requires the removal of the PG name and logo. One problem is that if derivative works are allowed, this would include works which are only trivial modifications to the original, which would have the effect of allowing distribution of the original. If the main concern is about commercial sales, possibly a CC-NC-SA license would effectively serve the purpose? That allows redistribution, including of derivative works, but forbids commercial reuse or distribution without separate permission, and requires all redistribution to be under the same license. Otherwise a new license for this situation might have to be created. It is often a good idea to have the assistance of a lawyer with IP expertise in creating a new license, or the wording chosen may have unexpected effects or include unintended contradictions. Or one could simply place a basic copyright notice along with text such as "Modified versions may be created only with permission from the author. Request permission at work-permisisons@example.com". However, if the work proves popular, there might be a large volume of requests.
You are concerned that your application is somehow a derivative work of MariaDB and therefore subject to the GPL. It's not totally clear to me whether that is the case or not. But it doesn't matter, because you are not distributing MariaDB itself (or any other part of your application). You're running it on a server which users are connecting to remotely. From MariaDB's licensing FAQ: Internal usage is free The GPL license only affects code that you distribute to other parties. Internal usage within an organization is totally free and not subject to any conditions. There is no such thing as 'internal distribution' that would restrict the usage of your code by requiring it to be GPLed. Connecting to a remote service that runs MariaDB (or any other GPL software) in the background is also free. For internal programs for which you own all the copyright(s), there is essentially no risk in using GPL software. The argument you can use in your defense is that if the software became GPL as part of the distribution, you as the copyright holder could immediately revert your part back to its original copyright. No one has the right to require you to reveal or redistribute your code to the outside of your organization even if you would have distributed it internally linked with GPL software! If your lawyers are concerned about distributions of software linked with GPL libraries between different legal entities within your organization, you can solve this by distributing your components and the GPL software separately, and have your other entity combining them. You can also switch to use the new LGPL client libraries. The use you have described in your question clearly falls into this case, and the presence of this FAQ item clearly demonstrates that the MariaDB developers intended to allow you to do this. The Free Software Foundation (the people who wrote the GPL) agree with this position for both unmodified copies and derivative works. Technically, you don't need a license to &quot;use&quot; a piece of software at all, assuming you have lawfully obtained it. But you're concerned about the possibility of creating a derivative work, for which a license is required. Fortunately, the GPL doesn't care about derivative works so long as they are not distributed.
Every software is potentially vulnerable, unless it runs on an air-gapped computer with sealed data ports. How vulnerability fixes are prioritized against other goals is usually a business decision, legitimately made by the management. There are some jurisdictions and issues where the law requires them to act, but again there is usually a judgement call involved. For example, the GDPR talks about due regard to the state of the art. What you describe seems to be a difference in opinion about the importance of the fix. Ask about that at Workplace SE, not here. There are ways for software developers to influence their management, but ultimately the management is responsible for the outcomes and gets to decide. You can inform your superiors, in writing. If you are in a large company, there may be a legal or compliance department. Inform them if you have a reason to distrust your superiors. In most jurisdictions, you cannot simply talk to the press, either now or later. If you believe that your company is acting criminally, talk to a lawyer.
Impressum Requirement Wow, based on your citations, you've done a lot of research on this topic. I'm just going to add one more reference, which is from the same site as your first German citation and has incredibly detailed and judicially referenced information on almost everything related to the Impressum. All my non-GitHub links are to sections of that page. Based on your research, I'm going to take it for granted that you understand that according to the Telemediengesetz (TMG), an Impressum is required on a web page if it is &quot;business-like&quot; (geschäftsmäßig), or if it helps, I prefer to word it as &quot;potentially commercial.&quot; I would have to argue that open source projects have to be seen as inherently &quot;business-like&quot; for the purposes of the TMG for two reasons: Some other legal person may have similar software as part of their business and might have the need to serve legal notifications to the owner of a GitHub project (TMG § 8 gives competitors the right to sue). Think potential copyright violations here. It is possible to build a more traditional commercial business around open source, for example what Canonical is doing around Ubuntu. Additionally, the common legal advice is to even include an Impressum on a personal blog, though I'm not aware of any court case having occurred at that level yet. In my opinion, a GitHub account can be seen as more &quot;business-like&quot; than a personal blog, and would follow that advice out of caution. I'll note that the XING situation you bring up is complicated. It centers over whether the content of XING pages is &quot;business-like&quot; according to the TMG. It may well turn out that some pages will need an Impressum and others won't. As for placing it in the project's readme.md, that might work but I have two concerns: The courts have essentially stated that the text of the link must imply that the required information under TMG § 5 is located there. For example, the words Impressum and Kontakt work, but the word Information does not. To me, &quot;readme&quot; is not sufficient, but this concern might be negated by the fact GitHub by default renders the readme.md directly on the project home page. While it has been ruled that the Impressum does not necessarily have to be directly on the home page (for GitHub, that would be the company's/users profile page), it must still be readily available in an intuitive location. I don't know if putting it in a project page satisfies the legal requirement. If it was sufficient, it's also likely that each project would have to have an Impressum so that it can't be missed. Examples The dominant pattern that I could find1 on GitHub is an off-site link to the Impressum contained in the profile page's byline right underneath the title. Examples: https://github.com/sedadigital, https://github.com/comsysto, https://github.com/znes, https://github.com/eSagu, https://github.com/TIBHannover. I'm almost certain this meets or exceeds the legal requirements. Example screenshot: Additionally, I found a few that had a repository specifically for an Impressum. Example: https://github.com/johsteffens. Since these repositories were clearly visible on the user's main page (either because there weren't enough repositories to make them span multiple pages, or because it was specifically pinned to the main page), I would argue these also meet the legal requirement for being readily available. While I didn't find any examples of it, another possibility would be to combine the above two approaches, having a link in the byline that links to an Impressum repository or some other page within GitHub. This would be useful if you didn't otherwise have an Impressum hosted elsewhere. There were also scattered examples of people placing an Impressum on a project wiki page or on an impressum.md file at the top level. However, none of the users I looked at were consistent in doing this across all their projects. Also as previously mentioned, it's questionable whether not having it on the main user profile page meets the legal requirement. The Wiki page in particular I don't think meets the requirement that it can easily be found. Found using the following Google search: site:github.com impressum -impressum.php -impressum.html -impressum.jsp -impressum-manager -github.io -issue. Exclusions meant to filter out a lot of false positives, mostly projects for websites that had their Impressum in code format meant for deploy and not for display on GitHub itself.
"Pastiche" is a literary, not a legal term, and as a professional coder, I would not use it to describe code that to some extent imitated other code. The legal question here is: is your code a derivative work of the code it is based on, and if it is, did you have permission to make that work. Copyright, in an Berne Convention country, which includes the EU, does not protect ideas and concepts, it protects expression. It protects the choices of words and symbols, and other forms of expression. If all you did was study example code, presented for educational purposes, and then write code that performs a similar function, using the same general techniques, then I don't think you have infringed copyright. That, after all, is why people post code to Stack Overflow and similar sites, to allow them to learn how to use specific coding techniques, including in commercial projects. I have used techniques posted to SO to do coding as part of my paid job. The usual test for copying under US law is "substantial similarity". This takes into account cases where there is essentially only one way to say or code something. I don't know the exact tests under the various laws of various EU countries, and they will not all be the same. But I suspect that on this point they are, well, substantially similar :). I can't advise on your specific situation. But if it is as described, I don't think you have a problem.
Yes, you can. To be precise, I claim that one can take BSD-licensed code and distribute it under the combined terms of both the BSD and the GPL licences. We know that, if I receive someone else's code under a BSD licence, I may redistribute it to you under those same terms. This is common practice, and not (I hope) in any way contentious. We also know that I may not redistribute it to you without the conditions that the BSD licence imposes; that is, I may not place less onerous conditions on you than BSD requires (that is, requiring the inclusion of the original copyright notice, the disclaimer, this list of conditions, and a prohibition on claiming the original author's endorsement on any modified version). So the question becomes whether I can distribute that code whilst adding more onerous terms than the BSD licence itself imposes. It is clear that I can. As the question notes, Microsoft is known to have taken code which it received under a BSD licence and used it in proprietary products. These come with very onerous conditions on the the use, modification, and redistribution of the derived code (usually, they permit one instance of it to be run, and no modifications nor redistributions of any kind). For clarity: if I were to seek from Microsoft permission to modify and/or redistribute the derived code, and they were to grant it, they would not be able to free me from the BSD requirements as they applied to the derived code; I would still need to comply with those. But they are perfectly capable of applying new, onerous requirements of their own. The GPL imposes conditions on redistribution that are more onerous than BSD's, but less onerous than those of most proprietary licences. I am therefore perfectly entitled to receive code under a BSD licence, and - with or without making modifications of my own - redistribute it, adding in the GPL's requirements, if I choose to. If I haven't modified the code, those added requirements are probably pointless; if you don't wish to be bound by them, you will go and get the code from the original author, who presumably will happily distribute it to you under the BSD licence. But if I have modified the code, and you wish to use those modifications, then you will need to abide by the requirements of both the BSD and the GPL licences, since both will apply to this new, combined work (the original code + my changes).
This is similar to giving a hammer and needing to state to one is not responsible if the taker uses it to hit their head with. I believe this is the wrong analogy to use here. It would be more like giving somebody a hammer and saying you are not responsible if the head flies off and injures you. There is a concept in &quot;things&quot; you obtain called &quot;fitness for purpose&quot;, so if you download open-source software like a registry cleaner, and it deletes your entire registry, the &quot;WTFPL&quot; doesn't absolve the authors of liability. Explicitly denying any kind of &quot;fitness for purpose&quot; or warranty helps shield the author from legal claims (even if they are meritless) because it kills it out of the gate. It's possible that the WTFPL license granter/author could still be sued and have to defend themselves in court because it isn't explicitly stated that there is no warranty or fitness for purpose. Open source does not mean that it's &quot;use at your own risk&quot;, which is why there are so many types of licenses and disclaimers. From comments: Thank you for this very clear answer. Does the fact that someone willingly retrieves free code with no control of the provider changes anything? (vs a software vendor which provides code suitable for A and B, in exchange for money) I think closer to your hammer analogy where I would sue the producer of hammer XXX, a hammer I found on the street or which was given to me without involvement of vendor XXX. No, this doesn't change anything. The software vendor here is the person who writes the code, even if they don't charge for it. They are the ones who license the software and they are the ones who take some level of responsibility for it. In this case, the software author is the &quot;hammer producer&quot; that you would sue... If you buy &quot;Registry Cleaner XL&quot; from Best Buy and it bricks your computer, you don't sue Best Buy, you sue the person who authored the software. In pretty much every case, the author is the responsible party, not the vendor, and it is the author who licenses it, not the vendor (the vendor just acts as an intermediary).