*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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/89ddc310-a5f7-45c6-87c4-1d5d4b7dab70%40googlegroups.com.
