- ASTM E57.04 is debating the type of open source license that we should adopt.
- One will require that all work be shared, the other will not.
- 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?
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.