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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.