Why do you mix the "licensed" use of the software with contributor agreement policies? about code.mil HOT 13 CLOSED

I'm glad @marctjones asked this question; I was having the same thought.

An open source license is what grants a forker the right to fork -- it's not about what originator takes in, it's about lifting redistribution restrictions on what goes out.

The originator's acceptance of inbound contributions is an unrelated matter, and it might actually be inadvisable to put anything at all about it in the outbound license or agreement. For example, you don't want to imply that you are going to accept any contribution as long as it comes with a DCO; nor do you want to imply that a given project will accept contributions at all (maybe some won't); nor do you want outbound language to constrain you changing the inbound contribution acceptance policy later (if fashion shifts away from DCO and to some new thing, for example).

Since the DOD is under no obligation to accept inbound contributions in any particular project, and can stipulate whatever conditions it wants to for incorporating contributions into its copy of a given code base, it would be better to take all contribution language out of this agreement, I think. The DOD is free to specify DCO as the standard for all its projects, if it wants, but it can just do that on a project-by-project basis.

from code.mil.

Hi, @BrandonBouier . FWIW, even though many people in government are new to this, I would still recommend not mixing contribution agreement with outbound license. They're really separate things: they enable different sets of people, and for different purposes. An easy solution is just to not present visitors with a contribution agreement at all at first -- in other words, just removing the language about contribution should result in a reduction of confusion for everyone, newbies included.

Once someone is interested in contributing, then you can have a separate document & procedure you introduce them to at that point.

(Responding separately to @storrgie: There are plenty of times in open source that work is not done out in the open, especially where legal agreements are concerned. Maybe it would be to their advantage to have their update discussion out in the open, or maybe it would be to their disadvantage; I actually would more expect the latter than the former, FWIW. It's normal and in no way anti-open-source for them to discuss behind closed doors and then publish a new draft for review.)

from code.mil.

This agreement would only apply to those projects which adopt it and does not attempt to set DoD-wide policy. This does not establish a rule or policy, nor does it apply to all DoD projects.

The DCO mechanism is a recommendation for Program Managers to adopt.

from code.mil.

Why mix the the idea of a license and the policy on accepting contributions though? Wouldn't it be simpler to just refuse to accept contributions from non-government employees unless they granted you a license under the FOSS license of your choosing?

For instance simple refuse any pull requests that do not include the DCO or a licensing statement of your prefered license. That does not seem to require a contract though. You can simply state that as the contribution policy of your project. It would avoid the complexities of mixing contract and licensing.

Similarly it might also be an easy way to transfer your government work into a GPL licensed work if that is in fact your goal. If you include source code created by a non-federal employees that is already licensed under the GPL, one could argue the rest of the work is a derivative work and is governed by the terms of the GPL?

from code.mil.

@marctjones These are great suggestions and exactly the kind of feedback we were hoping to receive by putting the draft agreement out there for comment. Thank you for your thoughtful input! We will definitely consider it.

from code.mil.

@shawoods Really glad to see a government agency being open minded about using more licenses including copyleft licenses. So glad to see the willingness to experiment! You might want to invite more FOSS attorneys into the discussion though. For example introducing contract law is a bit of a controversial topic amongst FOSS lawyers as well since there is some debate about if some of the existing licenses are contracts and how that would impact license enforcement. The Versata v Ameriprise cases ( and Ximpleware) have sparked some debate around FOSS licenses relationship with contract law.

My primary practice area for several years after law school was advising FOSS projects and on FOSS licensing for other entities. There is a well developed legal community around FOSS. It is definitely a unique area of practice between the legal issues and the community norms that need to be addressed. Happy to provide you with additional resources around this area if you and your legal staff are interested.

from code.mil.

Our hope is that the agreement will serve as a single place for the licensing & contributing "mechanics" - especially since a lot of people in the government are relatively new to the open source community.

That said, we're working on an update to the agreement that will hopefully clarify a few things.

from code.mil.

as per my comment in #8, where is the branch for this work. You close this issue but your "work" is not out in the open.

from code.mil.

@kfogel thanks for this comment! You raise some good points.

from code.mil.

You also could do a lot worse than taking advice from @kfogel, who probably does not recall that I once had the pleasure of meeting briefly.

from code.mil.

@kfogel agree completely with the side note, and that is what had to be done before this was created for open feedback. I'm being particularly nit picky because @BrandonBouier is closing tickets and waiving hands at a potential future resolution, which I don't think is in the spirit of being open.

From what I gather from responses from the DDS group, particularly in #8, the novelty of this approach is the unilateral openness. As we're using a revision management system and an issue tracker that intimately links to revisions, I'd prefer that tickets were closed with actual commits rather than a hand-waving at potential future commits.

Closed discussions with a published update would be acceptable, if the issues remained open until then. Otherwise this experiment in openness is experiencing deliberate censoring by the DDS facilitators.

from code.mil.

@kfogel I'd be curious to know your thoughts on the changes we've made

from code.mil.

Hi, @storrgie . I haven't been following the other tickets too closely, just this one, so you may be working with more information than I am. But I doubt, as a general matter, that any government agency can ever use a process as open as the one you're hoping for :-). The owner(s) of a repository can decide what the ticket-closing criteria are for that repository. I don't see any censorship going on here; that's a strong word. At least, you and I are certainly not being censored in any way.

@BrandonBouier, haven't had a chance to look yet; will as soon as I can (have some other deadlines today).

(Hey, @marctjones, thanks for the in-thread endorsement. My memory is terrible that way, alas, but next time we meet feel free to shame me and remind me of context!)

from code.mil.