Open Source Software Licensing

  1. ASTM E57.04 is debating the type of open source license that we should adopt.
  2. One will require that all work be shared, the other will not.
  3. One concern is that by not sharing there will be a number of versions of the format.

The ASTM E57.04 Data Interoperability subcommittee which I chair, and which is making great progress on a standard format is debating what type of open source license we should adopt. Basically the major issue is whether to require users of the open source libraries to have to share/return the code that they develop with the group, or whether they can make it proprietary.

One of the key concerns is interoperability. If the commercial interest code is not returned to the group, then it is more likely that there will be a number of “versions” of the format, which we all have had to deal with in handling data and operating systems. On the other hand the commercial interests are going to be less likely to develop innovative technology if they have to expose it to the community.

It’s a tough issue. Your thoughts?

This entry was posted in Standards, Technology, The Industry and tagged , , , , , . Bookmark the permalink.

1 Response to Open Source Software Licensing

  1. As the LAS specification effort shows, the specification is not the implementation.
    There are numerous LAS implementations out there, and while there is some modicum of
    interoperability, around the edges of the specification, things are quite hairy.

    The specification doesn’t need a license, unless you are granting some
    sort of technology usage license. I may misunderstand, but is the E57.04
    subcommittee going to produce a written specification, ala LAS, or is it going
    to produce both a written specification and software that implements it?

    In my opinion, a great specification is two pieces — a precise, well-written
    document and an open source implementation that truly validates whether data
    are within the bounds of the specification. The LAS specification effort
    misses this second part, and in my opinion, this is why that effort will continue
    to devolve. If the committee were to bless an implementation (hey, libLAS is
    right there for you ūüėČ ), use it to develop a validation suite, and then
    ensure the software is freely available to everyone, a few good things would
    happen. First, a powerful commercial interest with a Microsoft’ish market position
    variety can’t come in and embrace, extend, and extinguish the format that is
    providing an interoperable playground for all the small interests — their
    implementation either conforms to the specification as validated by the
    committee’s software choice or it doesn’t. Second, legacy support for your
    format is ensured due to the free (both as in beer and as in freedom) availability
    of the software. The format may become obsolete, but options for getting data
    out of that format into something else will always exist from more than a single
    vendor.

    libLAS has a very liberal license. Users (even commercial) can pretty much do
    what they want with the code as long as they follow the crediting requirements
    in their own software. This means they can potentially take libLAS, roll it
    internal to their organization, and continue on their way. From a practical
    and cost-benefit standpoint, it is definitely not in their interest to do
    that, however. libLAS’ development continues to march forward at a pace that
    is hard for an organization to keep up with. As long as libLAS’ direction as a
    software development concern continues to move forward, this momentum will
    help to preclude folks from taking the code and forking it internal to their
    organization. This inertia also increases as more folks use the software. Or,
    alternatively, an organization will make that mistake once, and then work hard
    to push their changes back into the mainline development effort so they can
    continue to receive the benefits/features that it ends up missing out on due
    to their internal fork.

    I think your choices for an open source software license for something like this
    boil down to two different varieties — liberal like libLAS uses (BSD) or
    something more conservative like the LGPL. A pure GPL (2.0 or 3.0) license
    will definitely scare away the commercial interests, but LGPL would still allow them
    to use the software in their own packages with the restriction that any improvements
    they make to the software are also made freely available. This may be a good
    compromise for those looking to enforce some sort of collaboration, but in the
    end the thing that incentivizes organizations to give back is whether or not the
    software is both a) better than they can maintain themselves and b) continues
    forward at a pace that they can’t keep up with.

    In my opinion, a good data transport specification is both pieces — a document
    and an implementation. You can have one without the other, but both together
    can help ensure a long-standing level playing field and provide an arena for
    constructive competition in your industry. The choice of software license isn’t
    as important as the specification committee blessing an implementation and
    providing for a validation suite to test whether or not independent implementations
    conform to the specification. The implementation is what ultimately determines
    whose interpretations of the specification are correct, and the committee should
    do all that it can to help ensure that its intent is understood and followed.

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.