FreeCAD
Add ladybug python module, fixes #411
Licenses... https://interoperable-europe.ec.europa.eu/licence/compatibility-check/AGPL-3.0-only/LGPL-2.1 https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility
According to my understanding this would require changing FreeCAD to AGPL3.
Would it be an option to add Ladybug as an addon which can easily be installed instead?
I've contacted the Ladybug authors, so we can discuss if there's way to solve this unfortunate incompatibility: https://github.com/ladybug-tools/ladybug/issues/640
in any case there is no ladybug package in conda-forge so this doesn't work as is, you would have to specify that it should be fetched from pip. I believe pysolar also provides the same functionality so maybe we can ship that
Licenses... https://interoperable-europe.ec.europa.eu/licence/compatibility-check/AGPL-3.0-only/LGPL-2.1 https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility
doesn't this cover our case here?
- In case the two components are not merged, but used according their normal usage instructions and distributed together to third parties (i.e. on the same media or distribution), each component - even modified - keeps its primary licence: inbound licence or outbound licence.
@adrianinsaval but you don't use
My understanding (IANAL) is:
Compatibility is depending on the type of "Use".
- Private or internal use is never restricted by any open licence and the resulting combined work does not need specific licensing, as soon it is not distributed to third parties.
We can have an addon which adds ladybug that users can install themselves without any issue.
- In case the two components are not merged, but used according their normal usage instructions and distributed together to third parties (i.e. on the same media or distribution), each component - even modified - keeps its primary licence: inbound licence or outbound licence.
We can have a freecad package in a package manager which can use a normal ladybug package, as long as we don't keep a ladybug-lib hidden in the freecad-package (like in a bundle). We can however have a zip file which contains two installers, one for freecad and one for ladybug.
- In case the two components that could be used independently are linked for ensuring their interoperability, for example APIs or data structures for exchanging parameters are copied/reproduced from one program to the other, Some legal theses (not confirmed in courts) state that by a kind of "viral effect" the inbound licence becomes applicable to the whole combined work. However, in so far the European Law would be applicable, it states that by exception to strict copyright rules, such reproduction can be done without obtaining the right holder permission or licence, provide this linking is compatible with a normal exploitation of the programs and does not conflict the legitimate interest of copyright holder. This is resulting from Directive 2009/24/EC recitals 10 and 15 invoking a copyright exception for making interoperable two components from various providers.
Here my understanding is that in EU (probably not the case for US and the rest of the world), we can include h-files from (A)GPL3 libraries so we can use those libraries. But if a header library (like boost) is under (A)GPL it wouldn't apply.
- In case substantial parts of the source code covered by the inbound licence have been merged / integrated with code covered by the outbound licence, the outbound licence, which is compatible with the inbound licence, authorise distribution of the whole combined work under the inbound licence. This is applicable to this new combined work only (a derivative or "forking" from both source codes, which is a specific project with a specific name), and does not normally authorises relicensing (changing the licence) of the original code covered by the outbound licence.
We can always distribute FreeCAD under AGPL3.
But when it comes to LGPL2.1+ compatibility with AGPL3, GNU quite clearly states that the combined has to be released under AGPL3:
I'm not a lawyer though and I when it comes to gray zones, I tend to argue to stay on the safe side.
AGPL3 is more restrictive than LGPL3, but releasing AppImage as AGPL3 does not really change licensing of FreeCAD source codes, because its a subset... So it will probably hurt noone to do that. All the extra permissions provided by LGPL are still licensed for FreeCAD codebase. So i see no reason why users of AppImage should care.
We can also argue that FreeCAD project uses upstream ladybug distributions therefore does not owe any source codes to users of its binaries (those are provided in upstream)
AGPL3 is more restrictive than LGPL3, but releasing AppImage as AGPL3 does not really change licensing of FreeCAD source codes, because its a subset... So it will probably hurt noone to do that. All the extra permissions provided by LGPL are still licensed for FreeCAD codebase.
So far I 100% agree.
So i see no reason why users of AppImage should care.
Most probably doesn't care.
But my point is that we need to change the license of the combination, the bundle/AppImage if we want to do this. But by doing that you're releasing it under a stricter license, which could cause issues if someone wants for instance to use FreeCAD with proprietary libraries on a website (to calculate the weight of a shape for instance). Then AGPL3 can cause issues.
This is a choice we have to make if we want to go down this route.
...or we could just provide ladybug as an addon and we avoid all this.
We can also argue that FreeCAD project uses upstream ladybug distributions therefore does not owe any source codes to users of its binaries (those are provided in upstream)
It doesn't matter if we change the code or not, it matters how we combine the work. But as noted on the EU page, as long as we keep installation separate, this isn't an issue (like providing ladybug as an addon).
which could cause issues if someone wants for instance to use FreeCAD with proprietary libraries on a website (to calculate the weight of a shape for instance
if someone is going to base his software on FreeCAD, he can always base his software on freecad source code rather than appimage. i don't think that needs of hypothetical developers should be reason to limit everyday primary users.
Alternatively there can be two AppImage releases with different licenses, one being specificaly for website developers. But it feels like a stretch.
...or we could just provide ladybug as an addon and we avoid all this.
We can effectively do this already by asking users to install ladybug (or any other packaged addon/dependency) via pip or similar. This is not the best user experience, but at least enables power users to use the add-ons.
Some workbenches add their own mechanisms to download key dependencies or add-ons. To me, the best approach would rather be to have a unified, streamlined mechanism to install those non-essential but nice-to-have dependencies. Coincidentally, I submitted a feature request for exactly this recently:
https://github.com/FreeCAD/AddonManager/issues/105
In my interpretation distributing ladybug inside the appimage is not "merging" the two projects, it is simply a distribution that contains both projects and freecad uses ladybird according to it's normal usage (importing in python)
This is not the best user experience, but at least enables power users to use the add-ons.
Not the best indeed. I can install libraries manualy myself. But when i have some buddies that i want to introduce into FreeCAD ecosystem or (god forbid) people that i want to collaborate with on shared project. There's no way they're gonna think im sane when i start explaining what pip is (or what they should do about /usr/lib/python*/EXTERNALLY-MANAGED file). Or even when i use multiple laptops and i've lost track what library i've installed on which of them. Whole situation becomes riddiculous rather quickly... My worst nightmare is that someone asks me how to get FEM working (at least on Linux, not sure about Windows).
I think we all agree here :-) That's why I made the "power users" distinction in my comment.
Anyway, if this is your hill then I think it would be best to add it to a dev meeting. This is how we handled similar discussion in the past.
(🤫Or addon)
