[asterisk-users] asterisk-gplonly dependency in asterisk-addons RPM

[Kevin P. Fleming]

Chris Miller wrote:

> Understood, I figured it was something like that. Do you have some
> mechanism in the source install that causes similar enforcement behavior?

No, because there's no practical way to do it. If someone downloads and
installs Asterisk and Asterisk-Addons from source, then downloads and
installs Skype For Asterisk, it will load and operate as they expect. If
doing so ends up violating a license that something in Asterisk-Addons
links to, there's not really much we can do about it. We could have some
sort of mechanism in Asterisk (similar to what the Linux kernel has)
that allows modules to know if other modules have been loaded that have
strict 'GPL only' usage permissions and refuse to load, but that seems
like it would be difficult to build and make work properly.

> It seems to me that the GPL information could be displayed in the
> "register" binary since no end user can use a Digium supplied commercial
> module without registration, right? It could also be displayed on the
> Digium website where end users have to purchase their Digium licenses.

But when the user is running 'register', there's no way to know they
will (or have) installed anything from -addons that might be in
conflict. In fact, it's the license on the content from -addons that is
in conflict, and so that's the only logical place for the restriction to
be placed. Otherwise, the language displayed by 'register', on the web
site, and other places would potentially have to enumerate all known
conflicting content, which is not practical.

> This begs the question of when the actual violation occurs. In other
> words, is this really a "usage" issue, or does the violation occur at
> install time even though the non-GPL component is not "usable"?

That's up to your lawyer to decide, based on the terms of the licenses
involved in the components in question.

> It sounds to me that many users are violating the GPL by installing the
> non-GPL modules. Rather than simply making it difficult to install, why
> not be proactive in encouraging compliance by detailing the steps
> openly. When I Googled for this issue, I turned up no useful
> information. Seems like a page explaining the above somewhere on the
> Asterisk and/or Digium site would be helpful.

No, they are not violating the GPL. The GPL has no terms related to
usage, it's a distribution license. If someone loads a
commercially-licensed module into their Asterisk process, and also loads
a module (not copyrighted nor distributed by Digium) that is licensed to
them under the GPL, that's not a violation of the GPL. Distributing that
combination, however, would be. The issue here is that there are
libraries used by components of -addons that *do* have usage
restrictions in their licenses, but those usage restrictions are not
part of the GPL, they are part of the specific licenses on those libraries.

> The only workaround at this point is to force install the RPMs. This
> encourages lesser skilled sysadmins to use this practice regularly (on
> all Linux dependency issues) without fully understanding what they are
> doing. I took the time to download the SRPM and saw this was an
> arbitrary dependency, but most sysadmins won't burn the time. What also
> concerned me was a few posts about a system stability issue with the
> SkypeForAsterisk module after force installing the RPM. This contributed
> to my being uneasy about proceeding with this route without full
> knowledge of the situation.

That's understandable; whether doing so will lead to admins blindly
installing stuff and overriding warnings is not something we can do
anything about. It's no different than Windows users who blindly click
'allow' every time their spyware monitor warns them, or browser users
who click 'accept' every time their browser warns about a mismatched or
expired SSL server certificate. We cannot protect users from their own
mistakes and lack of willingness to understand what they are doing. All
we can do is issue a warning that is designed to make them stop and
think before proceeding.

> I understand the reasons why this was done, but unless I've overlooked
> some resource on the interwebs, it looks like the other shoe never
> dropped and zero documentation was provided to work with this issue. I
> can't think of a clean way off the top of my head to address this in
> RPM, so I'd argue that RPM is simply not the appropriate choke point to
> enforce compliance. Feel free to send me a PM if you want to discuss
> further.

As far as I am aware, without building mechanisms into Asterisk itself,
there is no other 'choke point' that can be employed. The decision was
made to do it in the RPMs because it was convenient to do so. If there's
no way to get the RPM tool to display any additional information about
why the conflict is present, that's unfortunate, and I agree that we
need to get that information posted somewhere so that when someone
searches for it they'd be likely to find it.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming at digium.com
Check us out at www.digium.com & www.asterisk.org