By John Gruber
Kolide ensures only secure devices can access your cloud apps. Watch the demo to see how it works.
The choice of license makes a big difference: using the Library GPL permits use of the library in proprietary programs; using the ordinary GPL for a library makes it available only for free programs.
In other words, as a developer, you can use an LGPL-licensed code library (such as, say, KHTML) in an application which itself is not LGPL-licensed. If you, the developer, make changes or improvements to the library, you are required to release them under the same license, but you are free to license the rest of your application however you wish.
With GPL-licensed libraries, however, developers can only use them if they use the GPL license for their entire application. Thus the pejorative “viral” is often applied to the GPL.
You can read the rest of Stallman’s “Why you shouldn’t use the Library GPL for your next library” essay to see why he doesn’t like the LGPL, but the summary is that it gives Stallman the willies to see non-free applications benefiting from free libraries.
But Stallman lives in a bizarro-universe where quality application software magically appears from the fingertips of volunteers. In the real world, quality software comes from talented engineers, and talented engineers want to get paid. Apple put together a crackerjack team of developers for the Safari team. Some of the Safari engineers have dedicated months to improving KHTML. Months and months of man hours from some of the best developers in the world. KHTML is benefitting tremendously from this relationship with Apple — but it wouldn’t have gotten one bit of this if it had instead been licensed under the GPL.
What’s really cool about WebCore, however, is what it means for independent Mac developers. WebCore isn’t just an effort to satisfy the legal obligations of using LGPL software. It is repackaged and encapsulated with an API designed to make it easier for other developers to use it in their own applications.
For example, the Omni Group is now considering using WebCore as the rendering engine for OmniWeb 5. Omni Group CEO Ken Case wrote:
This means that we may be able to reach our compatibility and speed goals for OmniWeb much more quickly than when we were working alone, and then return our focus to doing what we do best: providing a rich browsing experience. Thank you, Apple!
WebCore isn’t just potentially useful for web browser developers, however. There are all sorts of applications that could make use of a fast, small, standards-compliant HTML renderer. Brent Simmons has already indicated that he’s looking into using WebCore in NetNewsWire. Email clients are another example of non-browsers that could potentially make great use of WebCore.
And don’t forget web development tools. Macromedia recently announced a deal with Opera that allows Macromedia software to include a built-in version of the Opera engine. Opera, of course, is a commercial software company, and most small Mac developers don’t have the financial resources of a company like Macromedia.
Windows developers have long been able to take advantage of a good system-wide HTML rendering library — the IE HTML renderer on Windows is relatively easy to include in any application. Of course, certain aspects of the IE situation on Windows led to a nasty little legal squabble, but providing a public API to the IE rendering engine wasn’t the problem — squashing the ability of other browsers (namely Netscape) to compete fairly against IE was the problem.
For an example of an application that makes good use of the IE API on Windows, check out some screenshots of NewzCrawler, a syndicated newsreader similar in scope to Ranchero’s NetNewsWire.
The lack of a decent system-wide HTML rendering engine has been a gaping hole for Mac developers. WebCore looks like it might just fill it.