[License-review] For Approval: W3C Software and Document License

[Carlo Piana]

On 09/08/2017 21:15, Wendy Seltzer wrote:
> On 08/09/2017 02:47 PM, Carlo Piana wrote:
>> Wendy, all,
>>
>> A few belated comments, as the early decision on the previous version
>> would probably estop objections to approval on pre-existing terms.
>> Because of the public and general teaching that our discussion creates
>> to the benefit of all drafters, I will anyhow make two them for the records.
> Thanks Carlo, replies below:
>> # Lack of a full liability disclaimer (common to many licenses)
>>
>> One thing that has always puzzled me is that the liability disclaimer is
>> **only to the benefit of the copyright holder(s)**. That means that if I
>> merely host the software to the benefit of others, or make insubstantial
>> (copyright-wise) changes, or just plug a component in my non-derivative
>> project, thus **not being copyright holder, but liable** for the very
>> use of the permissions of the  license, I will not be protected by the
>> liability disclaimer.
>>
>> I understand that many of the licensing conditions only belong to the
>> copyright holders, but with specific regard to liability (hence not a
>> direct copyright issue), why these licenses let non-copyright-holders
>> out in the cold, unprotected? Why not just using the elegant wording of
>> the GPL v3 as a reference: "ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO
>> MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE"?
>>
>> This discussion has arguably no impact on OSD compliance (or has it?),
>> the non-copyright-holder may add their own distribution terms, I reckon.
>> But those distribution terms **would not be based on copyright law**;
>> rather they will be on contractual or quasi-contractual grounds,
>> therefore in a much less solid terrain, if not in the sand. I would like
>> to see this point addressed by all submitters, if their license want to
>> create  commons and an ecosystem.
> The copyright license document speaks for the copyright holders, so it
> is their statement that they are disclaiming any liability.
>
> Distributors remain free to make their own non-conflicting statements,
> such as adding their own disclaimers of liability, or, if they choose,
> accepting liability (perhaps for a fee).

Agreed, I anticipated this objection, but I find it totally unconvincing.

Firstly, the copyright holders are perfectly at liberty of adding a
disclaimer to the advantage of all those who participate in the
distribution chain, with just a handful of words and no downsides.
Choosing not to do that looks very selfish, creating two class of
liabilities for those who distribute: those having copyright interest
and those not having copyright interest in the software, but perhaps
having done much work, including copyright subject matter, which they
have assigned to the project leader. Maybe this is not your case, but I
speak in general terms.
 
As I said, having liability disclaimers as a copyright condition is
totally different from having it on contractual terms (provided that
distributors may have a chance to enter into a binding agreement that
they will later benefit from). You surely see the difference.

Plus it creates unnecessary friction and legal paperwork to add up and
document at any distribution step, where the same could have been
achieved by adding a few words in the public license, which should be
self-sufficient for the entire distribution.

Secondly, if they chose to accept liability, they could do so by
*adding* their own terms to therms that would otherwise disclaim
liability. It's perfect commonplace that in software distribution
agreements the EULA disclaims all possible liabilities, and even the
distribution agreement does so, but then the distributor adds the
exceptions for which she undertakes liability.


>
>
>> # Implied possible ambiguity as to patents
>>
>> On a different but related topic.
>>
>> This license reads an evident copyright-only license: wide use of
>> copyright only concepts and wording; lack of any even vague reference to
>> patents or other rights impinging (h/t Andrew Katz) on the software are
>> a red herring. Is there any *arrière pensée* that the patents (if any)
>> that may read on an unmodified version of the software are intentionally
>> not licensed by the copyright holders and therefore if someone wanted to
>> use, distribute, copy, modify etc. the software, she should seek a
>> separate license?
> This is a copyright-only license. It makes no statement about the
> presence or absence of patent claims covering the licensed works.
> Copyright and patent are distinct regimes, so I don't believe there's
> ambiguity in offering one without discussing the other.

I beg to disagree.

Thank you for resolving the ambiguity, which indeed does not come from
the text (pretty clear), but from the claimed open source nature of the
license.

The scope of a FOSS license is to give permission to do things with
software. They are *historically* conceived as copyright licenses
because *historically* that was what drafters understood it was the
regime under which rights had to be conferred on software.

If different rights insist on software, the owner of those rights who
purports to give permission *must* give those permission under all the
rights she may have, or the openness test would miserably fail.

Otherwise it is like opening one lock of a door, with the other
remaining closed. The door will not open. So if the license is a key,
you cannot just say "this key will conditionally open all the copyright
locks on my doors" and claim that the doors will be "open doors". If
there are patent locks of yours, the doors will remain shut. [0]

A license which only gives copyright licenses but refuses to do so for
patents is not an open source license in my and many others' opinion.
It's a public license, it is valid, it has some scope, but it's not open
source.

I invite OSI to take a stance once for all as to this conceptual ambiguity.

> As you note, W3C Recommendations have a distinct patent policy,
> https://www.w3.org/Consortium/Patent-Policy that applies, per its terms,
> when a specification is made a W3C Recommendation.

Yes, and I always praise it as the to-date golden standard for IPR
policy in SSBs (kudos on that). But unfortunately this is totally
immaterial to the discussion on open source public licenses, which must
stand or fall on their own.

Carlo


[0] of course you can only give permissions for the rights you own or
control.


>
> --Wendy
>
>> I am aware of the IPR policy of W3C in this domain, and that this would
>> be an infrequent (but not impossible!) case in the context; I am also
>> aware that the suggested proliferation category is "non reusable". Yet,
>> leaving such possibility open is something that in a modern FOSS license
>> creates potential problems and eventually non-openness. Besides, despite
>> the clear ‒ and maybe elsewhere clearly spelled out ‒ intentions of the
>> drafters, a license might be interpreted beyond the intentions of the
>> drafter and sometimes also not against her interests; in many laws there
>> is a *contra proferentem* rule, but that may be recessive or non
>> applicable, and anyway being based on contractual law, *the rule itself*
>> would largely vary, never mind *its concrete application*. So if leaving
>> patents out of the license was not the intention of the drafters, this
>> could very well be the legal consequence of applying the proposed license.
>>
>> In a nutshell: what is the attitude of the license WRT the
>> (hypothetical) patents held by a copyright holder reading on the
>> licensed work?
>>
>> And why ‒ if the ambiguity was spotted ‒ was it not more clearly avoided
>> one way or the other? 
>>
>> At least up to the limited approach to the problem that the APL takes
>> (contributors' patent license), patents should be expressly taken care
>> by a FOSS license. See the CC0 discussion, and, in similar terms, see
>> the discussion we had WRT the MXM license. The fact that BSD and MIT,
>> and all academic licenses are historical cornerstones of FOSS licensing
>> is not a reason to perpetuate an use which was state-of-the art back
>> then, but it is by an large not any more.
>>
>> Cheers
>>
>> Carlo
[---]