DCO requirement

[brlcad]

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.

From 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.

There 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).

Barriers 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.

I 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.

DCOs 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.

[marctjones]

I disagree with @brlcad. I think the risks of not clarifying the licensing of contributions is always present because of how our copyright law works. If you do not have a license to modify or distribute a copyrighted work you are committing copyright infringement. Like it or not that is the legal regime we are under. This is the reason why the community celebrated when GitHub took steps to encourage people when creating new projects to include a licensing policy. There was so much "open source" code that was not licensed, so it definitely was not free software, even though the code was "open." The DCO helps ensure that every contributor is checking to make sure that every contribution has license attached to it.

Unfortunately disputes about licensing arise even in community projects. Including a licensing policy in your contributor policy helps avoid the disputes. Contributor policies are meant to help projects, but they do raise the barrier to contribution. It asks each contributor to participate in the keeping the licensing status of the project healthy. Projects often ask contributors to do more then just write code to help the health of the project. For example having a style policy raises the effort required to contribute to projects, even though by definition style does not have a functional purpose. Nevertheless many projects, including community projects, vigorously enforce style requirement for contributions because it makes the project easier to maintain in the long run.

Asking contributors to check that their contribution is compatible with the project distributes the licensing responsibilities to the project community. It seems more community friendly then asking one lonely project maintainer to have to do spend hundreds of hours of research later when a problem arises.

Asking contributors to clearly assert that their contribution is either licensed under the project's license, or that they checked and the contribution is licensed under a license compatible with the project, helps to avoid needless fights later about the licensing status of contributions. I can think of at least three three ways that even community projects benefit:

1. If the contributor is the copyright holder, it makes clear that the project has a right to use the contribution under a compatible license. (ex: stops someone from claiming that their contribution was never intended to be used under a permissive license and is now demanding the whole project relicense to their favorite copyleft license.)

2. It helps make the project's licensing overall be clear, so that what should be a friendly fork cannot be stopped because someone casts doubts about the licensing of some portion of the contribution. This happens even in community projects and sometimes comes from former maintainers who are not happy that someone is taking their project in a different direction (Or just because we are all people and sometimes we get angry and lash out.)

3. Draws contributor's attention to the licensing of the contribution they are about to submit, so they take a pause and reflect on the licenses of any third party libraries they may have used. The idea being that by affirmatively asking contributors to state the license of their contribution that they will think about the license of the contribution. By being conscious of the licenses in their contribution the hope is that it is that it is less likely contributors will inadvertently submit a contribution that uses CDDL code to a project that is GPL licensed.

Yes the act of putting in a commit statement "signed off by" does require a little bit more typing, but no more work then making sure that you only used 4 spaces for all of your indents, never used a tab and definitely didn't indent with 5 spaces somewhere in your contribution. Asking contributors to be aware of the licensing status of their contribution could involve a lot of work, but the risk to a project is significant if incompatible licensed code gets submitted, becomes tightly integrated, and is not noticed until later when a dispute arises.

I do not see the relationship between DCO's and code dumps. I agree if the DOD is going to release a project as FOSS, the community and the DOD are better served by the DOD developing a community and accepting contributions rather then just dumping the code on GitHub. But hey if they want to dump the code, great! Maybe someone else will fork it and build on it. On the other side I do not think there is anything wrong with a random drive by contribution by a developer who sees an issue, submits a patch, and moves on. That seems like one of the great strengths of FOSS. I think the DCO encourages that because it is easier for the project maintainers to know that the contributor intended the contribution to be licensed under the project's license.

But perhaps I am missing what the significant barrier some people believe that the DCO presents. Is is something more then the typing of the sign off or asking people to assert that they confirmed that the license of their contribution is compatible with the project?

But nevertheless I think @brlcad is right. Different projects should be able to take different approaches. I think it is entirely reasonable for this project to decide that like many carefully organized community projects (and yes many commercially backed projects) to recommend projects adopting its framework use a DCO. There are I think some circumstances where CLAs, CAAs, DCOs, and even contributor policies are not necessary or advisable, but this project seems to be contemplating situations where they are helpful. Not all projects need to meet everyone's needs or desires. If someone is ideologically opposed to even DCOs then this project is not for them. Just like if someone is predisposed to wanting a CLA or assignment, then this project is not for them.

But requiring a DCO is in line with community practices, even if there is a diversity of practices in the community. For that reason I would suggest that this is not an issue that needs to be "fixed." Perhaps one to be discussed but as @brlcad suggested perhaps the best place to discuss it is a community discussion forum like MIL-OSS instead of trapped in a project issue. And actually it sounds like the discussion has already taken place. Maybe a link to the thread in the MIL-OSS list would be helpful so the project maintainers can read it over if they are interested and were not already aware of the MIL-OSS discussion.

(This is not legal advice. This is my own view and not the view of my employer. And FYI I am not a particularly big proponent of the DCO, but I obviously see the merits of it.)

[brlcad]

I wasn't necessarily arguing the value of DCOs as there certainly can be disputes and uncertainty that they address. The three claims I don't necessarily see addressed in your detailed and thoughtful reply @marctjones is whether 1) DCOs are actually legally proven, 2) that the present additional burden for non-git repositories, and 3) that open source effectiveness (from an acquisitions standpoint) will be reduced.

As far as I know, there is no case law supporting or disputing DCO utility per point (1). There is widespread speculation it could help, it might reduce risk, and it has other documentation benefits (which you elaborate). However, on the legal perspective, there is also industry standard practice -- that one assents at a project's licensing when contributing implicitly, and that is de-facto established by hundreds of thousands of OSS projects. There is, to my knowledge, no case law refuting that either so to do this for legal reasons is simply an untested attempt at reducing a risk not yet realized.

One can certainly argue as you have @marctjones that the technical burden isn't significant. I don't disagree for git. I'm not even sure whether it's "significant" for non-git repos as per point (2), but it is undeniably "additional burden" and that should be considered, in my humble opinion, per social impact (not just legal merit). However insignificant, it is technically non-zero effort regardless that can only result in point (3). I don't think anyone would argue that requiring DCOs will increase participation...

Perhaps anecdotal, but I know many notable developers in the OSS community that have vehemently declared they will never sign a CLA or DCO as a matter of principle. They certainly have their reasons, but the reduction in OSS participation does present a reduction in effectiveness. How significant that is will almost certainly depend on the nature of the project in question, the community (if any) that exists, the utility of the code, etc. Point (3) is that barrier greatly puts your average mildly useful unknown new DoD OSS project at significant risk if imposed as a requirement universally.

[BrandonBouier]

@brlcad I think the DCO is a rather unobtrusive and pragmatic approach, speaking as both a developer & government employee. I agree with virtually everything @marctjones said above. Since we're being anecdotal, I also know notable developers in the OSS community, & they would have no issue signing a DCO (a CLA is a different story - part of the reason we've avoided it). We've also spoken to legal counsel in both the DoD & open source communities. We have legal counsel working on this initiative.

That said, I can understand if you're not a fan of the DCO. So my question to you is this: what do you propose instead? What do you think would be a superior solution to the process we're recommending?

[marctjones]

@brlcad great comments! I respectfully disagree (at least I do today, I reserve the right to be whimsical and change my mind later.)

I do not doubt that there are many people in the FOSS community that on principal will not sign a DCO or CLA. Personally I think the decision to sign either is more complicated then being pro or con either. Both are just legal tools to help clarify relationships. Personally I would be more concerned with the relationship that results then the particular legal tool used. At the same time the tool you use matters to the relationship. (How is that for hedging my position).

1 ) A DCO could be a lot of different legal tools depending on what text is in it or what part you are referring to but I think it is unfair to say it is legally unproven. I think it would be common for a DCO to act like a) a license, b) a representation or c) a consent/waiver. They are all recognized concepts in american law and there is a well developed body of law around them.

I think most people who doubt the effectiveness of a DCO are concerned that it is not really a license. Particularly it does not seem to be a license of code in a contribution that was created by a third-party copyright holder. But in that respect it seems to me to make some representations about the third party's code. To the extent that it is a representation it could have legal effect. For instance negligent and fraudulent misrepresentation are recognized as actionable torts in many common law jurisdictions. I would hope that the Linux Foundation and the linux maintainers consulted with lawyers when they adopted the DCO to find out what the legal implications are. So I think it is a mistake to assume (as I have seen other commenters suggest) that there is no good reason to assume the DCO is legally effective. While the DCO's text might be novel or "untested", the underlying legal concepts are not novel or untested.

I think there are at least two ways to think about the lack of court cases testing any particular legal document. One you can say well this never went to court so who knows if a court will enforce it or interpreted that way. The other is this never went to court because it is well drafted and clearly defines the relationships between the parties and no one wanted to bring it to court so a judge could tell them "This seems pretty clear to me, I am not sure why you thought you had a case." I would also suggest that in many cases seeking to use legal documents/language that has been to court several times is like asking for language that is so confusing that it requires a third party intermediary so it is bound to head to court again.

The "new" (the last 40 years or so) thing in legal writing is plain language writing. The whole idea that you should draft documents that are comprehensible and unambiguous. Legal documents should clarify the relationship so that the parties can have a productive relationship on the terms they both agreed were acceptable with a minimal amount of friction. Unclear documents do the opposite; they cause confusion about the parties rights and send the parties to court. Court test documents come from parties that had to go to court for some reason.

1-b) Those "implicit" agreements are legally operative, but can cause surprises. You enter into a contract for sale every time you buy groceries at the store. But that implicit contract has hundreds of years of legal development behind it to get to a point where it is mostly fair and easy to transact. Spelling out the relationship in text gives the parties the opportunity to control the relationship they are entering into instead of letting it be defined by what lawyers, judges, and the guy with the bigger stick thinks was "obviously" implicit. This is one reason why even small business have partnership agreements. You don't need any legal documents to create a partnership, but if you don't define it, the law will fill in the relationship agreement implicitly. So you better know if what the law fills in is what you wanted or create your own agreement to define what you want.

We don't have hundreds of years of FOSS licensing case law to rely on so better to be explicit about the relationships you want.

2 ) No idea about the burden on non-git systems. I mostly use git currently. But wouldn't the only problem be if if the version control system makes adding comments hard as part of a commit? If I recall correctly adding a comment/sign off to SVN was easy. I think you could even add a standard signature to it as well so you didn't have to retype it every time. I have heard people say that DCO's are hard for non-git systems a few times, but I am wondering what problem with what version control system they are thinking of. Would love to know the example they have in mind.

But yes, I agree it is definitely an additional burden even if only slight. But for reasons I hope I made clear I think it is a small price to pay for the reward.

3 ) What the heck, I will take the bait and argue that DCOs are just as likely to increase participation as decrease. As you said some developers are very principled about not signing CLAs and DCOs. I think that it is very common for developers to have serious opinions about FOSS licensing. FOSS developers do (and I think should) care about how their code is licensed. DCOs and CLAs help make clear the licensing health of a project. I am willing to bet, just like some developers don't contribute if they need to sign a CLA (myself included on occasion), or if the project does not use their prefered license, that there are developers who won't contribute if the licensing status the project is unclear. Why contribute to a project if you have no idea how your code is going to be licensed or treated by the maintainers? The DCO and CLAs at least make that clear. This is particularly true if a project ends up in public licensing dispute.

(This is not legal advice and I am not your lawyer.)

[marctjones]

@brlcad If you are interested in the implicit relationships of FOSS projects, you might want to check out Pam Chesteks' upcoming talk at LibrePlanet '17, Rock and roll bands and free software projects: A comparative analysis. It looks interesting.

[brlcad]

@BrandonBouier certainly you don't think the existence of non-signers implies the non-existence of signers... at issue is potential non-legal implications making DCOs required. It's making a (legal) risk management decision that is normally in the purview of a project manager who is more aptly suited to consider other (non-legal) risks and implications. Moreover, I intentionally did not claim to be for or against DCOs. Personal preference is irrelevant to a risk and impact assessment. I'm also well aware of the involvement of legal council -- Sharon has been active on the Mil-OSS mailing list and suggested posting this as an issue.

The issue isn't whether DCOs are legally advisable ... legal opinion on explicit vs implicit is exceptionally predictable. At issue are the non-legal pragmatic technical and social impact considerations and the risks they pose to acquisition. Not releasing code is also unobtrusive, pragmatic, and poses the least legal risk, but obviously prevents creation of thriving open source community, thus defeating objectives. DCOs may pose similar (social) risk.

As per solution, it was mentioned already -- DCOs should simply not be required. That doesn't imply they should be disallowed or discouraged. The Gov't PM, per their usual risk assessment purview, should assess impact accordingly based on their objectives, existing community, target audience, etc.

Dr. David Wheeler stated it better than I could in “Using an Open Source Software Approach for Cybersecurity Technology Transition”, November 24, 2015, IDA Paper P-5279. He says “Anything that significantly impedes contributions also risks viability of the whole project and should only be considered with caution.”

Bradley Kuhn of the Software Freedom Conservancy also has a good article on this topic @ https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/ where he notes (amidst bashing CLAs) "most Conservancy projects use the same time-honored and successful mechanism used throughout the 35 year history of the Free Software community. Simply, they publish clearly in their developer documentation and/or other key places (such as mailing list subscription notices) that submissions using the normal means to contribute to the project — such as patches to the mailing list or pull and merge requests — indicate the contributors' assent for inclusion of that software in the canonical version under the project's license."

[brlcad]

@marctjones Love the hedging, and actually mostly agree with your points too. ;)

DCOs were a result of the SCO lawsuits. They were conceived as a way to potentially avoid getting into that situation again. I sincerely doubt they have that effect, but that's mainly because I know the actual developer that committed the code in question that resulted in the lawsuit. The right hand didn't know what the left hand had done and no DCO would have stopped the commits from happening because the a company believed they had rights that they did not have. Of course, it's even more complicated, but

We also don't need to merely consider DCO conceptually, generically, as the DDS framing specifically mentions https://developercertificate.org/. Otherwise, I generally also agree with most of your (1) points too except to note that implicit "can cause surprises" but haven't to date -- at least not with respect to a software lawsuit involving implicit assent. I'd love to hear about cases otherwise, but that is what was meant by saying it's untested. Could there be a misunderstanding with implicit? Perhaps, but it's not happened yet to best knowledge.

There's not hundreds of years of case law, but there are hundreds of thousands of staff-years of implicitly contributed effort that have thus far been without significant issue (again, to my personal knowledge however limited in scope). There's not been a market failure on this issue (that DCOs fix) so why regulate it as a requirement for all? Remember this is about it being required, not preventing DCOs from being used.

I'll think we're now in agreement on (2), I'll take it as I wasn't arguing cost-benefit but that there is a cost to consider. ;)

For (3), I read that as conflating DCOs with having clear contributor or licensing documentation, but they're not one in the same nor do they necessarily go hand-in-hand. A project can require DCOs yet still not give the contributor any indication how it will be licensed or treated by the maintainers. It's a one-way assertion that one willingly contributes something they're legally able to contribute, and doesn't say anything about what the recipient does with it afterwards. In pragmatic terms, that one-way assertion of a DCO (potentially) shifts blame from the organization to the individual (e.g., if they're wrong in their rights assertion). That's why consideration (3) almost certainly has the greatest impact potential on social growth.

[brlcad]

Oh, and thanks for the link to Pam's talk @marctjones -- that does sound interesting!

[nigelht]

I submitted a license for review by the OSI that was copyleft downstream (OSL v2) and permissive upstream (apache 2.0 or later) to achieve having a CLA/DCO as part of the license agreement itself.

https://lists.opensource.org/pipermail/license-review/2016-October/002856.html

This allows folks to provide large code dumps that will be able to incorporate downstream updates and changes without needing a CLA from every contributor.

When or if it can get through the OSI approval process is still TBD but the use case was the distribution of large GOSS projects where the sponsor retains the ability to incorporate changes without needing a CLA or be locked into a copyleft.

The latter is important in as much as there are times where source code should not be shared with downstream users. For example there may be FOUO comments and details (the why we do X vs the how we do X) in otherwise unclassified code where binary distribution (or obfuscated distribution of byte code) is fine but source code isn't. You would be precluded from incorporating any GPL'd (or other copyleft) enhancement if you still wished to distribute without source.

Likewise you would be unable to distribute a project that used proprietary libraries or components and use any GPL enhancements from the community.

@bricad I am less concerned with the viability of an open source community around any specific GOSS project release as much as release of the source code itself. One way code dumps are still useful to the community and it only takes one or two developers with interest to maintain a code base.

I've also been able to refactor code from long dead FOSS projects for reuse on my own projects. Especially for older data formats where documentation is now spotty...any sort of working implementation, even in a different language, is useful.

[marctjones]

@brlcad I had not made the connection with the SCO lawsuits to the DCO, so thank you for pointing that out. I was only vaguely aware of the SCO lawsuits at the time they were taking place (I had coincidentally inherited responsibility as a SysAdmin for a SCO Unix box about that time). I am going to leave aside whether or not the Linux DCO would have prevented the SCO lawsuit because well I don't want to read the pleadings in that case. But I do agree that its origin might be instructive. So I went and tracked down the original email from Linus proposing the DCO.

Yes, you are correct its origin is related to the SCO lawsuit.

But according to Linus the purpose of the DCO is:

So, to avoid these kinds of issues ten years from now, I'm suggesting that we put in more of a process to explicitly document not only where a patch comes from (which we do actually already document pretty well in the changelogs), but the path it came through.

He went on to conclude:

Comments, improvements, ideas? And yes, I know about digital signatures etc, and that is not what this is about. This is not about proving authorship - it's about documenting the process. This does not replace or preclude things like PGP-signed emails, this is documenting how we work, so that we can show people who don't understand the open source process.

So the purpose of the Linux DCO is to document the workflow including the origin of code and how it comes to be incorporated into a project. He also explains the other benefits as well in his original email.

I notice that you reference Kuhn's blog post about CLA's that kind of veers off into DCO's. I did conflate them, and I did it on purpose. As I think he does a little as well (perhaps not as much as me). Because my point is that both CLA's and DCO's are about describing the relationships of the parties to a endevour. As I said before my point being you need to read the terms of the DCO or the CLA to determine if it is a good deal.

And as we both agree point (2) is about a considering the cost and hence implicitly I think considering the benefit.(See what I did there wink wink nudge nudge ) I think making relationships explicit is generally a good idea; but the question is: is it worth the cost of the lawyer? Some deals are too small to be worth spending money on a lawyer to create a bespoke agreement. So we in most transaction all go "well you all know what we mean" and move on, give the store money, take the soda (and get fat.) Of course FOSS is built on not using bespoke agreements. We reduced costs by using templated licenses. But we do not actually rely on implicit licenses, we rely on explicit licenses for a reason.

So following your lead, let's talk about the Linux DCO proposed here. Because here a draftsman has given us explicit terms of an agreement/representation/license for free. The author has stated it's purpose is to document the workflow and origin of code. Sounds pretty reasonable, but does the jive with the FOSS community?

Kuhn's position in the link you provide above is that:

We at Conservancy have spent years doing that analysis; we concluded quite simply: in this regard, all a project and its legal home actually need is a clear statement and/or assent from the contributor that they offer the contribution under the project's known FLOSS license.

Perhaps Kuhn/Conservancy is right about that, perhaps they are not. (In the selfish interest of keeping me and other members of the FOSS legal bar employed, I would suggest if you want legal advice you talk to your lawyer. Because this is not legal advice; I am not your lawyer; and these are my views not the views of my employer.) But isn't that what the DCO does?

Kuhn does go on to say that he thinks many CLA's try to shift liability (and I think he makes many good points), but in that post he is talking about CLA's shifting liability. Even if he were lumping in DCO's under that criticism (which I do not think he is) it still begs the question of is that what this DCO does? You said:

In pragmatic terms, that one-way assertion of a DCO (potentially) shifts blame from the organization to the individual (e.g., if they're wrong in their rights assertion). That's why consideration (3) almost certainly has the greatest impact potential on social growth.

I do not see the DCO shifting liabilities. It is merely making am explicit representation about the providence of the code. Isn't it an implied representation if no statement is made, but as I explained before implied agreements/relationships can come with surprises. Why leave it up to a judge to decide if you did or did not make a representation about patents or under this license or that license?

What language in the DCO do you think shifts liabilities away from were they already lie? I do not see any language in the DCO where the contributor is offering to indemnify the project. Sure the contributor might be held liable, but does the DCO change the theory of liability?

In regard to your response to point (1). You said:

I generally also agree with most of your (1) points too except to note that implicit "can cause surprises" but haven't to date -- at least not with respect to a software lawsuit involving implicit assent.

You may not have personal knowledge of implicit agreements causing problems in the context of free software. But, believe me, they have, big league! ;)

Well maybe I don't have personal knowledge of a "big league" problem. But I do have personal knowledge that misunderstandings about what was implicit has caused problems for free software developers.
But I think the developers involved felt like it was a pretty big problem. It sucks when all you want to is hack on some code and someone comes along as starts talking about suing you or getting into fights about the license of the code.

I am going to decline to speak to specific situations, but I would say just because a document hasn't gone to court doesn't mean it has no legal effect. Courts don't give documents legal effect, the law and the parties' actions do. Courts enforce and interpret the law when a actual dispute arises. Legal documents that don't cause disputes don't typically need to be interpreted by courts. And just because a dispute doesn't go to court or get resolved by a judge, doesn't mean it wasn't a problem. But of course the goal is avoid problems not create them.

Personally I would prefer to state the representation I want to make instead of letting a judge decide later if I did or did not imply one, and if I did imply one what that implied representation did or did not say. So I think Kuhn is on to something when he says projects "actually need ... a clear statement and/or assent from the contributor that they offer the contribution under the project's known FLOSS license." I think that is what the DCO basically does. That is basically what it's original author said it's purpose was.

[jordangov]

Hey folks, I'm going to talk with @shawoods on this one. I am not a lawyer, but active OSS contributor (in my non-gov life) and I will say that I am in that group that will not contribute to a project without a proper license. Although I am not saying I would not contribute without a DCO, I am saying that I do not believe them to be a cause of declining (or limited) community participation.

On a completely non-final, non-official opinion: I think a proper license should be required on any project included in code.mil, but a DCO should be a project-specific decision.

Again, I'll be following up on this in the coming weeks. Leaving this open for now, more comments welcome.

[brlcad]

You are tearing through the open issues, @jordangov ... well done. ;)

I don't think anyone was suggesting that the licensing and contribution terms of the project should not be clearly written down. I certainly wasn't.

Proper (e.g., OSI-approved) should be required. If the legalese doesn't speak to contributions (e.g., like Apache2 does), other project legal docs (e.g., LICENSE/COPYING file) should in SOME manner. I'd even add patents and trademarking to the list of things that should be mentioned. Those do not come with risk or cost implications that detract from acquisition.

The issue is entirely about specifically requiring a DCO and it's potential effect. Making it a project-specific decision where all risks and implications can be considered should work for everyone.

This will be especially critical for groups just getting started with OSS, which is frankly most of the USG.

[nigelht]

@bricad "OSI approved" is a problem as they have been remarkably non-responsive to GOSS community needs. NASA's update to NOSA has been in approval limbo for 3 years. CC0 is unlikely to get approved any time soon despite FSF and CC saying it's good for software and need by the GOSS community.

Federal agencies have specific needs and desires for their open source strategy that isn't always easily addressed by saying "just use Apache". It is maddening that a major GOSS contributor can't get even an up or down vote by the OSI board (much less approval) for an UPDATE to an existing special purpose GOSS license.

Nor are all OSI approved licenses likely fit for use by federal agencies due to legal requirements. IMHO a "proper" open source license is a OSS license from a list of approved maintained by the USG and not the OSI.

Back on topic, IMHO a DCO shouldn't be required as some agencies may wish code provenance to be handled in a different manner. Requiring a DCO as part of official policy is like requiring projects use git vs requiring projects have source code management.

git and DCOs may be a best practice in 2017 but maybe not in 2027.

[brlcad]

I'm well aware of the OSI's inattentive and unfamiliarity with GOSS. I actually ran on that platform for joining the OSI board (and will likely do so again!) and have called them out on issues several times. That said, I think the only failure with NOSA is that it wasn't rejected more quickly. It has problems that were discussed and not addressed due to disagreement. Fontana's pledge to summarily restate the concerns is a courtesy. I feel the only reason it wasn't rejected quickly is because it's NASA, which shouldn't procedurally have influenced matters but did..

For all intents and purposes, OSI is the de-facto representation recognized in ways that actually affect community development, programs like GSoC and academic journal publication.

For what it's worth, I'm working the CC0 patent issue with Creative Commons and others. I wouldn't support OSI approving it in it's stand-alone form as I see it violating clause #1 of OSD if a patent exists that is not royalty free. However, "CC0 + patent pledge" would make it conform.