I generally agree with your points. A comprehensive FOSS strategy does
require considering a lot of different things including how you can acquire
the rights to release the code as FOSS and determining what patent license
works for your organization. That doesn't necessarily mean that the
government needs a unique FOSS license/agreement.
You are right the government can not simply declare vendors release their
code under a FOSS licenses. I did not mean to suggest that that is what DDS
as doing. But it can contract for the required rights. To me it always
seemed cleaner to acquire the right to release code under a FOSS license in
a contributor agreement rather than having a FOSS license doing double
duty. In the case of the government perhaps a clause in a procurement
contract could serve that purpose of getting the government that right.
Often the CRADA, FAR, and DFAR regulations allow the flexibility for the
government to negotiate for those rights, even if they also mandate that
the government at minimum get a certain set of government purposes rights.
The process for determining when patents should be licensed and what FOSS
needs a software patent license at all, seems like it could take advantage
of some of the processes of the programs you listed to determine what
patents the government wants to license now. That might mean the government
needs a new FOSS agreement, but perhaps it could in many cases also just
grant a gratis patent license along with a existing FOSS license that does
not grant any patent license, or, as you suggested, perhaps one of the
existing FOSS licenses would provide an appropriate license.
On Mon, Feb 19, 2018 at 3:25 PM Ben Hilburn <bhilb...@gmail.com> wrote:
> Ah, thanks for the clarifications! And yes, I agree, those are fair points.
> On Mon, Feb 19, 2018 at 2:38 PM, Tzeng, Nigel H. <nigel.tz...@jhuapl.edu>
>> On 2/19/18, 8:38 AM, "License-discuss on behalf of Ben Hilburn" <
>> license-discuss-boun...@lists.opensource.org on behalf of
>> bhilb...@gmail.com> wrote:
>> 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
>> My point was that there may be no contractor code at all and therefore
>> there is no code under any sort of FOSS license, just public domain.
>> Depending on the existence of contractor developed code under a FOSS
>> license to make the entire code base FOSS doesn’t work in this case.
>> 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.
>> The use of Apache 2.0 is problematic because it IS a fairly unique
>> problem. The issue is the USG as a single entity implies that a patent
>> grant under Apache 2.0 provided by the ARL gives that patent away even if
>> it was not created by the ARL but some other part of the federal government.
>> Your scenario is different where the developers implements a patent
>> someone else owns. They don’t own the patent so the patent grant under
>> Apache is meaningless.
>> The only place that the broader open-source community has dealt with this
>> issue is in the educational world which is why we have ECL v2. Which is
>> Apache with a patent grant only for those patents owned by the authors of
>> the code.
>> License-discuss mailing list
> License-discuss mailing list
License-discuss mailing list