Hi, On Thu, Sep 22, 2016 at 06:53:47PM -1000, Brian Smith wrote: > Olaf Buddenhagen <olafbuddenha...@gmx.net> wrote:
> > Sorry for being late to this discussion, but I feel the need to remind > > everyone of the infamous OpenSSL licensing problem, i.e. the fact that > > the SSLeay license it is (partially) covered by is considered > > GPL-incompatible by many -- including (among others) the Debian project. > > This affects not only OpenSSL itself, but also all forks, including > > *ring* AIUI. [...] > Insofar as Debian is concerned, they figured out a way to ship OpenSSL. Shipping OpenSSL itself is not the problem. Shipping any program using GPL code linked against OpenSSL is. Debian doesn't do that: all GPL programs are built against GnuTLS instead. (Either natively, or using the wrapper provided with GnuTLS.) While I singled out Debian, because I'm best familiar with the situation there, this issue is really not limited to Debian at all. Folks from Fedora for example, when they contemplated consolidating on a single SSL implementation a few years back, proposed using NSS, precisely because it doesn't have the licensing issue (while providing good OpenSSL compatibility). Note that the only reason why the issue is even disputed at all is that the GPL has an excemption for libraries shipped with the operating system, which is often deemed true for OpenSSL itself -- but it's certainly not true for any Rust library using OpenSSL code... > AFAIU, there is very little SSLeay-licensed code in *ring*. None of it > seems irreplaceable and actually it seems desirable to replace most or all > of it with Rust code under the ISC license anyway. That would be great :-) But unless and until that actually happens, it has to be considered hand waving... Unfortunately, my mention of the SSLeay license has been misleading: actually the original SSLeay license and the OpenSSL license used for newer code *both* come with the problematic advertising clause, i.e. *all* OpenSSL code is GPL-incompatible. Also note that "replacing with Rust code" might or might not be good enough, depending on what it means exactly. Just translating the old code to a different language bit-by-bit does *not* obsolete the original copyright -- only rewriting it from scratch without regard to the original code does... Though the exact dividing line is a bit of a grey area I think. > > In view of this, I believe anything directly or indirectly based on > > OpenSSL and its derivates cannot be considered a viable option. > > Rather than disqualifying things based on non-technical criteria, let's > focus on technical criteria and then see what we can do to fix the > non-technical stuff. The nature of software is that it is malleable; > generally a problem today isn't a problem tomorrow if we're willing to do > work to solve it. I can't agree with this view. Technical problems can be solved -- legal issues are way more fundamental. -antrik- _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
