Improving Perl’s GPS Support

A little while ago, I wrote an article for PerlTricks on GPS and Perl, primarily using the GPS::NMEA module. Accessing GPS data was one part of a larger project I’m working on (recording telemetry data for car racing). Unfortunately, I also discovered some limitations in the GPS::NMEA module.

Firstly, as we discovered after the article was published, the coordinates returned are not decimals that you can just stick into Google Maps and get the right location. I had thought the inaccuracy was due to taking readings indoors (it was only off by a few miles), but it turned out to be something else. The decimal portion is actually the number of arcminutes rather than an actual decimal. This isn’t documented anywhere in the module. The correction is easy, but I feel like the module ought to be doing it for me, or at least document what’s coming out.

Secondly, the module gathers data like this:

This comes out of GPS::NMEA->get_position(). This reads the data off the serial port line-by-line until it sees one starting with “GPRMC”, which indicates the line has the position data. There are other commands being sent, such as altitude and velocity, but those are thrown away until it hits the next position data line. This means that if you want to read both position and velocity (as I do in my project), you’ll be waiting much longer than you should for each of those.

This would benefit from a callback interface to get the data as it comes in a loop.

Lastly, there are license issues. It’s under the classic “same terms as Perl itself”, which is problematic. What version of Perl? Earlier ones were GPL-only, and newer ones add the option for the Artistic license.

There are issues with the Artistic license itself, too, especially the first version (which Perl5 still uses). The FSF has criticized it as “too vague; some passages are too clever for their own good, and their meaning is not clear. We urge you to avoid using it, except as part of the disjunctive license of Perl.”

Also, you can’t guarantee what terms Perl will have in the future. While it’s unlikely to happen, the US government could argue that since Larry wrote the early versions under their watch, they could swallow up the whole thing. A more likely scenario (given the problems with the Artistic license above ) is that the Perl devs could change the license at any time. They wouldn’t necessarily change it to something you like–remember the flamewars about the GPLv3 in the larger FOSS community?

I hate to rewrite GPS::NMEA, because some of the comments and code indicates that there was a lot of time spent getting it to work with the quirks of different GPS modules and OSen. For Perl code that originated in the late-90s, it’s very well written. If it were just a matter of the first two technical issues, we could probably work out a better interface on top of the existing code. I’m uncomfortable working with the license issues, though, so a rewrite may be the only way to go.

Website Pin Facebook Twitter Myspace Friendfeed Technorati del.icio.us Digg Google StumbleUpon Premium Responsive

Tagged , , . Bookmark the permalink.

4 Responses to Improving Perl’s GPS Support

  1. Peter Rabbitson says:

    You never mention what you *intend* to use as a replacement license. If you are looking for a copyleft license – I strongly urge you to reconsider. An unwritten[1] rule of CPAN is that it is explicitly “TiVo-friendly”.

    With regard to “same as perl itself” being vague – it doesn’t have to be. Here is what I came up with after extensive research: https://metacpan.org/source/RIBASUSHI/DBIx-Class-0.082820/LICENSE. It is not perfect, but is not half-bad either. Moreover you can apply this to existing projects with no controversy, as simple clarification of intent (a module was written against perl 5 by efinition, there was no loadable .pm module support prior to 5.0). Here is the full changeset as it was applied to DBIC project-wide: https://github.com/dbsrgits/dbix-class/commit/a2bd379666#diff-19e579bc315f02736320e3c57c24771e

    Cheers!

    [1] Though search for the word “viral” here: https://github.com/Perl-Toolchain-Gang/toolchain-site/blob/master/berlin-consensus.md

    • Timm Murray says:

      Explicitly laying out the license like that is definitely better, though I’m still not comfortable with the Artistic license. Most of my modules these days are under 2-clause BSD.

  2. bulk88 says:

    Without verifying that every single contributor to the source code has a signed and notarized CLA, you can not be sure that a 1 line patch was written by someone on employers time and therefore the contributor never had copyright of their code when they submitted the patch. Once, just a single patch like this lands in your codebase/repo, the whole repo is now unlicensed proprietary software of that employer and you and all your downstream users will be sued for millions in court. So your safest option is to stick to 100% proprietary software to reduce this risk.

    I also suggest the CLA require submitting a fingerprint and DNA to prevent identity theft of the purported code contributor (NSA impersonation to put in a backdoor) :D

    • Timm Murray says:

      > So your safest option is to stick to 100% proprietary software to reduce this risk.

      Hahahaha, no. Besides missing the point, proprietary software does not protect against that at all. Internal practices at large companies, where software is often contributed by outside contractors, often leaves the code in a state of ambiguous ownership.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.