[License-review] Approval: BSD + Patent License

[Lawrence Rosen]

Larry Rosen wrote:
> > Here's another example: Apache2.0 allows AFL3.0 contributions. GPLv3 
> > allows Apache2.0 contributions presumably including those AFL3.0 parts.
> > But GPLv3 doesn't allow AFL3.0 contributions because that license 
> > "contains contract provisions."  :-)  You figure it out.

Mark Wielaard responded:
> This seems somewhat offtopic for this license review. And it seems that 
> the simplest explanation is that the presumption is incorrect. But I think it
> shows that if your goal is to create a new license that is compatible with
> another one, then it is good to talk to the license steward to make sure
> your assumptions are correct.


Whether or not you talk to this license steward (me!) to explain AFL 3.0, there is another reason why this topic is relevant for the license-review@ list.

McCoy is proposing a BSD license plus patent license. It is an okay FOSS license. But AFL 3.0 did that very thing 10 years ago. The only reason for AFL 3.0 not being accepted generally for that same purpose is the FSF's complaint, "contains contract provisions." That kind of quasi-legal balderdash is directly relevant to what McCoy and others want to do. 

And if AFL 3.0 isn't satisfactory for some random reason, then use the Apache 2.0 license. If FSF continues its argument that the Apache 2.0 license is incompatible with GPLv2, make them prove it with an argument that would pass muster in law school or the courts.

This subject is LICENSE-REVIEW.

/Larry

Lawrence Rosen
"If this were legal advice it would have been accompanied by a bill."

Rosenlaw & Einschlag (www.rosenlaw.com) 
3001 King Ranch Rd., Ukiah, CA 95482
Cell: 707-478-8932 
LinkedIn: http://lnkd.in/D9CWhD 


-----Original Message-----
From: Mark Wielaard [mailto:mark at klomp.org] 
Sent: Saturday, January 16, 2016 8:16 AM
To: License submissions for OSI review <license-review at opensource.org>
Subject: Re: [License-review] Approval: BSD + Patent License

On Fri, Jan 15, 2016 at 12:34:20PM -0800, Lawrence Rosen wrote:
> Jim Jagielski wrote:
> >> We fully expected that the FSF (and others), based on this and from 
> >> their feedback, would formally state that ALv2 was compatible; you 
> >> can imagine our surprise (and disappointment) when, not long after 
> >> we released it, we were told "nope".
> 
> FSF opinions on license compatibility, to steal McCoy's phrase for 
> this purpose, seem "like an exercise in whack-a-mole." Roy Fielding's 
> stated opinions on that dispute between FSF and Apache were as usual dead-right.
> FSF's objections to Apache 2.0 came out of left field.  

If you read the whole history then it is clear that the FSF was (at least according to the public record) pretty consistent. Patent retaliation clauses are not GPLv2 compatible. That doesn't mean they are not a good idea, they are. And that is why GPLv3 does contain one.
Based on the same language the FSF suggested the ASLv2 should adopt.
That is also what they said publicly they would do when reviewing the
ASLv2 draft and when the ASLv2 was finalized.

The point is not who is "right" about who is reponsible for this dispute which is now 10+ years old. Reading the whole history shows some people might misremember or misunderstood what was said by whom, or simply assumed the opinion of the other didn't matter. Sadly that happens.
The point is just that at least with respect to patent retaliation clauses and the GPLv2 the FSF has publicly been very consistent.
So if the point of this license is to be explicitly GPLv2-only (and not just GPLv3+) compatible, then adding a patent retaliation clause is not the way to go. Just stick with an explicit patent grant.

> Here's another example: Apache2.0 allows AFL3.0 contributions. GPLv3 
> allows Apache2.0 contributions presumably including those AFL3.0 parts.
> But GPLv3 doesn't allow AFL3.0 contributions because that license 
> "contains contract provisions."  :-)  You figure it out.

This seems somewhat offtopic for this license review. And it seems that the simplest explanation is that the presumption is incorrect. But I think it shows that if your goal is to create a new license that is compatible with another one, then it is good to talk to the license steward to make sure your assumptions are correct.

Cheers,

Mark
_______________________________________________
License-review mailing list
License-review at opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review