What (combination of) licenses is popular for public/shared proprietary software (“Feel free to contribute, but only we can make commercial use”)? A software product (a web service) is being developed. In essence, I want the software code to be hosted publicly on GitHub. Anyone should be able view, download, modify, use for personal use, and contribute back with improvements as they want, meaning most of the "open source" principles - but not all, as... ...Only I may make commercial usage of the software code. But the more I search on the Internet, the more confused I get about this topic. According to me, this situation has to be a common desire by developers or organizations, but yet it seems hard to find a clear answer to exactly how an organization can achieve this. I have a hard time believing that each person or organization has to call in a lawyer that writes a custom license each time, right? In other words, reinventing the wheel all the time. Isn't there a straightforward, popular, or common license or license model that achieves this? Perhaps "dual licensing" is the only way to achieve this? If so, are there any examples of GitHub projects that do this?
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.
Ok here is my go at answering my own question: (see comments above &amp; below for links) Depending on what you want to do, GPL can be a bit complicated, with multiple versions, version numbers, and added exceptions over the years. it can be a headache. However, for this purposes of app development incorporating GPL/LGPL libraries, it is fairly straightforward. Keep in mind to check version numbers on all relevant documents, although they are most likely v3.0. As far as I know linking to a GPL library binds you to also releasing your code under GPL. So that is a no-go for closed source, but that brings me to my 1st question. is it legal for me to remain closed source while incorporating external libs that are both BSD and LGPL? and I think the answer to that is yes provided that I dynamically link to said component (.so .dll .dylib .framework). Permission of this is granted under section 4d of LGPL v3.0. d) Do one of the following: 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source. 1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version. My 2nd question Would it change the ability for me to stay closed source if i were to use an altered version of one of these libraries? It is my interpretation that in this case the only source you would need to provide is that of the modified library, and that the application itself can remain closed source. I'm basing this on grounds that nothing has changed from the situation for my 1st question other than the fact that the modified component library is now a derivative work under standard GPL v3.0. finally my 3rd question what is the legal effect on static vs dynamic linking? This seams to be a bit iffy. Again see section 4d of the LGPL v3.0. By this wording dynamic linking is much preferable, and there are basically no requirements. If you choose to link statically though(in other words as part of the project build) things get complicated. To fully understand see LGPL definition of "Corresponding Application Code", and then see sections 4 5 and 6 of the GPL document. Full source is not required, but as far as i can tell you are required to provide all necessary materials for someone to build the project from scratch, so they can use a different version of the library if they so choose. This, in my opinion, would not be closed source. I hope that is clear enough? I did quite a bit of looking around the internet in coming up with this answer, and in the end even some reading of the license, though I'm not sure I've actually read them through in there entirety. Keep in mind that there are multiple version of each license, and you should check version numbers for each LGPL library you use. There is a lot of good information on on opensource.stackexchange, although much more than one can process in a single sitting, and with occasional disagreement on finer points. Below are some related links. gnu.org/licenses/gpl-3.0.txt gnu.org/licenses/lgpl-3.0.txt copyfree.org/content/standard/licenses/2bsd/license.txt opensource.stackexchange.com/questions/1700/are-derivative-works-a-subset... opensource.stackexchange.com/questions/2772/can-this-nvidia-licence-be-us... opensource.stackexchange.com/questions/2488/do-i-need-to-host-qt-source-w... opensource.stackexchange.com/questions/1431/are-there-examples-of-proprie... opensource.stackexchange.com/questions/5162/are-the-terms-of-lgpl-3-0-alr...
You can't patent an algorithm, but I'll assume you are talking about the case where you have patented a machine or process that uses an algorithm, but that adds significantly more, and that the software being distributed implements much of this process. Courts might find an implied licence or promissory estoppel when distributing software under an open source licence that doesn't explicitly exclude patent licencing as part of its terms. It would be prudent to state your patent rights and explicitly exclude a patent licence if you intend to enforce your patent rights. As an example, this software implicates a patent , so they allow "permission to use, copy, modify, and distribute this software and its documentation for educational, research, and non-commercial" purposes. Users that want to use the software commercially need to contact the authors who also happen to be the patent owners, and I assume would negotiate a patent licence at that point.
What you are missing is that the original copyright holder can give permission to make derivative works with strings attached. There is no automatic right to derive something from a copyrighted work. Those strings could include constraints on what you create in the process of making the derivative work. Yes it is a string limiting what you can do with something you own, but you would have been warned in the license and had the choice to start from scratch. People do create work-alike software with no copyright strings using two teams and a &quot;clean room&quot; design process. It is a lot harder than modifying something another person has developed. Also, law and someone's understanding of morals need not be aligned at all. And, in patent law, just creating something all by yourself from scratch does not give you ownership. If someone else did it first and got a patent you can't make the item you might think you own. IP law is complex and looking for &quot;fundamentals&quot; may not get you anywhere.
You are free to sell or not to sell to whoever you like (unless it is illegal discrimination, like not selling to white Christians), but it doesn't make a difference, because anyone who buys the software from you can legally sell it on to anyone they want. So you cannot control who ends up owning the software. If I want the software and you don't sell it to me, and I still want it, I'll just ask a friend to buy it and give them the money. Other people would just get a pirated copy if you refuse to sell to them (and would have very little bad conscience since they offered you cash and you refused to take it). You can put terms into a license, and in the USA this is binding. The customer may not agree with the license, and in that case they have the right to get a refund for the software. In the EU, I don't think a license is binding, so you'd have to sign a legally binding contract with the buyer. Apart from all that, you have very little chance to find out if the software is used against your wishes and to do anything about it.
The MIT license is non-exclusive. If S is the sole copyright holder, S can issue any other non-exclusive license in parallel, and can also stop offering the software under the MIT license. However, open source licenses such the MIT license are generally understood to be irrevocable, so S cannot prevent other people from using the software who already received it under the MIT license terms. But: only if S is the sole copyright holder. There is no particular reason to believe that S would be the sole copyright holder. One does not gain a copyright ownership just by supervising other people, although an employer might gain copyright ownership over works created by employees (e.g. the US “work for hire” doctrine). That the copyright notices only mention S's name is an indication that S might be a copyright holder, but that's neither sufficient nor necessary for showing that S holds sole or joint copyright in the software. This leaves three relevant scenarios: S might be the sole copyright holder, in which case, yes, S can effectively discard the MIT license. This might be the case e.g. if there was some other copyright assignment, outside of the MIT license. What copyright transfers or assignments are valid depends on the local laws, e.g. some jurisdiction do not recognize copyright as transferable and at most allow the assignment of economic aspects of copyright. S might not be the sole copyright holder, but have additional permissions to the work. For example, there might have been extra licensing agreements, outside of the MIT license. Or S might have special rights for a work of joint authorship, if and only if the jurisdiction recognizes such additional rights. S might not be the sole copyright holder and not have any agreements outside of the MIT license. Then S has no additional rights, and is bound by the terms of the MIT license. This doesn't have to be a problem: S can still pretty much do whatever S wants with the code, as long as S fulfils the license terms. These are pretty simple: just keep a copy of the copyright+license notice with any copies of the software the students created.
Using this answer on Open Source Stack Exchange, If a repository has no license, then all rights are reserved and it is not Open Source or Free. You cannot modify or redistribute this code without explicit permission from the copyright holder. If a project doesn't have a licence, then normal copyright rules apply - this means that the author reserves all rights. The way a project is obtained, nor (except in exceptional cases), does not alter the ownership of copyright of a project. Bob will always hold copyright, unless he releases a legal document, such as a licence, that grants others various rights to the project.
The CC-ND license seems to be what you are looking for. However, Sec. 2(a) has two conditions, one allowing copying and distribution of the unmodified original (as stated in A), but also allows the user to modify but not distribute a modified version of the work (they may "produce and reproduce, but not Share, Adapted Material"). This would mean that a reader could rewrite your paper, as long as they keep it to themselves. If this bothers you, I think you could not rely on a standard named license, instead you'd have to provide your own – such as CC-ND 4.0 without clause (2)(a)(B). Rewriting a legal document is a risky proposition, even for a legal professional, because you have to carefully think through all of the implications of any new punctuation, adjectives, and deletions. If you contemplate deleting clause (2)(a)(B), you should come up with a line of reasoning that compels you do delete it in order to accomplish your goal, and check that the deletion doesn't thwart that goal. That is why people pay money to lawyers (and also why you need to make your goal clear to that lawyer, lest the agreement be inconsistent with your goal).