https://bugzilla.redhat.com/show_bug.cgi?id=1198498 --- Comment #4 from Rich Mattes <richmattes@xxxxxxxxx> --- The bundled library guidelines are mostly about trying to minimize the amount of duplicate code in the distribution for bugfix and security reasons (its easier to update a flaw in a single shared library than it is in 30 copies of sha1.c scattered around the distribution). For small copylibs like this, an alternative exists where the package needs to add metadata that indicates the copylib's presence, for tracking purposes. The sha-1.c file already has a standing exception to the bundled library policy, and can be used as-is as long as the proper Provides: are in place as described in the table at https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Requirement_if_you_bundle. No action is needed upstream. b64.c looks like it's in the same boat, and would probably be approved as a copylib by the fpc. But if it's sufficiently modified from the original implementation, it would probably be considered a fork and OK to include as-is. The nghttp2 code would probably also be considered a fork since you're just copying a small private API from another project. So I would file a ticket with the FPC asking them to look at both of these libs and verify that their use is OK before doing any work to port away from them upstream. I'm reasonably confident that they are, but I'd like to get the official ack. -- 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 https://admin.fedoraproject.org/mailman/listinfo/package-review