[Geo4All] for and against use of code with both FLOSS and payware versions

[Tom Roche]

[endnotes after .sig]

summary: Geo4All and other OSGeo codebases should decide to use, extend, or depend upon external code based upon the quality of that code and its license. Arguments have been made on this list (unfortunately mostly in multiple, orthogonal threads) to reject external code simply because that code was developed by a for-profit entity which also provides for-profit extensions. Such arguments are flawed empirically and deductively, though more systematic examination of the empirical case should be made. Instead, decisions regarding adoption and dependency of a codebase should be made on the quality of the codebase (including, e.g., comprehensibility, commenting, and documentation) and its licensure.

details:

This is a legitimate discussion which should be moved to its own thread, rather than have it repeatedly seep into orthogonal threads like 'Ideas invited from "Geo for All" community for Global Week to help demonstrate and raise awareness of "geo" in education at UNESCO'. The discussion has focused on a particular codebase, but often makes general claims. Since I seek to examine the latter, I will discard the particular names and use the following variable names. The general claims regard code that is simultaneously

* developed by a for-profit entity D

* which is itself FLOSS, hence I will refer with the name 'P_floss'

* ... but which has payware extensions, to which I will refer with the name 'P_pay'

The case has repeatedly been made that Geo4All should not base or depend upon any such P_floss because

A1. P_floss will always be inferior to P_pay ; at least, P_floss will not be 'the very best'[1].

A2. P_floss is likely subject to abandonment by D[2].

Both these arguments (A1 and A2) are seriously flawed, as most of us--at least, those of us who are Linux users--know from daily experience. (Given that this list concerns a branch of scientific computing, and that most scientific computing is done at least on the "server side" on Linux, I will assume that most listizens are also Linux users, with some knowledge of the following claims.)

The vast majority of Linux installations worldwide are based on two branches: Debian and Red Hat[3]. While Debian itself is completely free, the vast majority of its users run code distributed (and significantly written by) Canonical, i.e., Ubuntu. Canonical and Red Hat are both for-profit, funding their operations (including providing FLOSS code[4]) with commercial services, including providing code with payware extensions[5].

If A1 were true, the majority of Linux users should for years have suffered from functional deficit. Having thus suffered, one would expect the vast majority of them to have migrated to fully-FLOSS alternatives like Debian, which is not produced by a for-profit entity, and does not provide a payware extension. Yet the vast majority continue to freely use P_floss from Canonical and Red Hat. Supporters of A1 should be prepared to explain how A1 is compatible with that fact; I suspect they cannot, but ICBW.

Note

1. I am *not* arguing that there are *no* cases in which a for-profit provides inferior "crippleware" in addition to its payware. I *am* arguing that the claim that P_floss is *inevitably* crippled compared to P_pay is empirically false. Particularly, in what appears to me to be the largest cases of for-profits providing both FLOSS and payware extensions, that this experience has *not* been harmful as claimed by A1.

2. I would be very suspicious of depending on code provided by *some* for-profits, depending on their histories. One particular 4-letter acronym comes to mind, given its attempted strangulation-at-birth of US GIS FLOSS. That being said, if the code and its license is good, adopt.

3. I am not thrilled with the empiricality of my rebuttal: I would prefer to cite a systematic examination of a large number of cases where a for-profit provides both FLOSS and a payware extension. But I am not aware of even one such study; if *you* are, please pass pointers.

A2 is similarly flawed, but this time both deductively and empirically. Again, empirically, in the above very large usecases: Canonical has been in business since 2004 and Red Hat since 1993, yet there appears to have been no abandonware. More importantly, whether or not the for-profit abandons its code is not important: as long as the code is originally released under a sufficiently robust license, it can be picked up by its community, as in the notable case of LibreOffice[6]

Finally, a quick "spike" of objections that may be raised regarding Linux. The point is occasionally made (by the unwise :-) that the development of Linux itself is "fully free," and that derivatives like those provided by Canonical and Red Hat are somehow therefore irrelevant, and that all projects should strive for the "full freedom" of Linux, not its derivatives. The problems with this line of argument are multiple, including

1. Development of Linux has been mostly corporate-supported for many years; in fact, for most of its existence, the majority of contributed LOCs have come not merely from corporate employees, but from those whose job it is to contribute to Linux.

2. It has for most of Linux history been difficult--and is today probably impossible--for a user to "adopt Linux" rather than some distribution. Over that period, usage of Linux distros which are P_floss as defined above (i.e., developed by D with payware extensions P_pay) has vastly exceeded usage of those that are not.

HTH, Tom Roche <Tom_Roche at pobox.com>

[1]: https://lists.osgeo.org/pipermail/geoforall/2016-September/003181.html
[2]: Unfortunately I don't have an archive cite for this, but I seem to remember the claim being made. Apologies if not. The OSGeo lists are unfortunately not particularly searchable, and my websearches on 'site:lists.osgeo.org Cesium' etc were unconclusive.
[3]: full disclosure: I am writing from a workstation using LMDE, a Debian derivative, and have mostly worked on clusters running some version of Red Hat Enterprise Linux (RHEL).
[4]: Canonical provides Ubuntu as FLOSS. RedHat sponsors Fedora and is affiliated with CentOS; both are FLOSS.
[5]: Red Hat pioneered this model with RHEL and Red Hat Network (RHN); the latter has evolved into several managed services. Canonical similarly has provided Ubuntu Advantage and more recently Landscape, which is more fully RHN-like.
[6]: https://en.wikipedia.org/wiki/LibreOffice#History