[License-review] Fwd: [Non-DoD Source] Resolution on NOSA 2.0

Wed Jun 20 00:39:25 UTC 2018

We last discussed the NASA 2.0 license on May 7. This was a different
discussion from the usual, as OSI had already voted to disapprove the
license, without providing much in the way of feedback.

At that point, the license *wasn't really in consideration any longer.* I
offered to look at the license and provide that feedback, and did so. I
concluded that OSI had made the correct decision. NASA's lawyer
subsequently explained some of the language, and I spoke with my own
counsel, but this did not change my conclusion.

My storied "weight" was not at all in play when the license was
disapproved, my participation was all after that time.

    Thanks

    Bruce

On Mon, May 7, 2018 at 1:02 PM, Bruce Perens <bruce at perens.com> wrote:

> Marc,
>
> Open Hardware licenses also have the issue of attempting to license what
> is not clearly protected, in a way that can be enforced between two parties
> but not necessarily in the chain of redistribution common to Open Source.
>
> I was an early proponent of Open Hardware licensing, and eventually
> distanced myself from it. The reason was that I did not wish to create new
> norms in the industry which courts would then cite in creating  protection
> where it did not previously exist. The creeping expansion of intellectual
> property protection that we can cause by developing new norms is against
> the interest of the very communities which have been using Open Hardware
> and Open Data licenses. Consider, for example, the effect if the schematic
> diagrams in a century of electronics magazines suddenly acquired protection
> which could be extended to manufactured objects, rather than just
> publications.
>
> Open Data licensing and the license under discussion also present this
> potential to create new norms which aren't really in the interest of the
> various open communities. Their own work would be protected more
> effectively, but at the cost of losing access to work which is presently in
> the public domain.
>
> The effect is similar to the problem with the recent decision regarding
> APIs in *Oracle v. Google *overturning what we thought we knew from *CAI
> v. Altai. *We acquire the potential to enforce the GPL more reliably
> across an API boundary, eliminating (IMO always wrong) arguments about
> dynamic linking insulating against the GPL obligation. However, we
> potentially lose the ability to make free versions of proprietary languages
> and APIs.
>
>     Thanks
>
>     Bruce
>
> On Mon, May 7, 2018 at 12:40 PM, Marc Jones <marc at joneslaw.io> wrote:
>
>>
>>>
>>>> The attorneys crafted the NOSA with language that specifies, under
>>>> contract law, that the Government is a third-party beneficiary of all
>>>> down-stream distributions.
>>>>
>>>
>>> Right. So, the government has a right to sue someone for breach of
>>> contract who is not directly a party to a contract with the government. And
>>> thus it seems to me that you are attempting to propagate the obligation
>>> from that very first person who received the software in the act of the
>>> government's releasing it from secret. But I am still not seeing that such
>>> a party actually has any consideration to offer to the next party in this
>>> chain.
>>>
>>>
>> Just because material is not protected by copyright, it doesn't mean you
>> cannot restrict its use by contract. The terms of contracts are not
>> generally preempted by copyright law. To oversimplify things, the contents
>> of a phone book are not protected by copyright. See, Feist Publications,
>> Inc. v. Rural Telephone Service Co., 499 U.S. 340 (1991). Nevertheless at
>> least one court has held that an individual's right to distribute those
>> facts can be restricted by contract. Procd, v. Zeidenberg, 86 F.3d 1447
>> (7th Cir. 1996). I do not think that is particularly remarkable since NDA's
>> are routinely enforced and are generally meant to restrict  a party to the
>> contract's ability to share facts. The parties in ProCD were both private
>> parties, but unless there is a statute denying the federal government the
>> ability to do so, I would be surprised to find out the federal government
>> can't do what a private party could do. For that reason without
>> specifically researching the topic, I do not doubt the Federal Government's
>> ability to enter into a contract that limits a person's ability to
>> distribute source code not protected by copyright.
>>
>> I do think the point Bruce raises about binding downstream users to the
>> contract terms is interesting. This problem I think is commonly encountered
>> by the authors of open data "licenses." Many open data licenses are
>> explicitly defined to be contracts, because - I have always assumed - the
>> authors of the licenses expect the license to be used in the distribution
>> of material that has little or no copyright protection. Although the trend
>> is for more open data publishers to just use a public domain dedication
>> like CC0, there are still organizations that prefer to use contracts to
>> distribute their open data. For instance the Community Data License
>> Agreement is explicitly a contract and that was published just this past
>> year. [1] Most of the licenses published by Open Knowledge International
>> are also contracts. [2] Related to open data licenses, many of the Creative
>> Commons licenses are designed to be be licenses but with a fall back to
>> contract law in case the jurisdiction will recognize it as a contract.[4] I
>> acknowledge many of the open data licenses also deal with EU database
>> rights, but they are intended to work in the United States as well in the
>> absence of database rights.
>>
>> I am unaware of any cases showing how effective these open data licenses
>> are at binding downstream users to a contract. I would think the main
>> problem is how to form contracts on redistribution. How do you ensure that
>> the party receiving the material intends to agree to the contract terms?
>> And do so reliably so that everyone who comes into possession of it as it
>> is redistributed also agrees. Establishing the original publisher as being
>> a beneficiary of any subsequent contracts might solve the privity issues
>> required to enforce contracts, but it won't cause a contract to exist if
>> the elements required to form a contract do not otherwise exist.
>>
>> Considering the nature of how FOSS is distributed, I don't think you can
>> rely on the exact same arguments in ProCD either since it is unlikely that
>> people using FOSS source code will ever click a button saying I agree, nor
>> will there be a box to ship the terms with. It's not clear to me that
>> shrink-wrap or click-wrap agreements are applicable, or that browser-wrap
>> agreements are generally effective. Perhaps requiring by contract that a
>> notice of the terms of the contract at the top of each file reproducing any
>> of the text covered by the agreement would be sufficient notice to bind
>> subsequent users. But once someone violated that contract and published the
>> uncopyrighted text, is there any recourse? And would NASA or any open data
>> publisher care? I would expect that the users of open data license,
>> generally accept the risk that at least some portion data will escape the
>> terms of the agreement and are comfortable with that.
>>
>> -Marc
>>
>> [1] https://cdla.io/permissive-1-0/
>> [2] Section 2.0 of the ODBL license says "This License is: ...  c. An
>> agreement in contract between You and the Licensor."
>> https://opendatacommons.org/licenses/odbl/1.0/
>> [3] "To the extent this Public License may be interpreted as a contract,
>> You are granted the Licensed Rights in consideration of Your acceptance of
>> these terms and conditions, and the Licensor grants You such rights in
>> consideration of benefits the Licensor receives from making the Licensed
>> Material available under these terms and conditions." Creative Commons
>> Attribution-ShareAlike 4.0 International Public License available at
>> https://creativecommons.org/licenses/by-sa/4.0/legalcode
>>
>> _______________________________________________
>> License-review mailing list
>> License-review at lists.opensource.org
>> http://lists.opensource.org/mailman/listinfo/license-review_
>> lists.opensource.org
>>
>>
>
>
> --
> Bruce Perens K6BP - CEO, Legal Engineering
> Standards committee chair, license review committee member, co-founder,
> Open Source Initiative
> President, Open Research Institute; Board Member, Fashion Freedom
> Initiative.
>

-- 
Bruce Perens K6BP - CEO, Legal Engineering
Standards committee chair, license review committee member, co-founder,
Open Source Initiative
President, Open Research Institute; Board Member, Fashion Freedom
Initiative.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20180619/07f4703a/attachment.html>