Please keep non-free add-ons out of releases
It's good that Chamilo allows other people's software to work with it. It's expected that not all of that software will be free software. While we should provide the option to install such non-free add-ons, we should IMO not suggest it to our users. In particular, I'm talking about the non-free math editor which can be enabled from the settings (which is not even free as in beer), and to a lesser extent about text-to-voice services with a non-free license, Google maps, and so on.
I realize that those features make Chamilo very powerful. However, they also turn it into an advertisement for those programs. I am happy to spend my time on a great free software project. I'm not at all happy to spend it on promoting non-free software.
I think the proper solution is to allow plugins for all sorts of things, which can of course have any license. We can even distribute our own "free as in beer" non-free plugin package for some things. If people really want to, we can also distribute the commercial and proprietary plugins.
I'm thinking of packaging Chamilo for Debian. For that it is required to have this split, or else all of Chamilo will end up in non-free. It doesn't belong there, and we want people who prefer free software to see that Chamilo is for them. :-)
Updated by Yannick Warnier over 6 years ago
- Target version changed from 1.9 Stable to 1.9.2
I fully agree with you and one goal is to package for Debian so indeed, we would like to keep those plugins out. I have discussed this with Juan Carlos who removed it, and we are now discussing with the editors of the mentioned software about the parts that they can release as free software so as to allow users to install the non-free parts more easily if they want to and after being informed about the non-free (as in freedom) character of the software they might want to install.
I realise that even this is non-optimal, but we have been asked by a few (only a few) teachers to simplify the integration process. Adding it as a plugin is a better option, indeed. I will take this into account (not likely to be ready for the next release though)