Vikram Goyal's Blog

J2ME Archives

Motorola to develop Java ME stack under Apache

In news that is sure to drive further the fragmentation issues of development using Java ME, Motorola has announced that it is going to develop its version of Java ME under the Apache license. As the report says: "it's not clear whether the Motorola and Sun projects are complementary or competing". I can't understand if Motorola is legally authorized to create a product called Java ME when Sun is the legal owner, even though it is being open sourced? Can anybody clarify this?

The timing is absolutely wrong and the aim seems foggy. Sun has just open sourced Java ME, so why develop a conflicting product, even under the ambit of Apache? The stated aim is to reduce device fragmentation. Ha! By developing a different base API to Sun's Java ME? How will that work? Not only will developers have to content with the established device fragmentation issues, this will introduce another layer of complexity and API fragmentation. Have you tested on Sun's Java ME based devices? Have you tested on Apache Java ME based devices?

The truth seems to be a marketing push to garner respectability within the Java ME development community to push Motorola and create a Motorola-centric development ecosystem.

"Although we are not aware of Sun's open-source plans, we would hope Sun would join in this effort," said Mark VandenBrink, a senior director and chief platform architect in Motorola Mobile Devices business.

Huh? Who, within the community, is not aware of Sun's open-source plans?

Why are Sun's code examples such bad examples of coding?

I was browsing through the Sun supplied Location API examples in the latest Wireless Toolkit when I came upon this:

Ok, so it's just a few lines of code that are, to put it mildly, exceeding the generally accepted 80 character limit. The fact that there is no explanation of what this class actually does in the Javadoc comments is to be expecting too much. Hey, it's the 'Main CityGuide MIDlet'. What more explanation do you want?

So, I decided to investigate further. At random, I picked another code example, the BallCanvas class in AudioDemo. Just a small snippet from this:

The formatting is all over the place, the commenting is, as you can see in the highlighted section, verbose (Destroy for the method called destroy()!).

OK, so these are just two examples, but when you look at the rest of the code examples, two things stick out.

1. Code comments were not a priority of the engineers writing the code samples for Java ME. There is no consistency.

2. Code formatting is all over the place. There is no adherence to any established guidelines or any semblance of quality control.

Why does Sun think it is ok that these code samples be released without mandating that a due QC be applied to them? Is this the same for examples of Java EE and Java SE? I know these are just code samples and Sun is doing us a favor by releasing them, but it shouldn't take me the better part of a day trying to gloss over badly formatted and incompletely commented code for a technology that Sun is trying to sell.

When you are trying to learn a new facet of Java ME technology based on these code samples, it would help if you have spent your years doing code reviews for undergraduates.

Open source Java ME

One of the benefits of Sun's decision to open source Java ME (along with the rest of the Java brand, but I am concentrating on Java ME), especially for an author and writer, is the ability to peek inside the code to understand what's going on. This provides a deeper understanding of the source code, and ultimately, a better communication to the readers than learning from the API.

Of course, in that regard, open sourcing Java ME has no benefit. The source code for Sun's implementation of the complete Java ME API stack has been available for a long time now via the Sun Community Source Licensing. Check it out here. The community source licensing is very similar to what the goals of open sourcing it would be. Of course there are differences, and I am no lawyer, so make your own judgements by looking at the community source licensing page here. It even allows you to modify the source code and contribute the changes back for 'the benefit of the community' without getting paid. Sounds very much like open source to me :).

MMAPI 1.2 released

JCP has quietly released the 1.2 API specification for MMAPI (JSR 135). This is only a maintenance release and contains mainly documentation changes in the API. The change log is here.

Note that the change log notes that the changes are accepted for 1.1 release, when in reality, it should be 1.2 release. I guess that there will be another release to fix that!

Pro Mobile Media API Book released

Update 10th May 2006: Sorry! All free copies are gone. If you need it, please consider buying the book.

In keeping with complete compliance with the java.net weblog policies, may I introduce you in a selfless way to my book on Mobile Media API, recently released by Apress.

Mobile Media API, as you may know, allows you to add multimedia capabilities to your Java enabled device (For an introduction to this API, please read a tutorial at java.net by, ahem, me, here: http://today.java.net/pub/a/today/2005/09/27/j2me4.html). The book covers this API in exhaustive detail and shows you how to add audio and video, generate tones, play with MIDI, capture audio and video streams and so on.

You can buy the book at Amazon here, or get to the book's website at Apress here. The Apress site also has a sample chapter on Media Player Lifecycle and Events. Finally, the book's companion site is here, where I run a case study on audio/video/text blogging from your mobile phone using MMAPI.

I also plan to giveaway two copies of the book to the first two people who promise to write a review on Amazon afterwards. Please email and convince me of your commitment at vikram@mmapibook.com!

Comments, feedback etc. also welcome at vikram@mmapibook.com.

FTPOnline special report on Java ME

FTPOnline has published a series of articles on Java ME development. There are some good articles here, especially if you want to sell Java ME to your boss or in your enterprise. Martin de Jode's article on Efficient MIDP for Symbian-Based Devices is well written and contains good tips, although I couldn't figure out why the same tips won't apply to non-Symbian devices (On that note, most tips would apply to any Java development). Michael Yuan's article on Java ME is an introduction to newbies from a non-technical perspective and is a good but predictable read.
Nokia is strongly featured with two articles on developing across the Nokia platform, first with the enhancements to Forum Nokia, and second, with advancing Java on Series 40, which covers some of the useful series 40 API's.

Help me win a coffee mug!

Update 22nd April 2006: Thank You to everybody for helping me get the second place and win the much coveted mug!

Of course, by winning the coffee mug, I will be a more productive blogger and wake up from my blogging slumber.

This is not entirely a blog entry for personal gain (so you can't boot me off Chris!). I am helping to spread the word of this worthwhile competition. As a previous winner (3rd prize still allows me to call myself a winner. Snif.) I have seen the benefit that this comeptition can bring to no-name software developers and students with half decent ideas.

So.. if you click on the image below, I get points that will help me win a coffee mug. But in the bargain, you get to know of this useful competition for Java ME (OK! J2ME) applications run by Sun and BenQ. A fair trade, I say. Click away!

What does the 'new version of Java for mobile' announcement mean?

A little over a week ago, this news item had me intrigued about the release of a new version of Java for mobile phones by middle of this year. Not finding any independent corroboration, I dismissed it as irrelevant, till Sun itself used this news item as the basis for a press release.

I have read the news items but I don't understand the implications.

Is there a new version of MIDP imminent? As per JCP, MIDP 3.0 (which is the next profile in line for mobile phones after MIDP 2.0) doesn't even have an expert group yet, let alone think of a specification.

Is there a new version of the Sun Java Wireless Toolkit coming out? Again, it doesn't make sense. First, version 2.3 of the toolkit was released not long ago in beta. Second, it is a development environment, not a runtime environment, so phones with this technology can't be due for release in the end of 2006 or early 2007 (unless it means that applications that you can test on this environment will be able to run on phones due out end of this year or early 2007 - a very convoluted way of making a point, which is wrong in any case, as there are several phones that have the capabilities discussed already).

If any reader here works at Sun and is in a position to find out details could post them in comments, it would benefit us a lot? What exactly is coming out by mid-2006?

Frustrated with J2ME implementation differences

I am getting increasingly frustrated with the level of differences in MIDP, CLDC and optional API's implementations. Device manufacturers are increasingly making independent rules for their implementations, so much so, that it is almost impossible to port applications from one device to another.

Take the case of Mobile Media API (MMAPI) that enables MIDI, tones, audio and video in your MIDlets. The specification for this API is ambiguously written, in parts. You are guaranteed to have major headaches providing workarounds for different devices. Part of the blame lies with the device manufacturers as well, who provide arbitrary implementations with their own understanding of the specifications.

A specific case relates to the supports.mixing property. If true, the MMAPI implementation must provide the ability to play two sampled audio files simultaneously. But can you? No. Several implementations decide to interpret it as a combination of a MIDI file AND an audio file, rather than two pure sampled audio files. Others, decide to make available the mixing of two MIDI files, ignoring sampled audio completely. Still others give even worse results, by only allowing mixing of tones. The API is specific in this regard and mandates the support for mixing of two sampled audio files, if this property is true.

So, who suffers due to this? Content developers and consumers.

The solution, in my opinion, is for Sun (or any other regulatory body), to certify the implementations of MIDP, CLDC and ALL optional API's as conforming to the specifications. Developers will then know, which implementations they can confidently work against.

It is not such a difficult task. There is already a Java Verified program for certifying applications. Why can't we request the same level of momentum and commitment from device manufacturers and Sun?

I am even open to a third party being set up to provide this compliance against the specifications. There is an increasing number of optional API's coming out, all of which will lead to even more frustration and incompatibilities. Surely there is a market here for somebody to grab. Only if the device manufacturers would be willing to play ball.

$100 laptop - No Thanks. $100 smartphone - Yes Please!

You may have heard about the $100 laptop initiative by the MIT Media Lab. If not, let me summarize it here for you. The initiative is to provide one such laptop per child in developing countries because "Laptops are both a window and a tool: a window into the world and a tool with which to think. They are a wonderful way for all children to "learn learning" through independent interaction and exploration.". This laptop will have the following features:

-- It will be Linux based and will have a full-color screen
-- A wind up battery to receive power
-- WiFi enabled
-- 500 MHz, with 1GB of RAM and a minimal Hard Disk

Hmm. Without any comment on these features, let me list the specifications of my mobile phone (Motorola A925):

-- Symbian OS based, TFT, 65k colors with touch screen and hand writing recognition
-- Rechargeable battery with upto 160 hours of standby
-- Network and Internet connectivity by 3G, which defaults to normal mobile network if 3G is not available. Bluetooth, Infrared and USB enabled.
-- ARM processor at 168 MHz, 32 MB RAM and 16 MB of internal memory with possibility to extend with a card

This phone is over 2 years old and currently retails for about $300. The phones that have been introduced in the market since this phone have even more impressive feature sets.

So, my point?

Instead of spending money on a crank it yourself laptop with limited capabilities and an arbitrary, ambiguous and sure-to-escalate price point, MIT labs should have looked at the mobile phone market and learned a lesson or two from it. Instead of a laptop, it should be looking at providing a smartphone.

Today's mobile phones are powerful devices. By the time the $100 laptop comes into production, the simplest of mobile phones would surpass it in technical ability by leaps and bounds, as you can see by my comparison with my 2 year old Motorola A925. The difference between a high-end smartphone and a computer these days is negligible. So why burden these kids with old technology which will find no relevance in tomorrows markets?

Further, the penetration rate of mobile phones in most countries, especially developing countries, is much higher than landlines, simply because Governments are incapable of providing this infrastructure, while private enterprise in mobility has flourished, providing networks in areas where people had to trudge miles to see a phone earlier.

So, not only do you provide these kids with a high end processing machine in the form of a smartphone, you provide them connectivity, perhaps the best possible gift for a child in a developing country.

One Laptop Per Child (OPPC) is wrong... Make it One Smartphone Per Child (OSPC).

What bugs you about J2ME?

In a post from couple of days back, I blogged about the massive market that Nokia has announced for J2ME applications. The comments on that post are mostly pessimistic. Most developers are unhappy with the state of J2ME, with anger directed towards Operators, Manufacturers and Sun equally. This is not an isolated case. Previously, when I had blogged about raising interest in J2ME, I had got the same complaints.

So what is wrong with J2ME? What would you like it to do? What are, as developers and companies, our options? More importantly, what are the solutions to make it a dominant player in the handheld applications market?

Maybe, if we verbalize our angst enough, we will get solutions.

I look forward to the comments.

Handy tool for Mobile Device Information

Any J2ME developer knows that the promise of write once and run anywhere, like the J2SE promise, is based on marketing genius and little, if any, factual grounds in reality. If anything, it is, worse for J2ME (or Sun Java ME) because there are so many different manufacturers/operators and implementations that it is practically impossbile to put your application out without actually trying your application out on those said devices.

With this in mind, the Mobile Device Information project being run on java.net is an excellent, comprehensive and searchable source of information for different devices. It is a Java application that is run via Java Web Start, uses the WURFL database and is maintained by Jim McLachlan.

If you have Java installed on your machine, you can run the file here. The homepage for the project is here.

I want a piece of the pie

While everybody, and I mean everybody, is talking about the coming death of Java and the demise of Struts, nobody seems to be realizing that their is a new frontier on the Java horizon.

Java ME (or J2ME whatever you prefer).

Ok, so it isn't new and it isn't perfect. But I am gob smacked by the numbers published by Nokia. More on this later.

I find it debatable that Java on the desktop or the Server is dead or dying. Yes, Java for beginners is tougher now. That is the sign of a mature language, not one that is dying or dead. Yes, I am confused about where it is going, but that doesn't mean that I am ready to ditch it for the current flavor of the month, even if it is Ruby on Drugs.

Java on desktop and server is mature and thriving. There are lesser markets to explore. But there are newer frontiers that represent opportunity.

Take the Nokia announcement. Some snippets:

- More than 180 operators are now deploying Java services.

- 708 million mobile Java devices had shipped as of June.

- 635 models of mobile Java devices are offered.

- 32 mobile device vendors use Java technology.

- More than 45,000 Java applications are on the market.

- Approximately 23 million mobile Java downloads have been performed each month this year.

and to cap it all:

"Nokia forecasts that developer revenue from mobile Java applications on Nokia devices will reach 340 million euros this year."

Wow. If that is not an awe inspiring, swear by Java, renounce all other languages moment, then I don't know what is. Quick, somebody get me on line to Nokia.

Nokia joins Eclipse for J2ME development

Nokia has decided to join the Eclipse project as a board member and a strategic developer, whatever that means.

Sorry, I know what it means. a) it gives Nokia veto power over Eclipse's J2ME environment and b) it allows Nokia to push its own developer tools for J2ME development.

I know that a large percentage of J2ME development is targeted for the Nokia devices. Ok so they do have the best J2ME toolkit and besides, they have the largest customer space. Nevertheless, something bothers me with this apparent monopoly that is going to happen on the Eclipse development environment. How will it work out in the end for developers using Eclipse for J2ME development and targeting multiple manufacturers? What happens to EclipseME? The press release is silent on these issues.

User Interface Optional

It is common knowledge that mobile device applications require a special effort to define an interface for them. Minimal is not only in, but a required aspect of all such applications. But to me, the applications that are most likely to succeed are the ones that don't require any interface at all.

Ok, I lie. All applications will require an interface. An interface to start them and an interface to set basic settings, whatever they may be. But after that, the application should require no user input at all. Can you see where I am going? Applications that require the user to type things for each activity or scroll through horrendously long lists or have multiple pages for completing an interaction are going to fail.

Games are an exception, of course. Games require interactivity. But I am not too fond of business or productivity applications that require multiple user input. Even browsing on the mobile is a tedious activity. I have several 3G phones and the best one is a monolith that works best when I use the associated pointing device. The other phones require complex interactivity with the navigation button and your best teenager enthused SMS capabilities just to input a URL in the inbuilt browser. Would I use them to bid on ebay? Would I use them to register for a service which requires my details? No. I'd rather carry my 3.5 KG laptop with me than kill my fingers.

Mobile TV is a great idea. It has all the ingredients of what I say can be a successful application. Once started, it requires no user input (unless you classify watching the monitor as an input). But how long can I stare at the tiny screen without getting bleary eyed?

So, what is the solution? Here are some ideas...

-- The obvious. Creative applications that require minimum input. If you can't do that then see next point.

-- Design so that the user needs to spend the minimum amount of time interfacing with your application on the mobile. Have a web component that the user can interface with when required. The user can update the web profile/settings etc. and your application updates itself based on these settings.

-- Explore alternate user interfaces. Voice commands and Camera input are more important technologies for mobiles than traditional computers.

Vikram

Current activity in the J2ME world

Last month or so has seen a lot of activity in JCP with regards to J2ME related JSRs.

New JSRs:
-- Service Connection API for J2ME:
"A new high-level API for connection services via frameworks supporting identity based services, discovery, and authentication. The API supports Service Oriented Architectures (SOA) and other similar network service application models."

-- XML API for Java ME:
"This JSR provides a common general purpose XML API for the next generation of mobile devices."

Public Review
-- Mobile Sensor API
"The API provides general Sensor API that extends the usability and choice of sensors for J2ME applications. It defines generic sensor functionality optimized for the resource-constrained devices like mobile devices."

Closed Public Review
-- Advanced Graphics and User Interface Optional Package for the J2ME Platform
"The Advanced Graphics and User Interface (AGUI) Optional Package will migrate the core APIs for advanced graphics and user interface facilities from the J2SE platform to the J2ME platform"

-- Digital Set Top Box Profile - "On Ramp to OCAP"
"The requested specification will define a J2ME profile based on the Connected Limited Device Configuration (CLDC) that is appropriate for use by small-footprint cable television set top boxes"

Proposed Final Draft
-- Personal Profile 1.1
"This JSR will update the existing Personal Profile (JSR-62) specification to reflect the J2SETM 1.4 APIs"

-- Personal Basis Profile 1.1
"This JSR will update the existing Personal Basis Profile (JSR-129) specification to reflect the J2SE 1.4 APIs"

-- Connected Device Configuration (CDC) 1.1
"This JSR defines a revision to the J2ME CDC specification. This JSR provides updates (based on J2SE, v1.4) to the existing core, non-graphical Java APIs for small electronic devices"

-- Foundation Profile 1.1
"This JSR defines a revision to the J2ME Foundation Profile. This JSR provides updates (based on J2SE, v1.4) to the existing core, non-graphical Java APIs for small electronic devices."

-- Information Module Profile - Next Generation (IMP-NG)
"This specification will define a profile that will extend and enhance the "J2ME Information Module Profile" (JSR-195)."

Final Release
-- Payment API
"Enabling application developers to initiate mobile payment transactions in J2ME applications"

-- Content Handler API
"Enabling J2ME applications to handle multi-media and web content can give developers and users a seamless and integrated user environment on mobile phones and wireless devices."

Maintenance Draft Review
-- Mobile 3D Graphics API for J2ME
This maintenance review includes the changes described here.

Phew! With this much activity, one would think that J2ME would be the next best thing. :). I am quite interested in the Payment, Content Handler and XML APIs. Of course, the proof of the pudding will be when the mobile phone manufacturers start bundling these APIs in their mobile phone pies.

Let me know if I have missed something noteworthy.

MIDP + DoJa = Mojo for Sun?

Javaworld reports that Sun and Japan's NTT DoCoMo have combined forces to update DoCoMo's inbuilt Java platform. This platform, called DoJa, was built by NTT in 2001 and is the primary platform for developing applications on mobile phones in Japan.

Why, you may ask. Why not upgrade DoJa to MIDP 2.0 instead, rather than creating a separate breed of the J2ME platform? There is enough fragmentation in the J2ME world as it is, without deliberately creating more.

I think the answer lies in the market sustainability of the DoJa brand. Obviously, DoJa is a stronger market force than MIDP in Japan and NTT would like to keep backing the winning horse.

According to the Javaworld report, Takeshi Natsuno, senior vice president of multimedia services at NTT DoCoMo says: "Both DoJa and MIDP have good points. The next Java should take advantage of both, But rather than combining DoJa and MIDP, we should be thinking from scratch. ... We're not intending to merge [them], but to take a reference from both sides and think about what should be the Java platform for future phones."

I am not familiar with the Japanese market and would like comments from people who are.

Raising interest in J2ME

Consider these facts:

-- There are 708 million J2ME based phones as compared to 700 million PC based Java deployments.

-- The market for commercial mobile applications is set to reach $1.6 billion by 2008.

-- There will be an estimated 1.0 billion mobile phones in the world by end 2006.

I presented these facts in my Introduction to Mobile Java presentation last night to the Australian Computer Society Special Interest Group. The numbers are awe inspiring. The audience was bewildered when I told them that there is not a single company in Brisbane (Australia) that specializes in developing applications for this market.

The latest Javalobby newsletter bemoans the same fact.

"At JavaOne it was crystal clear that mobile vendors are eager to get more Java developers involved, but the mobile space still seems to be struggling for attention."

So why is it struggling for attention?

First, lack of information. Java developers don't realize that J2ME has grown at a rapid pace and that they can do more with it than they thought possible.

Second, lack of a 'killer' J2ME application. Ok, there are some good ideas in the market, but there is no application that catches the attention of the public.

Third, the respect factor. Developers don't want to be seen working for a technology which is considered too simplistic and which is primarily written to develop games. From developing a J2EE app to J2ME MIDlets is considered a step down. Developers don't realize that they can leverage their knowledge of J2EE to develop server centric J2ME apps.

Fourth, fear of competing technologies. What happens if J2ME doesn't actually catch on? What happens if device manufacturers stop bundling J2ME and other technologies become more prevalent?

It will only take one well thought, commercially successful, mainstream application that will help lift the J2ME market. I am sure that the day is not too far.

Watch this space.

Introduction to Mobile Java

I am giving a presentation on Mobile Java this Wednesday (13th July) to the Australian Computer Society's Software Developers Special Interest Group in Brisbane, Australia.

If you in the area and would like to attend please register at the ACS website (under Events). Registration is free for members and $15 for non-members.

Hope to see you there and I will put up the presentation slides up here after the event.

Vikram

I wish I was at JavaOne!

Ok, so the title of this post says it all. I wish I was at JavaOne.

There is an absolute smorgasbord of presentations that I would want to attend. My interests are in, as you may guess, in J2ME and this years JavaOne is chock-a-block full of interesting appetizers, entrées and main meals.

The next best thing to being there? Nothing really. I am on the other side of world (down under actually) and can only imagine how good it would be to actually attend it in person.

Dream on.

Create mobile applications with drag and drop

I am a little ambivalent about using the new mobility pack from Netbeans. The visual mobile designer for creating MIDlets is an interesting concept and looks darn good. But my hesitation stems from my previous forays with drag and drop visual editors for creating desktop applications and I dislike the amount of extra code that these editors put in. You know the ones, where the comments include a warning “Do not modify this code in the code editor”!

The Visual Mobile Designer for MIDlets seems to do just that. Several pieces of linking code that come with the dreaded warning. It is a good option for small, simple MIDlets, but for larger projects you seem to lose the flexibility.

I think I will be sticking with the code editor for now. But hats off to the Netbeans developers for an aesthetically pleasing and innovative idea.

JSR 209 - Bringing Swing to a mobile near you

I recently noticed JSR 209 that promises to migrate Swing UI set to MIDlets, amongst other things. The API is in public review and the last date for the review is 18th July 2005.

Personally, I don’t think I will use it. It seems to me to be a huge package which doesn’t add much in terms of functionality. MIDlet UI’s need to be simple and effective and making them Swing enabled is well, tad unnecessary.

How will Swing scale to MIDlet size proportions? I don't know. Rather than working on migrating Swing to MIDlets, it might have been better to enhance the LCDUI.

Of course, Swing is only part of the package. The rest of the package covers Java 2D Graphics, Image I/O and Input Method framework, and these may be useful in their own right.

Javamasters finalists announced

The finalists in Javamasters 2005 were announced yesterday. There are two categories, Student and Business. A team of experts from Sun and Siemens narrowed the entries to the top 10 in each category.

You now have the chance to pick this years winner in each category. There are some fantastic prizes up for grabs just for voting. Voting ends on July 15th. Vote now!

New JSR's for J2ME

This month's newsletter from JCP contains four JSR's that are directly related to J2ME.

1. JSR 253, Mobile Telephony API - Allows you to control calls and network services. This JSR is in early draft review stage, which finishes on 10th of June.

2. JSR 242, Digital Set Top Box Profile - Profile that will sit on set top boxes. This JSR has passed public review ballot.

3. JSR 238, Mobile Internationalization API - This JSR is in its final release and provides I18N of MIDlets.

4. JSR 226, Scalable 2D Vector Graphics API for J2ME - This JSR is also in its final release and provides an API for rendering 2D vector graphics and images in MIDlets based on W3C Scalable Vector Graphics (SVG) format.

All exciting stuff!

Do you know which version of MMAPI you are using?

J2ME wireless toolkit 2.2 comes with the promise of a reference implementation of MMAPI 1.1. However, the actual version distributed with the toolkit is 1.0 and not 1.1.

So where is the actual reference implementation (RI) of the Mobile Media API (MMAPI) 1.1? As far as I can see, there is no such implementation available publicly.

Those in the know will point out that MMAPI 1.1 is only a maintainence release over 1.0. It includes several documentation changes and only a couple of actual API changes. The change log is available here.

The release notes for the toolkit say that support is provided for MMAPI 1.1. This is not true. The mmapi.jar in the lib folder contains 1.0 implementation. The API docs are also 1.0 docs, even though the release notes say that they are 1.1.

How am I sure that the supplied mmapi.jar is 1.0 and not 1.1? In 1.1, RecordControl's setRecordStream() method should throw a SecurityException. Try it in code and see (or ahem, just decompile).

Anybody know what's happening here?

Continue Reading...

This work is licensed under a Creative Commons License.