third_party about pjproject-archive

[jaredsmith]

I couldn't agree more. That being said, I can understand the Asterisk developers' hesitance to make this fork any more different from upstream than they have to.

[saghul]

PJSIP already allows using non bundled versions of third party libraries: --with-external-portaudioand so on.

The fact that the code is in the third party directory doesn't mean it's used when building packages, can this be a problem?

[jaredsmith]

Actually, yes -- I know Fedora frowns on having the third-party libraries bundled in the code, even if the packaging ends up using the system version of the libraries instead. My understanding is that Debian feels the same, although I haven't taken the time to look at the Debian policy in any detail. It's also a problem when the third party directory contains code that isn't acceptable (for patent or other licensing reasons) to the distribution. For example, the "third_party/mp3" directory stands out a red flag here.

[saghul]

Sigh. I guess the solution would be to ask the PJSIP guys if it would be possible for them to release tarballs without the third_party directory.

FWIW, the mp3/ directory just contains a wrapper around the lame encoder, I don't think that particular piece code can be any problem, but I do get your point.

[jaredsmith]

Yes -- that's exactly what I'd love to see -- a tarball without the third_party/ directory.

Just found another potential issue with code in the third_party/ directory as well -- the g7221 directory doesn't have any LICENSE file, but the file headers seem to indicate that the code is copyright Polycom and all rights reserved. :-(

Assuming for a moment that this really is the G722.1 code that Polycom released, it's under the following license: http://www.polycom.com/company/about-us/technology/siren/siren-license-agreement.html. Inclusion of the license text seems a prerequisite for using/including the code. I don't even want to begin thinking of through the implications of linking that code with GPL code -- it definitely appears to be a non-GPL-compatible license.

In short, I think the pjproject guys are playing fast and loose with this third-party code, and I'd rather not see it in the tarball at all.

Saúl, do you have a relationship with the pjproject developers, and would you be willing to ask them about building a tarball without the third-party code?

[saghul]

Saúl, do you have a relationship with the pjproject developers, and would you be willing to ask them about building a tarball without the third-party code?

I've used PJSIP for many years, but I don't have a direct backchannel ;-) If you send an email to the mailing list with your proposal I'll be sure to chime in and support it.

Now, I guess we want to have the dynamic linking patches merged in first, so that peple can dynamically load stuff like codecs.

[matt-jordan]

I remember Tzafrir mentioning during AstriDevCon that he had produced packages for Debian by removing the third party library folder completely. IIRC, it compiled just fine without it.

Is it a requirement of Fedora that they be provided with a tarball by the producer that they don't have to modify in the least? Or is the ability to "rm -rf third_party" sufficient?

If not, I'd be happy to chime in on any post on their mailing lists as well.

[matt-jordan]

Heh - in the interest of "just trying it", I blew it away on a local copy. There are some minor modifications that would have to be made to just ignore the third_party directory completely. At a minimum, we should probably look at the changes Tzafrir made for Debian and see how hard they'd be to push upstream.