Fman Build System licensing

[Matt Wilkie]

from "Re: Linux Snapcraft and Packager integrations are broken" thread:

We might not be allowed to use FBS because of licensing: "To comply with its license, you need to open source your application itself under the GPL, or buy a commercial PyQt license". This is probably because they solve some of the packaging and distribution problems by bundling PyQt, which is GPL (or commercial). I've asked their licensing department to clarify if this restriction applies to X/MIT projects such as Leo.

FBS author Micheal Herrmann got back to me quickly and granted a specific exemption for Leo, so long as the text of that exemption was added to the LICENSE file. However it only applied to Leo specifically and not to forks. This would mean that other works from Joe Orr, Vitalijie etc. would have to ask for their own expemptions. Not very palatable in my opinion. However, in further discussion we arrived at a much better and cleaner solution: create a new repo under Leo Editor organization that is specific to FBS packaging and distribution. This repo would have GPL license, and thus not need an exemption. Anybody who wants to fork Leo proper can continue to do so as they've always done, ignoring the FBS specific repo.

So Chris yes you can freely explore FBS as a better packaging tool (if you still have appetite for any of this ;-).

I'll add the relevant portions of my discussion with Micheal as a later reply to this thread.

-matt

[Matt Wilkie]

Edited conversation with Micheal Hermann:

-----
From: Matt Wilkie <maphew@gmail>

Hi,

A colleague pointed me to the Fman Build System as a solution for many of our packaging and distribution problems. However the licensing description at https://build-system.fman.io/ sounds problematic. Our project is open sourc eX/MIT. There's zero chance of being able to use the GPL license as the project has been going for 20+ years (we can't get agreement and copyright from all contributors).

We use PyQt5 from PyPi.org. Can we use FBS at all or are we hooped?

{...}

http://leoeditor.com (https://github.com/leo-editor/leo-editor)

Thanks,

Matt

------
From: Michael Herrmann <mic...@herrmann.io>

Thanks Matt. I'm willing to grant you an exception that lets you use fbs for Leo, under the condition that you add the following to your LICENSE file:

Leo uses fman's build system (fbs) for packaging and deployment. fbs is normally licensed under the GPL. This would force Leo to be licensed under the GPL as well. This is impossible for historical reasons. So, Leo has obtained express permission from the creator of fbs Michael Herrmann to use fbs without being bound by the GPL. However: This exception only applies to Leo itself. If you fork Leo, or use parts of its code that depend on fbs, then you are bound by fbs's GPL license or need to obtain an exception of your own through https://build-system.fman.io.

-----
Matt Wilkie <map...@gmail.com>
17 Aug 2019, 15:13 (2 days ago)
to Michael

Thank you for the kindness Micheal. I'll bring it to the team and see what the concensus is.

I'm a bit leary of the part (emph. added) "If you fork Leo, or use parts of its code that depend on fbs, then ...". Parts that depend on fbs? Absolutely. Just forking Leo though? Now that GitHub, BitBucket, et al have made forking trivial and the standard method to generate a patch that restriction seems too much.

{...}

On forking: what if the LICENSE addendum were in a distinct "packaging & deployment" section (folder), and clearly applied only to the contents of that folder tree, and to the resultants from that code? (the release packages). Or perhaps better yet, a separate "packaging" repo under our organization?

This way contributors and collaborators can fork Leo itself without any concerns or changes to their workflow as they've always done. And we don't have to police or add explanations that get in the way of the main activity.

-matt


-----
On Sun, 18 Aug 2019 at 22:48, Michael Herrmann <mic...@herrmann.io> wrote:

Hi Matt,

a separate packaging repo actually sounds like a good solution. Then this repo could be under the GPL while LEO itself stays X/MIT. It would also be clear to contributors.

Cheers,
Michael

--
Michael Herrmann
Vienna, Austria
Follow me on Twitter