> Not every contractor is going to allow their work to be open sourced
> without a cost…especially if part of the code base was developed using
> internal funds. Under DFARS 252.227-7014 <(252)%20227-7014> the
> government only has government purpose rights for software developed with
> mixed funding and restricted rights for software developed completely with
> private funding. In the case of a CRADA the government usually only
> retains a non-exclusive, nontransferable, irrevocable license to the IP
> ((15 U.S.C. 3710a (b) (1) (A))).
I don't think you are saying different things. Yes, clearly many
contractors are not going to open-source code without cost - but that's not
what Marc is saying. Per his e-mail, "the DDS is intentionally taking
contributions from contractors only under FOSS licenses". He's not saying
that contractors *have* to share their code as FOSS, only that it won't get
merged if they don't - which makes sense, anyway.
> So, it’s not as simple as declaring that any contractor development on a
> GOSS project must only be under a specified FOSS license listed in the
> CLA/DCO. A lot of the time there isn’t any contractor code in the codebase
> anyway. The government developers may be responsible for a complete CSC or
> CSCI of a larger system. For example, a component simulator or a protocol
> library. It is probably better for NASA to have it released under NOSA
> rather than PD.
Not sure I'm following your argument, here? If a party has been contracted
by the government to write code, as part of contract negotiations the
government can require that the code be delivered as FOSS. Especially with
the recent changes in the NDAA, the government is clearly trying to push
acquisition officers to be more knowledgeable about these things.
> Any comprehensive GOSS strategy has to take into account these cases as
> well as the desire of federal agencies to be able to commercially license
> There is also significant issue with blanket patent grants under most FOSS
> licenses that has to be addressed under a federal government open source
> agreement. An ARL developed software package that unknowingly implements a
> NRL software patent and released under Apache is an issue best considered
> and mitigated before it happens rather than after. A federal open source
> agreement probably needs the same sort of patent language as ECL V2 vs that
> of vanilla Apache.
The DDS policies posted online don't discuss patents much, aside from a bit
in the license selection portion, "Our suggestions for permissive licenses
are *MIT*, *ISC*, or *BSD-3* unless patents are potentially involved in
which case we suggest Apache 2.0 although the others work too." I have no
idea how intra-government but inter-org patent licensing works, though, so
I don't have anything to add to this piece of the discussion. It's worth
noting, though, that the broader open-source community has long dealt with
the same question, "what if someone unknowingly implements a patent and
publishes it under the Apache license," problem that you raise here; I
don't think it's unique.
License-discuss mailing list