search

asterisk / pjproject-archive

Asterisk fork of PJSIP NO PULL REQUESTS OR ISSUES!!!
GNU General Public License v2.0
69 stars 42 forks source link

third_party #3

Closed paravoid closed 6 years ago

paravoid commented 11 years ago

This is probably of a larger scope than this fork is about, but if the goal is to be friendly to packagers, then third_party must go… Distributions are not very fond of embedded third-party libraries (and are in fact forbidden by most of them) and especially the ones that exist within the distribution as proper shared libraries (portaudio, speex, srtp etc.). Depending on how pjproject and these libraries are loaded, It could also be a symbol hell for downstreams. But I'll stop before I reiterate all my arguments in the asterisk-dev discussion here :)

jaredsmith commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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.