Markup formats can inspire just as much devotion and loathing as programming languages. TeX versus HTML, DocBook versus Mallard—the list is probably endless. But the "lightweight" markup formats (Markdown, reStructuredText, AsciiDoc, and so on) are the subject of particular scrutiny. Users almost always write them by hand, not in a dedicated tool, and the formats are becoming ever more widespread: as input formats in web applications and as the preferred document format on sites like GitHub. But these lightweight formats, Markdown in particular, have developed a reputation for compatibility problems in recent years—see the CommonMark effort for one of several attempts to impose order on the chaos. Thus, when version 6.0 of ReText, a GUI editor for Markdown and reStructuredText documents, was released recently, I was curious enough to take a look.

ReText is a Python 3 application that uses Qt for its interface. Officially, only Linux is supported, though other Unix-like systems may find it usable as well. The new 6.0 release is available from the Python Package Index (PyPI), but users will also have to separately ensure that they have the Qt5 and PyQt5 packages from their distribution installed, since the pip tool will not resolve those dependencies. The distribution's PyQt5.QtWebKit package for Python 3 is an optional dependency that, as we shall see, may also be worthwhile.

Visually, ReText presents a simple editor window by default, with a tab for each open document. Displaying line numbers is optional, as is highlighting the current line and displaying a vertical guide line at some user-specified column width. The editor window employs a small amount of syntax highlighting, but nothing that would break the vertical or horizontal alignment of the monospaced text in the editor. Any words marked-up as **bold** will be shown in **bold** along with the markup, for instance, but text marked-up as ###headlines will not be rendered at a larger font size. There are also two menus for inserting markup; one for the basic formatting elements (text style, lists, headings, and so on) and one for typographic symbols.

One of the main draws of ReText, though, is found outside of the editor window itself. The application supports a "live preview," showing how the document in the editor will look when rendered as HTML. The live-preview pane can be set to be displayed by default, which is is probably the setting most users will want. After all, Markdown and reStructuredText do not have many of what would be considered "syntax errors" in richer languages: the only way you know that you mixed up the () and [] of a Markdown link element is by seeing it displayed incorrectly when converted to HTML.

In addition, the editor has several conveniences, such as a table-editing mode that keeps the columns in a Markdown table automatically aligned by inserting extra spaces where needed. It is also possible to tweak the behavior of the tab key (to insert a specific number of spaces), which can be rather handy indeed when one is trying to adhere to a specific style guide. The editor window also highlights trailing white-space characters, which can (oddly enough) have semantic meaning in some Markdown implementations. Files can be exported to HTML, ODT, or PDF.

At this basic level, ReText succeeds admirably. It is only when one gets further down the Markdown rabbit-hole that matters become tricky. After all, which "flavor" of Markdown one needs for a particular document matters a great deal. If the document is destined for the Markdown implementation used by a specific site or program, it would be best to know that the ReText editor supports the right variations. Even if not, generic Markdown has certain quirks—such as interpreting the underscores in a_variable_name as the italic tags (thus rendering "avariablename") that may be problematic.

In practice, ReText offers a well-defined, though poorly advertised, flavor of Markdown. It uses the Python Markdown library and, thus, inherits that library's interpretation of the format. But ReText also supports the use of Python Markdown extensions, on a per-file, per-directory, and per-user basis. The Extra extension set is enabled by default. Extra enables a variety of niceties, such as table support, a simpler syntax for designating code blocks, and the ability to specify certain HTML attributes in a Markdown element.

The user can turn on any installed Python Markdown extensions for a particular file with an HTML comment (inserting raw HTML being a common practice to overcome Markdown's limitations):

<!-- Required extensions: sane_lists, wikilinks -->

Putting a list of extensions, one per line, in a file named markdown-extensions.txt will enable those extensions in ReText for the entire directory. Placing that file in ~/.config/ will enable it for all files the user edits.

The official Python Markdown extensions cover most of the common complaints about generic Markdown. Several third-party extensions are also available that can add support for (among other things) GitHub-flavored features. Keeping track of which Markdown extensions one needs is not a particularly fun job, but at least it is one that only needs doing (or revisiting) rarely.

The other half of the Markdown puzzle is figuring out whether ReText's live preview adequately represents what will actually be shown when the document is viewed elsewhere (such as on GitHub). The built-in renderer provides a quick-and-dirty answer that is mostly useful for troubleshooting the basics: did I forget to put a space in the right place, did I use the wrong heading level, and that sort of concern. But ReText also offers a WebKit renderer option for the live preview page, if the user has installed the PyQt5.QtWebKit package for Python 3.

Activating the WebKit renderer for the live-preview pane might provide output a bit more likely to match what is seen when Markdown or reStructuredText is converted to HTML by a web application. Its other selling point, however, is that it is required if one wants to make use of the ReText's Math extension. The math features are built on MathJax, a cross-browser JavaScript display engine, not by a Python Markdown extension. On the plus side, users can write a wide variety of expressions, since MathJax supports TeX math syntax. The downside is that the output will only be viewable on a web page that uses MathJax (precluding, among other things, GitHub's Markdown implementation).

Fortunately, working with reStructuredText is just as easy as working with Markdown—easier, even, given that reStructuredText does not come with Markdown's competing-standards issues. All of the same features are available in ReText, regardless of which format is used.

One of the most common questions about ReText appears to be whether it will add support for AsciiDoc in addition to Markdown and reStructuredText. The answer appears to be that AsciiDoc's toolchain lacks Python 3 support, so ReText would not be able to export AsciiDoc files to any of its output formats.

For day-to-day editing of Markdown files, though, ReText is a welcome addition. I have also experimented with several Emacs modes that offer some degree of Markdown previewing, and ReText offers a substantially nicer editing experience.

Personally, I am still not much of a fan of Markdown as a document format—due, in large part, to the competing yet incompatible implementations. But another reason is that, while the format works well enough for simple formatting, its simplicity falls away as more and more features are added. It is nice to have headings and bulleted lists that work in plain ASCII text and in HTML, but by the time one gets to right-aligning columns in a table or specifying "alt" text for inline images, Markdown's syntax ceases to be simple or intuitive. Having an editor that smooths over those issues is a big help.

Along those lines, ReText is probably a better fit for its task than something like the LyX editor is for TeX and LaTeX. Markdown and reStructuredText are simpler than TeX, so the toolbars and menus do not get bogged down trying to encapsulate the complexity of the language. At the same time, though, one invariably loses a lot of the power of TeX whenever one tries to wrap it up in a GUI. Markdown remains lightweight; it is just easier to work with in a proper GUI editor.

Comments (19 posted)

At first, the Aquaris M10 Ubuntu Edition — often called the Ubuntu tablet — resembles most modern tablets, with a hard plastic case that folds into a stand, limited multi-tasking from an overview screen, and some ability to act like a workstation or laptop. However, even a tentative exploration reveals that the Ubuntu Edition is much more, due mostly to its operating system and the Unity interface, which comes of age at last on this tablet.

To start with, the tablet runs Ubuntu 15.04, and includes support for free formats such as .ogg and .odt , with a full list of software licenses available from the System Settings. Install the Terminal app, and you can see for yourself all the features — and one or two more — of Ubuntu on the desktop, such as the usual entries in /etc/apt/sources.list or the mounting of an SD micro card as a subdirectory of /media . Even more importantly, the Ubuntu tablet has no need to be rooted for a user to gain full access to it. Instead, once you select Developer mode from the System Settings, you are logged in as root — or, as the online instructions explain, you are in a setting from which "anyone can access, change or delete anything on this device by connecting it to another device."

At the same time, the Ubuntu tablet's security features are far more extensive than a typical tablet's. The Galaxy Tab 2 10.1, for instance, includes privacy features, but does nothing to call attention to them, and they are disabled by default, which probably means that it often runs with almost no security whatsoever. By contrast, the first-boot wizard for the Ubuntu tablet urges users to add basic security such as passwords, presenting the options in order of effectiveness. Features that increase access and could potentially allow damage to the system, such as the Terminal app or Developer mode, each require the user's password as well — although they are also somewhat protected by their obscurity, either by not being initially installed, or by being placed several layers down in the interface.

Similarly, while the Galaxy Tab 2 10.1 includes an email application that, once configured, automatically downloads messages, the Aquaris M10 includes only a Gmail app, which requires a login with each use. Users who want another mail reader must download it from the Ubuntu Store.

The result is a tablet organized like a Linux-based laptop or workstation. For anyone who has tried to secure a typical Android tablet, scouring the interface for the necessary tools and risking rooting to gain some control over the machine, the Ubuntu tablet provides the immediate comfort of a familiar environment based on well-understood logic.

Unity in its natural habitat

Unity has been available on the desktop since 2010. On a twenty-four inch widescreen monitor, Unity can seem primitive and limited, but on a tablet's 10.1 inch touchscreen, this sometimes-derided graphical interface comes into its own. Developing on the ordinary tablet's use of a dragging finger to scroll up and down a window, Unity expands dragging — or swiping as it calls the motion — into a means of navigation for everything.

Swiping from the left edge of the screen displays the launcher of favorites, from the right the display of running applications (from which a swipe towards the bottom edge closes an app), and from the bottom additional details of the current application. Similarly, swiping from the top refreshes the current application, while swiping down from the indicator icons on the far right opens the configuration tools.

This form of navigation takes some adjustment — so much so that ideally the box should include a single sheet illustrating the types of swipes for quick reference. The brief tutorial in the first-boot wizard or the online help is not nearly enough to allow users to memorize the kinds of swipes, all the more so because finding the first-boot wizard again is difficult.

However, for me, swipes justify the entire idea of the touchscreen for the first time, providing a simple and elegant tool. Swiping simply feels less disorienting than jumping from screen to screen. Moreover, it can also be quicker; for example, instead of having a "back" button, you can right-swipe to jump directly to any open application. Because you are usually swiping into the screen instead of changing from screen to screen the way you do in most tablet interfaces, you can easily retrace your path. Although swipes are very much a feature of touchscreens, they create an interface that, while suited to the form factor, finally gives a the small screens of tablets the power of a desktop environment such as MATE or GNOME.

Desktop mode

From its first boot, the Aquaris M10 is organized so that it feels like a desktop computer. However, its tools are a mixture of typical tablet apps and standard Linux ones. You can run tools like GEdit or LibreOffice at any time, but aside from using your finger as an imprecise drawing tool in GIMP, to be productive with them, you need to switch on Desktop mode in the System Settings. In Desktop mode, the main screens of apps morph into full-screen windows and dialog windows, and Unity acts approximately as it does on a desktop.

You can enter Desktop mode in three ways. The easiest is to connect the tablet to a monitor or TV using the USB port. However, you can also start Bluetooth to run a mouse or keyboard, or connect the tablet to a USB hub.

Unfortunately, none of these choices are completely satisfactory. Granted, Bluetooth can be flaky, but I have yet to manage to enable both a mouse and keyboard at the same time. At times, too, Desktop mode slows to a crawl. The basic functionality is there, but the instructions are sparse. To make full use of Desktop mode, users have discover for themselves details such as the fact that default user is "phablet", or that screen shots taken by pressing both ends of the volume button on the top right of the tablet are stored in /home/phablet/Pictures/Screenshots . Such inconveniences make Desktop mode less than seamless.

Still, even with these inconveniences, Desktop mode enhances the Ubuntu tablet by potentially extending its range of apps. While the Apple Store or Google Play have many thousands of choices, the Ubuntu Store has less than a hundred. Since Linux apps can presumably be modified for the tablet relatively easily, Desktop mode can perhaps make the porting of applications easier until the Ubuntu Store is more thoroughly populated.

Packaging problems

Specification HD Full HD Size (mm) 246x171x8.2 246x171x8.2 Weight (g) 470 470 Screen (in) 10.1 10.1 Resolution 1280 x 800 - 149 ppi 1920 x 1200 - 224 ppi Aspect ratio 16:10 16:10 Storage 16 GB (10 or less usable) 16 GB (10 or less usable) RAM 2 GB 2 GB CPU MediaTek Quad Core MT8163B up to 1.3GHz MediaTek Quad Core MT8163A up to 1.5GHz GPU MediaTek Mali-T720 MP2 up to 520MHz MediaTek Mali-T720 MP2 up to 600MHz Bluetooth 4.0 4.0 WiFi 802.11a/b/g/n (dual band - 2.4 GHz - 5 GHz) 802.11a/b/g/n (dual band - 2.4 GHz - 5 GHz) Cameras Front 2MP, Back 5MP Front 5MP, Back 8MP Audio 2 0.7W speakers 2 0.7W speakers Battery LiPo 7280mAh LiPo 7280mAh A complete list of specifications is available here.

When showing the Aquaris M10 around, I have found two main reactions. The Linux users generally react with some variation on "a tablet that acts like a desktop computer? Cool!" By contrast, less experienced users tend to look at the greater security and the use of Unity, and ask with genuine puzzlement, "Why bother?"

Better marketing and packaging might overcome this second reaction, but I suspect that the most immediate source of this indifferent second response is the packaging. In both the HD and Full HD models of the Ubuntu tablet (the Full HD model has slightly better specs and is the basis for this review), most specifications are average at best (see sidebar).

In particular, the Aquaris M10 ships with less than 10GB of on-board storage, and applying the latest upgrade reduces that to less than 8.5GB. Yet the specifications state that the tablet can use nothing greater than a 64GB microSD cards, although I suspect that it might support a 128GB card, which would bring the tablet up to the specifications of similarly priced tablets. As for the battery, in my experience, a full charge lasts no more than seven hours.

Equally disappointing is the contents of the package. The tablet ships with a protective screen cover that is almost impossible to apply without trapping air bubbles between it and the screen. The printed documentation amounts to four pages consisting mostly of obligatory notices and warnings, and a diagram of the hardware, without any mention of the online manual or how to access it.

Even worse, in my case, the box included a micro-USB cable that didn't fit its slot, and a recharging cord that had a European plug. Apparently, BQ, the manufacturer, does sell a converter, but, given my North American address, it might have mentioned this detail.

This lack of attention to detail is disappointing, because, as one of the few Linux-based tablets — especially if Android is counted separately — the Aquaris M10 Ubuntu Edition has a lot riding on it. Although its firmware is proprietary, it is still one of the more open tablets on the market today, and its failure for any reason would undoubtedly discourage the development of other open hardware. The only hope is that BQ is willing to commit in the long term to the Ubuntu Edition and upgrades the packaging eventually.

Meanwhile, despite the packaging, for those with the experience to appreciate its unique features, the Ubuntu tablet is an attractive niche product. Personally, once I learned my way around, it became first tablet I have not found a test of patience to use for any length of time. Because of its security, familiarity, and interface, it is currently my mobile computer of choice.

Comments (15 posted)

The Free Software Legal & Licensing Workshop (LLW) is a three-day event held every year for legal professionals (and aficionados) who work in the realm of free and open-source software (FOSS). It is organized by the Free Software Foundation Europe (FSFE) and, this year, the event was held in Barcelona (Spain), April 13-15. The topics covered during the event ranged from determining what constitutes authorship, how to attribute it, and what is copyrightable, to the complexity of licenses and how to make them more accessible for potential licensees lacking in legal background. In addition, license enforcement and compliance were discussed, with a particular focus on how the GPL and related licenses have done in court.

According to the organizers, there were approximately 90 attendees, 70% of whom were legal professionals and 30% technical professionals linked in some way to legal matters in their communities or companies. Attendees came from legal firms, traditionally open-source companies and communities, such as the Linux Foundation, Red Hat, and Debian, tech companies with some open-source products (Intel and others), and companies that are using open-source software embedded in their products. Discussions were held under the Chatham House Rule, which means that names and affiliations of participants are only available for those who have explicitly agreed.

As mentioned above, one of the hot topics was that of enforcement. It is worth pointing out that both FOSS and the related Creative Commons (CC) licenses, especially those that include copyleft clauses, are relatively modern legal documents. Those licenses are often infringed upon, either due to ignorance or because the conditions they require for compliance are not taken seriously.

The return of gpl-violations.org

The true test of a legal document is how it stands up in court. Harald Welte carried out a lot of the legwork to get GPL and GPL-like licenses recognized as legally valid and binding through his gpl-violations.org work and his role in suits against infringers in the mid to late 2000s.

Welte has recently decided to bring gpl-violations.org back to life after a hiatus in which he was involved in other projects. In his brief talk, Welte said that although "licenses are not an end in themselves, but tools to promote a collaborative development model", it is important that companies realize that "complying with [FOSS] licenses is not the maximum they can do to collaborate with free software. It is, in fact, the bare minimum."

German GPL court cases

In her presentation, Dr. Miriam Ballhausen from JBB Lawyers (based in Berlin, Germany) reviewed the history of enforcement of licenses in German courts, much of which came out of work by Welte and gpl-violations.org. She described the precedents set and how they have affected compliance. She also gave some insights on the steps to follow if a company is believed to be infringing.

Germany is probably the country in which most suits have been filed for FOSS-license infringements, starting with Welte vs. Sitecom (Regional Court of Munich, 2004). In that case, Welte sued Sitecom B.V. for including and distributing a modified version of GNU/Linux within their wireless routers, but not providing access to the modified source code.

There had been some prior difficulties enforcing the GPL in Germany because the terms of the GPL are deemed to be general terms and conditions, which meant the German law on general terms and conditions applied. More importantly, software can only be effectively licensed in Germany under a license that is written in German. Hence, Sitecom argued that the GPL, in this case version 2 of the license, was ineffective and its terms could not be enforced. Furthermore, the defendant stated that, by licensing code under the GPL, the authors waived their intellectual property rights.

However, the court ruled in favor of the plaintiff. The court concluded that either the defendant abide by the clauses in the GPL or the defendant must abide by regular copyright laws. If the GPL is deemed ineffective, then there's no license and no rights were granted to Sitecom. If the GPL is deemed effective, then the defendant would be bound by its terms. One way or the other, the defendant had infringed.

The precedent established by Welte vs. Sitecom has allowed Welte to win other cases and settle many others (which can be seen in the gpl-violations.org news archive). In addition, a case heard in the Regional court of Halle in 2015 upheld the legal standing of the GPLv3 as well.

Consequences for infringers

Under German law, winning an infringement case gives the plaintiff the rights to certain claims, namely:

the right to claim a cease and desist from further infringements

the right to claim for damages

the right to claim for removal (i.e. recall from the supply chain) of the infringing product

the right to claim information about the chain of distribution and number of sold devices

the right to claim for reimbursement of costs

Ballhausen touched briefly on the last three claims from the list, commenting that plaintiffs have never required a removal of a product, because product removal has never been their objective; no plaintiff has ever requested information about the chain of distribution simply because this information would be of no use. Finally, with regard to the reimbursement of costs, awarding coverage of legal costs is automatic in European law when a plaintiff wins a case.

Requiring that the defendant cease and desist from further infringements is, however, an important issue, since the aim of most of these suits has typically been to force compliance onto the infringers. To cease infringing, the defendant must provide access to the exact same source of the code supplied with the product (yes, there has been at least one case where the defendant tried to pull a fast one and linked to an outdated version of the software), and a full copy of the license. It is not enough just to say "some of the software included with this device is distributed under license XYZ".

Ballhausen explained that a notification to cease and desist can, and probably should, be sent to the infringer before court proceedings, thus allowing the infringer to correct the fault before actually being sued. In Ballhausen's experience, friendly letters advising of infringements tended to be ignored and were often not considered clear enough by the court if the parties ended up going to trial. So a no-nonsense letter demanding immediate cease of infringement is preferred. If the case does end up in court, the plaintiff can request an injunction to stop the distribution of non-compliant products before the resolution of the case.

In terms of damages, though there have been no damages awarded to date, the plaintiff could in theory request that the infringer hand over the profits it made while distributing the non-compliant products. However, there has been some controversy as to what, if anything, an infringer should pay.

In a case heard in the regional court of Cologne in 2014, the court went as far as ruling that the defendant would have to pay all profits from sales, customer service, support, and other services for the product subject to the dispute. In other cases, however, courts concluded that it was nearly impossible to calculate an amount and that it would have been easier if the software had been dual-licensed. The infringer would then have to pay as if it had licensed the proprietary version of the software.

Consequences for free software

The GPLv2 and GPLv3 have been ruled to be valid legal licenses in Germany and the cases that have been fought in court have helped establish a framework of legal arguments for the rest of Europe. This has also trickled down to other FOSS-like or FOSS-inspired licenses, such as the AGPL, LGPL, and the family of CC content licenses, Ballhausen said.

There are, of course, downsides to the successful enforcement of FOSS licenses. Due to the proliferation of repositories and media, not all of which are clearly licensed, as well as the ever-growing number of licenses, using or reusing code, images, audio, or video has become somewhat of a minefield for those seeking to use FOSS-licensed software and media. Some participants in the discussion at the LLW event argued that there was some anecdotal evidence that this complexity has had a chilling effect to some degree on the adoption of open source by companies.

To mitigate some of the uncertainty companies may feel when thinking of using open-source software or media, Dr. Till Jaeger, also from JBB, presented an automated Attribution Generator. Although it is currently only a proof of concept, is not translated into English, and works exclusively for CC-licensed images found on Wikipedia and Wikimedia Commons, this application helps generate a legally correct attribution. A questionnaire leads one through the process of collecting information needed when publishing images to create a legally sufficient attribution line. The code for the project is available from GitHub and distributed under the GPLv3.

Conclusion

All of the speakers agreed that, thanks to all the work carried out by Welte and others, the legal validity of FOSS licenses, once a gray area, is becoming much clearer thanks to a growing corpus of precedents. At least in Germany, enforcing the GPL or the CC family of licenses is not at all a quixotic endeavor anymore.

The issues with FOSS licensing these days lie elsewhere, affecting more the licensees than the licensors. The complexity of licenses themselves and the proliferation of different licenses and versions makes licensing a complex topic. This may negatively impact the adoption of FOSS technologies by third parties. This complexity is pushing legal professionals in the FOSS sector to develop tools to help companies simplify compliance.

[ The author would like to thank the Linux Foundation for assisting with his travel expenses and the FSFE for help during the event. ]

Comments (2 posted)