search

18F / open-source-policy

This repository contains the official Open Source Policy of 18F
https://18f.gsa.gov
Other
300 stars 94 forks source link

Finalizing our source code policy #6

Closed konklone closed 10 years ago

konklone commented 10 years ago

This takes @rjmajma's work on his fork, moves it into an 18F branch, and clears up some mis-synced commits. The best way to view this PR is by using GitHub's prose rendering, here:

https://github.com/18F/source-code-policy/pull/6/files?short_path=f00382f#diff-f00382fe8760019c2c7bdf002ff40131

Let's use this PR to finalize the policy. Let's discuss proposed changes on this thread. You can also comment line-by-line on the diff, if that's your style.

As they are agreed to, anyone with write privileges on this repo can push more commits to the raph-finalizing branch, which will automatically update this PR.

When this PR is merged, let's consider the source code policy ready for blogging-about, and ready for linking-to. We should be proud of it. But let's not consider it "done" forever -- further issues and PRs should be welcome, from both inside and outside 18F.

konklone commented 10 years ago

There are two exceptions added for open sourcing code:

  • If open-sourcing the code or opening its development will result in privacy violations or security vulnerabilities.

If we structure our work properly, this should never be the case. The closest thing would be where it's helpful to version private configuration files, that may contain passwords, keys, etc. But that's not source code, and should be managed separately from project code.

As for privacy violations, I'm not sure where that would come into play.

  • There is an overwhelming business need to not publish original or modified source code.

Can you help me understand what this is for? As written, it feels like too much of a catch-all.

konklone commented 10 years ago

One other thing - you've removed the line about requiring contractors to publish their work as OSS/public domain, but appear to implicitly do so here: "Code written entirely by 18F staff, and by contractors who are developing software on behalf of 18F, are within the public domain."

I'd like to make this more explicit. Got a :+1: from you on that in a different channel, so I'll plan to take a pass at that.

konklone commented 10 years ago

I just made two updates to this PR:

NoahKunin commented 10 years ago

Believe strongly that we remove that 4th bullet point about "overwhelming business need". There's no way to formally evaluate something like that.

"Privacy violations and security vulnerabilities" is both sufficiently comprehensive and specific enough for our current purposes. Remember, that line applies not just to our customers in the public sphere, but our federal clients as well. Business need is way too general. If the client isn't ready for the project, even under a code name, to be known in the public, it's also quite likely they're not ready to work with 18F methodology.

jpyuda commented 10 years ago

Pulling out one of my line comments since additional pushes to the PR have hidden them.

I think some of the issue with the "overwhelming business need" line is that the language is aiming for clarity (and in general I'm a fan of clarity), because precision would be very convoluted.

One example of what might be an "overwhelming business need" -- at CFPB, there was a long debate about whether or not algorithms used to look for fair lending violations should be published. In almost all of these instances, there can be arguments both ways -- so it really has to be case-by-case in close collaboration with the client.

How do we capture language that says this kind of thing will be rare, and require considerable need? The word "overwhelming" is, at least, a good start.

konklone commented 10 years ago

If we were to come up against a specific exceptional circumstance that suggested we should not open source certain things, then I would describe the exception as that: "exceptional circumstances", and I would expect that the fact and reason for the exceptional circumstances would be discussed publicly somewhere.

I don't know if that actually merits a described exception, but if we were to include one, I'd want it to read something like "Other rare, exceptional circumstances, and where the reasons for doing so are publicly available."

I also feel that "the rare exception that we'll tell you about" is implicit in all policies like this, and doesn't merit an explicit line item that we'll never write quite right and could be used by our clients to justify whatever they wanted if they felt strongly enough.

NoahKunin commented 10 years ago

@jpyuda Yep, the fair lending thing is the exact thing I was thinking of. But to me, that's still a privacy issue. The questions we would ask to determine whether or not some data element should be private and not released is the same sort of analysis we would follow, but it's the privacy of the agency's data at question, as opposed to the data of the public.

I think we actually can create a formal and specific evaluation for this issue, so I'd love to leave out "business need" until we create that. I'll try to join the call later this week and speak directly to this issue.

konklone commented 10 years ago

And @NoahKunin, a few of us met this morning and talked through some of it -- this commit by @jpyuda is the result of it. More on the call (or this thread, of course).

NoahKunin commented 10 years ago

Well hey, works for me!

To be even more tactical, we should probably look to fork the CFPB OSS checklist.

On Tue, Jun 3, 2014 at 1:21 PM, Eric Mill notifications@github.com wrote:

And @NoahKunin https://github.com/NoahKunin, a few of us met this morning and talked through some of it -- https://github.com/18F/open-source-policy/commit/ab720c2267f9ac306361b697c1104c13f2abb469?short_path=7e05e2d#diff-7e05e2dc1a051a7606f1d6f0365f8313 by @jpyuda https://github.com/jpyuda is the result of it. More on the call (or this thread, of course).

— Reply to this email directly or view it on GitHub https://github.com/18F/open-source-policy/pull/6#issuecomment-44994146.

Noah Kunin - Delivery Architect @noahkunin http://twitter.com/noahkunin | @18f https://twitter.com/18F

konklone commented 10 years ago

From the meeting, some further (non-substantive) changes -

konklone commented 10 years ago

There's been a small raft of rewords by @rjmajma, @leahbannon, and myself, and we are good to go. If anybody has any :warning: then ring in, but this version is what we're going to send over to comms and prepare to talk about.

Thanks to everyone for their help! Especially @noahkunin @quepol @arowla @jpyuda for edits, and everyone else who participated offline.

:us: :+1: