GitHub - Can I legally commit proprietary source code in a private repository? I maintain an open-source application project, which I committed in a public GitHub repository. The source code I wrote is open-source (under MIT license) and owned by me, however it depends on a third-party library, for which the source code is proprietary of its providing company. Of course I bought a copy of this library, however for practical reasons I want to create a private GitHub repository, on which I think commit this proprietary source code and link it as a sub-module in my public application project. I performed a test to check if a thus created private sub-module may be accessed by anyone from my public application project, and it seems it's not the case, although the sub-module appears as a link, which is exactly what I wanted: an access to this sub-module for me exclusively, and no access for any person which just want to get my source code. However is a such practical legal? I.e can I commit the proprietary source code of another company in a private repository I own, if this repository cannot be accessed by other persons than me?
Per the comment, the applicable license term seems to be Licensee agrees to maintain in confidence the source code version of the Licensed Software by using at least the same physical and other security measures as Licensee uses for its own confidential technical information and documentation, but in no case less than reasonable measures. So if your own code is on a physically unconnected thumbprint-secured blah blah blah computer deep in a mountain, with files encrypted, so must theirs be. If yours is stored in &quot;the cloud&quot; with decent password protection, theirs must be as well. This seems to describe your Github use (I don't have any knowledge of the degree of hackability of private Github repositories). The legal judgment as to whether this is &quot;reasonably secure&quot; is based on whether a prudent person would know that it is practical to gain unauthorized access. Protecting a file with the password &quot;password&quot; would probably be found to be unreasonably insecure.
Whether this is considered a trade secret (at least in the US) depends partly on whether you've taken reasonable action to keep it secret. If an employee thought it was OK to publish the algorithm, that's evidence that you didn't try very hard to keep it from getting out. Even if nobody's noticed it yet, getting the blog post taken down in't going to get it off the internet. You may as well try to do it anyway. If nobody has noticed the algorithm by now, you want to make it harder for them to find. You need an IP lawyer pronto. Depending on where you are, you might be able to get a patent on the algorithm still, but patents are hard to enforce, and it appears to be getting harder in the US to patent algorithms. (There's a Stack Exchange site so people can look at patent applications and see if they can invalidate the application with prior art.) You can't license out the algorithm without having some legal way of stopping other places from just using it. If you have more proprietary algorithms or things that aren't generally known that give you a competitive advantage, it would be a good idea to inform employees that they aren't supposed to reveal them. Check with your IP lawyer to see what you should do.
You probably can. There are a few questions here. First, is the message protected by copyright? In general, it probably is, but there are many exceptions that might allow you to use it without permission. Unfortunately, these exceptions vary from jurisdiction to jurisdiction. The exceptions tend to allow the use of small excerpts of a work for various sorts of purposes that don't undermine the copyright holder's ability to profit. That leads to the second question, which is why you are using that message. If you're including it in your source code so you can test whether a message generated at run time is in fact that message, that's one thing, and it's probably okay. On the other hand, if the owner of the copyright sells a database of all its message strings, and you're compiling a similar database that you also intend to sell, that's probably not okay. A third question concerns the Firefox license terms. It's entirely possible that they allow you explicitly to do what you're considering, in which case it doesn't matter what copyright law says about it. On the other hand, Firefox is open source software, and under some open source licenses, if you incorporate any of the source code in your own product, you are required to release your product's source code under the same license. If you're not already planning to do that, you should consider carefully whether including that error message would trigger that provision (if there is one) of Firefox's open source license.
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.
The GPL does not forbid you from charging money for software, nor does it require you to provide source code to the general public. What the GPL requires is that your software be free software, with "free" used in the sense of "free speech" rather than the sense of "free beer." According to the Free Software Foundation (authors of the GPL), the right of users to sell software is a requirement for it to be free software. If you receive a GPL license for software, you can give it to whoever you want provided you also ensure that person can get the source code. You don't need to make the source code available to the public, only to the people you actually distribute the binaries to. The GPL is structured along the lines of "if you distribute the software to someone, you must give them these rights;" it is not structured along the lines of "you must distribute the software." Of course, if users have the right to distribute copies for free, it's hard in practice to charge money (all it takes is one user distributing copies). But that doesn't mean you can't try. Some companies make substantial money selling free software through various models (e.g. Red Hat, which charges money for support). Others might bank on the fact that plenty of people are willing to pay to get it from the official site, and aren't interested in finding a free copy somewhere. It doesn't matter; as long as they license the software to you under the GPL and give purchasers access to the source code on the same terms, they're in the clear (if you want to redistribute binaries, it's your job to redistribute the source code as well).
It depends on what you are selling to the enterprises. You could be selling just a licence to use the program, and retain all the rights on the source code. You could be selling the rights to the source code. For #1, the source code is yours and you can do what it pleases with it1. In fact many programs offer both an open-source licence (which usually forces the user to make its changes to the code publicly available) and a commercial one (which allows the user to keep the modifications of the source code for themselves). For #2, the source code is no longer yours so it is not up to you to decide what to do with it. 1I am assuming no other agreements imposing limits on those; for example that none of your contracts to your customers have a clause forbidding you from making the code available to the public.
The words "proprietary format" are important. Are you sure the format is proprietary? If it is, then it's likely protected in which case they might have grounds to sue (but that does not mean they would definetly win). If the format is not proprietary, and so long as you don't share data which is proprietary then I believe you fine. I'm not a lawyer - but I cite GIF files as an example. They were still protected by the US and some other countries until at least the late 90s and there were various threats to open source linux companies who shared code that used the file format. I'm not aware of anything other than threats and never heard of any company being sued, let alone winning or losing. Another example that comes to mind is the RedHat ISO format. My understanding is RedHat could not stop anyone from sharing open source, but they could prevent folks from sharing the format they assembled and shared the open source. Again, I am not sure if it was ever tested in any court of law anywhere.
The code is copyrighted. You are not given any permission to use or copy any part of it, nor to create a derivative work based on it. There is no way for you to "make the copyright null". The code was copyrighted in 2005, and the copyright will not expire until 70 years after the death of the author, under US law. The period would vary in some other countries, but in no country that I know of will it expire in the next few years. That the author is dead, or the publisher out of business, does not change this legally. Someone, probably the author's heir, or perhaps whoever bought the remains of the publisher's business, will own the copyright. However, the ideas and programming techniques shown and discussed in the book are not protected, and you may use them freely to write programs, commercial or non-commercial. You need not even acknowledge the book as a source of ideas, although to do so would be nice. Of course, since the author is dead and the publisher not active, if you were to infringe the copyright by copying code from thsi book, there is a reasonable chance that no one would notice, but if someone did notice, the current owner of the copyright could sue you for infringement, and could perhaps win sizable damages. It would be safer to write your own original code using only the general ideas from the book. In future, do not ever assume that you can just take someone else's code (or other creative work, such as a book) and reuse it without permission, unless it is in the public domain, for example because it was published before 1923.