> A more powerful form of scripting can be done from Python, using the `marcel.api` module. With this module, you have access to the operators of marcel, neatly integrated into Python.
This looks like an appealing feature! Having some more coreutils-like functions available in python (i.e., stuff that I wish was in the `os` module) would simplify some cases where I otherwise might have to resort to `subprocess` calls. The GPL license definitely narrows the number of situations where I would realistically be able to add this as a dependency, though.
GPLv3 is a "strong copyleft" license. It comes with some significant pros and cons compared to more permissive licenses like MIT and BSD. You can find more about the philosophy behind it here: https://www.gnu.org/philosophy
As the author, a benefit it offers you is protection against someone selling your work or a derivative of it, or redistributing it with added restrictions.
From a user's perspective, the main downside is that using GPL software as a dependency makes the user's project a derivative work, which requires them to license their own project with the GPL (or from a selection of other compatible copyleft licenses).
In that sense it's considered a "viral license," i.e. everything downstream of the GPL software needs to adopt GPL. This is less of a problem for an application, but is more troublesome for a library (with many dependents of its own, with dependents of their own, and so on). It also means that if you use it in commercial software, you essentially need to open-source all of it.
So in your case, just using Marcel as a shell with GPL doesn't put any licensing obligations on the user, but using it as a library does.
I hope that helps! Someone else feel free to chime in if I misrepresented any of that.
Anyone is welcome to sell GPL'd work, also someone else's GPL'd work, as long as the license remains GPL and source code is available to the buyers of the work, under the GPL, if you distribute the software to them. If you don't (i.e. SaaS, you run the software, it is never distributed further) then you don't have to give the source to anybody! This is what the AGPL was created to address.
Yes, in this scenario the LGPL was created so that I could create a library, and if anyone modified my library they had to share the improvements however using my library does not then apply the GPL to your code.
> The license allows developers and companies to use and integrate a software component released under the LGPL into their own (even proprietary) software without being required by the terms of a strong copyleft license to release the source code of their own components. However, any developer who modifies an LGPL-covered component is required to make their modified version available under the same LGPL license.
Yes. If they modify marcel.api they are bound by the LGPL to release their modifications, however they are not bound to release their application if they use marcel.api
There is GPL, LGPL and AGPL (probably others).
GPL code is viral, think of Linux and if you incorporate Linux code in your code them you have to GPL it, which means if you distribute it you have to give a copy of the source to your customers.
AGPL is newer and extended this, because Amazon et al, took GPL software and offered it as a service, so didn't "distribute", could make their changes and offer it as a SAAS and not offer their code changes. AGPL covers this scenario and means that you have to offer the source if you provide network access.
LGPL is almost as old as GPL, and allows people to write libraries as open source, which Microsoft could use in Windows without GPL'ing Windows but would require improvements to the library made by Microsoft to be distributed.
But as always, read the label to make sure there isn't a side effect that we missed in this chat.
The sister comment appears to be somewhat confused. The "virality" of GPL is that if you "link" a GPL program then your license must be compatible and the combination as a whole becomes GPL. Importing a library may count as a derived work/linking.
The LGPL was created to avoid this limitation and is a natural choice for programming languages and interpreters.
As an example, GNU Guile, an interpreter for the Scheme language, is LGPL licensed. Writing any nontrivial Scheme script requires importing code from Guile. If it was GPL then all scripts had to be GPL compatible; but since it's LGPL, programs using Guile modules can have any license (even proprietary).
This looks like an appealing feature! Having some more coreutils-like functions available in python (i.e., stuff that I wish was in the `os` module) would simplify some cases where I otherwise might have to resort to `subprocess` calls. The GPL license definitely narrows the number of situations where I would realistically be able to add this as a dependency, though.