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: [email protected] Check us out at www.digium.com & www.asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
