hi Mohammedreza, I'm answering this separately for clarity :).

comment #3:

> Two day ago, Mohammad and I had a chat over this that if we keep Maneage GPL licensed, wouldn't it be possible for someone who uses non-GPL licensed software to use Maneage in their project and even release the GPL part?
> I believe the answer to both questions are yes.

I think so too - many of the packages that we download/compile/install are free software but not GPL, and some are probably free software but GPL-incompatible.
 

> I will put forward these questions:
> * let's say you have written a bash script and you have used grep, which is GPL licensed, inside your script, do you have to license your script with GPL?

The GNU.org guidelines (as you link to below) insist that the result of running a program is not covered by copyright. The result of reading a book  is not a copyright issue. So I would say "No".

> A script is open source in nature, so you can do whatever you want with it, no questions asked. There is no need to extend or tailor this analogy to our case because it is already tailored, in its current form, to our case: we have a GPL licensed script (like grep) and someone else might wanna use it in his/her own project where s/he is using proprietary software,

Just two corrections there: a script is not necessarily either open-source-definition licensed, nor free-software licensed. Secondly, 'grep' in Maneage is a binary, not a script. :)
 

> * does s/he need to license his/her project with GPL? Well, certainly not. But of course with enough precautions and measures not to deny our right of freedom!
> ** https://www.gnu.org/licenses/gpl-faq.en.html#GPLInProprietarySystem
> ** https://www.gnu.org/licenses/gpl-faq.en.html#CanIUseGPLToolsForNF
> ** https://www.gnu.org/licenses/gpl-faq.en.html#CanDeveloperThirdParty
>
> * Is s/he releasing the source code of the propriety software? of course not!

There's plenty of non-free software which is not fully proprietary (GNU/FSF probably disagrees, but I think most people would agree that there's a spectrum). But if someone wanted to download/compile/install or download/install a non-free, even fully proprietary program, that would be up to him/her to decide if that's consistent with the non-free conditions in the licence. In fact, in principle a web server may require a login or an online signing of a terms-of-agreement statement. That's up to the people developing that to work out how to handle - and for them to contact legal people if they're worried.

I agree - someone doing that would have to be careful not to risk the overall default GPL and other free-licensed aspects of Maneage.

I think the links you gave are very useful, and a key part is:

However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and nonfree programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.

So I think that making any non-free (better non-free than not-free, for consistency with wider usage) components well separated, at arm's length, is what we would need.

For example, in parallel to high-level.mk, we would have non-free.mk . We would probably also have to modify project , maybe to have both ./project make and ./project make non-free_, , for example. I think that Debian would be a good example to follow.

comment #1:

> One fast licensing solution that I have been considering for some time, is to convert the license of Maneage to LGPL.

I see no reason for switching to LGPL. On the other hand, we could clarify that the GPL is the default licence for all the component programs and makefiles (which might not legally count as "programs") of the Maneage package .

> Once they start using Maneage and seeing the benefits of free software, we may be able to convince them to slowly shift from those software and data formats. But in order to see these benefits, they need to be able to use Maneage first, in a way that they can incorporate proprietary software.

Sure. So the question is how to handle this specifically.

> Also, I feel Maneage can be appealing to industrial applications too and if we adopt LGPL, they can safely benefit from and give-back to it.
>
> So I am changing the title of the task to be more clear.

So I'm changing in again to what seems to me to be more clear. :)

On the technical aspect of what components need to be modified to allow it, one fast solution that comes to my mind is this: we can include the build instructions of non-free software in 'reproduce/software/make/not-free.mk' and add a special variable in 'TARGETS.conf' for people to be able to select such tools if they want, and ofcourse automatically cite them if they have a paper (like any other software).

While non-free software is incompatible with Maneage in terms of licensing elements of "the package itself", downloading, compiling and installing non-free software is allowed, it seems to me (though I'm not a lawyer). There are going to be some people who, although they understand the political reasons for using free software (euphemistically called "philosophical" reasons by the FSF), will choose to install some non-free software as part of the Maneage configure pipeline.

Are there arguments to forbid this?

Which existing tools in Maneage need to be changed so that the non-free part is well-isolated from the free part (as in Debian) and appropriate ostracised as a temporary compromise?

The software acknowledgments scripts would have to handle this (see
https://savannah.nongnu.org/bugs/index.php?58545 for a related point).

One example of a widely used cosmology program that is still non-free after many repeated requests is CLASS: https://github.com/lesgourg/class_public/pull/242

This task would to some degree answer (via the creation of a 'task') the "POSIX dependency" point of the review https://doi.org/10.22541/au.159724632.29528907, in which the author says that propietary (non-free) software is sometimes needed.