Problem statement: libwebrtc uses BoringSSL, which uses the OpenSSL license, which is not GPL-compatible and cannot be linked to GPL code. Several applications use GPL-licensed web extensions -- I can think of three off the top of my head -- so we exclude Source/ThirdParty/libwebrtc in Tools/[gtk,wpe]/manifest.txt.in to ensure libwebrtc is never distributed in releases and cannot be linked with GPL code. Strawman proposal: void webkit_web_extension_allow_gpl_incompatible_features(gboolean); If no web extensions are loaded, or if every loaded web extension calls this function, then we can enable WebRTC. If any WebKitWebExtension fails to call the function, we get no WebRTC. We would then relicense the Epiphany web extension to LGPLv2+ and enjoy WebRTC to heart's content. Downside of this plan: we'd have to change WebKit to dlopen libwebrtc if and only if using GPL-incompatible code is allowed. Not sure how hard that would be.
Why not extend webkit_settings_new_with_settings ?
WebKitSettings is a UI process API, whereas WebKitWebExtension corresponds perfectly to actual web extension shared objects. The UI process might not know which web extensions are going to be in use. In fact, if you write a custom web extension and install it into Epiphany's web extensions dir, WebKit will happily load it. That would be a strange thing to do, definitely not supported, but if you want to write GPL a web extension that, say, changes all text color to red, you can do it.
Ok, thanks for the info.
Closing this. The worry is that dlopening libwebrtc would be a lot of work and it would be simpler to just proceed with plans for gst-webrtc instead.