From: Gary Thomas <gary@mlbassoc.com>
To: openembedded-core@lists.openembedded.org
Subject: Re: wpa-supplicant & EAP-TLS
Date: Wed, 15 Aug 2012 04:47:52 -0600 [thread overview]
Message-ID: <502B7E58.5010002@mlbassoc.com> (raw)
In-Reply-To: <1344976258.7750.33.camel@x121e.pbcl.net>
On 2012-08-14 14:30, Phil Blundell wrote:
> On Tue, 2012-08-14 at 08:47 -0600, Gary Thomas wrote:
>> I don't see anything explicit on this topic. That said, the latest version
>> (1.0) is dual licensed GPL and BSD and the OpenSSL license is BSD compatible
>> from what I can tell.
>
> Yes, wpa-supplicant itself has been OK in this respect for some time.
> (The dual-licensing option has actually been removed for the very latest
> versions of wpa-supplicant and it's now under the BSD license only, but
> this is fine for OpenSSL compatibility purposes.) However, there are
> quite a lot of other SSL-using programs which are only licensed under
> GPL terms and linking these with OpenSSL is problematic for some people.
> In an ideal world the oe-core license machinery would be able to detect
> and warn about that conflict, but I don't think we are quite there yet.
>
> As a general rule, we don't want to build and ship multiple SSL
> implementations when one will suffice. GnuTLS seems to be the most
> compatible (in license terms) which is why it is generally the default.
> However, DISTROs which don't need to worry about the OpenSSL-GPL
> conflict for whatever reason might legitimately want to use OpenSSL
> globally, and DISTROs which aren't too bothered about potentially
> shipping both might legitimately want to use OpenSSL for specific
> packages like wpa-supplicant even if they have GnuTLS elsewhere.
I looked a bit into this and found that OE-core is already rather
schizo on this topic, so I'm not quite sure what needs to be done
here (i.e. should there be a DISTRO_FEATURES switch that chooses only
one?) It would seem that all systems (at least those with wpa-supplicant
included) will already have both SSL libraries installed.
opsnssl is used in these packages:
midori
socat
curl-native
openvpn
bind
telepathy-idle
dhcp
xserver-kdrive
tcf-agent
python
rpm
git
task-core-basic
mailx
libzypp (=> sat-solver, zypper)
wget
gnutls is used by these packages:
cups
wpa-supplicant
neon
curl
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
next prev parent reply other threads:[~2012-08-15 10:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-14 11:44 wpa-supplicant & EAP-TLS Gary Thomas
2012-08-14 11:46 ` Phil Blundell
2012-08-14 11:49 ` Saul Wold
2012-08-14 11:52 ` Gary Thomas
2012-08-14 13:59 ` Henning Heinold
2012-08-14 14:13 ` Koen Kooi
2012-08-14 14:47 ` Gary Thomas
2012-08-14 20:30 ` Phil Blundell
2012-08-15 10:47 ` Gary Thomas [this message]
2012-08-15 10:52 ` Phil Blundell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=502B7E58.5010002@mlbassoc.com \
--to=gary@mlbassoc.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox