{"action":"created","issue":{"url":"https://api.github.com/repos/deptofdefense/code.mil/issues/117","repository_url":"https://api.github.com/repos/deptofdefense/code.mil","labels_url":"https://api.github.com/repos/deptofdefense/code.mil/issues/117/labels{/name}","comments_url":"https://api.github.com/repos/deptofdefense/code.mil/issues/117/comments","events_url":"https://api.github.com/repos/deptofdefense/code.mil/issues/117/events","html_url":"https://github.com/deptofdefense/code.mil/issues/117","id":214266867,"number":117,"title":"DCO requirement","user":{"login":"brlcad","id":940391,"avatar_url":"https://avatars0.githubusercontent.com/u/940391?v=4","gravatar_id":"","url":"https://api.github.com/users/brlcad","html_url":"https://github.com/brlcad","followers_url":"https://api.github.com/users/brlcad/followers","following_url":"https://api.github.com/users/brlcad/following{/other_user}","gists_url":"https://api.github.com/users/brlcad/gists{/gist_id}","starred_url":"https://api.github.com/users/brlcad/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/brlcad/subscriptions","organizations_url":"https://api.github.com/users/brlcad/orgs","repos_url":"https://api.github.com/users/brlcad/repos","events_url":"https://api.github.com/users/brlcad/events{/privacy}","received_events_url":"https://api.github.com/users/brlcad/received_events","type":"User","site_admin":false},"labels":[{"id":680893558,"url":"https://api.github.com/repos/deptofdefense/code.mil/labels/policy","name":"policy","color":"fbca04","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":15,"created_at":"2017-03-15T02:49:05Z","updated_at":"2017-09-06T04:37:06Z","closed_at":null,"author_association":"NONE","body":"This issue was discussed on the MIL-OSS mailing list and partially resolved already, but reiterating here as an issue for public comment.  The issue raised: requiring a DCO is legally unproven as necessary, complicated for non-git repositories, and will likely reduce open source effectiveness.\r\n\r\nFrom an acquisitions standpoint, the last point imposes the highest risk as community engagement will be reduced.  How much will depend on many factors that cannot be (easily) measured but the impact can only be negative as a DCO is a barrier to contributions.\r\n\r\nThere is an argument that DCOs are in common use.  In response to that substantiated claim, I would posit that DCOs are almost universally imposed by projects with substantial existing communities (often with large corporate sponsorship), not your average open source project.  Moreover, none started with DCOs as is being proposed here, which could ultimately result in open source project failure (as in no community, no adoption, no growth).\r\n\r\nBarriers to contribution can result in non-thriving open source, one-way code dumps that are de-facto DOA.  That single restriction alone could stop projects from gaining any traction, thus defeating the goals of accelerating acquisitions, improving technology at reduced cost, and establishing relations with the public.\r\n\r\nI would submit that project creators should have the right to decide the appropriate social risk based on the nature and goals of their code.  A project intended to be a one-way code dump or a large collaboration involving many contractors may have no problems requiring DCOs whereas a smaller new project hoping to build a vibrant community may need to wait until there is one established before re-assessing their overall risks.\r\n\r\nDCOs should not be required until there is clear evidence of need and all risks are taken into consideration.  This is critically important as there are not just legal risks, but significant risks to participation, community engagement, and acquisition."},"comment":{"url":"https://api.github.com/repos/deptofdefense/code.mil/issues/comments/327372235","html_url":"https://github.com/deptofdefense/code.mil/issues/117#issuecomment-327372235","issue_url":"https://api.github.com/repos/deptofdefense/code.mil/issues/117","id":327372235,"user":{"login":"brlcad","id":940391,"avatar_url":"https://avatars0.githubusercontent.com/u/940391?v=4","gravatar_id":"","url":"https://api.github.com/users/brlcad","html_url":"https://github.com/brlcad","followers_url":"https://api.github.com/users/brlcad/followers","following_url":"https://api.github.com/users/brlcad/following{/other_user}","gists_url":"https://api.github.com/users/brlcad/gists{/gist_id}","starred_url":"https://api.github.com/users/brlcad/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/brlcad/subscriptions","organizations_url":"https://api.github.com/users/brlcad/orgs","repos_url":"https://api.github.com/users/brlcad/repos","events_url":"https://api.github.com/users/brlcad/events{/privacy}","received_events_url":"https://api.github.com/users/brlcad/received_events","type":"User","site_admin":false},"created_at":"2017-09-06T04:37:06Z","updated_at":"2017-09-06T04:37:06Z","author_association":"NONE","body":"I guess I should have expected this after taking the bait... ;)  I hope to get too far off topic @nigelht, as it distracts from the important DCO point, but I know there was not consensus on NOSA 2 *approval* though a majority did agree it was better.  That said, I also don't think it's nearly as relevant today given all the discussions prompted by different approaches: by ARL's open source policy, the federal code.gov platform, and code.mil's legal framing.\r\n\r\nThe issue with patents is an important one that I think is one of the most important contemporary topics that OSI needs to address and hasn't yet.  Some feel that corner of IP has no bearing on the OSD.  I wholeheartedly disagree though, as I've encountered numerous codes that are completely useless (in open source terms) because the authors patented it.  When a contributor/author does not divest themselves of patent rights they hold, I see that fundamentally violating several OSD clauses.\r\n\r\nI believe all IP rights come to bear on being Open Source or, more broadly, on a recipients ability to inspect and use source code in a meaningful unbiased manner.  ARL's policy takes a specific approach (see the IEC review board section) and, for better or worse, IS their answer to all of the questions stated.\r\n\r\nIn my opinion, licenses that take a position on patents put recipients in a far stronger position of mutual understanding than DCOs.  As such, licensing that has contributors grant a royalty-free patent license (like Apache 2 or ECL 2) or pledge away IP interests beyond the stated terms (e.g., ARL's approach) are good because they demand OSD acceptance by all parties to the agreement, recipients and authors.  Sure it's \"safer\" to not divest oneself of patent rights, but then so is not releasing the code.\r\n\r\nFor agencies, the objective should be accelerating acquisitions and building open source community rapport.  Not addressing patent interests in some manner is a minefield. "}}
{"actor":{"display_login":"brlcad"}}