> The only thing that I find that may be an issue for some use cases is
> https://polarssl.org/kb/generic/is-polarssl-fips-certified
Not meaning to sound flippant, but if we ever did seek FIPS
certification I suspect that our choice of SSL library would be the
least of our worries.
__
On 05/27/2014 11:44 AM, Joe Julian wrote:
It has a specific exclusion for GPL 3.0.
https://polarssl.org/foss-license-exception
Gluster is licensed under GPLv2 _or_ LGPLv3+.
(PolarSSL also has an exclusion for LGPLv3. I expect this works for us.
Our lawyers will let us know.)
--
Kaleb
The only thing that I find that may be an issue for some use cases is
https://polarssl.org/kb/generic/is-polarssl-fips-certified
On May 27, 2014 6:43:54 AM PDT, Jeff Darcy wrote:
>One of my tasks for 3.6 is to update/improve the SSL code. Long ago, I
>had decided that part of the next major upd
Also, IANAL, but their code is GPL compatible, even if they are being
dicks and requiring copyright assignment for their proprietary dual
licensing. But at least their code is GPL compatible, which OpenSSL's
is not. So I say +1, use this.
On Tue, May 27, 2014 at 11:44 AM, Joe Julian wrote:
> It h
It has a specific exclusion for GPL 3.0.
https://polarssl.org/foss-license-exception
On May 27, 2014 8:01:51 AM PDT, Kaleb KEITHLEY wrote:
>On 05/27/2014 11:00 AM, Kaleb KEITHLEY wrote:
>> In any event, it's license didn't pollute our code. Do we need
>> to have our attorney bless the change.
>
> My only concern is its 'pure' GPLv2+ license — is that compatible with
> with our 'GPLv2 or LGPLv3+' license.
The answer that matters, as always, is that only a real lawyer can say.
My own uninformed guess is that we would be considered a derivative of
them (instead of vice versa) and thus we'd
On 05/27/2014 11:00 AM, Kaleb KEITHLEY wrote:
In any event, it's license didn't pollute our code. Do we need
to have our attorney bless the change.
_its_ license didn't pollute our code.
--
Kaleb
___
Gluster-devel mailing list
Gluster-devel@gluster
On 05/27/2014 09:43 AM, Jeff Darcy wrote:
So, before I expend a ton of effort replacing this code, does anyone
else think it shouldn't be done and that the enhancements should be made
to the current OpenSSL code instead?
The most compelling arguments — to me — are the speed with which things
> I think the main question regards CentOS support, with further questions
> about Debian/Ubuntu support.
I believe CentOS would leverage the EPEL support. PolarSSL is already
packaged for Debian (Wheezy) and Ubuntu (Trusty) so we should be set.
> If we have to ship PolarSSL packages with our re
I think the main question regards CentOS support, with further questions about
Debian/Ubuntu support.
If we have to ship PolarSSL packages with our releases to support major
distros, is that too much of a burden?
-JM
- Original Message -
> One of my tasks for 3.6 is to update/improve
One of my tasks for 3.6 is to update/improve the SSL code. Long ago, I
had decided that part of the next major update to SSL should include
switching from OpenSSL to PolarSSL. Why? Two reasons.
(1) The OpenSSL API is awful, and poorly documented to boot. We have to
go through some rather unple
11 matches
Mail list logo
