Hacker News new | past | comments | ask | show | jobs | submit login
RFC: Improving license and patent issues in the LLVM community (llvm.org)
63 points by protomyth on Oct 26, 2015 | hide | past | favorite | 19 comments

The Apache license isn't compatible with GPLv2.

Isn't it possible to take a standard patent clause and add it to their UIUC/MIT licenses? Google has done something similar with Go, using BSD + their own patent grant.[1]

[1] https://golang.org/PATENTS

A. GPLv2 also isn't compatible with GPLv3, or a host of other licenses as well (There is tons of software that is not GPLv2 or later). So far, nobody has pointed out a piece of software this would cause actual issues with[1]

B. I wrote that patent clause ;) The patent clause is one-way, and works in part because Go collects CLA's that grant google and contributors other patent rights.

So using such a license basically has the CLA option as a pre-requisite.

[1] (interestingly, at least to me, this incompatibility this raises weird issues around doing things like using older gplv2 gcc's with newer gcc runtime libraries. The gcc runtimes require gpl compatible software as part of the exception, and define gpl compatible in a way that seems to exclude gplv2 ;P)

I've always wondered why the liability clause in Apache License 2.0 explicitly takes on liability for certain situations compared to no liability with MIT, ISC, BSD licenses, and I fear it because I can't control what users do with code I've published (think rm, fdisk, or anything else that can be easily misused). Can you explain what it means, and why it's not use-at-own-risk? For what it's worth, I like the patent clause for obvious reasons like dealing with current reality.

It's funny that the liability clause seems pretty similar to that found in GPLv2.

What liability does the Apache License accept other than that which is required by law?

"8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages."

The "unless required by law (...)" part is the problem.

Compare it to ISC's disclaimer:


The intent is that I provide code and I'm not held liable if you use it irresponsibly or recklessly. Whatever current laws are, licenses can be tested in some local court and found invalid, but laws change and not all courts rule the same on a Tuesday. Therefore a license should state intent and not encode a certain market's laws from a certain year.

Patents are a special case because of the racketeering going on. Like copyright, the patent system was meant to foster more published work and not as a money making and extortion mechanism. There's a reason why places without concern for copyright or patents are more innovative. In that sense the liberal licenses encourage use in all situations by anybody because they want it to be used rather than restrict who's allowed to use it in what way.

The real problem is that there is no software safety or quality standard which can be measured and tested like for everyday items such as knives or power tools and won't exist for the immediate future. But that doesn't mean we should include disclaimers that hold you liable if somebody deletes their backups with your implementation of /bin/rm.

The interesting question then is if you need and want GPLv2 and Apache License 2.0 because they explicitly claim liability, does that mean you cannot use OpenSSH, OpenSSL or FreeBSD? Wouldn't you in that case be using an "illegal" tool like medicine from another continent?

You are not a legislator, your contract/license can not nullify acts of the legislative branch. If something is required by law it is in there, you don't get a say about it until next election day. I would be very interested to know why you think the ISC license is above the law, do you have any references that say software licenses can nullify legislative acts?

An open source software license is the wrong place to include what's current law in one or more jurisdictions. As I said, it's the job of a particular court to decide if a license is valid in some specific place. An open source software license is meant for the whole world and therefore should only include the intentions of the author without an encoding of current laws. The software is likely to exist longer than some law that was encoded into a license text. I'm sorry you took my text to mean I'm suggesting a license can void laws. On the contrary I was suggesting it cannot, but English isn't my first language, and I may have failed to be clear.

Again, what about the illegality of using a BSD/MIT licensed piece of software if you require GPL/Apache style liability?

GPLv2 incompatibility does seem like a possible issue. Moving to Apache would make it impossible to ever embed LLVM in the Linux kernel, for example. That might seem unnecessary now, but perhaps someday there will be a use for a JIT in the kernel, that we can't foresee.

The same problem might exist with other patent clauses, though - is the Go one compatible with GPLv2?

"Moving to Apache would make it impossible to ever embed LLVM in the Linux kernel, for example"

Because the kernel is GPLv2 only, you also can't embed the GCC JIT, as it's GPLv3.

So essentially, you are screwed along multiple axes

"but perhaps someday there will be a use for a JIT in the kernel, that we can't foresee."

Maybe, but you can't solve every use case on one side.

(IE it may be that the kernel may have to have some licensing movement as well)

Yes, multiple axes, but this would be a regression for LLVM.

In any case, there are other compilers which would remain license compatible with the GPL2, so should the kernel ever need one it could still have one, I guess it just wouldn't be LLVM or GCC.

"but this would be a regression for LLVM"

Surely, but as you can imagine, the LLVM community needs to figure out whether this is a use case they care about (it was raised in that discussion, and i think the consensus so far has been "not really")

Yes, of course.

see eBPF

It seems from what I understand from the discussion that fundamentally you can't have a patent clause in a license and having it being compatible with GPLv2. (IANAL)

Edit: see the last paragraph in this email: http://lists.llvm.org/pipermail/llvm-dev/2015-October/091636...

> The Apache license isn't compatible with GPLv2.

That seems potentially fixable, if they're changing the license anyway. Apache with an exception for linking to GPLv2 could work.

> Isn't it possible to take a standard patent clause and add it to their UIUC/MIT licenses?

Writing a new license is almost always a bad idea, and if they did write such a license, it should go to OSI and FSF for review first.

Not sure why this got posted, but the gist of it is:

LLVM has reasonable reasons to want to move to either a CLA or straight Apache license (which has a CLA built in).

Then the discussion bifurcates into both a ton of armchair lawyering, and an IMHO reasonable discussion of the merits of each option.

"Not sure why this got posted"

Just figured people might like to know a piece of software a lot of us use might change its license. That change might have positive / negative effects on current activities.

I'd be pretty sad if they go the Apache route, permissive licensing is a longer term benefit IMHO.

Usually when people speak of 'permissive' open source licenses they mean noncopyleft ones including the Apache License 2.0. Do you define 'permissive' as meaning 'textually simple noncopyleft licenses'? (I sometimes use 'simple permissive' for this category.)

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact