GPL v3 - Do I need to show passwords and secure keys in source I'm developing in Python using Qt5 (PyQt5), which uses GPL v3 (http://www.gnu.org/licenses/gpl-3.0.txt). I understand I need to make the source available, but if I create a separate file secret.py which contains only one line - the secret API key I use to communicate with my server (it's like a password), and that file or the API has nothing to do with the PyQt, Qt - do I need to show it in source? Can I compile the software to executable file and attach source without the secret.py, or that is against the license?
This seems to fall under &quot;Installation Information&quot; according to the GPL v3 license. &quot;Installation information&quot; doesn't need to be provided as source code, but it must be provided in such a way that others can take the source code, modify it, and make it work with the &quot;Installation Information&quot; that is provided. (Technical: At the place where the passwords and secure keys are entered in the source code, I would modify the code so that it doesn't build, followed by instructions how to create your own passwords and secure keys. So you try to build the program, it fails, it points you to instructions, you follow the instructions and change the source files, you try to build again, and it works).
This could be a problem if the consultancy agreement contains a provision that assigns to the client any copyright in any code created by the consultant. That is why there should be no such provision. In the absence of such a provision, the consultant owns the copyright in the code, so it would be impossible for the consultant to infringe that copyright. Even so, copyright protects a particular expression of an idea, not the idea itself. The idea of an "analyze data" class containing a "read data" function is not itself subject to copyright protection. It could potentially be patentable as a "process," but it would fail to meet the criterion of novelty. It would also fail to meet the criterion of non-obviousness. On the other hand, a software developer cannot (without permission) copy source code that is protected by copyright simply by changing the names. Changing the names would constitute the creation of a derivative work, and the right to create derivative works is also protected by copyright.
You're not going to find an OSI-approved or FSF-approved license that meets your needs because these licenses comply with the OSI definition or FSF definition of open-source software, and your requirements don't. Looking at your requirements, it looks like you want a license where users can modify the software and use it for private use, but cannot use it for commercial use. I ran a search on TL;DR Legal to see what licenses match. There are some one-off licenses that appear to be written by individuals or groups or written by companies that explicitly call out a particular software package. One appears to be a modification of the Apache License. I wouldn't recommend simply using one of these without not only reading them thoroughly yourself, but also consulting a lawyer - just because they started with a license that is trusted doesn't mean that a change they made didn't cause problems if it were to be challenged. For a project hosted on GitHub, it doesn't need to be open-source. You can upload a project that is all rights reserved, but by using GitHub, you do need to allow others to view and fork your repository. However, I wouldn't expect many outside contributors. Why should I give you my hard work if you're just going to turn around and make money on it? That's essentially free labor. I'm not aware of any listing of vetted licenses that are designed for commercial use of software, like how the OSI and FSF maintain lists of licenses. There is a Binpress license generator, but again, it's not a vetted license. How much stake you put into license generator or some random license you find on the Internet is up to you and the level of risk that you find acceptable. If you want to make money on your open-source software, you may want to rethink your approach. In my experience, I've usually seen dual licensing achieve this. One license is a custom written commercial license while the other is a very strong copyleft license, like GPL or AGPL (depending on how you intend your software to be used), which forces companies to also open-source their software if they use yours. It doesn't explicitly prevent commercial usage, but many companies will either look for an alternative that has a more permissive license or purchase the commercial license to prevent their software from being required to be open-source as well. You may also be interested in questions on Open Source about how to monetize open-source projects. There are options out there - selling support and maintenance or related services or selling additional documentation or examples. Under this model, all of your software is free and open source under any of the well-known open-source software licenses, but you make money supporting users of the software.
You can read it, you can examine it to the point where you understand it, and then you can get inspired by the code and write your own code, without copying the code on the website, which does the same thing. If there is no license, then you can do what copyright law allows you to do. You are not allowed to copy the code, or create derived works by taking the code and modifying it.
The Free Software Foundation considers that the Apache 2.0 license is compatible with the GPL 3.0: This is a free software license, compatible with version 3 of the GNU GPL. But not compatible with the GPL 2.0, though: Please note that this license is not compatible with GPL version 2, because it has some requirements that are not in that GPL version. These include certain patent termination and indemnification provisions. The patent termination provision is a good thing, which is why we recommend the Apache 2.0 license for substantial programs over other lax permissive licenses. But what does it mean when the FSF says a license is &quot;compatible with the GPL?&quot; It means that the other license and the GNU GPL are compatible; you can combine code released under the other license with code released under the GNU GPL in one larger program. All GNU GPL versions permit such combinations privately; they also permit distribution of such combinations provided the combination is released under the same GNU GPL version. The other license is compatible with the GPL if it permits this too. GPLv3 is compatible with more licenses than GPLv2: it allows you to make combinations with code that has specific kinds of additional requirements that are not in GPLv3 itself. Section 7 has more information about this, including the list of additional requirements that are permitted. So what can you make of this? The FSF considers these two licenses compatible and it also means that when you combine code under these two licenses, the effective obligations that will apply are these of the Apache and GPL combined, including source code redistribution. But why are the compatible? Is the fact that the FSF says so enough? We can check what the Apache Software Foundation says on the topic: The Free Software Foundation considers the Apache License, Version 2.0 to be a free software license, compatible with version 3 of the GPL. The Software Freedom Law Center provides practical advice for developers about including permissively licensed source. Apache 2 software can therefore be included in GPLv3 projects, because the GPLv3 license accepts our software into GPLv3 works. So irrespective of the deeper why, they tend to agree and as they are the authors of the respective licenses, this carries some weight. But wait, this is not true the other way around as the ASF goes on: However, GPLv3 software cannot be included in Apache projects. The licenses are incompatible in one direction only, and it is a result of ASF's licensing philosophy and the GPLv3 authors' interpretation of copyright law. So in a nutshell, the FSF considers that the terms of the Apache license are compatible with the copyleft terms of the GPL 3.0. The ASF agrees, but the copyleft terms of the GPL 3.0 are not compatible with the permissive terms of the Apache 2.0: a combination of the two would have to be copyleft.
The creator of the software doesn't provide any warranty. If you feel confident in the quality of the software, nothing stops you from providing a warranty. If the software doesn't meet your guarantees, you will have to pay out because you provided the warranty, depending on the terms. Not the creator of the software because they explicitly didn't provide any warranty. If that's what you want to do, go ahead. I wouldn't. You don't have to republish under the BSD license, which you wouldn't. You must attach the license terms, which clarifies the role of the original creators, and that they don't give a warranty. Doing this allows you to copy the software. It doesn't mean you can't provide a warranty.
Broadly speaking, the difference is the "sharealike" clause of CC-BY-SA. Any derivative of a CC-BY-SA work must itself be licensed CC-BY-SA, whereas a derivative of an "MIT with attribution" work can be under any license the author wants. There are a number of other differences in the fine print (eg. CC forbids DRM, where MIT doesn't), but that's the big one.
If you're in the U.S., then section 117 of the Copyright Act is likely what you're looking for. The U.S. Copyright Office says: Under section 117, you or someone you authorize may make a copy of an original computer program if: the new copy is being made for archival (i.e., backup) purposes only; you are the legal owner of the copy; and any copy made for archival purposes is either destroyed, or transferred with the original copy, once the original copy is sold, given away, or otherwise transferred. Based on the information you provided, it sounds like you meet all three of these criteria. They also note that your particular software's license agreement might include special conditions that affect your right to make a backup copy. Such a warning would only make sense if it was legally possible for the software distributor to make such a limitation, so I'm afraid the direct answer to your main question is "yes". It's definitely not the norm - at least in my experiences - but it is a possibility so you'll need to consult your program's license agreement. There's also a possibility that the company misunderstood you and was thinking that you were running a backup server (in the sense of a redundant infrastructure) and not making an offline backup of your entire server. It's quite normal to require an additional license for the former case.