Bug 214813 – [WPE][GTK] Add WebKitWebExtension API to indicate web extension does not link to GPL code, and use it to gate WebRTC access (?)

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebRTC

[Michael Catanzaro]

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.

[Jan-Michael Brummer]

Why not extend webkit_settings_new_with_settings ?

[Michael Catanzaro]

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.

[Jan-Michael Brummer]

Ok, thanks for the info.

[Michael Catanzaro]

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.