Skip to content

Conversation

@Harvie
Copy link

@Harvie Harvie commented Jun 9, 2025

See #411

@hyarion
Copy link

hyarion commented Jun 9, 2025

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?

@Harvie
Copy link
Author

Harvie commented Jun 9, 2025

I've contacted the Ladybug authors, so we can discuss if there's way to solve this unfortunate incompatibility:
ladybug-tools/ladybug#640

@adrianinsaval
Copy link
Member

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

@adrianinsaval
Copy link
Member

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.

@hyarion
Copy link

hyarion commented Jun 10, 2025

@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:
image


I'm not a lawyer though and I when it comes to gray zones, I tend to argue to stay on the safe side.

@Harvie
Copy link
Author

Harvie commented Jun 10, 2025

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)

@hyarion
Copy link

hyarion commented Jun 10, 2025

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).

@Harvie
Copy link
Author

Harvie commented Jun 10, 2025

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.

@furgo16
Copy link

furgo16 commented Jun 10, 2025

...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:

FreeCAD/AddonManager#105

@adrianinsaval
Copy link
Member

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)

@Harvie
Copy link
Author

Harvie commented Jun 10, 2025

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).

@furgo16
Copy link

furgo16 commented Jun 10, 2025

I think we all agree here :-) That's why I made the "power users" distinction in my comment.

@hyarion
Copy link

hyarion commented Jun 10, 2025

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)

@luzpaz
Copy link
Collaborator

luzpaz commented Oct 16, 2025

bump

1 similar comment
@luzpaz
Copy link
Collaborator

luzpaz commented Dec 4, 2025

bump

@adrianinsaval
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants