April 19, 2007 by jimstogdill
Open Technology IV – GGL vs. GPLR
A while back I suggested the idea of using a modified version of the GPL to support enterprise-spanning DoD or government projects in gated communities. I realize that this would, at first glance at least, be anathema to the majority of the Free Software Foundation members, but my goal is to bring the GPL ethos to the DoD and better serve the taxpayer by eliminating reprobate Primezilla-like behaviors. I call it GGL; Government General License (maybe it should be GGGL; Gated Government General License – but that doesn’t sound as good).
When I try to explain GGL (and the parent idea of GLOSS – government licensed open source software) to people in the government space they frequently ask me “Why do we need that? We already have Government Purpose License Rights.” Which leads me to this comparison of GPLR and GGL.
First off, GPLR is useless; and here is why… GPLR gives the government the right under certain circumstances to transfer source code from one contractor to another; but it is easily subverted by…
– a contractor builds some of the source on their own dime and thus gains muddy proprietary rights over some (who knows which part?) of the code base.
– a contractor negotiates a contract that precludes GPLR on some or all of the source; which gets muddy over time.
– a contractor brings their own IP in at the beginning of a new product, mixes it liberally with the source they write under the contract, and voila, who knows which part is proprietary and which part is GPLR?
– the government has a “favorite contractor” or is dealing with its own inter-Service political issues and simply refuses the request to transfer source.
– a potential innovator that desires access to the source isn’t yet under contract to do anything with the source, and therefore isn’t permitted to receive it (for example during the competitive phase of a contract that they haven’t yet won).
– the government and the originating contractor agrees to turn over the source under GPLR rights, but the process takes so long that the source turned over has been effectively superceded by the time it is turned over.
The reality of GPLR is that it doesn’t faciliate the easy transfer of source between tax-payer funded programs that should have access to the same IP; and it virtually guarantees forking when it does transfer it.
In fact, our company was recently working two programs for the same military service. The two programs had an obvious synergy, used many of the same core technologies, and would benefit from sharing infrastructure from one program with the other. Both programs were with the same customer organization and were being developed by the same small group within our firm. Even in those circumstances, a situation completely devoid of competitive issues, it took six months to get permission from the government to transfer source between the two programs! (And… the decision to permit the source to be transferred between programs left murky the question of joint program configuration management; it implied the code would unreasonably be forked).
So, what about GGL?
Like GPL, GGL is envisioned to support “Copyleft“. However, it would add the ability to scope distribution within a defined gated community; where the community was defined as broadly as possible, but no more broadly (for example… a critical defense technology may be distributed to any contractor working in that domain, but not to foreign powers). These distribution gating mechanisms may not be able to be addressed strictly through copyright, and thus may require GPR-like contractual treatment to define and enforce. What I mean by this is that GGL might be implemented through a hybrid combination of copyright licensing and DoD-wide standard contractual clauses.
The cool thing about GGL when compared to GPR is that it will take the government out of the middleman role and will support the ability to develop true collaborative communities. A contractor developing software under a GGL license model would be obligated to share source with any other contractor (or person) who satisfied the community scope attributes; and may also define the tools and collaboration mechanisms that are required to support the community. So in the case I mentioned above, all that would have been required to transfer the source from one program to another would be a quick verification that the receiving program was “in the community.”
I envision a day when broad classes of software within the DoD (particularly reusable DoD-specific infrastructure stack) are developed and licensed within well understood gated community types for broad re-use and collaborative development.
GGL doesn’t address the fundamental incentives required to get contractors to participate in GLOSS development, but I believe wide use of GGL contractual terms (e.g. everywhere that you would currently expect to find GPR terms) and wide use of GGL licensed source would facilitate a great degree of collaboration when and where the right incentives are put in place.