Investigate moving ext/exif to libexif

[nikic]

Libexif: https://github.com/libexif/libexif

The current exif extension has many bugs and has historically suffered from security issues. It would be great to use an established library instead.

From a cursory look, a potential blocker for this is the lack of TIFF support in libexif. There's a PR for that at libexif/libexif#17, but it seems stuck.

[johannes]

Libexif uses LGPL. This is problematic when statically linked. And for shared linking I'm not sure whether we can rely it to be on all systems.

[nikic]

@KalleZ did some experimentation with libexif in https://github.com/KalleZ/pecl-exifkit.

@johannes What does that mean in practical terms? Does it mean we can't bundle the library with php-src?

[johannes]

IANAL - obviously.

We also have precedent: libmbfl, which be bundle in mbstring is LGPL.

What does it mean: PHP License says "do whatever you want, but give credit (and don't use PHP name etc.)" thus allows shipping binaries (as Zend does/did in Zend Server) in commercial context.

LGPL says "you can use this in something not GPL, but the LGPL component has to be swappable" meaning that if a user uses a precompiled PHP they have to be able to replace the .so/.dll./.dynlib with the LGPL code and use a version they compiled themselves. Thus somebody shipping PHP binaries has to link libexif as shared lib.

Whether this only applies to libexif.so or also applies to all code including a libexif header I leave to interpretation of your favorite lawyer ... if the headers only contain function declarations it's simpler, I guess; if they have macros with logic or even C++ templates it becomes more complex.

I believe if we have this on ext/exif it's fine. Users/distributors can build that shared and all problems solved (except for all the new problems due to shared libs), however we obviously shouldn't do it in a patch version :)

Distribution guys like @remicollet or @oerdnj might have more insight/opinions.