To implement a feature for the audio and video element, we need to import the SoundTouch [1] library in the mozilla-central tree. It is LGPL 2.1 licensed [2]. Can we use this library in the tree? If yes, do we specifically need to keep the resulting library in a separate dynamic library (.so or .dll), or can we put the code into libxul.so? Are there other implication when using this particular piece of code in Gecko ? [1] : http://www.surina.net/soundtouch/index.html [2] : http://www.surina.net/soundtouch/license.html

Yes, we need to keep it in a separate dynamic library, and make sure it's always dynamically linked. You might even want to call it mozlgpl.so or a similar name, so that we can add other LGPL code to it later. (Does that make sense from an engineering perspective, or should we have one shared library per library?) CCing Luis as this is the first time we've done this, to see if he has any additional thoughts on requirements. Gerv

It would be best to do a shared library per lgpl library, if that is feasible from an engineering perspective, so as to meet the requirements of LGPL 2.1 6(b). You'll also need to prepare a suitable license text for about:license, in compliance with LGPL 2.1 Sec. 6. This should be fairly straightforward to do - model it after the other texts in about:license. Source code will be placed in hg and source tarballs? Or separate? Either is fine as long as we are doing it somewhere.

> LGPL 2.1 Sec. 6 (2) > >...will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. I don't think we can promise that we'll "operate properly with a modified version of the library, if the user installs one," so the mozlgpl.so approach that Gerv suggests (with external linkage that we define and modify at will) seems more prudent.

Can you elaborate on that a bit, Jet? The requirement isn't that you can operate properly regardless of the modification, simply that if placed in the right location, with the right soname, etc., the OS will attempt to load it and not fail *for reasons imposed by the app* (e.g., checksumming the library or something like that). If the user modifies the source to simply return -1, the application is not expected to handle that gracefully internally (or else no one would ever use 6(b)).

I think we want to control the linkage into the LGPL code we use, rather than allow untested (by us) libraries from loading into Firefox. Of course, if the user were to build mozlgpl.so from modified sources, then replace our shipping version, we would unknowingly load it as our own. Is this enough for us to assert compliance with LGPL 2.1 Sec. 6 (2)?

(In reply to Jet Villegas (:jet) from comment #5) > I think we want to control the linkage into the LGPL code we use, rather > than allow untested (by us) libraries from loading into Firefox. Of course, > if the user were to build mozlgpl.so from modified sources, then replace our > shipping version, we would unknowingly load it as our own. Is this enough > for us to assert compliance with LGPL 2.1 Sec. 6 (2)? Yes; this is precisely the right which must be preserved. They have to be able to change it out for one which works the same or differently without us trying to stop them. Gerv

I'm ready to put the import patch up for review, here, but I need to mention the library in about:license. Should I create a LGPL section, and say that files in `media/libsoundtouch/src` are LGPL licensed hoping that we will use more LGPL libraries in the future, or create a SoundTouch section, and put the text for the LGPL?

Paul: probably best to file a bug and assign it to me :-) (It doesn't matter if updating about:license lags the code import by a few days.) Please put a copy of the LGPL in a LICENSE file in the directory into which you are importing the code, though. Presumably media/libsoundtouch? Gerv

(In reply to Gervase Markham [:gerv] from comment #6) > (In reply to Jet Villegas (:jet) from comment #5) > > I think we want to control the linkage into the LGPL code we use, rather > > than allow untested (by us) libraries from loading into Firefox. Of course, > > if the user were to build mozlgpl.so from modified sources, then replace our > > shipping version, we would unknowingly load it as our own. Is this enough > > for us to assert compliance with LGPL 2.1 Sec. 6 (2)? > > Yes; this is precisely the right which must be preserved. They have to be > able to change it out for one which works the same or differently without us > trying to stop them. We could lock the library (checksum, etc), so long as the user can unlock it or re-checksum their modified library. IANAL of course

I'm not sure why we are going down this path. I can compile any other Moz library from source and drop it into my Firefox install, and potentially break something. In that case, I get to keep both pieces. Why would that not be equally true for libsoundtouch? I don't think we need to go to extra effort to prevent people swapping out a library simply because its license specifically names it as a right you need to preserve. That seems perverse :-) Let's just do this this obvious, simple way. Gerv

(In reply to Gervase Markham [:gerv] from comment #10) > I'm not sure why we are going down this path. I can compile any other Moz > library from source and drop it into my Firefox install, and potentially > break something. In that case, I get to keep both pieces. Why would that not > be equally true for libsoundtouch? I don't think we need to go to extra > effort to prevent people swapping out a library simply because its license > specifically names it as a right you need to preserve. That seems perverse > :-) You misunderstood - I was talking about locking it to outside perturbation, so the user could replace it on purpose or at least be warned it was replaced. It's possible to do so (which was being asked); whether that's a good idea or not is a separate question. :-) > Let's just do this this obvious, simple way. Agreed. We don't do this for all the other system libraries we depend on (and can be overridden by the user); the only difference here is that we'd be distributing it.

Conveniently, that's what it implemented in bug 779997: libsoundtouch.{dll, so, dylib}. For the DLL, we made sure to fill the copyright, etc. field appropriately. It works pretty well. Should this bug be closed, now?

The library this bug is about has been landed. This can be closed, now.

Considering it's preferable to avoid the proliferation of shared libraries, I'd like to note that libsoundtouch is licensed under LGPL 2.1 *or later*, and that LGPL 3.0 section 4 (d) has an alternative that LGPL 2.1 6(b) didn't provide, and that, as I read it, allows us to *not* ship libsoundtouch as a shared library.

:glandium: a few minutes perusal suggests that you are right. If you want to file a bug on making libsoundtouch to be not a shared library, and instead get us to take the code under LGPLv3 and use that permission, please do so, and CC me. Gerv