Hi, @Trevor
You've asked:
> Can you take FOSS software, add your own spices to it, and then sell it?
Please be aware that I'm NOT, by any means, an expert in FOSS licensing (so, please do take what I write about this with "a grain of salt"). Having said that: I believe you can, although what you can do depends on whether the FOSS software in question uses a so-called Copyleft license or a so-called Permissive license.
The following is "taken" from https://fossa.com/blog/all-about-copyleft-licenses/ :
" (...) Copyleft vs. Permissive Licenses
The primary differences between copyleft and permissive licenses are compliance requirements and how “open” any code modifications must be. Typically, permissive licenses only require users to include a copy of the license text and the original copyright notice in any redistribution of the licensed code. Otherwise, they can do whatever they want with it. For example, a developer can take the code, modify it to create a new program, then keep the code of that program to themselves, making it proprietary and closed-source. They could then sell that program commercially.
Copyleft licenses, on the other hand, have more stringent conditions. Like permissive licenses, they generally require users to include the original copyright notice and the license text, but they also obligate users to make the source code of any modifications or derivative works to all recipients of the binary, under the same license as the original.
Copyleft License Use Cases
The best type of license for any given piece of software depends on a number of factors. Before selecting a license for your own OSS project, consider what you want to achieve with your software and how you want others to interact with your code.
For instance, a copyleft license may be the right fit for your project if you:
- Want to share improvements with the OSS community
- Believe in a collaborative approach to building software
- Want to commercialize your project
- Don’t want your code made proprietary by someone else
- Are creating a project within a community that tends to use a specific copyleft license
On the other hand, a permissive license might be the best choice if you:
- Don’t want to spend much time (or worry) on license compliance
- Want to make it as easy and appealing as possible for others to use your code
- Are creating a project within a community that tends to use a specific permissive license
(...)
Types of Copyleft Licenses
Copyleft licenses come in two flavors: strong and weak. This distinction turns on how much new or adjacent code is subject to the copyleft license.
Under a strong copyleft license like GPL, if you redistribute a program that includes GPL code written by others, you must make your entire program available under GPL. That includes any linked libraries or other components of the program. Examples of licenses that fall into this category include GPL v2 and GPL v3, as well as the Affero GPL License (AGPL).
Weak copyleft licenses also obligate users to release their changes. However, this requirement applies to a narrower set of code. The Mozilla Public License 2.0 and the CDDL (Common Development and Distribution License) are examples of weak copyleft licenses that illustrate this principle. If a user keeps the licensed code in separate files, they can then combine it with additional and/or modified code to create an aggregate work. The newly added files may be released under a different license or kept proprietary (closed-source). This is sometimes referred to as file-based copyleft. Another example is the LGPL, which mainly applies to libraries. Any changes to the library must be released under the same license, but a work that simply uses the library is exempt. (...)"
.png "Commander"){kind=icon}
