https://bugzilla.redhat.com/show_bug.cgi?id=1760617 --- Comment #15 from Qianqian Fang <fangqq@xxxxxxxxx> --- @Ankur I agree with you that it makes software more modular and scalable if all dependencies can be built as separate packages. However, I think the scenario here is slightly different. the 4 external components that mmc depends on, namely, sse_math, waitmex, cjson and SFMT, are extremely lightweight units, and are designed primarily for embedded use. For example - sse_math is a header-only single-unit header file - waitmex and cJSON are both single-unit (waitmex.c/.h, cJSON.c/.h) libraries - SFMT is also a single unit (SFMT.c with multiple header files) library if you search on github, the majority of the appearance of SFMT are for embedded use, similar to mmc, https://github.com/search?q=SFMT.h&type=Code same for cJSON https://github.com/search?q=cjson&type=Code in fact, the embedded use of these utilities are seen as an advantage by the authors of these tools, and they intentionally designed the unit as portable and lightweight as possible to enable such use, and also to ensure such by using a more permissive license (BSD, MIT, ZLIB). In a way, I am permitted, by the respective licenses, to convert each of the cited units into GPL and place a uniform license disclaimers in each of the units, so that it looks more like an integrated/single-licensed source-code tree, but I prefer not to do that because I have to make such edits again if I want to sync some of the units to new releases. I also thought it would give upstream authors more visibility by keeping their original disclaimers in the source codes; but I did not expect this visibility to turn into a restriction for me to distribute the final software in the license that I desire (which is known to be compliant with the upstream licenses). again, I am not against packaging these lightweight libraries separately (I am happy to help), but it is not as beneficial in the case of mmc. Because these libraries are generally not available even in open-source distributions, not mention about windows/mac where the majority of mmc users use, to make mmc dependent to such libraries makes the code hard to compile for a large portion of my existing users. I will also have to deal with future changes of the API interfaces and data structures that may happen independent to my codes. So, even we can create separate packages for these utilities, I still prefer my code to embed these lightweight units for portability - perhaps in the future if these libraries become widely available like libz, libblas or libOpenCL, then, I may consider switching to dynamic linking mode. let me know if this makes sense to you. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
