[License-review] Approval: BSD + Patent License

Smith, McCoy mccoy.smith at intel.com
Wed Jan 20 22:33:14 UTC 2016

If the FSF says that this license is GPLv2 incompatible, it fails to meet its purpose and will be updated so that it is.  I've tried to model the license language on existing licenses already stated by FSF to be GPLv2 compatible (and to remove any parts that are specifically identified to not be GPLv2 compatible), so I certainly believe it to be compatible.  If anyone has any good arguments why they think it would not be, I'd love to hear them.  If I read my history correctly, UPL was approved as a GPLv2 compatible license by OSI in February 2015, prior to the FSF officially designating it as GPLv2 compatible in September 2015, so I don't believe FSF designation is required before OSI approval.

As to the UPL, as noted in the original submission for the BSD + Patent license, it is (AFAIK) the only other OSI-approved permissive license with an express patent grant that is written to be (and has been acknowledged by the FSF to be) GPLv2 compatible.  The text is derived from MIT, with an included patent grant that varies in at least two material ways from the patent grant in Apache/Eclipse/BSD + Patent:  1)  the patent grant extending to the unmodified Software "contributed to *or provided by* the licensor"; 2) the patent grant extending to combinations of that Software with other software or hardware identified in a "lrgrwrks.txt" file included with the Software.  The reasons for those choices in the UPL appear to be pretty well documented in the discussion thread for the approval of that license by OSI;  depending on the perspective of the licensor and any licensee, that grant could be a bug, or could be a feature, over BSD + Patent.  The choice of the Apache/Eclipse formulation of the patent grant (and the BSD 2-clause as the foundational basis of BSD + Patent rather than MIT), is the relatively familiarity, and "popularity," of those formulations to those I have spoken to about permissive licensing and GPLv2 compatibility.  I think there is room for at least two choices on this type of license, particularly when different entities have different perspectives on the scope of the patent license grant they want to give, or want to get.

I'm definitely sensitive to the question of license proliferation (and believe I may have some bona fides in that regard: http://www.cnet.com/news/intel-to-stop-using-open-source-license/), having served on the first iteration of the License Proliferation Committee of OSI circa 2005. Which is why I submit this license somewhat advisedly and suggesting that it be a special purpose license under OSI's categorization system, as it exists primarily to solve a particular problem.

As to the scope of the patent grant itself and efforts that a licensor might engage in to undermine it, I again refer back to Apache & Eclipse (or for that matter, other OSI-approved licenses with patent grants of equal or similar formulation).  I believe these license grants to be reasonably clear and generally well understood, and believe that the BSD + Patent grant does the same.  Another goal here is to adopt the simplicity and brevity of BSD 2-clause and the Apache/Eclipse patent grant.  One could of course draft numerous clauses and definitions that more specifically address various worst case scenarios - and many of us have read, or written, proprietary licenses doing just that - at the expense of such simplicity and brevity, as well as at the expense of casting off the comfort and familiarity that many users have with the language of these licenses.


From: License-review [mailto:license-review-bounces at opensource.org] On Behalf Of Tzeng, Nigel H.
Sent: Wednesday, January 20, 2016 6:36 AM
To: License submissions for OSI review; mike at opensource.org
Subject: Re: [License-review] Approval: BSD + Patent License

The license is short so review by the FSF should be quick.  If someone is requesting a "niche use" license is it unreasonable to say "prove to me that it actually fills that niche"?  However unlikely what if the FSF says "No" or just doesn't answer for a while?

I am also curious why UPL isn't good enough.  Because UPL is a re-worded MIT license with patent grant:

What is the UPL and why did you create it?

The UPL is a highly permissive license, including both copyright and patent licenses, which permits use and relicensing under both copyleft and commercial terms, and also facilitates use as a contributor license agreement.

It was originally borne out of a discussion in the Java Community Process around what it would take to permit collaboration on JSR reference implementations in open source forges without the necessity of collaborators signing the JSPA or an Oracle Contributor Agreement. In order to accommodate the broadest possible use case, the license needed to include an express patent license and to be broadly agreed to be GPLv2, GPLv2+Classpath Exception, CDDL, and commercial license compatible, including the ability to cut and paste code between modules, and while it is almost universally agreed among those knowledgeable in FOSS licensing that license proliferation is something to be avoided without good cause, since a license meeting these relatively simple and obvious criteria did not exist, it was decided to draft one.

Drafting started with the MIT license, and after a lot of discussion with other open source lawyers, developers, members of the Java Community Process Executive Committee, and reviewers and board members of the Open Source Initiative, and several rounds of revision, finally arrived at the vetted license text you see here. The license was approved by the OSI as conforming with the Open Source Definition and non-duplicative of existing permissive licenses in February 2015."

Can you point to some concrete problems the UPL solves that you could not have addressed with the MIT, BSD or Apache licenses?

The most important problem the UPL solves is the inclusion of an express patent license in a license that is both broadly agreed to be uniformly copyleft compatible and also permits the software to be freely used in commercially licensed software (i.e., without concerns about reciprocal license obligations).

The MIT and BSD licenses do not include express patent licenses, and while many argue that there is an implied patent license, there is nontrivial debate about the existence & scope of any such implied license.  This is addressed in some more detail below.  The Apache license, on the other hand, is argued by some not to be GPLv2 compatible, which makes it tricky to use in connection with GPLv2 licensed code - the GPLv2 is still by far the most popular open source license, and unambiguous, undisputed GPL compatibility was a crucial qualifier for any license considered for use in the JCP.  (Even the BSD license has been argued not to be GPL compatible - while this need not be addressed here, and it is not the conclusion of the FSF or most others, by virtue of expressly permitting relicensing on other terms, the UPL is definitively and fully GPLv2 compatible.)


So exactly why do we need a BSD variant with patent grant when we already have a MIT variant with a patent grant that the FSF has already publicly agreed as GPL V2 compliant on their website?

All of a sudden license proliferation is a non-issue?  That's fine by me as I've never been that much of a fan of that concern.

Are any of the other concerns voiced two years ago about UPL any better addressed by BSD+Patent Grant?  I guess without the Larger Works clause there is one less file to look for.

However, I would ask that if the BSD+PL:

"(b) by combination of their copyrighted material with the work of authorship to which such copyrighted material was added by such copyright holder or contributor, if, at the time the copyrighted material was added, such addition causes such combination to be covered by the patent claim. The patent license shall not apply to any other combinations which include their copyrighted material. "

better fulfills the same role as the UPL:

"(b) any piece of software and/or hardware listed in the lrgrwrks.txt file if one is included with the Software (each a "Larger Work" to which the Software is contributed by such licensors),"

Because at least the lrgrwkrs.txt file is explicit.

Q. Does using the "at the time the copyrighted material was added" phrase means that if I want to do my due diligence I need to look at commit times and when patents were granted to make sure someone hasn't submarined a patent in there?

Q: What happens if someone commits changes to a BSD+PL licensed reference implementation that at the time of commit there isn't a patent BUT later on they apply for and a patent is granted to them?  Do I have a patent license or not?



On 1/19/16, 11:57 PM, "License-review on behalf of Josh Berkus" <license-review-bounces at opensource.org<mailto:license-review-bounces at opensource.org> on behalf of josh at postgresql.org<mailto:josh at postgresql.org>> wrote:

On 01/19/2016 06:12 PM, Mike Milinkovich wrote:
Wow, this thread has degraded to the point of silliness.
Every OSI Board member who has commented on this license has said
positive things about it. It's a good license. It fills a niche that we
have long wanted filled.

Yes, and I have an *immediate* use for such a license.

I haven't seen an attorney weigh in on the patent grant issues inherent
in a liberal patent-grant license.  Has one posted a review elsewhere?

Josh Berkus
PostgreSQL Project
License-review mailing list
License-review at opensource.org<mailto:License-review at opensource.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20160120/14468251/attachment.html>

More information about the License-review mailing list