There are times to love Google and there are times to hate Google. At the moment, I’m in the latter phase, though it may not be for the reason you’re thinking based on the subject of this post and Annette Hurst’s article, “The Death of ‘Free’ Software or How Google killed GPL.” I’ll be clear, the reason I hate Google at the moment is because that headline popped up on my phone in Google Now, not because someone thinks that the GPL has been undermined and destroyed. Larry Ellison seems to have had a longstanding grudge against Google and Android and has been hell bent on destroying the latter, which is the underlying reason this legal warfare began. As annoying as these lawsuits have been, they’re not over yet and the GPL and open source sure as hell aren’t over just because Google won this particular case for the moment. Let me explain a few things, including why Ms. Hurst’s article is wrong before it spreads virally across the internet. She may be a lawyer, but oddly, she has a relatively weak grasp of what issues the case was about. I’m going to try to explain it, why she was wrong, and why I wish GPL was indeed dead.

Lets start with what the case is fundamentally about rather than focus on why it came about.

Oracle is suing Google over their use of the Java API, which was developed by Sun Microsystems back in the 90s. The goal of Java was to allow developers to write software once and run it anywhere. This was made possible by compiling the written code into bytecode which could then be interpreted by the runtime system installed on the local computer to execute as intended. The runtime system is written for the local computer’s operating system so that the Java application or applet can run at near native speed. Ideally at any rate. (A later adaptation called a Just In Time compiler, or JIT, came about to transcode the bytecode into the operating system’s native code so that it is indeed competitive with applications written in other compiled languages.) There are two executable “targets” for Java depending on the developer’s intended method of execution: applet and application. A Java applet is run from within a web browser, and is probably the most common way to encounter and use Java. Well, before Android came along, but that’s technically a different story that I’ll get to later. A Java application, as I implied earlier in this paragraph, is executed directly on the user’s computer via the runtime system. Fundamentally, Java is Java, regardless of whether it’s in an applet or application, though applets are generally speaking more restricted than applications for security reasons. (There are ways to circumvent many of those restrictions, but there’s no need to get into that.)

The problem with Java in general, which ultimately lead to the sale of Sun Microsystems, was that they were pretty much giving it away for free. Sun was a great friend to open source developers and operating system developers, allowing anyone to use Java to develop applets and applications as they pleased, and even develop alternative versions of the runtime system provided that the bytecode generated by their compilers were compatible with Sun’s runtime and their runtimes were compatible with the bytecode generated by Sun’s compilers. This interoperability mandate was important because Sun couldn’t be expected to develop an official Java runtime for every operating system that was out on the market from both big developers like Microsoft, Apple, IBM, and Red Hat and small ones, such as Be, OpenBSD, and all the independent, small timers. Not to mention, Sun had their own operating system, Solaris. In order for Java to truly run everywhere, Sun needed developers on other operating systems to develop their own runtime system and compiler, and made reference implementations available through the magic of open source. The lawsuits have declared that these reference implementations were under a dual license, the GNU Public License (GPL) and a commercial license. I’ll explain GPL later, and why I hate it, but suffice it to say it’s an open source license that has certain rules that need to be followed, but essentially allows anyone to use it for free. Commercial licenses, of course, are intended for commercial use, are usually sold by the license holder, and usually have additional benefits all around. Again, I’ll come back to these licenses later.

Another problem with Java was that it was plagued with security issues over the years, and it ran up against Macromedia’s Flash (Macromedia was later purchased by software powerhouse Adobe) which handled animation  and media better natively than Java did at the time. As security issues appeared and Flash grew in popularity, Java’s use declined. In fact, by 2012, Firefox began disabling Java support by default, forcing users to enable it either temporarily or permanently by a conscious choice. Firefox was joined by Chrome and other browsers afterwards. While Flash had and has its own security issues, it was and still is wildly popular.

When Google bought Android and began preparing it for use in smartphones years before Oracle bought Sun Microsystems. At some point, the Android team decided to use the Java API as the basis for developing applications for their new operating system. Although Android would be compiling code Java source code to a bytecode, it would be doing so to Dalvik bytecode rather than Java’s. The goal of using the Java API  in Android, was to provide a means to develop for Android with a well known, flexible and relatively simple to use language. They could easily have chosen C or any of its more direct relatives like Objective C or C++, assembly/assembler, or even invented an entirely new language. Given that Java was well established and Sun was losing money rapidly, Sun was more than happy to allow Google to use the Java API as the basis for developing apps on their new mobile operating system. Why? Because anyone that wanted to develop an Android app needed to learn Java if they didn’t already know it, and that would boost the use and spread of Java, which could potentially bring in indirect revenue to Sun.

You may be wondering exactly how that would be accomplished given that Java was free. (“Free as in beer” in this case.) Like Google, Sun made money on advertising deals, in this case in the installer of their official runtime, SDK, and JDK they offered to install third party toolbars and other applications alongside their  own software. The more developers installing the Sun runtime and JDK, as was necessary to develop for Android, the more opportunities Sun had to make money.

Then, suddenly, Oracle bought Sun, and started an aggressive campaign to bring down Google and Android through whatever means necessary. The cases went back and forth, but ultimately led us to this ruling this week. Oracle, through Ms. Hurst’s company, was claiming that Google had to use the commercial license for the Java API, not the GPL version, so they were in violation of the license and the law. The problem is, that any individual or corporation can use GPL licensed code freely, and here’s the kicker, provided that they make any changes they implement freely available on demand. So, if Oracle/Sun had created a wooden cube, and Google used the cube under GPL to create a white cube with wiggly lines, Google would have to share with the world how they created the white cube with wiggly lines. This is the — and this is key — viral nature of GPL. In principle and practice, anything that is based on GPL code is automatically GPL itself, and only the true owners/origin of the code has the right to issue the original code under a different license. Since the API was open source, GPL’ed as Oracle claims, the Android API had to be open source, and in particular GPL’ed as well.

And here’s where things get tricky. While I can’t say for sure that the Android API is indeed under the GPL license — a quick look at a source file shows the Apache 2.0 license in a file in the SDK —the Android API is indeed open source and more importantly, that doesn’t really matter. The API is being used as a means to create bytecode that is separate and different from the Java bytecode, despite the fact that the language being used is close to if not completely identical. Android has been open source since before the first SDK became available in 2008, and the code it produces is only intended to be operable within Android devices via the Dalvik bytecode and runtime. Google has added a fair amount of code directly within the Android API, but anything that is critical to Google specific business is downloadable separately from the Android API. So, in the bottom line, Google is using Java’s organization of classes, functions, and interfaces and description of such things in a purely textual sense to describe how things get compiled into their bytecode and used as apps on Android. That doesn’t violate the GPL, and the commercial license that Sun says Google had to use is irrelevant because the GPL itself indicates that it’s not necessary.

More pointedly to Ms. Hurst’s outrageous claim that this Google victory destroys the GPL, that is a flat out falsehood. Open source is not going to die as a result of this case. GPL is indeed legally stable, though it permitted Oracle to lose this case because their lawyers don’t seem to have a good grasp of the implications and use of open source licenses. And GPL software will continue to be developed; after all, many people use one of the biggest pieces of GPL software directly or indirectly at some point everyday: the Linux operating system which is at the heart of a great number of servers on the internet, providing web content, e-mail, sound and video, and even just plain text. If you’re an Android user, you use Linux everyday because Android was built on top of Linux. So in yet another way, Google is in compliance with the GPL. So what is Oracle complaining about? Simple, they’ve run out of ways to stab at Google in their efforts to bring down this giant.

Now, why do I hate GPL? It’s that viral nature. As a programmer, I have a very real grip on how much effort goes into doing even small tasks within computers, and I have a huge appreciation for being able to build on the work of others. In many cases, there’s no need to worry about the shoulders on which I’m standing to accomplish my goals. Many of the C/C++ libraries and SDKs are either considered standards, meaning they’re present in just about every compiler and/or SDK, at no charge, or their one of the even more lenient open source licenses such as the MIT or BSD license. Hell, some things are just plain public domain, meaning there’s no license at all and anyone is free to do anything they want with the code. But so often, a very useful or critical library you need is GPL. That isn’t so bad if what you’re doing is also going to be licensed under the GPL, but if you want to sell your product and not share your secrets, you have to back off of that GPL and find another library, if there is one, that will suit your needs. Maybe you’ll get lucky and find a commercial license for the same library and can afford it. Maybe another implementation is LGPL (Lesser GNU Public License) which allows you to link to the library without automatically making your code GPL. Whatever the case may be, that GPL can haunt you. God forbid that you use GPL code or library in your work unwittingly; anyone that makes the discovery can immediately demand that you reveal all of your hard work even if the one bit of GPL code is something completely innocuous and arbitrary. That hardly seems fair to me, and it’s the bane of the small, independent developer that can’t afford to buy a commercial license for every library they need to use.

So yes, I want GPL to die in a fire, but I at least have a reason for it to do so. Google didn’t break GPL, despite what Oracle claims, and clearly Oracle’s lawyers need to come to a better understanding of open source licenses before they appeal this case.

Thanks to newly found free time, the latest Android SDK updates, and the desire to finally finish this app, a little info-utility that I started working on about a year ago is now nearly complete. It’s almost certainly not going to make me any money, but I wanted to do it nonetheless since it’s useful to me. When I have more of it done, possibly on the day I decide to release it, I’ll actually let you know what it is… 😉

THEN I’ll be spending a lot more time on Themis…

I’ve spent most of the last weekend working on Sylence, and I’ve made a significant amount of progress. After doing some reading, I see no reason to use the Android 3.0/4.0 fragments tech in Sylence, and while I’m debating the idea of developing an application widget, I have definitely made some positive changes.

First and foremost, the biggest change so far is that in the dialog to create a new silence alarm, the date and time pickers aren’t initially visible. You will see the current date and time, and a date and time 45 minutes later. Tap the date, and you will be presented with the date picker. Similarly, when you tap the time, you will be presented with the time picker. I think this looks and works better than the old system, though it may be a little less obvious.

Also, the horizontal scrolling is gone in that dialog; the day of the week options for recurring alarms are now stacked vertically when recurring is selected, so when editing an alarm, you can immediately see which days are selected and which are not.

The next major change, although completely invisible, is the way that Sylence does the important work of checking to see if the phone should be silenced or not. Until now, a service has been running full time, sleeping for roughly one minute then waking up and doing a check before going back to sleep. As of the new version, the app will use Android’s AlarmManager to do this, which may save more power than the old way. (Note that the old way didn’t use very much power, but this way should use even less.) The caveat, however, is that in order to do its work properly and timely, the AlarmManager needs to obtain a partial wake lock to wake up the processor long enough to do its work; otherwise, the alarms won’t be triggered until the device is woken up by another program or by user actions. In order to obtain a partial wake lock, I had to add another new permission, WAKE_LOCK, to the list of permissions used by Sylence. Without it, I’d either have to go back to the old method or Sylence would only operate on its schedule while the phone was in use.

Another down side is that I’m adding more advertising to Sylence. I’m considering adding a “Pro” version back into the Android Market without the advertising, but I haven’t decided at this time.

I still haven’t gotten much in the way of feedback on Sylence at all, so I’m just doing things as I see fit, No ratings in the Market, no comments, no bug reports, no feedback. If you don’t like how Sylence is progressing, let me know. It’s the only way I can improve it, and right now is the best time to do that. There are still some changes I want to make before I release this new version, but if you want something in it, now’s the time to let me know!

Update 12/29/2011 2:59 am: Sylence 1.5 has been uploaded to the Android Market with new screenshots.

I just released a slightly newer version of Beta 5 that fixes 2 bugs: the most important issue resolved is that posting prices over 3G/Edge wasn’t working for some strange reason, though I didn’t change that code between releases at all. So I switched to a different method of communicating with the server and it seems to be working well again now. The other issue resolved is one that I had hoped would be in the initial Beta 5 release: you may now double tap on a location in the map to enter a gas price at that location. I’m still not 100% sure why this wasn’t working on Android 2.x but was on 1.6, though it may have to do with code obfuscation that is now being done. Whatever the cause, it’s fixed now.

Over the last week, despite my other obligations, I’ve been a bit busy with my published Android applications. Among other things, I fixed a few annoying bugs in Sylence culminating in a series of releases last week, and today I published the long awaited update to Gas Up.
I am disappointed in this release, beta 5, of Gas Up however.  A feature I spent a fair amount of time figuring out seems to be working on only one of my three Android devices. That feature is the ability to double tap on the map and enter a gas price/station at that location. It works properly on my G1 running Android 1.6, but is missing from my Huawei Ascend (Android 2.1) and Nexus One (Android 2.3.3). I’m not going to dig around and fix this issue at this point; instead I’m going to do a complete rewrite of Gas Up because I have learned a significant amount about Android since I started development on Gas Up nearly a year ago. I’m sure it will be quite some time before I complete the next iteration, but I’m even more sure it will be better than ever.

As of now, Sylence is available in the Android Market in the United States, Canada, and the United Kingdom for $1.00 U.S.. There are still somethings that need to be worked on, but I wanted to get a functional version out and about tonight. Go buy it and enjoy!

As of Tuesday afternoon, Sylence is feature complete though I sill have a bug or two to squash, and other details to implement. The gist of the application is that it allows you to set “silence alarms” so that your phone’s ringer will automatically be turned off at scheduled or recurring times.

I’ve decided to sell the app for $1.00 (US) in the Android Market, but I don’t yet have a target date for that. The word is “soon” though. I’m considering doing an ad supported version but I guess it depends on the demand.

As of today, this semester is over for me and I am already working hard again. While I haven’t touched Gas Up today, I have started on another project I’ve been meaning to do for a while now. This new project is called Sylence and is fairly simple and straight-forward: it is a scheduler for silencing your phone. For more than a year, I had been using FoxyRing to silence my phone as needed, taking advantage of the widget that would let me silence my phone for up to 5 hours at a time, but I found that I would occasionally forget to use it before I entered a class. So, I did the logical thing, and wrote the author(s) to ask them to add a scheduling feature. Let’s just say I got a negative response, and I’m still not sure why.

So, for months I mulled over the idea of writing my own, but didn’t do anything about it. Tonight, after watching the FoxyRing service crash yet again for no apparent reason, I uninstalled the app, and vowed to do something about it. Since I just finished my finals today, I got started on the app. At this point, I don’t know if I’ll make it free or attach a low price (I’m figuring around $1.00), but I’ll be putting it in the Android Market as soon as I deem it done, or at least done enough to use. Eventually I think I’ll add a widget similar to what FoxyRing offered, but right now I’m not sure how far I’ll push this new little app.

On the Gas Up front, I will be doing some heavy coding on it in the next week, and I’m going to try to get Beta 5 out and about by the end of next week.

I just want to give a quick status update on Gas Up Beta 5, so here we go:

As of about 5 minutes ago, double tapping on a location on the map will switch to the “Submit Price” tab, and attempt to look up the address of the tapped location. This is not fool proof, and it’s not guaranteed to get an address ever, let alone on the first try, simply because of network congestion, server latency, or even if Google simply doesn’t have an address for the tapped location. But, when it does work, it gives you the ability to submit gas prices at locations other than where you currently are. For best results, zoom in as closely as possible before double tapping.

The code to prevent double accidental duplicate price submissions caused by network lag is mostly done in the application. I still have a few loose ends to tie up in the app, and to handle on the server side of things, but so far so good.

I’m now considering downloading all current gas prices for the selected fuel type at once rather than doing it based on the viewable area in the map at designated intervals. Although I’m not too concerned about network traffic on the server side of things, the repeated querying, several times a minute, from all running clients can slow down overall performance for everyone, not to mention it could affect your bill if you don’t have an unlimited data package. What I will probably do is switch it to download all the price submissions once every 15 minutes for the selected fuel type, and if the app hasn’t checked in the last 15 minutes on start-up or when the fuel type is changed, to download updates immediately.

Also under consideration, though not deeply yet, is the possibility of adding some kind of excitement to the app. I don’t know how many of you have even heard of it, but there’s a social mapping/gps app called Waze. It makes using the app at least somewhat fun by giving subscribed users points for exploring previously unexplored or not recently explored streets, and it maintains a leaderboard on a state by state and national basis. Perhaps something similar can be added to Gas Up with a little effort, but that would mean that I’d have to add account information, which in turn means that when a gas price is submitted, I’ll be associating that account with a location. Not to mention storing that location and user information. I’m a bit reluctant to do that, but I would appreciate getting some feedback from my user community on the issue. (Assuming there is a user community for Gas Up… 😉 )

November 30, 2010 8:27 pm

Just wanted to make an addendum. As of a few minutes ago, double tapping ton the location of a gas station already in the database will automatically load that gas station’s name, address, and coordinates (latitude/longitude) in addition to switching to the Submit tab. I’ll be applying the same thing for when you switch to the Submit tab normally as well. If the gas station isn’t in the database, you’ll still need to enter the information as before.

Also, I’m in the process of changing how the data is transferred to your device. When building or rebuilding the database, it [Beta 5] will now download all gas stations currently in the database, though I’ll probably change that to be all within the country that you’re currently located in. Yes, I’m considering opening this up to more countries now, but initially I’ll probably only expand the beta to Canada.

As a further note, I just updated the server side code to handle some of the new changes, and everything still seems to be working. Please let me know if something isn’t…

Although no one has asked,  some of you may be wondering where beta 5 of Gas Up is. Well the simple answer is that I’m not done with the changes yet, but the more accurate answer is that I’ve been too busy to work on it since I announced that I was working on it.

As you may or may not know, I’m currently enrolled in college and trying to change my career path. While I was enrolled last year as well, I didn’t begin development on Gas Up until the middle of this year’s summer semester, which I took off. Add to that the fact that my former employer asked me to do some work right after that “back to work” post, then maybe you have a good idea of how busy I’ve been over the last few months.

I’ve also begun to question the lifespan of the app as well. Despite the fact that the developer’s site states that there are over 400 installations at the moment, price submissions have dropped off to almost nothing. Without price submissions, Gas Up is useless.  I can only blame myself for it, because of the length of time between updates but I’m wondering if there’s still any interest.

Well, I will commit to completing beta 5, but I’ll reevaluate the situation several months after that release.  Give me your feedback either way!