Really they are only open-sourcing GovDelivery. There's a lot of questionable code in there. Is this really how you'd do this?
// the user may have put in an address of the form "Full Name" <email@domain.tld> instead of just the address,
// so we want to filter to the right address
function govdelivery_filter_email($address) {
// borrowed from the drupal valid_email_address($mail) function
$user = '[a-zA-Z0-9_\-\.\+\^!#\$%&*+\/\=\?\`\|\{\}~\']+';
$domain = '(?:(?:[a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9])\.?)+';
$ipv4 = '[0-9]{1,3}(\.[0-9]{1,3}){3}';
$ipv6 = '[0-9a-fA-F]{1,4}(\:[0-9a-fA-F]{1,4}){7}';
// setup an array for the matching expression
$matches = array();
// the regex below is adapted from drupal's valid_email_address($mail) function
preg_match("/$user@($domain|(\[($ipv4|$ipv6)\]))/", $address, $matches);
return $matches[0];
}
The module uses MySQL-specific functions (FROM_DAYS, TO_DAYS, FROM_UNIXTIME) so it is not portable. Relying on these instead of the PHP equivalent makes me wonder how many other shortcuts are in there.
Several undefined constants are referenced (NAGIOS_STATUS_*).
I'm not sure what's going on in odmService.php.
The module was authored by Chris D'Antonio of Acquia (which we can assume has a contract with Uncle Sam), aka http://drupal.org/user/250704
If you use Drupal much at all, you'll find that, while the core is cross-database, 90% of contributed modules are MySQL-only. It's what you get when you don't provide an ORM, I guess.
Internal code is always very specific to the platform upon which it's installed. It's hard to justify spending time to make software run in environments you're not using.
Now, there's a school of thought which holds that you shouldn't open-source something without going through and auditing it for local-isms. There's another that holds that it's better to get the software out there.
I'm not sure into which of those schools I fall personally, but if getting this stuff open-sourced was a bottom-up effort, it'd be hard to get the higher-ups to say 'yes' and then immediately ask them to invest a ton of developer time on the process.
>Internal code is always very specific to the platform upon which it's installed. It's hard to justify spending time to make software run in environments you're not using.
I'm having a lot of fun with that right now, knowing that we're doing a migration in the next year or so, but not having a clear path to write my code so it will carry over to the new platform.
Of course, we still don't have nailed down what that platform will be, but so it goes. It's just painful to write code you know will be obsolete inside of a year.
But your criticisms primarily address portability and well-packagedness which was probably not an original design requirement. Now that it is open source it may be an issue, but is it a valid target issue for tax dollars?
I believe this is an appropriate point for the community to step in.
These aren't worthless modules either; they all address needs that core Drupal lacks. Node Embed particularly sounds useful to me.
It's a minor nit to pick, but I believe the majority of this was done pre-election, and hence, paid for out of campaign dollars. That isn't to say that some of us didn't pay for it, but the initial development of these plugins was almost certainly not done with taxpayer money.
If you're ever in the DC area, I'll be more than happy to depress you with all of the ways in which taxpayer money is all but thrown away by the millions, but in this particular instance, I think we're okay.
I wonder if source code can be requested under the Freedom of Information Act. The act only applies to the executive branch but that's still probably a lot of software.
This varies widely but our website code is definitely owned by NASA - they even run the version control system to make sure that other contractors don't "forget" to give it to them.
Many times, those pieces of software integrate with commercial third party components. In most of those cases, the government produced software is basically just glue to bind together lots of libraries.
Under section 105 of the US Copyright Act, works produced by the US government are not entitled to domestic copyright protection and are therefore, essentially, public domain.
IANAL but we've been down this road with the license on the White House flickr feed.
Apparently this does not apply to contractors - which I find rather inconsistent.
If the contractor clause is not applicable to this work even releasing it under the GPL is questionable, because that's most decidedly not the same as releasing it to the public domain.
I'm not sure they have the choice about whether or not to GPL it. They are building on GPL'd code, which means their code must be GPL'd. Perhaps there's a formal way to say, "we won't go after you if you use our code against the terms of the GPL, but we can't control what Drupal does".
> Under section 105 of the US Copyright Act, works produced by the US government are not entitled to domestic copyright protection and are therefore, essentially, public domain.
What if the works are derivative of works licensed under the GPL?
I'm not surprised. All third-party content on whitehouse.gov has been under a Creative Commons licence since Obama took office: http://www.whitehouse.gov/copyright
* Akamai Integration: http://drupal.org/project/akamai
* Context HTTP Headers: http://drupal.org/project/context_http_headers
* Node Embed: http://drupal.org/project/node_embed
* GovDelivery: http://drupal.org/project/govdelivery
All released under the GPLv2.