1. Whole sections of the license are missing, such as section 5 - it's just not possible to agree to something in this state.

2. It's governed by the laws of Texas, so internationally that's not going to work - I'd have to hire a lawyer just to figure out what this means

3. Most importantly, I've no idea why I'd want to use this over embedding Chrome or Servo.

4. There's no ARM support. So no use on RPi, and potentially no use on Mac OS on Apple Silicon, depending on the secret sauce used.

That's before I even start to dig deeper - is it thread safe? Can it fall back to software renderer if needed? Will it be contentious for the GPU with other code that wants to use it?

Only the C & C++ bindings are official, the others are 'community maintained'. Whatever that means.

What I don't get, is why couldn't a dev team just embed WebKit directly - what does this really give? Can it put a browser in game in 3D, or is it a 2D overlay? Will it work with VR / AR?

The website makes a big deal over memory usage, which might be important in some cases, but what about CPU cycles? GPU cycles? Latency? Impact on framerate? Compatibility with Unreal, Unity, Godot, other engines?

I think it's a good project, but there's a lot of considerations before I'd even download for experiments.

Also the license does not forbid commercial use, the free license allows use in commercial software by companies up to $100K in gross revenue. For use in commercial projects beyond that, we have pricing available on our website [3].

* [1] https://github.com/ultralight-ux/WebCore

* [2] https://github.com/ultralight-ux/AppCore

* [3] https://ultralig.ht

2. ?

3. Chrome (or more specifically CEF -- Chromium Embedded Framework, the one used by Spotify et al.) is significantly more heavy than UL. Memory use is massive. Google doesn't care about API stability and ABI breakage is so common you'll have to keep up with all API changes (the ones published and documented anyway...) to get anything done. Good luck embedding Servo!

4. ARM support is coming.

---

> the others are 'community maintained'. Whatever that means.

I maintain the Rust binding to Ultralight [0] via the CAPI to provide an ergonomic way for people to work with it. Adam is busy improving Ultralight itself, so I find it worthwhile to maintain it. That's what it means.

[0] https://github.com/psychonautwiki/rust-ul

You know, it doesn't really seem that hard to embed Servo in a Rust application [0]. It's a pretty interesting read.

Anyone know how stable Servo is for this kind of thing? It's not uninteresting as a cross-platform GUI solution or as more lightweight alternative to CEF (assuming it is more lightweight, I haven't done the science on it or anything). Given that you have total control over everything it renders, it's not massively important if it's not 100% HTML compliant or whatever.

Interesting space to watch for the future. Hopefully the Mozilla layoffs don't doom Servo.

[0]: https://github.com/paulrouget/servo-embedding-example

However, Servo just isn't ready yet. There are just so many rendering issues that it's worth waiting for it to become more mature. (If you don't believe me, open https://psychonautwiki.org with Servo..)

Also I think Adam is a great person and I think it's worthwhile to support his project.

It really is not that simple. Rendering a modern webpage or webapp requires a lot of components. You can't just take webkit and call it a day. For example in the chromium engine Blink which is the Webkit fork doesn't event render pages. It consumes HTML and CSS and produces "display lists" i.e lists of drawing commands. Those are fed to a rasterizer engine that must maintain a whole stack of trandormable layers which are managed in various render trees. Finally pages are radterized in tiles and then composited together for the final image that is show in the viewport. All of this covers millions of lines of code on top of Blink! And we're not even talking about things such as executing JS or syncing JS input handlers with the rendering or doing the actual page loads over HTTP/S or handling windowing and platform APIs and user input etc. All of which are really more or less essential in order to make anything that is actually useful.

  Glib::RefPtr<Gtk::Application> app = Gtk::Application::create("");

  Gtk::Window window;
  window.set_default_size(1366, 768);

  WebKitWebContext* context = webkit_web_context_new_ephemeral();
  WebKitCookieManager* cookies = webkit_web_context_get_cookie_manager(context);

  WebKitWebView* widget = WEBKIT_WEB_VIEW(webkit_web_view_new_with_context(context));
  Gtk::Widget* wrapper = Glib::wrap(GTK_WIDGET(widget));
  WebKitSettings* settings = webkit_web_view_get_settings(widget);

  Gtk::Box layout(Gtk::ORIENTATION_VERTICAL);
  window.add(layout);

  webkit_web_view_load_uri(widget, parse_address(argv[1]).c_str());

  window.show_all();
  app->run(window);
  exit(0);

1. That Section (5) is left intentionally reserved (empty) since the commercial version of the contract provides commercial license grants. This is typical when offering multiple versions of a contract.

2. Contracts are typically governed by laws of a certain government (this is called venue). You can indeed enter into an agreement with another party using a venue in another country. (FWIW I agree the Free License is a bit too unwieldly-- I'm going to switch to an slimmer alternative that's more grokkable)

3. You would use UL for lower-level control over the embedding itself-- the library allows you to override file system loaders, font loading, drawing/rasterization, clipboard integration, and drawing itself (via GPU display lists). You can think of it like a smaller, lighter, cross-platform WebKit that's way more "hackable" and is designed to display HTML in an existing app rather than function as a standalone browser (right now, we're primarily used in games).

4. ARM64 support is on the way, there'll be an Apple Silicon port later this year.

For your other questions:

- [Is it thread safe?] This is in our docs, the API is not currently thread safe but you can run the whole thing on another thread. (an upcoming multi-process RPC layer is being built around the core API, and that will be thread-safe/async)

- [Can it fall back to software?] Latest build of UL can fully render on CPU, so yes.

- [Will it be contentious for GPU?] The overhead is minimal. Views are painted on an as-needed basis to GPU display lists, you can see the full GPUDriver interface here [1].

- [Only the C & C++ bindings are official] Several users of our community maintain open-source bindings for other languages, we will move into supporting them directly as the project grows.

- [Why couldn't a dev team just embed WebKit?] As one who has worked on exactly that for 11 years, it's really not that simple. The API of WebKit itself is not designed for embedding inside an existing application, and also much of the design decisions of the engine itself is designed to build a browser, not render HTML. Furthermore, most WebKit ports are tied to a specific windowing-system which is a big deal breaker if you're embedding HTML inside exotic, cross-platform environments likes games and headless server apps.

- [What about CPU cycles? GPU cycles? Latency?] Sure I can put up more benchmarks to that effect, the website is undergoing a refresh for the 1.2-stable release so it's out of date.

- [What about Unreal, Unity, Godot?] Several users have already used the API to integrate into Unreal and Unity, we will make an official plugin for all three later.

Hope this helps clear things up! I'm usually available in Discord [2] if you have more questions.

* [1] <https://github.com/ultralight-ux/Ultralight-API/blob/master/...

* [2] <https://chat.ultralig.ht>

Edit: I think it’s at https://github.com/ultralight-ux/WebCore.

From a business standpoint, we were offering paid commercial support for not just Awesomium but all the Chromium-related parts and that surface area had grown to be way too large to be maintainable. For the product to succeed we had to refocus efforts on building a solution we could fully own and met the requirements of our core market-- and that took about 6 years of R&D.

That top-level repo is just our packager/samples, 90% of our code is open-source and available on GitHub (released under LGPL), see our WebCore [1] and AppCore [2] modules.

The product as a whole contains two proprietary modules which are indeed non-free but allow free use in non-commercial and commercial projects up to $100K in gross revenue.

* [1] https://github.com/ultralight-ux/WebCore

* [2] https://github.com/ultralight-ux/AppCore

Anyway the sole core benefit proposition compared to chrome seems to be less memory use.

People will click on a GitHub link.

This is manufactured hn clickbait. I've never flagged before but this one deserves it

I wish them well and the technology may be great, but trying to play hn like that is not welcome.

* [1] https://github.com/ultralight-ux/WebCore

* [2] https://github.com/ultralight-ux/AppCore

* [3] https://ultralig.ht

Yes, the GPU renderer (and CPU renderer) took about 4 years of R&D alone to get to a usable state (we started on GPU rasterization long before WebRender was even around).

FWIW, a large number of our customers need commercial support and have complex integration concerns that go significantly beyond what those offerings provide (just in the past week, we've been doing custom development for several game studios to get our renderer working in their engine on their platforms).

Also we fully intend to stay current with WebKit trunk (we use a fork of their WebCore/JavaScriptCore modules) since a number of our users need to support modern HTML/JS/CSS (latest build supports ES6 modules, WebAssembly, and more).

I don't understand that. The readme says "Ultralight is a lightweight, cross-platform, HTML rendering engine for desktop apps and games." How does this fit with your argument?

> which it cannot do with open source code (not allowed by the developer agreements.)

Why not?

These agreements very rarely (read: never) allow publishing of the SDK sources in any fashion. Even simply exposing code that calls into SDK functions would be in violation.

You don't get access to the SDK unless you sign the contract, and if you sign the contract and breach it, they have legal cause against you. Usually if you want to use third-rdparty software for these closed platforms, the third-party and you must both have developer agreements with the platform owner. This of course excludes software that you as a developer ported to the platform on your own.

Edit: I found it, it’s in another repository at https://github.com/ultralight-ux/WebCore.

That seems rather important.

Free for non-commercial use.

Free* for use by companies with less than $100K annual gross revenue.

Edit: I mean, sure, you could use it in your proprietary Electron app to make it more lightweight. At least on Windows, macOS and some Linuxes, the rest of users is left out then, but those free software enthusiasts are unlikely to use your software anyway.

> https://forum.ultralig.ht/t/community-language-bindings/20

``` Several awesome members of our community have created bindings for other languages!

Check them out below:

    C# – https://github.com/ImpromptuNinjas/UltralightSharp 104
    Rust (High Level) – https://github.com/psychonautwiki/rust-ul 21
    Rust (Low Level) – https://github.com/psychonautwiki/rust-ul-sys 7
    Java – https://github.com/Janrupf/ultralight-java 10
    Go (High Level, Framework) – https://github.com/ImVexed/muon 22
    Go (Low Level)-- https://github.com/raff/ultralight-go 19

That said, I suspect that many of the more modern JS APIs which are organised as separate modules are much easier to exclude when building something like Electron. I'm talking about these kinds of APIs: https://developer.mozilla.org/en-US/docs/Web/API

Many APIs there to exposed things from deep inside the rendering engine, but there are still plenty left which are likely separate, like Bluetooth, Gamepad, Ambient Light, Beacon, IndexedDB, Image Capture, Geolocation, Payment request, Web Audio, etc.

Builds of Electron with exotic APIs removed could be good although I'm sceptical of whether that would bring the run-time memory use down much, i.e. what (API) you don't use, didn't hurt you anyway.

The hardest part for maintainers would be saying no when everyone inevitably asks to expand the feature-set.

[1] https://wails.app [2] https://pywebview.flowrl.com/

Anything else is just the laziness of not caring about Web standards and shipping an whole browser instead.

Every day ChromeOS is one step closer to overtaking all desktops.

It's nearly impossible to write a new browser engine that is compatible with all the legacy mess on the wild web, but for packaged webapps a modern minimal engine is exactly what they need.

Something that I have always asked myself is: If the code is open source, how would it ever be possible to enforce such a licensing model?

However, you can have parts of a codebase be FOSS licensed, if the license is compatible with non-FOSS code. BSD, MIT and Apache licenses allow this, copyleft licenses like the GPL don't.

https://opensource.org/osd.html

As a result, the license would be incompatible with copyleft licenses.

Of course, you could kindly ask your "customers" to please pay for a license in case they're using the software for some purpose. Good Luck with that.

[1] https://www.outrunlabs.com/revery/

[2] https://v2.onivim.io/

https://github.com/mikke89/RmlUi/

or for apps:

https://sciter.com/

Here it runs in Unreal Engine: https://sciter.com/see-sciter-lite-unreal-engine-in-theaters... - HTML/CSS primitives are rendered directly into DirectX surface controlled by Unreal.

> Ultralight is a new port of WebKit combined with a new [proprietary] lightweight renderer intended specifically for embedding in apps and games.

And the Licensing section:

> Ultralight is free for non-commercial use and free for commercial use by companies with less than $100K gross annual revenue. For more info see LICENSE.txt

Pricing [2] is available from the main web site.

[1] https://github.com/ultralight-ux/Ultralight#architecture

[2] https://ultralig.ht/#pricing

Also, while it's good that you bring up accessibility on threads like this one, I don't think it's a good idea to go straight for the threat of legal action. The natural response to that tactic is to question whether there will really be legal reprocussions, and that's a distraction from the real issue. Instead, I tend to focus on the moral problem of blocking people from doing their job, getting their education, etc.

I never heard about any "usual disclaimers", what exactly are you referring to?

AFAIK nobody is going to be suing developers for their software and the worst that can happen is people with accessibility needs simply not using your programs. The main issue is with employees with accessibility needs being unable to perform their work due to your software and having no other alternative - this is a case where their employer (not you, unless you are said employer) can be sued.

But beyond that i never heard anything about requiring legal advice before using any sort of UI framework for general professional use (TBH that sounds absurd).

In practice the worst that can happen to you is people with accessibility needs not using your software.

It doesn't make sense to charge $2000/yr for an app that makes $1 of revenue.

> $0K - $500K : $2000

But under Free License it says:

> Free for non-commercial use.

> Free* for use by companies with less than $100K annual gross revenue

Got confused.

You don't have to purchase a license, but you can if you want.

We didn't abandon anything, we announced to the community that we were stopping development of Awesomium (our previous Chromium fork), are going to build something new (which turned out to be UL, I wrote the rationale elsewhere in this thread), and continued to support our paid customers for years after (all licenses came with a 1 year annual support contract with option to renew, we would be in contract violation if we didn't).

We did stop maintaining the free online support community which I think is where this sentiment came form. Users were upset that there were no new versions of Awesomium and there was a 4 year gap before the first alpha of Ultralight was released which left a number of users rightfully annoyed.

I personally couldn't promise that were _would_ be a successor project since Ultralight was so experimental (the GPU renderer alone took about 4 years to get working on all platforms). That lack of communication and subsequent gap in updates is what led users to believe the project was abandonware (luckily, I'm here to say it isn't and we're still alive!).

FWIW, Ultralight was actually built in tandem using internal feedback from our existing customers. Many of our current users are ex-Awesomium users.

Our advantages are much more than memory usage-- it's also distributable size, low-level integration, single-process mode (no external renderer processes), GPU rasterization (and integration into custom GPU drivers), and custom modification of the library itself (most of the library is open-source and on GitHub-- it's much more amenable to "hacking" on than Chromium so it's a better fit if you need a custom HTML rendering solution than Electron).

We're still building out our desktop app runtime (AppCore) to match the API of Electron, but the low-level renderer is already finding a solid foothold inside of games (PC, macOS, and consoles) and headless server renderers.

* [1] https://chat.ultralig.ht

This is a lightweight alternative.