Lobo Project Blog

Primarily about the Lobo web browser and the Cobra rendering engine

The JavaFX 1.0 License – Completely unreasonable?

Posted by lobochief on December 22, 2008

We’re kicking off a brand new blog today, as you can see, and to do this I thought I’d discuss the JavaFX 1.0 license. There was some chatter about this back in August, but this was prior to the release of JavaFX 1.0. (See posts by Mark J. Wielaard and Anthony Goubard). The license was supposed to be early stage, and so on.

Of course, one of the key parts of the Lobo Project is its direct rendering of JavaFX. We believe that eventually HTML should be considered just one web language in a sea of web languages, and not the be-all and end-all of the web. JavaFX is the sort of thing that can move us in that direction.

We started working with JavaFX under the assumption that it would be open source, preferably with a license compatible with the GPL 2.0. This makes sense as OpenJDK is GPL 2.0. Certainly, Sun gave the impression explicitly that their intention was to make it open source.

New Default Browser Home Page - Under Construction

New Default Browser Home Page - Under Construction

Now, as widely known, JavaFX 1.0 differs considerably from its preview releases both in its syntax and APIs. Naturally, we’d like to update Lobo’s preview support of JavaFX Script, and we’ve already made some progress in this area. We’re creating a site at fx.lobobrowser.org that will be our new JavaFX-based default home page for the browser. Right now we only have an “under construction” page there and you need Lobo 0.98.4 (not released yet) to see it. It’s a cool “under construction” page, nevertheless, considering that it only uses a simple under-construction icon. The effects you see there (screenshot to your right) are entirely done in not too many lines of JavaFX code. It’s not one big image.

As part of bringing Lobo up to date with JavaFX 1.0, I was reading the license that comes with the SDK. I don’t know if it’s just me but some parts of it seem completely unreasonable and unworkable. Take, for example, the following section.

4. JavaFX Technology Restrictions. You may not create, modify, or change the behavior of classes, interfaces, or subpackages that are in any way identified as “javafx”, “sun” or similar convention as specified by Sun in any naming convention designation.

This means that if you find a problem with the software, you can’t fix it yourself. You can’t create a quick patch that will hold you over until a fix is made official. That’s not even the problem, though. What if you want to create a specialized application that requires JavaFX technology to behave differently?

Personally, I’m not too worried about that one because we’re able to get the JavaFX runtime to work with Lobo without making modifications to JavaFX libraries. Consider the following restriction, however.

5. (a) The copies of Software provided to you under this Agreement are licensed, not sold, to you by Sun. Sun reserves all rights not expressly granted. (b) You may make a single archival copy of Software, but otherwise may not copy, modify, or distribute Software. However if the Sun documentation accompanying Software lists specific portions of Software, such as header files, class libraries, reference source code, and/or redistributable files, that may be handled differently, you may do so only as provided in the Sun documentation. (c) You may not rent, lease, lend or encumber Software. (d) Unless enforcement is prohibited by applicable law, you may not decompile, or reverse engineer Software. (e) The terms and conditions of this Agreement will apply to any Software updates, provided to you at Sun’s discretion, that replace and/or supplement the original Software, unless such update contains a separate license. (f) You may not publish or provide the results of any benchmark or comparison tests run on Software to any third party without the prior written consent of Sun. (g) Software is confidential and copyrighted. (h) Unless otherwise specified, if Software is delivered with embedded or bundled software that enables functionality of Software, you may not use such software on a stand-alone basis or use any portion of such software to interoperate with any program(s) other than Software. (i) Software may contain programs that perform automated collection of system data and/or automated software updating services. System data collected through such programs may be used by Sun, its subcontractors, and its service delivery partners for the purpose of providing you with remote system services and/or improving Sun’s software and systems. (j) Software is not designed, licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility and Sun and its licensors disclaim any express or implied warranty of fitness for such uses. (k) No right, title or interest in or to any trademark, service mark, logo or trade name of Sun or its licensors is granted under this Agreement.

You can’t redistribute any part of the software? Suppose you want to include some JavaFX classes as part of your existing Swing application. You obviously need to redistribute javafxrt.jar and other such JAR files. That, or you have to ask your users to download the JavaFX 1.0 SDK in addition to the JRE, and have them use javafx instead of java to run your application. This seems highly restrictive and inconvenient for everyone.

The license has the following clause, though: “However if the Sun documentation accompanying Software lists specific portions of Software, such as header files, class libraries, reference source code, and/or redistributable files, that may be handled differently, you may do so only as provided in the Sun documentation.” Unfortunately, I don’t see anything about redistribution of JAR files over at JavaFX.com, the site where I’d expect the aforementioned documentation to be located.

I think Sun is a reasonable company, in any case, and these issues will be resolved in time (perhaps with some pressure from the community). In the meantime, we’ll have to make some assumptions about the JAR files that can be distributed. I’d suggest they are the following.

javafxc.jar (compiler is already GPL)
javafx-swing.jar
javafx-rt.jar
javafxgui.jar
websvc.jar
Scenario.jar
jmc.jar

I can see that redistributing DLLs, particularly the on2 video codec DLLs, would be a problem. We’re not planning to redistribute those, and we’ll have to figure something out about video playback.

But in regards to the other JAR files, unless a lawyer from Sun sends us a cease & desist, we’re just going to assume that it is perfectly reasonable and expected that you should be able to redistribute the unmodified JAR files as part of a free/open-source application. Hopefully the licensing issues will get ironed out in time.

About these ads

4 Responses to “The JavaFX 1.0 License – Completely unreasonable?”

  1. […] The JavaFX 1.0 License – Completely unreasonable? We’re kicking off a brand new blog today, as you can see, and to do this I thought I’d discuss the JavaFX […] […]

  2. I too don’t understand why that license says what it says. However our bossman recently posted JavaFX – The Road Ahead and hopefully you’ve already read this. It explains some issues around open sourcing JavaFX – such as no-way-no-how for the media codecs (we don’t have the rights) but the rest of it will be opened.

  3. lobochief said

    Yes, that’s my impression as well. Everything but the media codecs could easily get open sourced.

  4. […] The JavaFX 1.0 License – Completely unreasonable? […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
Follow

Get every new post delivered to your Inbox.

%d bloggers like this: