Hacker News Reader

Comment by andrewstuart2 | Hacker News Reader

It seems like they've cut a wide swath for (probably) exempting the most interesting of the software that could have been developed in the open.

> Applicable exceptions are as follows:

> The release of the item is restricted by another statute or regulation, such as the Export Administration Regulations, the International Traffic in Arms Regulation, or the laws and regulations governing classified information;

> The release of the item would compromise national security, confidentiality, or individual privacy;

> The release of the item would create an identifiable risk to the stability, security, or integrity of the agency’s systems or personnel;

> The release of the item would compromise agency mission, programs, or operations; or

> The CIO believes it is in the national interest to exempt publicly releasing the work.

[1] https://sourcecode.cio.gov/Implementation/

View on HN

The important thing is that this changes the default. Instead of the default being closed and needing to justify open-sourcing something, the default will be to open-source things and having to justify keeping something closed. That's huge.

It pushes the incentives around as well, though. Unless there's some sort of marginal cost for each line of code they choose to keep proprietary, they'll inevitably do "the least work necessary" when they realize that some project is going to have components fitting these clauses, by by boxing up the entire effort under one of these clauses.

Ideally, with some sort of force opposing propriety, the incentive would be such that the government would think it in its best interests to granularize their code into small libraries, programs, and network services, so that they could open-source as much as possible, leaving tiny "classified kernels" as wrappers for libraries or plugins for apps.

For an idea of such a force: maybe create a "proriety credit" that a government department would to buy for each 1000 lines of code they refuse to release, whose funding goes to this effort to open-source everything else?

LOC-based metric tied to money... What could go wrong?

An overabundance of semicolons per line? A complete abandonment of python?

One-liners that would kill Perl masters by heart attacks half from envy, half from horror

I was using LOC as a hand-wave-y abstraction; substitute something like "total AST-node information-theoretic entropy measured via compressed size of language-canonicalized source" if you want to be picky.

This is great thinking on this matter, much better than the blunt instrument we're looking at currently.

I still kinda think the blunt instrument is an improvement over the status quo, but it's hard to say.

That looks like PACER still falls under that.

I wonder if this would make it easier to build a replacement whose interface isn't utterly terrible. Of course, the hard part would be convincing the courts to use it. Based on a sample size of one Clerk of Court, who thinks PACER is absolutely fantastic, this will be hard. To be fair, it is state-of-the-art in terms of access to court documents in the US.

Could you imagine an API-only version of PACER where developers were free to build search, mobile, other front-ends on of it? Sure, that's basically a high school project using a MongoDB or CouchDB back-end. But legal tech is horribly antiquated and govt-legal tech has a long way to go. It seems like the best move would be API-only so that individuals and companies could build services on top.

BTW - check out www.casetext.com for an idea of what private enterprise can do in terms of making public records useful.

Different branch, though. This policy only covers certain executive branch agencies.

Of course there are many exemptions. Did you expect them to release the F-22 source code or NSA PRISM architecture?

Operational stuff no, but GCHQ publish their graph database for example: https://github.com/GovernmentCommunicationsHeadquarters/Gaff...

Of course not. That's why encryption algorithms are always best kept proprietary. /sarcasm.

Sure it's wide, but it also seems pretty reasonable to me

My main disappointment is that I'm not sure it will be reasonably applied, as so many things could be interpreted as having national security implications when in reality they're only used with security-sensitive data.

Or alternately, every system that handles private information (which, for a government, is basically all of them) will be considered to be a security risk to open-source even though the dataset will still be private.

"Security through obscurity" will mean that nothing gets opened.

I agree with your comment, but I think it will be easier to pass this right now with some wide exemptions and potentially expand it somewhere down the line.

The first two look reasonable, but after that it goes downhill. "The release of the item would create an identifiable risk to the stability, security, or integrity of the agency’s systems or personnel" means "I don't feel like it and you can't make me."

I'm probably misreading it, but "the integrity of the agency's personnel" makes it sound like "the in-house developers wrote terrible code and people will criticize them for it".

Or the stability. Open sourcing certain code may literally lead to insanity! I think this was just poorly word-smithed and the "correct" interpretation would only apply the protection of security to personnel.

I believe the correct parse is:

                             / (the stability, security, or integrity of the agency’s systems)
  (an identifiable risk to) < (or)
                             \ (personnel)

This probably excludes pretty much everything except probably the most boring things - public information websites, etc. Anything within the DoD, for instance, will at minimum be tagged "for official use only", which already exempts it from FOIA requests, so I don't see this really opening much up at all.

DoD work can, in at least some cases, be open-sourced. We had some work with DARPA where open-sourcing was actually mandated in our contract (at our request), and that code was, for a while at least, in active use in the field. Although I guess research is a little different.

Whether or not it's feasible is entirely dependent on the project, though. Something that's ITAR/EAR (or classified) is never going to be open-sourced.

So they commit to nothing at all.

This doesn't include anything developed at DARPA, right?

Lots of DARPA sponsored projects have open source releases.

Reply on news.ycombinator.com