Spotify on Debian GNU/Linux in Canada

Today I decided to try out the free ad-sponsored Spotify music streaming service. It has been available in Canada since September 2014.

After signing up you can immediately use the flash-based web player at play.spotify.com.

Installing the client app

Alternatively you can download and install the Spotify client app. I cannot say yet what the advantages or disadvantages are, maybe reading this article can be helpful.

Anyway, if you want to try the client app, for Debian (or Ubuntu) users it works like this:

  1. Add the repo key (to verify downloaded packages)
  2. Add the spotify repo to apt sources
  3. Update apt caches
  4. Install the spotify client

Here are the shell commands (requires sudo):

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys BBEBDCB318AD50EC6865090613B00F1FD2C19886
echo deb http://repository.spotify.com stable non-free | sudo tee /etc/apt/sources.list.d/spotify.list
sudo apt-get update
sudo apt-get install spotify-client

After successful installation you will find a “Spotify” entry in the “Multimedia” section of your start menu.

Using your Facebook login

If you use your Facebook account to sign into Spotify you will probably see this question:

Spotify would like to post to Facebook for you.
Who do you want to share these posts with?

It is safe to choose “Not Now” which prevents Spotify from posting to your timeline. The login will still work.

If your are using the downloaded stand-alone client app and the Facebook login fails with an error page, then simply enter the email address and password from your Facebook account into the login fields of the Spotify client app.

Spotify says that it only uses these credentials to pass through to the Facebook authentication and won’t store your password anywhere. I hope that’s true.

“Lidar News” publishes uninformed (L)GPL rant

In its “Random Points” column, the June 2015 issue (Vol.5 #4) of Lidar News, recently renamed LidarMag, contains an opinion piece called “Open Source Mania” (PDF) by Lewis Graham, a director of the board with ASPRS, the organization that defines the LAS file format.

The article contains grains of interesting and potentially relevant comments on the LGPL, but without properly spelling things out: The LGPL – if not amended with a static linking exception as in the LASzip license – has “copyleft” implications when the library code is statically linked, which is somewhat similar to but not as strict as the “strong copyleft” nature of the GPL. I recommend reading the LGPL section of the “Copyleft Guide” or a good article on the Open Source “risks” and considerations during corporate acquisitions and mergers.

Having said that, Lewis Graham’s piece contains many inaccuracies and unfair judgements:

1) The author underhandedly attacks Martin Isenburg’s broadly supported attempts to have the LGPL-licensed de-facto standard LASzip accepted as an Open Standard and then goes into a rant about the GPL, while lumping both licenses together as “viral”. The LGPL – not the GPL – explicitly allows the use as dynamically linked library without any licensing impact on the main program. Combining the attack on the LASzip community with a rant against GPL while ignoring the main difference between LGPL and GPL is unfair to say the least.

Lewis also fails to mention that the LASzip license is actually LGPL with an additional clause that explicitly allows even static linking without licensing impact on the main program.

2) He falsely claims that “Open Source” was never defined but fails to mention the Open Source Initiative (OSI) who coined the term and provided exactly that Open Source definition.

3) The article misleadingly mentions the Free Software Foundation as the “anchor organization” of Open Source, repeats the old misunderstanding that “Free Software” should not cost money and fails to mention the “Free Software” definition by the FSF.

4) The author spreads long debunked FUD (fear, uncertainty, doubt) about the GPL, claiming that all “code [that] touches GPL code in any manner [..] is now GPL”. In particular he makes false claims that the following uses of GPL code would be “viral”:

  • Executing a GPL licensed program from a script via process execution (“Unix fork”) explicitly does not impose any licensing restrictions on that script, as per GPL FAQ
  • Derived works that incorporate GPL licensed code, do not automatically become GPL licensed. Only when the derived work is distributed the following applies (quoting GPLv2, section 6): “Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions.”

5) The author repeatedly refers to an “Open Software Foundation”. He seems to confuse or conflate Open Source Initiative (OSI) and Free Software Foundation (FSF). The actual “Open Software Foundation” – later merged into “The Open Group” – has not much to do with either OSI, FSF or software licenses.

6) The author keeps calling the GPL “toxic”, while in fact the GPL is a widely known and court-proven license in the software industry that many companies use successfully as part of their business models, for example Redhat (Linux), Oracle (MySQL), etc. Especially Dual Licensing based business models actually benefit from the relatively restrictive nature of the GPL.

7) The author praises the MIT license as “reasonable” because of its permissive nature (i.e. not imposing any significant licensing restrictions on derived works). As he makes that judgement he takes only the perspective of companies that want to use Open Source libraries in their proprietary closed-source products. He ignores the perspective of Open Source developers, communities and companies who want to protect their work from embrace and extend and other hostile take-over strategies and deliberately use copyleft licenses like the GPL to protect their software.

8) Overall, the author fails to accept that it is the copyright holders freedom to chose a license that suits their needs and intentions.

Viewport meta tag for better page rank in mobile Google search

Algorithm changes are rolled out to Google’s data centres to let mobile-friendly web pages get higher ranking on Google Search. Some sensationalist news outlets call this “mobilegeddon“. I think it is much ado about very little.

Google provides a mobile-friendly test and at first old-o.github.io did not pass.

So I learned about the viewport meta tag and after adding the following to the head section of my html pages they now pass the test:

<meta name="viewport"
content="width=device-width, initial-scale=1.0, user-scalable=yes"/>

About the viewport meta tag

180x130_viewport-meta-tag

The “viewport” meta tag is not part of the official HTML standard, but the validator at the W3C will still accept your pages as valid.

The tag was initially introduced by Apple Safari, but is now widely supported by most mobile web browser. As of spring 2015 Microsoft IE for Windows Mobile is the main exception: It requires some vendor-specific CSS.

Non-mobile web browsers typically just ignore the tag, which is fine because the whole “viewport” concept only makes sense for the relatively small screens of mobile devices.

Lacking a standard definition, for now the best specs are the respective web developer pages at Apple, Mozilla and Google.

Responsive accessible web design

Please note: Passing the Google test is nice for your page ratings, but truly “responsive” web design that works well on all browsing devices requires more effort, as this article on html5rocks.com explains quite well.

And of course, all supporters of an open, inclusive web should always ensure the accessibility of their site, for everyone regardless of disability.

OSGeo Open Letter for Open Formats of LiDAR data

A widely unnoticed revolution is going on in the field of capturing landscapes for mapping and other geographic purposes, and it is laser based:

LiDAR is the technology that uses lasers on small airplanes to literally scan in whole geographic regions and turns them into 3d point clouds. In many ways, especially for high-resolution 3D elevation data, LiDAR is already replacing traditional satellite based approaches, and enables a plethora of applications in many fields of science and business.

So far, the de-facto standard file formats for storing these “point clouds” are LAS and its compressed variant LASzip (Open Source, LGPL, developed by the German software engineering firm rapidlasso).

But recently ESRI, the market leader for Geographic Information System (GIS) software, has stepped into the arena with a closed source compression format, deceptively called “Optimized LAS” (aka *.zlas), and is positioning it as a direct competitor to the widely used Open Source LASzip format.

The closed-ness of the ESRI file format and the resulting fragmentation of the LiDAR community and its data stores, has now lead to a concerted “Open Letter of the Need for Open Standards in LiDAR“, signed by many representatives from LiDAR related companies, research institutions and the wider geo-informatics community.

I hope that this is a step towards protecting the LAS format from “hostile takeover” by ESRI and I have added my name to the signature list today.

In the very least the Open Letter will raise awareness of the importance of Open Standards and Open Source in the essential field of geographic data, data about our planet, about the world we all live in, which should be Open Data, available to all via Open Standards via Open Source tools, not locked away in vendor-proprietary binary formats that can only be read and processed using that single vendor’s tools.

JBoss Undertow is pulling me in … :o)

I am very impressed as I am trying out the various code examples for Undertow, a kick-ass, light-weight yet powerful, ultra-easy-to-embed HTTP and Java Servlet engine.

One of my side projects requires an embeddable yet feature-complete Java HTTP engine with low memory footprint and a simple straightforward API. I dismissed Tomcat, briefly considered Jetty, found Winstone too old and unmaintained, simpleframework not well-enough documented, vert.x and netty a little too much for my purposes and/or too complicated, so that a few weeks ago I had actually started to clone and refactor NanoHttpd.

The NanoHttpd refactoring was a great learning experience, but it certainly felt like I was reinventing the wheel in the form of a cute and mobile but slightly rusty foldable unicycle. ;o) – no offense please, nanohttpd developers

Then I found out about Undertow. The author Stuart Douglas is now officially my hero. What an awesome job he is doing! The server meets all of the above mentioned requirements and is apparently also comparatively fast. No wonder it is the HTTP engine used by Wildfly, the new JBoss AS.

Anyway, if you want to try yourself, I’d go with version 1.1 final at this time, i.e. this in your Maven pom.xml:

<dependency>
    <groupId>io.undertow</groupId>
    <artifactId>undertow-core</artifactId>
    <version>1.1.0.Final</version>
</dependency>

I decided to pretty much ignore the documentation section of the undertow.io website for now, as it is still for version 1.0 and the API has changed – improved, I guess – since then. It seems to me, that at this point the core code itself and the usage examples are the best documentation for version 1.1. Both are Maven modules of the undertow github project.

By the way, if you are wondering why the project has no issues section on github: The issue tracking is done in the JBoss Jira.

How to report profiles of LinkedIn spammers

If you use LinkedIn discussion lists – like the “Java Developers” one that I frequently participate in – you might have seen posts about “Fast Loans” and other annoying commercial messages that are unsolicited, way off-topic and commonly referred to as spam.

A first step is to point out to the poster, typically by simply commenting on their posting, that each LinkedIn group has a “Promotions” section and kindly ask them to delete the spam and to select the “Promotions” category accordingly in the future. Sometimes this friendly approach actually works.

LinkedIn has an official guideline for “Flagging an Inappropriate Discussion or Comment in a Group“, but often the recommended flagging of individual posts leads to no visible change and quickly gets tiresome, since it will only temporarily hide the flagged content and – in my experience -leads to no repercussions for the spammer themselves.

If you are lucky, your LinkedIn group has active owners who you can contact and they might block the spammer and/or even lock down the group to “members only”. But unfortunately, group owners often do not have the time or motivation to do this kind of policing.

So if a spammer ignores your friendly requests and continues to fill your favorite discussion group with garbage and you have run out of other options, consider reporting their LinkedIn profile like this:

- Go to the LinkedIn profile of the spammer (by clicking on their name)
- Use the dropdown arrow of the blue "Send [Firstname] InMail" button
- Select "Block or report"
- Click the option "Report [Firstname Lastname] so that"
- For "Flag profile as" select "other"
- In "Details" put this, replace LINKEDIN_GROUP_NAME accordingly:

This profile has been repeatedly used to post unsolicited, completely off-topic, commercial messages on LinkedIn groups like ‘[LINKEDIN_GROUP_NAME]’. The owner of the profile has so far ignored all requests to stop the spamming. Please take appropriate actions.


- Then click "Continue" button on the bottom
- Agree to the prompt "Are you sure you want to report [Firstname Lastname]?"

Finally you should see a notification:

“Thank you. The profile has been flagged for review by LinkedIn Customer Service.”

Optionally, copy that notification text and paste it into a comment / reply to the spam posting that caused you to report the person. That way the spammer will notice that (and how many) people reported them.