[License-review] Approval: BSD + Patent License

Kevin Fleming kevin+osi at kpfleming.us
Mon Mar 27 18:18:23 UTC 2017


As non-lawyer layman yadda yadda yadda, I wouldn't be surprised if the lack
of sublicense language in the patent grant portions of Apache 2.0 is
intentional. If I publish code under that license I may very well be
willing to allow downstream distributors to relicense under other
(compatible) licenses, but I would want to restrict my patent grants to
only distributions which retain the Apache 2.0 license.

On Fri, Mar 24, 2017 at 7:34 PM, Lawrence Rosen <lrosen at rosenlaw.com> wrote:

> McCoy,
>
>
>
> My recollection is that early FOSS licenses didn't fully appreciate the
> legal complications for software of contractual privity when there is
> sublicensing. On the other hand, GPLv2 avoided any contractual implications
> and sublicensing altogether. Many software transaction lawyers then thought
> that was strange.
>
>
>
> I believe that the original Mozilla License was the first to be explicit
> about sublicensing and patents.
>
>
>
> A contractual license directly from the IP owner to the downstream
> licensee, bypassing sublicensing as in modern FOSS licenses, wasn't well
> understood then by many of us. Nor were patents.
>
>
>
> /Larry
>
>
>
>
>
> *From:* License-review [mailto:license-review-bounces at opensource.org] *On
> Behalf Of *Smith, McCoy
> *Sent:* Friday, March 24, 2017 2:56 PM
> *To:* license-review at opensource.org
>
> *Subject:* Re: [License-review] Approval: BSD + Patent License
>
>
>
> The intent is to replicate (to the extent possible, identically) the
> rights of BSD 2-clause, with an appended patent license styled on the
> Apache/Eclipse model (less the defensive suspension clause which is said to
> render Apache GPLv2 incompatible).
>
>
>
> BSD doesn’t state that the rights that it conveys are sublicenseable,
> hence those grants are not recited as such.  Neither do Apache, or Eclipse,
> in their patent grants (although interestingly, Apache and Eclipse do in
> the **copyright** grant: I’m curious if anyone has knowledge as to why
> the difference).  Thus the lack of a sublicense right in this hybrid
> license is both internally consistent (both the copyright and patent grants
> to not recite a right to sublicense), and consistent with the licenses upon
> which it is based (they use the same language that BSD and Apache – in its
> patent grant – does, which do not specifically recite a right to
> sublicense).
>
>
>
> Which brings us to the more philosophical issue:  ought there be an
> enumerated sublicense right in a license of this type (open source &
> permissive)?  I believe there are two camps on this one:  sublicense rights
> should (or need to be) included, and sublicense rights are unnecessary.
> The latter view is, I believe, based on the premise that the license itself
> goes directly from the IP-rightholder to the entity/individual exercising
> the license – even if there are intervening entities or individuals in the
> distribution chain between those two.  Andrew Sinclair discusses these two
> views briefly in his article in IFOSSLR on BSD:  http://www.ifosslr.org/
> ifosslr/article/view/28/62
>
>
>
> Given that BSD has, for quite some time, worked compatibly with many
> copyleft and proprietary licenses, and Apache has as well with most (GPLv2
> being the notable exception), I would anticipate this license would as
> well, even without the enumeration of a sublicense right (in any of the
> grants).
>
>
>
> Although it is possible that minds might differ on that point.
>
>
>
> McCoy
>
>
>
> *From:* Jim Wright [mailto:jwright at commsoft.com <jwright at commsoft.com>]
> *Sent:* Wednesday, March 22, 2017 11:13 AM
> *To:* license-review at opensource.org
> *Cc:* Smith, McCoy
> *Subject:* Re: [License-review] Approval: BSD + Patent License
>
>
>
> McCoy, I can’t recall if we discussed this in the last round, and
> apologies if we did, but you appear to have taken the position below that
> code licensed under this license can be freely sublicensed on different
> terms without an express grant of sublicense rights.  (I infer this is what
> you mean when you say they can "distribute it under different license
> terms," but please correct me if otherwise.  The Apache license is cited as
> a similar example, but the ASLv2 expressly includes sublicense rights.)
>
>
>
> I note the nicely worded reference to “those receiving rights under this
> license” but is it your position that people are free to sublicense on
> different terms code received with distribution rights but without a clear
> grant of sublicense rights, in all jurisdictions from which code under the
> license might originate?  Did you consider adding an express grant of
> sublicense rights to eliminate any ambiguity or risk of an opposite finding
> on this point?
>
>
>
>  Best,
>
>   Jim
>
>
>
>
>
>
>
>
>
> On Mar 20, 2017, at 2:56 PM, Smith, McCoy <mccoy.smith at intel.com> wrote:
>
>
>
> >>See interlineations.<<
>
>
>
> *From:* License-review [mailto:license-review-bounces at opensource.org
> <license-review-bounces at opensource.org>] *On Behalf Of *Tzeng, Nigel H.
> *Sent:* Friday, March 17, 2017 12:30 PM
> *To:* License submissions for OSI review
> *Subject:* Re: [License-review] Approval: BSD + Patent License
>
>
>
> If one of the commonly accepted objectives of BSD-style licenses is to
> “place minimal restrictions on future behavior” and “does not become a
> legal time-bomb at any point in the development process“ does the addition
> of “or hereafter acquired” in the patent grant section fit the objective?
>
>
>
> >>BSD+Patent, like BSD, is a permissive license.  Anyone receiving code
> under this license has the option to distribute it under different license
> terms if they are worried that their own use of that license represents a
> “legal time-bomb.”  Given the widespread use of licenses (like Apache) that
> cover after-acquired patents, it seems unlikely that that provision
> represents a significant impediment to use, although any licensee will need
> to evaluate it based on their particular circumstance (and patent
> portfolio, if any).<<
>
>
>
> <snipping rest of conversation but leaving license in thread>
>
> *From: *License-review <license-review-bounces at opensource.org> on behalf
> of "Smith, McCoy" <mccoy.smith at intel.com>
> *Reply-To: *License submissions for OSI review <
> license-review at opensource.org>
> *Date: *Tuesday, March 14, 2017 at 5:11 PM
> *To: *License submissions for OSI review <license-review at opensource.org>
> *Subject: *Re: [License-review] Approval: BSD + Patent License
>
>
>
> In light of Luis’s comment, which is valid and spotted a drafting flaw,
> I’ve slightly revised the draft (in the attached, and directly below) to
> put a clearer condition of revocability on the patent license.  I’ve used
> language more consistent with BSD’s language (using the term “condition”)
> although have not used “breach” as that’s not terminology used in BSD.
>
> I’ve also removed the square bracketed portion, as per the discussion
> below, I believe they are worth retaining (absent someone convincing me
> they cause problems I don’t currently see).
>
> Consider this the latest and greatest version of the license.  I’ll let
> any further comments come in for a few weeks, then post something on the
> list indicating what the final version of this license is and asking for
> its formal approval for adding to the list.
>
>
>
> McCoy
>
> ============================================================
> ============================================================
> =================================
>
> Copyright (c) <YEAR> <COPYRIGHT HOLDERS>
>
> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions are met:
>
> 1.      Redistributions of source code must retain the above copyright
> notice, this list of conditions and the following disclaimer.
>
> 2.      Redistributions in binary form must reproduce the above copyright
> notice, this list of conditions and the following disclaimer in the
> documentation and/or other materials provided with the distribution.
>
> Subject to the terms and conditions of this license, each copyright holder
> and contributor hereby grants to those receiving rights under this license
> a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable
> (except for failure to satisfy the conditions of this license) patent
> license to make, have made, use, offer to sell, sell, import, and otherwise
> transfer this software, where such license applies only to those patent
> claims, already acquired or hereafter acquired, licensable by such
> copyright holder or contributor that are necessarily infringed by:
>
> (a) their Contribution(s) (the licensed copyrights of copyright holders
> and non-copyrightable additions of contributors, in source or binary form)
> alone; or
>
> (b) combination of their Contribution(s) with the work of authorship to
> which such Contribution(s) was added by such copyright holder or
> contributor, if, at the time the Contribution is added, such addition
> causes such combination to be necessarily infringed. The patent license
> shall not apply to any other combinations which include the Contribution.
>
> Except as expressly stated above, no rights or licenses from any copyright
> holder or contributor is granted under this license, whether expressly, by
> implication, estoppel or otherwise.
>
> DISCLAIMER
> THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
> IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
> THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR
> CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
> EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
> PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
> OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
> WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> ============================================================
> ============================================================
> =================================
>
> *From:* License-review [mailto:license-review-bounces at opensource.org
> <license-review-bounces at opensource.org>] *On Behalf Of *Smith, McCoy
> *Sent:* Monday, March 13, 2017 2:50 PM
> *To:* License submissions for OSI review
> *Subject:* Re: [License-review] Approval: BSD + Patent License
>
>
>
> A good comment, and it raises a somewhat interesting point.
>
> I replicated that language from Apache.  In the original draft, I had
> taken it out, given that I interpreted it to only apply to the defensive
> patent termination provision in Apache, which I of course removed from this
> license to ensure GPLv2 compatibility.
>
> Someone (I think Jim Wright) pointed out that having the patent license be
> revocable when the other conditions of the license are not satisfied (which
> in the case of BSD, I think would mean only the attribution and license
> notice provisions) might be a bug, as someone could argue that they receive
> the benefit of the patent license without having to comply with the (fairly
> minimal, in the case of BSD) obligations of the license.  As a result, I
> put the conditional revocability back in, but using the same language as
> Apache.  Which as you point out, is ambiguous or doesn’t capture the
> intended meaning (which is as described above).
>
> You are correct in the intent with that parenthetical.  Your language
> might be a solution, although I might see if there is another way to phrase
> it.
>
> *From:* License-review [mailto:license-review-bounces at opensource.org
> <license-review-bounces at opensource.org>] *On Behalf Of *Luis Villa
> *Sent:* Monday, March 13, 2017 1:42 PM
> *To:* License submissions for OSI review
> *Subject:* Re: [License-review] Approval: BSD + Patent License
>
>
>
> Hi, McCoy-
>
> One question: "irrevocable (except as stated in this section)" - I don't
> see any possible revocation clause in that section (paragraph?). Did you
> intend something like "irrevocable (unless the license's conditions are
> breached)"?
>
> Luis
>
>
>
> On Sun, Mar 12, 2017 at 5:19 PM Smith, McCoy <mccoy.smith at intel.com>
> wrote:
>
> All:
>
> It has been over a year since the last discussion on this proposal;  I
> would like to revive it again in view of the following:
>
> 1.  I have gotten some feedback from the FSF on the license.  At the time
> of initial submission of the license, several on the list suggested that,
> given the special purpose of this license -- to provide a version of the
> BSD license that was both GPLv2 compatible and included an express patent
> license, I should get confirmation from the FSF that it is indeed GPLv2
> compatible.  I have heard from the FSF and they have confirmed the present
> draft [appended and discussed below] is GPLv2 compatible.
>
> 2.  I have also gotten feedback from others on the last draft (on-list,
> and privately), as well as from the FSF,  which has resulted in me
> reconsidering the last draft and tightening up and/or altering the text
> somewhat (not to change the substance, just to change ambiguities or other
> drafting issues).  So the latest version (reproduced below, as well as
> appended in color-coded format to show the origin of the text) is in this
> e-mail.
>
> A few drafting notes on this version:
>
> A.  There are two provisions in this draft that are in square brackets
> ([]).  Those represent provisions that I have added in response to the
> comments of others on this list, but which I haven't yet decided should be
> in the final version.  The first provision (that the licensed patent claims
> are those "already acquired or hereafter acquired") comes from GPLv3 -- but
> is not in any of the licenses (BSD, Apache, Eclipse) from which my license
> is derived.  That provision is intended to make explicit that the license
> is intended to cover patents acquired by the licensor after the grant has
> been made.  I think that that is inherent in the grant language of Apache
> and Eclipse (and the Apache FAQs say it is explicitly), but the language
> does have the benefit of making it explicit and part of the license text
> itself.  The second provision is an explicit disclaimer of all other
> licenses beyond those expressly granted.  That language comes from Eclipse,
> with modification.  I'm now of the mind to keep in the bracketed
> provisions, given that I think being express/explicit is better, even if
> there is an argument that these provisions are somewhat unnecessary given
> the unbracketed language already covers the concepts.  I'll leave these
> provisions open for additional comment by anyone who wants to convince me
> there is a good reason to leave them out.
>
> B.  The patent license grant is on behalf of "copyright holders and
> contributors."  I have used that language as a result of its existing use
> in the disclaimer section of 2-clause BSD, which I interpret to be intended
> to cover those who make copyrightable contributions as well as those who
> might make contributions not subject to copyright (an issue discussed in
> some depth in separate threads about military and/or government open source
> licensing, particularly those not subject to US copyright rights).  In
> order to make that distinction more clear, the patent clause now has an
> embedded definition of "Contribution(s)" which intended to now capture both
> types of contributions -- copyrightable and non-copyrightable.  Although I
> tend to disfavor embedded definitions in a license of this type (since BSD
> is free of them), this was one definition that seemed to be needed as a
> point of clarity.
>
> Further comments are welcome.  Now that the GPLv2 compatibility issue is
> resolved, I'll leave this one open for additional comments from the member
> list for a bit,  in case anyone sees further drafting improvements they'd
> like to suggest -- or express objections as to why the license itself
> should not be approved.  I will then indicate that the text is finalized
> and ask for Board approval to add to the OSI list.
>
> McCoy Smith
> Law & Policy Group
> Intel Corporation
>
>
> _______________________________________________
> License-review mailing list
> License-review at opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review
>
>
>
> _______________________________________________
> License-review mailing list
> License-review at opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20170327/2c8635eb/attachment.html>


More information about the License-review mailing list