[License-review] Approval: BSD + Patent License
Jim Wright
jim.wright at oracle.com
Thu Jan 21 15:43:28 UTC 2016
Thank you for the thoughtful and detailed reply McCoy, a pleasure as always. Sounds like you’re going to propose a revision then?
Assuming you end up tweaking not to exclude hardware components, and adding back conditioning of the patent license on attribution along with the copyright license, then to address the proliferation question, I think that might nail down a few substantive differences from the UPL (which, IMHO, is the core of non-proliferation evaluation - clear differences in effect of the license):
- As you correctly observe in one of your other replies, the UPL includes a patent license from someone who redistributes under the license (though they may choose to sublicense under other terms to avoid this - it was a feature :), the BSD+PL will not include one, so in the base case, a recipient would still be relying on an implied license from any non-contributor for any use of the code. This may also affect how distribution of combinations would likely be interpreted (in the A/B/X/Y example, under the UPL, a party distributing two pieces of code under the license would license both, while under the BSD+PL, they only license the code they’ve contributed to and arguably not another piece of code distributed alongside, though one might at least try to counter-argue that this combination is itself a copyrightable contribution in some cases (collective work anyone? {Shudder}) then causing them to grant a license to the assembled whole.)
- The UPL expressly permits sublicensing, the BSD+PL does not (and the extent to which sublicense rights may or may not be implied varies both by circumstance and by jurisdiction - one may not safely assume that sublicense rights to the code would be implied in all jurisdictions) such that under the BSD+PL you could not necessarily, e.g., cut and paste code into something licensed under terms that require the entirety of the work to be under a single license, or offer the work on proprietary terms, and purporting to do so could be infringing.
- Getting to Nigel’s most recent question, I believe the UPL patent grant *would* include a later granted patent from a licensor under the license, while the language of the BSD+PL would arguably *not* include it due to the instantaneous nature of the grant.
There are other differences but I don’t think we need a comprehensive list here.
Best,
Jim
> On Jan 20, 2016, at 8:38 AM, Smith, McCoy <mccoy.smith at intel.com> wrote:
>
> -- Hardware Per Se license exclusion:
>
> You know, after your first comment (and some other public or private comments I got), I'm thinking that maybe the exclusion of "hardware per se" from the license may not be helpful, and perhaps harmful, for the following reasons:
>
> 1. I have a feeling that it might render the license GPLv2 incompatible; although OSI licenses are generally used for software, they can be (and have been) used for hardware*, and to exclude out hardware from the patent license could be considered an additional restriction incompatible with GPL (either v2 or v3). EPL and CPL both have this exclusion, and the FSF does not point to that as rendering the licenses incompatible with GPL, but that's likely because the weak copyleft nature of these licenses was the primary reason for the opinion that EPL & CPL are GPL compatible.
>
> 2. "Hardware per se" is, in my (and others') opinion, somewhat ambiguous in its scope.
>
> Nigel Tzeng suggested substituting a more general disclaimer (for example " No other express or implied licenses are granted"); I can see some merit to that as an alternative disclaimer. I'm curious of the mailing list's thoughts on this sort of disclaimer. I know it is something that is often put in proprietary licenses, although even those sorts of disclaimer don't necessarily preclude an implied license being found (at least in the US, per the Transcore decision and certain progeny). As to whether this disclaimer might impact GPLv2 compatibility, I think not (given the finding that the Clear BSD -- with a complete disclaimer of all patent licenses -- is GPLv2 and GPLv3 compatible: http://www.gnu.org/licenses/license-list.en.html#clearbsd )
>
> --Irrevocability of patent license:
>
> When importing that Apache/Eclipse patent license, I did take out the clause that the grant was "Subject to the terms and conditions of this License" (Apache)/" Subject to the terms of this Agreement" (Eclipse). When I drafted it, I was thinking that the "Terms and Conditions" of BSD are so minimal that making the grant conditioned upon them was not worth it, and that patent litigation is a pretty expensive hammer to wield in order to get someone to comply with the two conditions of BSD-2-Clause. But then again, we do see some people failing to comply with those minimal requirements, and they do provide a valuable notice function that ought to be preserved (and to get the valuable benefit of a patent license, you ought to at least comply with those requirements). I'm leaning toward maybe inserting a "subject to" clause to the patent grant for this reason and to maintain better consistency with the Apache/Eclipse patent grants.
>
> --License from redistributor:
>
> This really is a question as to the scope of how the Apache/Eclipse style patent license is drafted; I have of course reproduced (as best I can) that form of license. Those licenses are measured by the contribution made by the patent holder (alone or in combination). A mere redistributor, who makes no changes/"Contribution", is not subject to the grant of that form of license (at least I believe that to be the interpretation -- anyone can correct me if they think I am wrong). As the Apache form of a patent license is the type that many patent holding entities find an acceptable bargain (and which why many of them like Apache, but for its GPLv2 incompatibility), I've retained that scope.
>
> --Sublicense rights:
>
> I've tried to track the language (and thinking behind) BSD and Apache/Eclipse, which I believe is designed to be a direct license from the copyright holder to everyone that uses the licensed subject matter, thus precluding the need for a sublicense right (this is also the thinking that was part of the drafting and discussion of GPLv3). I'm not aware of the argument that somehow the lack of sublicense rights in BSD (or other licenses) might render it GPLv2 compatible, and I'm curious as to how that would work given that the FSF has long maintained that sublicense rights are not a part of GPL, and GPLv3 says, in Section 2, that "Sublicensing is not allowed" (because they believe it to be unnecessary.
>
>
> *Those of you know me know I've been noodling around with issues around open hardware licensing for a while, and I have some skepticism about the use of OSI licenses in their pure form for hardware licensing, but that's beside the point of this particular license draft and OSI approval.
>
> McCoy
> -----Original Message-----
> From: Jim Wright [mailto:jim.wright at oracle.com]
> Sent: Friday, January 15, 2016 9:20 AM
> To: License submissions for OSI review
> Cc: Smith, McCoy; josh at postgresql.org
> Subject: Re: [License-review] Approval: BSD + Patent License
>
> McCoy, I applaud your efforts here. A few questions in no particular order:
>
> - If a patent claim has some parts of a device or method in hardware and some in software, is the intent of stating that hardware per se is not licensed here that it not be covered? (While some have concluded CC0 is GPL compatible even with an express reservation of patent rights, in my mind, the idea of expressly reserving some patent rights that may actually cover the software as combined with HW on which it runs is curious.)
>
> - I note you make the patent license irrevocable - how do you intend this to interact with the conditional nature of the copyright license? The wording strikes me as interesting here, because you provide that anyone exercising copyright rights under the license is the beneficiary of an irrevocable patent license grant - but what if the party exercising copyright rights is also breaching the license in another context (e.g., providing attribution for one use but not another). The way I read it, the party is exercising copyright rights under the license, and therefore all their activities benefit from the patent license, potentially even if out of compliance in other contexts…?
>
> - Vis-a-vis Carlo’s question, and Richard’s, I might go further - does a recipient get, or not get, patent rights from a downstream redistributor under the license, since a redistributor is arguably neither a contributor nor a copyright holder here?
>
> - This one will not be popular but some have actually questioned the idea of the BSD license’s GPL compatibility (vs., e.g., MIT). Would it be useful to add sublicense or other rights for certainty in this regard?
>
> Oh, and Josh, McCoy can answer for this new proposed license, but as to the UPL, we considered this, and I think we would take the position that A is a licensor having provided the software under the UPL of X+Y, and therefore has granted that patent license to “anyone obtaining a copy of” X+Y. (We can discuss offline if you like in order to avoid bogging down the discussion of McCoy’s proposal.)
>
> Best,
> Jim
>
>
More information about the License-review
mailing list