-
Notifications
You must be signed in to change notification settings - Fork 75
Add ladybug python module, fixes #411 #412
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
Licenses... 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: |
|
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 |
doesn't this cover our case here?
|
|
@adrianinsaval but you don't use My understanding (IANAL) is:
We can have an addon which adds ladybug that users can install themselves without any issue.
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.
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.
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) |
So far I 100% agree.
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. 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.
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). |
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. |
We can effectively do this already by asking users to install ladybug (or any other packaged addon/dependency) via 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: |
|
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) |
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) |
|
bump |
1 similar comment
|
bump |
this repo is not in use anymore, if we want to include ladybug it has to be added to https://github.com/FreeCAD/FreeCAD/blob/d116764dc380be41ab73af4e9032baabb28f701f/package/rattler-build/recipe.yaml#L139-L174 and https://github.com/FreeCAD/FreeCAD/blob/d116764dc380be41ab73af4e9032baabb28f701f/pixi.toml#L10-L66, the license question still remains |

See #411