Hi, On Thu, May 02, 2013 at 08:22:39AM +1200, Robert Collins wrote: > W.r.t http://www.squid-cache.org/mail-archive/squid-dev/201206/0075.html > > I would like to expand on this - this is based on my reading of the > license terms that are under debate by the Ubuntu tech board now, > *not* on a desire for a particular outcome. > > As a Squid upstream I *hate* that Debian and Ubuntu don't ship SSL > enabled binaries. The only issues I see are technical, legacy ones - I > don't perceive a moral issue here given that OpenSSL is free software: > It is very unlike the situation with a proprietary OS, and I wish that > Squid *could* put an exception in place for OpenSSL. > > However, we have spotty contact with the union of all developers, and > it would require considerable human bandwidth to get an exception in > place - so far no-one has made the time to really get that happening.
How about "we are adding the following exception for linking against OpenSSL: ... If anyone objects, please speak up by 2013-mm-dd." And then things are fixed. :) > So - it is a violation to ship OpenSSL linked Squid IFF you agree that > OpenSSL isn't a 'system library', and to date I have sided with the > Debian interpretation of that. As a project however, Squid would like > to see SSL enabled binaries shipping by default. I can guarantee that > I wouldn't stand in the way of OpenSSL being determined to be a system > library, though I can't make that statement for the set of all past > contributors to Squid! However, any such postulated contributor that > objects could have stated their grievances with Fedora/RHEL at any > time in the past, so it would be very odd for them to turn up now and > complain specifically to Ubuntu, were Ubuntu to start shipping SSL > enabled binaries. > > Finally, it irks me that Fedora and Debian/Ubuntu have different > answers for the 'is OpenSSL a system library' question. It makes it > hard for folk writing software :(. I've personally never had a problem with the OpenSSL linking. It seems a needlessly picky interpretation of the intent of these licenses. -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
