LLVM relicensing update and call for help | Hacker News Reader

LLVM relicensing update and call for help

blog.llvm.org

283 pointsingve188 comments

It was a good idea to post this to HN. Back when I was an LLVM contributor I was using an email address from a provider who is no longer around. I had no idea that the LLVM maintainers were trying to get a hold of me. There's probably a lot of overlap between LLVM contributors and HN readers.

Which provider? What was their domain name?

Just Ctrl+F their name in the spreadsheet.

Accessibility of that blog is absolutely abysmal. I read the post thinking "cool, too bad you have no contributor list easily available" but the problem is that links are no-underline white, just like the text itself.

dhs.org in case anyone is wondering.

Thanks for not telling me to use a Windows keyboard shortcut against a spreadsheet I didn't know existed.

Where in that page is a spreadsheet? Maybe I’m just not seeing it on mobile device.

Search for "http" under "Call for help" and click that link. It's linked on the second page.

Yeah that site would benefit from just using browser default CSS.

Yeah. I see one person I know and have forwarded the blog post to them.

MAMEdev hit this problem a few years back as well. Thankfully, the end result of code that needed to be ripped out and rewritten ended up being pretty small comparative to the whole project. A lot of that came down to there being no corporate interests involved, so no corp VS author arguments-- the worst ones to deal with were contributors who were adamant about keeping the original non-commercial license on their contributions.

Did they? That's interesting. No one ever contacted me about my contributions and whether I'd like to relicense them or not. I also noticed someone went through a long time ago and scrubbed a lot of names out of the source code entirely. Which is nice.

As far as I know, anything that they couldn't find an author on was eventually rewritten from scratch. That's the only time a name would be removed from a driver-- a complete redo.

Expect to have someone reach out to you soonish, though, so we can be absolutely sure of what happened and correct any mistakes on our part that may exist.

FWIW, going with Apache 2.0 is/was a mistake.

There is a clause in the license which implies that almost everybody who uses GitHub/GitLab/etc. to work on an Apache 2.0 project in the common workflows is in breech of the license.

Specifically, the license says that every file with modifications has to include a corresponding notice that the file was changed. Nobody does this in practice.

Unfortunately the license is simply badly written.

Licenses like the GPL don't have this problem because they only require that a modified version of the software is clearly marked as such without stating how that marking should be done. So the metadata contained in the Git history should be enough to satisfy those superior licenses.

>Specifically, the license says that every file with modifications has to include a corresponding notice that the file was changed. Nobody does this in practice.

Can't you achieve this easily with a git hook or something like that?

It can be achieved easily by manually editing the file. This is not the problem.

People are in violation of the licence not because it's bothersome to produce the notice, but because they are unaware of the clause.

Yeah it's horrible how Apache 2.0 has become an industry standard with this clause in place. I think this industry standard status was the main reason why LLVM has chosen it.

If the corporate lawyers all agree it’s a standard and they don’t care about that clause then going with the license that the lawyers are all comfortable with seems like absolutely the right choice.

Very likely.

But someday, some lawyer may litigate. Woe betide us all.

While I agree the license is badly written, I think you can construct an argument that the common workflows do not violate the license:

- 4.b says, "You must cause any modified files to carry prominent notices stating that You changed the files." When you modify the file using Git (etc.), the file is stored in the Git database in such a way that it can only be accessed indirectly, by going through an object (a commit) whose entire purpose is to be a record and notice of your modification. That seems pretty prominent.

- 4.c obligates a redistributor like GitHub (etc.) to "retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work." But the prominent notice was never in the Source form of the Work, it was in the Git metadata.

Consider the analogy to the patch-based workflow: if you email a patch to a mailing list, you satisfy 4.b because the email itself serves as a prominent notice, but 4.c would not obligate the maintainer receiving the email to add the information in the email (such as the From: header) to the Source form. They could just apply the patch as given.

This is a somewhat strained reading, to be fair, and it'd be nice to standardize a fewer-clause version of the Apache license à la the fewer-clause versions of the BSDs. It seems to me that the Apache license minus 4.b, 4.c, and 4.d would clearly be a FOSS license by any standard that accepts the existing Apache license.

It wasn't clear to me that "the list of remaining individuals and corporations we need to get agreements from" in "Call for help" was a link since it's not underlined and styled with exactly the same color, font, and font size as normal text. The link points to https://docs.google.com/spreadsheets/d/18_0Hog_eSwES8lKwf7WJ... If you know anyone on that list, consider reaching out to them with a link to this blog post.

This might be the largest contributor relicensing project of any IP category: 2800 people and companies. 94% progress is impressive.

Wikipedia changed its license around 10 years ago, I think.

This was enabled by the license though (GNU Free Documentation License) so they didn't need to contact individual contributors.

Wikipedia was licensed under GFDL 1.2 or later, so relicensed by convincing the FSF to release an updated version of the GFDL (version 1.3) that adds a very narrowly worded clause allowing relicensing that pretty much only applied to Wikipedia.

Which does point to the hidden danger of the FSF licenses when “any later version” exists.

It's not exactly hidden when it's clearly stated in the license, and relatively common practice to omit that clause.

I don't think most people expect the next version of the license to ... lead to a completely different license.

Its not totally different - cc-by-sa is pretty similar in spirit to gfdl with no cover text, non-derrivative sections etc.

Of course practically speaking, being able to legally print out a wikipedia article without printing out the entire gfdl is a pretty big difference. To the point where i am aware of people licensing photos under gfdl to claim its open source while in practise its impossoble to reuse practically.

I mean your point still stands that its weird to release a new license just for wikipedia.

It didn't only apply to Wikipedia, there were plenty of other large public wikis that used to be GFDL-licensed only and were able to transition to CC-by-sa.

More reading for those interested: https://lwn.net/Articles/305892/

> An MMC [Massive Multiauthor Collaboration Site] is "eligible for relicensing" if it is licensed under this License, and if all works that were first published under this License somewhere other than this MMC, and subsequently incorporated in whole or in part into the MMC, (1) had no cover texts or invariant sections, and (2) were thus incorporated prior to November 1, 2008.

> The operator of an MMC Site may republish an MMC contained in the site under CC-BY-SA on the same site at any time before August 1, 2009, provided the MMC is eligible for relicensing.

Not to be crass, but surely some of these people are just.. dead?

It's an old project, and a lot of contributors.

What happens to the ownership of code in that case?

Ownership goes to the author's heirs.

OpenStreetMap’s relicensing (from CC-BY-SA to the Open Database Licence) involved more contributors and, unlike Wikipedia’s, wasn’t assisted by a licence hack.

> The copyright owner can be either an individual, for example the person who wrote the code originally; or a company, for example a company that employed the person who wrote the code.

Here, there be dragonnes...

I can easily see an IC agreeing to a relicensing, thinking they had full rights, but their employer, at the time, had a "shower clause," and trying to (and maybe succeeding in) getting that section of license nullified. At least, costing the LLVM a bunch of money and time.

This was one reason that I made sure that my employer did not have a "shower clause," before starting to develop a lot of open-source software.

Knowing them, I'll bet that people hired after me had to sign that away, but I was never made to sign anything like that; even retroactively.

This is a mammoth effort, and I wish them well. I suspect they have already wargamed a lot of the possible issues.

> The copyright owner can be either an individual, for example the person who wrote the code originally; or a company, for example a company that employed the person who wrote the code.

Here be dragons indeed. This is flat out incorrect. In quite some jurisdictions, copyright is a nontransferable inalienable right any authors gains upon writing something, in perpetuity (can't even be transferred after death). Others, such as employers, may merely license is, sometimes exclusively.

I'm sure you're right that that's how it works in some jurisdictions.

But it's not how it works in the US, which is where the person responding to you lives. In the US, copyright is transferrable, and "works for hire" are initially owned by the employer.

Either way, saying that the quoted bit is "flat out incorrect" seems like an overstep, in my opinion.

LLVM has contributors from all over the world, hence it is relevant. It is certainly not an overstep. I work on a project with contributors from a few countries and this proved a major blocker for changing our license (not impossible, but much work!)

Is the distinction here really germane? If someone else holds an exclusive, transferrable, perpetual, sublicensable license to a work you produced, that's more or less the same as holding the copyright from LLVM's perspective. Of course all this only matters if they encounter a situation where it is difficult to determine the rightsholder, and they are not able to obtain agreement from all potential holders, and there ends up being a dispute.

In such jurisdiction, copyright attributions/assignments are simply not legally possible. We've had to scrap the one in place for on of our projects.

The type of contract you should have contributors from such jurisdictions sign is a license to use. If you haven't, getting 'permission' is meaningless; the author possibly (in my experience: probably) doesn't know they're actually not legally able to agree to such a change.

I imagine if this ever comes to bite projects in a big way, they'll move to the legal agreement of the type you suggest, and/or cease accepting contributions from the relevant jurisdictions.

That being said, LLVM is not asking for a copyright contribution here. They are asking the contributors to sign an agreement, the meat of which is, "The Contributor authorizes LLVM to include the Contributions in the LLVM project, and the Contributor hereby licenses the Contributions under the terms of the Apache Software License, version 2.0, with the LLVM exception." That's not a copyright assignment.

Other groups also do not ask for a copyright assignment. Here's from Google's CLA: "Subject to the terms and conditions of this Agreement, You hereby grant to Google and to recipients of software distributed by Google a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works." In this agreement, you still own the copyright, but you've given Google a perpetual, worldwide, royalty free and sublicensable license, which means that Google could basically reexport your contributions under whatever license they want. Facebook/Meta's CLA is almost identical. They aren't excluding any countries from contributing, so presumably this type of language is sufficiently enforceable everywhere.

But if you grant a license that's sublicensable and exclusive (with all the extra legal rights granted), that's effectively transferring copyright since you can do everything you could as if you had transferred copyright.

However, in most jurisdictions where copyright is non-transferable, the original holder also permanently retains a right to cancel any such licensing agreement, at any time without cause. They cannot grant a license in perpetuity, and any language in the license to that effect has no legal weight whatsoever.

As far as I can find online, this is an edge case that's unlikely to ever be relevant.

Dutch law allows the voiding of licenses after "unreasonably long" terms. One suspects that it would be hard to show that a term is unreasonably long when you're talking about a contribution to open source software.

In Poland, there's a limit of five years, on the author's wish, with one year's notice. Fair enough, a Polish contributor might possibly demand that their code be taken out of a projects with a year's notice. It seems unlikely that many Polish devs will exercise this right, since, if their contributions are significant, it would probably result in blacklisting, and if not significant, it would probably not be worth it. But I suppose it could happen. If it happened often, Polish devs would likely stop being welcome to contribute to open source projects.

In Canada, there is automatic time-based reversion of rights 25 years after the author's death. So if you write code at 35, and die at 80, your estate could conceivably demand that your code could be removed from a project 70 years after you wrote it. Similarly, in the United States, you can revert your rights after going through some process and paying a fee after 35 years.

The probability of any of these things happening seems sufficiently remote that it doesn't seem worth worrying about. Technically these CLAs might not actually grant perpetual licenses, but in practice they're likely close enough.

I don't think you've quite understood the risk, here.

> Fair enough, a Polish contributor might possibly demand that their code be taken out of a projects with a year's notice. It seems unlikely that many Polish devs will exercise this right, since, if their contributions are significant, it would probably result in blacklisting, and if not significant, it would probably not be worth it. But I suppose it could happen. If it happened often, Polish devs would likely stop being welcome to contribute to open source projects.

This is the same for Australian developers.

This is also where the primary risk is, and it cannot be mitigated by _any_ copyright license. At any point in time the authour can revoke the license, which is an unlikely event, but because of how licensing works, they can revoke the license for _one individual or corporation_, as well.

For example, it is conceivable that someone who has contributed to a large project, say... Linux, has an issue with one particular corporation who have been found to acting unethically, say... Google. They can revoke the right to use their contributions to the Linux kernel by Google. They don't have to supply a reason for it.

This is thus far untested in court, but that is what the current copyright framework allows for.

The developer may risk blackballing themselves, but they may also not care at all. They may do so by making it about idealism, in which case what they are capable of has little to do with their own personal future.

> This is the same for Australian developers.

I don't see any sign of this being the case in my searching. This document (https://www.lexology.com/library/detail.aspx?g=628b5bca-b7d5...) suggests that Australia does recognize perpetual licenses ("Does the law in your jurisdiction recognise the validity of ‘perpetual’ software licences? ... Yes."). Would you provide a citation?

> For example, it is conceivable that someone who has contributed to a large project, say... Linux, has an issue with one particular corporation who have been found to acting unethically, say... Google. They can revoke the right to use their contributions to the Linux kernel by Google. They don't have to supply a reason for it.

As noted above, I'm skeptical that this right exists in Australia. But if it does, the worst that would happen is that a person's contributions would need to be removed from Linux. There are probably a handful of individuals who own the copyright to their works whose contributions would be difficult to replace, but most of them probably have sufficient economic or other incentives not to do something like what you're describing. That vast majority of new code written in Linux is written by employees of large corporations and isn't subject to this risk the same way.

> This is thus far untested in court

To say the least. It seems likely to me that courts in many jurisdictions would decide that an open source bait and switch was not what their corresponding legislatures had in mind when drafting license reversion rules. This risk seems unlikely to me, because you'd need a dev with plenty of wealth to pay lawyers, who also really hates some company beyond any practical economic extent, and also contributed a lot to Linux as a private individual. I don't know how many of that type of person you're going to find.

> As noted above, I'm skeptical that this right exists in Australia.

The right to control the integrity of one's work is a Moral Right, and moral rights fall outside of copyrights in Australia. A very basic introduction is here [0].

Granting the use of a work in perpetuity is permitted, but revoking that perpetuity is also permitted and cannot be limited.

> But if it does, the worst that would happen is that a person's contributions would need to be removed from Linux.

In the example I gave, Linux wouldn't need to make that change, as the revocation only occurred for a single sublicensee. The Foundation might choose to make that change, but they also might not.

> because you'd need a dev with plenty of wealth to pay lawyers, who also really hates some company beyond any practical economic extent, and also contributed a lot to Linux as a private individual. I don't know how many of that type of person you're going to find.

Individuals like Richard Stallman? He may not have direct wealth, but he has the means to obtain it. And the ideology necessary to become a thorn in the side of a particular corporation if he so chooses.

[0] https://www.copyright.org.au/browse/book/ACC-Moral-Rights-IN...

Looks like the moral rights regime in Australia is pretty similar to that in many civil law systems. You cannot just revoke your license based on the right of integrity. Where do you get that idea from? Based on the introduction, it works just like in most other systems: you would have to show derogatory treatment. And that, considering the nature of the work (computer code committed to an open source project), seems to be hard if not impossible in any conceivable circumstances.

> In the example I gave, Linux wouldn't need to make that change, as the revocation only occurred for a single sublicensee.

The other person already responded to your understanding of moral rights. I would also question this assumption. A copyleft license that excludes certain participants who are otherwise complying with this license because of animus on the part of one contributor is not really a copyleft license in spirit. It would be an untenable precedent to set that any contributor can effectively ban anyone they like from using Linux. I strongly doubt the Linux community would keep code like this even if they were technically allowed to.

> Richard Stallman ...

Would never countenance a situation like the one you're contemplating. He cares most about software freedom and what you're describing is basically the opposite.

> It seems likely to me that courts in many jurisdictions would decide that an open source bait and switch was not what their corresponding legislatures had in mind when drafting license reversion rules

Whether or not this works is dependent per-country; many countries have judicial systems which do honor the intent of a law, while others (most common law incl. USA) read strictly by the letter of the law, which is why legal loopholes exist.

>m8r-9yw8a5@mailinator.com "/dev/humancontroller"

That one should be fun. An anonymous mail account service.

Those will be the code to replace in the final step.

Looking at the spreadsheet, it looks like his only commit is one that changes a bunch of %lu to %zu? I think that's trivial enough that it's not copyrightable.

LLVM likely doesn't want to take the risk that a court could find it copyrightable if the author decides to file a lawsuit. My guess is that regardless of the triviality of the change they're requiring these agreements.

I am not a lawyer.

The article talks about options for remaining contributions for which they can't get in touch with the contributor, and says:

"We can check if copyright even applies to the particular contribution. Very small contributions may not be covered by copyright, and hence may not need a license agreement."

It is an anonymous e mail address, there is no way for anyone can actually prove that they are the contributer.

not a lawyer, obviously

I think that, depending on circumstances, it _can_ be trivial to prove in court. Examples:

- If the contributor can prove they checked that specific mailbox during the period involved (for example from logs, or because the git repo of their system config shows they ran a cron script checking it)

- If the contributor can have a few others state in court that they received other messages sent from that account around the time that must have come from them.

- if the contributor mailed a few friends saying they contributed to LLVM, giving some details of the changes.

I would expect courts to accept either as enough evidence.

On the other hand, if you can't prove to a court that you wrote the code, then you can't claim to have copyright over the code for the purpose of accusing LLVM of infringing your copyright by relicensing your code.

Not that I suspect LLVM to take that kind of risk, but it is an interesting consequence of anonymous contribution.

Racket had to do this to go from lGPL to Mit, it was a long process. But they did it to make the language more accessible to developers. Developers are scared away by lGPL.

Not all contributions were relicensed (resulting in code being rewritten), and we lost some code in the standard library (the csv parser).

Now Racket is trying to make it more friendly to people by created a new language (called Rhombus for now) that is Racket without the parenthesis.

They are playing the long game. But I hope these changes attract new Racketeers in the future

> Developers are scared away by lGPL.

I see GPL as a sign of quality and am attracted by projects using it. It's a promise nobody will ever take that thing away from me once I've started using it.

I'm a developer, by the way. :-)

Edit: Not to mention that some people even using GCC, Linux and Java.

Out of curiosity, how does the GPL promise that versus the other common open source licenses? E.g MIT, BSD or Apache?

As I understand it:

MIT code can be freely taken into proprietary fork, with software modified and sold and no patches contributed.

Not sure how often it happens? Has it actually happened and is it a plausible attack? Nowadays at least AGPL is needed to defang "and we will sell it as service rather than selling software" workaround for GPL.

As a practical matter, it means you cant just copy the files into your sources to some subdir, or you cant just link it statically. So you cant release a single-exe version of your project.

These are things some projects like to do, and GPL blocks that. So all thing considered, it may be easiest to just not use GPL code.

you can't copy MIT-licensed files without crediting it either.

And you can statically link GPL code, assuming you release the source to all app users. You might be confusing it with LGPL, which says you can link to proprietary apps dynamically, but have to release source in all other cases.

You can also link to proprietary apps statically if you provide the object files: https://softwareengineering.stackexchange.com/questions/3127...

I thought useing GPL code without modifications was acceptable without any licensing, or is that a 'lesser GPL' license?

You're thinking on the LGPL.

The GPL is the prototypical copyleft licence, designed to encourage the liberation of software, in part via its dependencies.

You can use GPL code however you want.

You have only obligations when you distribute the results. Whatever you do in your private basement is completely unaffected by that. The GPL gives you freedom to do whatever you please. That's the whole point of it!

When you distribute binaries resulting form work based on GPL code than the people receiving those binaries (and only them) are eligible to get alongside the source code which allows them to rebuild the binaries you distributed to them. That makes sure that those other people also have the same freedom as you to do whatever they please with the programs and code. So the GPL preserves freedom among users of GPL code.

Apple's OS is a fork of BSD without the fork being open source.

It’s more complicated than that. It was not a fork, they just copied some parts of FreeBSD and OpenBSD. The kernel is XNU, and descended from Mach. Also, Darwin (the base OS, which includes the BSD bits) is open source. What isn’t is the GUI on top of it, which comes from OPENSTEP.

The open source part of Darwin/XNU doesn't deserve to be called a "base OS" since version 6, when Apple closed the sources of a lot of drivers. There's no hardware that will boot these systems if you restrict to what is available under the APSL.

https://web.archive.org/web/20091118172944/http://www.pureda...

https://github.com/apple/darwin-xnu

Apple derived OSes, the Windows TCP/IP stack before Windows Vista, PlayStation OSes, Nintendo and Playstation SDK, the BSD stuff taken into commercial UNIXes, just from top of my head, there are surely other examples.

GPL software, and extensions to it, are free and will stay like that.

That can't be said about software under the above mentioned licenses.

I'm not sure how the GPL guarantees that it will stay like that anymore than those other licenses?

You can always relicense GPL content as long as everyone agrees. You can also change it to source on request versus always accessible.

key is "as long as everyone agrees"

If you wrote the code, you can refuse to relicense.

OP also said it was a sign of 'quality'. Not sure how GPL promises that over other OS licenses.

I'm the OP and I'm not a native speaker but to my knowledge "quality" denotes in English besides a few other things the meaning of "value" (in the sense of worthiness) or (related to that meaning) "excellence". Something being high-quality makes this thing valuable.

I didn't mean "code quality", or the like, as a license can not enforce that obviously.

> I see GPL as a sign of quality

Personal opinion is that BSD > GPL. Free as in properly free. I always donate to BSD license folks. When corporations use BSD software, they usually get engaged in the BSD community - under the stilts of management, suited lawyers and spreadsheet bean counters, it's just us programmer folk... you know. We like tinkering things and BSD software tends to have a different philosophy. Very welcoming to people who want to propel the world forward. Truly liberating, try BSD software.

This is a matter of hot debate, and I don't want to trigger such discussion. AFAIU it is a bit of perspective of where the freedom is. With BSD there's more 'freedom' to incorporate with proprietary code, which eases commercialization. Companies like it better because of that and are likelier contributors. With GPL, while you can still monetize your code, protects the freedom of the Commons better by preventing the proprietary commercialization of open source code. And that is a reason why many businesses shun it. Personally I am in favor of the 4 freedoms of open-source and like to use (A)GPL.

Yeah, agree it is hotly debated and not worth discussing further. I've recently been bitten by GPL and it's fresh on my mind how insidious it can be. That said, I work in commercial environment where BSD-licensed software is highly regarded.

Saying that corporations prefer something they can profit from without giving back vs something they can not is circular reasoning to me. Conversely if you look on the other side you'll see developers bitten by permissive software licences (MongoDB, Elasticsearch, ...).

"without giving back" is a bit of an exaggeration. You could have a giant 20M line proprietary codebase, and if you incorporate a 20-line function from a GPL source, GPL says you need to relicense the whole thing.

I prefer the MPLv2, it lets commercial users actually use the code, but they still have to contribute back any changes they make.

Or lacking adequate case law, that's what the FSF et al. would want you to believe, anyhow. Although a bit vaguely drafted in this respect, the copyleft effect of GPL depends on the concept of a derivative work under copyright law. It would be a bit far-fetched to claim that in your example, the combination of the function and the codebase is a derivative of the function you incorporated.

Anyway, because the fact that people think GPL is that extensive is enough to create unnecessary problems, I too prefer MPL, where the copyleft scope is defined very clearly for its use case.

I don’t think it matters whether the GPL can successfully be enforced against the example you describe. The license’s author intended that it could be, and that is what matters.

A philosophical disagreement with the license’s intent shouldn’t be overlooked just because the license might not actually be enforceable.

So you would be actually fine with GPL if excerpts up to 1000 lines were not covered by copyleft?

No, the GPL is for what it's for, large codebases like Linux where you want to make sure it doesn't fragment too badly. Most code isn't this, though.

> I prefer the MPLv2, it lets commercial users actually use the code, but they still have to contribute back any changes they make.

Sure, but how is this verifiable? Not verifiable = not happening.

Anyway, the idea of using a 20 line function in a 20M line codebase is a total strawman. Think of it from the 20 line function author's point of view - free money for corporate? They lack the expertise internally to write this function?? It's crypto code and getting it 100% right is extremely valuable? Then they need to be licensing it from the author.

It sounds like the idea you have here is that someone has licensed their code under the GPL but "didn't really mean it"? I think you should flesh out that side of your argument... why should corporate be permitted to use this code? Authors who are worried can release their stuff as MIT or CC0.

Companies have a legal department to make sure this kind of thing is followed, otherwise they have potentially huge liabilities.

For things that have a single author, the relicense option is possible, yes. But how about projects that have several?

To me the great thing about software is that other people can use the code I wrote without it costing me anything. I understand the various attitudes of wanting others to be bound by some terms of sharing the work they do too, or paying for a license, but at least from my experience it limits the adoption of my code, and I'd rather my code be useful in as many places as possible, with the only requirement being that if you fix any bugs or extend the functionality in a deeply intrusive way, you contribute that back.

Not all corporations are assholes. Many give back, many people contribute code often becomes the reason for the project to exist. They give life to open source projects by buying support and sustenaining their livelihood.

I am sick of this constant myopic view that all corporations are evil and people working there have no regard for open source development.

The truth is probably closer to being opposite than the anti-corporate crusader zeitgeist of HN. The point of the original comment was to express that behind all the corporations, there are just real people like you and me.

I was only commenting on the reasoning. It's not a question of evil, just of basic business incentives.

> The truth is probably closer to being opposite than the anti-corporate crusader zeitgeist of HN. The point of the original comment was to express that behind all the corporations, there are just real people like you and me.

I'm a (small) business owner so I'm fully conscious of that. But it's a reality that past a certain size a corporation will optimize for its best interests given the current set of rules (law). If a company contribute to open-source it's not because they are nice, it's because the added value in marketing/hiring/commoditizing their competitors makes business sense, otherwise no matter their convictions people would get punished in their performance review, and the stock value would tank. Only specific corporate structures allow people inside a company to go against the baseline.

With few exceptions, I generally view the purpose of permissive licenses as "encouraging derivative software with EULAs and other restrictions", and the purpose of copyleft licenses as only allowing derivatives that don't restrict such freedoms.

Copyleft software therefore guarantees more freedom than permissively licensed software.

The choice often isn’t between having a given derivative work be permissively licensed or copyleft. It’s between having the derivative work exist at all or not.

As a software author, choosing a license that requires people to be subject to more conditions to use my software is giving them less freedom, not more. If someone makes a derivative work with a restrictive license, that doesn’t make my software any less free.

> that doesn’t make my software any less free

You might say it makes your software less yours, though.

A restrictive license protects your interest in the code. After all, that's why companies are releasing their code under restrictive licenses.

100% agree there's a tradeoff of this with popularity, and it will never matter for almost everyone. But the people for whom it does matter get upset sometimes --- licensing is a choice that needs to be made with eyes wide open.

People can't simply take away MIT-licensed code either - it grants you the right to use that code, and does so irrevocably.

What GPL does is make sure that code that is built on top of that will also be accessible to you, if the product it's used in is made public. But your own contributions and anything MIT-licensed it is added to will never be legally taken away from you.

With software, we don't see any frozen particular version as the main asset, but the continuity of the project is the asset. Otherwise we wouldn't de-value unmainted software so much. (The code is there, the license is clear, it could be used).

GPL makes sure the project's main strand of development stays accessible to you.

Well, unless the copyright holder of that code decide to use another licence in the future — then the snapshot that was licensed as GPL will remain available to you, but the main strand of development may not.

But yes, if this copyright is spread over many people (as it is in this case), then re-licensing is a herculean effort that is especially unlikely to succeed if it's designed to take away user rights, so in that sense a GPL'd project is more likely to remain open.

That's a different situation, because the LGPL is not a problematic license in terms of drafting.

With LLVM, the license isn't really changing in spirit. The concerns seem to be more practical — my understanding is that they're trying to get out from under a poorly drafted patent clause and also unify the code under a single license so they can move stuff around more easily.

Many major corporations (like, say, IBM) have no problem with LGPL. Where did you find a bunch of developers who thought it was a problem?

It's not the developers who are afraid, it's the companies who want to use the code for free, for proprietary purpose, and redistribute it. They want to take as much as possible but don't want to give anything.

I would rephrase to "they want to take as much as possible but don't want to give back the entire codebase using the free software".

LGPL doesn't require to make the entire codebase free software

(GPL does. It is part of the contract: get some, give some.)

Thanks, I was just thinking this month how I would like to write lisp without parens.

> Developers are scared away by lGPL.

For me it's very much the opposite, I refuse to contribute code to anything licensed under the MIT/BSD/etc family of languages.

It makes me sad to see so much confusion, incorrect information, naiveté and paranoia going around regarding the GPL that it's scaring people off. I think that most of these people would feel differently if they understood better.

I think the systematic defanging and watering down of the free software movement is a great loss.

I don't think people who shy away from GPL are in favor of the free software movement. People who advocate for MIT like licenses like 'open source', but they usually explicitly reject the ideas from free software.

Some of these concerns are simply commercial, and some are philosophical. I think people might have been convinced to dislike GPL. But I don't think that was misinformation or confusion. It might be fear-mongering about the effects of a 'viral license', but we can only guess at their effects.

Personally I dislike GPL because it limits developers like me, and because I find the (roughly true) idea 'you can only use GPL code if you're own code is GPL' too coercive. I don't think that is a virtuous method for improving the world.

If those people are coherent I assume they are also contributing and running one of the BSDs as their main UNIX.

Huh? I would guess most people are pragmatic and are happy to use and contribute to any software licensed under OSD-compliant terms. You can do that while still preferring to contribute to permissively licensed projects. Of course that goes both ways, I don't see many free software purists that refuse to use permissively licensed software either.

I have yet to see BSD / MIT meaningfully improving my personal life, quite unlike the GPL which pretty much made my career possible thanks to the wealth of GPL software under Linux

Have you ever used software linked against OpenSSL? It’s licensed under APL, which is very similar to the BSD family of license - it allows use in closed source projects. Or OpenSSH - it’s developed by the OpenBSD folks and licensed under a BSD style license. Or Firefox - licensed under MPL, very similar to APL. The rust compiler is dual-licensed under MIT/APL. Both ruby and python are dual-licensed with at least one license from the BSD/MIT group, the python license itself is similar to BSD as well. The Linux kernel allows incorporating BSD/MIT licensed code in the kernel itself and though I didn’t check, I’m certain there are examples.

> and though I didn’t check, I’m certain there are examples.

The whole GPU driver subsystem for example.

> Have you ever used software linked against OpenSSL? It’s licensed under APL, which is very similar to the BSD family of license - it allows use in closed source projects.

well, if I could I'd definitely choose gnutls over it even before getting to licensing issues tbh. Also how much better did it being useable in closed-source projects (those I don't use unless there's really no other viable choice and doing it myself is not an option) make it ?

> Or OpenSSH - it’s developed by the OpenBSD folks and licensed under a BSD style license.

yes, though I'm not sure if I'm using any openssh-specific interface, ssh -X maybe ?

> Or Firefox - licensed under MPL, very similar to APL.

MPL is closer to GPL in spirit than MIT/BSD, no ? AFAIK you can't make a closed-source derivative of Firefox (which is what matters).

> The rust compiler is dual-licensed under MIT/APL.

I don't use it. The only Rust software I'm using is ripgrep I believe ?

> Both ruby and python are dual-licensed with at least one license from the BSD/MIT group, the python license itself is similar to BSD as well

I don't use either neither as a developer or a user, the huge majority of my direct interaction with my computer is through C or C++ software; mainly KDE stuff.

But all of this is besides my point - if there wasn't a big ecosystem of (L)GPL software existing when I was a teen (Linux, KDE, core/binutils, GCC etc) I'm not sure I could have taught myself enough computing to achieve what I seek to. If everything was BSD I doubt these software would have evolved into something good enough to make for a correct desktop experience (last time I tried a BSD it was deeefinitely not useable enough for me unless replacing most of the BSD base with the GNU one like I do on my mac machines for instance). I've also used proprietary software for instance, but I would not say they made my life "meaningfully better".

It's debatable that most GNU stuff would be available if it were not for BSD.

> Personally I dislike GPL because it limits developers like me, and because I find the (roughly true) idea 'you can only use GPL code if you're own code is GPL' too coercive. I don't think that is a virtuous method for improving the world.

I have no idea what you're talking about. You can use gpl code without being the owner of said code.

You're thinking in very selfish terms. The gpl is bot about safeguarding rights for the developer, but instead it safeguards rights for the user. When code is licensed as gpl, it's a promise to the user that they'll always be able to get, use, and modify the code for the software. That comes at the cost of developers not being allowed to make the code private.

I think that safeguarding user rights is a virtuous method of improving the world.

> I have no idea what you're talking about. You can use gpl code without being the owner of said code.

When I use GPL code in my projects, that forces me to publish my projects under GPL. That limits my freedom as a developer. This is indeed thinking about my needs more than thinking about general needs.

> I think that safeguarding user rights is a virtuous method of improving the world.

I agree that the world would be better if more/all code were open source and user-modifiable. I do not agree that the ends (user freedom) justify the means (GPL or other copy-left licenses). I think the means are harmful because they are coercive. If we look at the effect of GPL on the ecosystem, e.g. ZFS, you see that people re-license to GPL because the alternative is untenable maintenance wise. This re-licensing is not happening because people agree with the license, but for practical reasons. Essentially a few people have decided "this is exactly how things need to be" and through copyleft licenses, they are twisting the arm of everyone else. That is not how I think it should be decided how intelectual propert rights should be improved.

In the ZFS case, essentially what GPL was meant to prevent happened. There was an open piece of software (ZFS), people were making improvements to that software (ZFS on Linux getting development), but they could not be used upstream.

GPL is a one-way street in the open source world. It sucks up code from other open source projects but it cannot give anything back. In some cases, I think this makes GPL a net negative for the open-source (using the wide definition) community. I think the only defense GPL can offer here is "but that part of the open-source community is wrong and harmful". I think it makes sense that the non-GPL parts of the open-source community are not happy about that stance.

In general "if you just do exactly as I want there is no problem" is not how we should treat each other in my opinion. We should leave room for different viewpoints and some form of discussion. Rather than saying "my way or the highway". If you take that stance, then don't be surprised people don't want to cooperate.

The number of people who refuse to commit to MIT/BSD/etc. code is almost not existing, the number of people who refuse or cannot commit to GPL is plentiful.

> It makes me sad to see so much confusion, incorrect information, naiveté and paranoia going around regarding the GPL

I agree, there are still too many people who think the GPL is _just_ another license. It's not and many figured this out the hard way after they already accepted contributions under the GPL and moving away has become hard to impossible.

Moving away from any particular license is hard to impossible.

Not being able to relicense code provided by other people without their agreement is definitely a feature of any license.

Let’s not kid ourself: the main reason companies don’t like the GPL is because they don’t want to share the code they actually use in their products. Making that impossible is an intended consequence of the license not some unforeseen flaw. If you are fine with companies profiteering from your work then choosing the MIT or BSD license definitely make sense.

The whole discussion really is about commercial interest in the end.

The biggest risk of the GPL is in fact not companies but to you as a creator. If you plan on commercializing your work in any capacity, accepting contributions under the GPL will be the end of that. Given the murky laws around copyright reassignment getting contributions in under a more liberal license so you retain extra rights yourself is tricky.

There are many projects which learned after a few years that their choice of license backfired on them.

> The biggest risk of the GPL is in fact not companies but to you as a creator. If you plan on commercializing your work in any capacity, accepting contributions under the GPL will be the end of that.

If you accept contributions, that’s not your work anymore. That’s your work and your contributors work. You are still perfectly free of removing said work and commercialise your own. You just can’t profite from the work of others without asking them. That’s a feature of the license not a risk.

> Given the murky laws around copyright reassignment getting contributions in under a more liberal license so you retain extra rights yourself is tricky.

You are misrepresenting the situation once again. It is not about retaining your own right. The whole issue is on the work of others.

Something does not stop being my work when it hat contributions from others but generally that’s besides the point. The main issue of GPL comes from the risk to the original creator itself. Others not using the software is less the concern.

> The main issue of GPL comes from the risk to the original creator itself

The risk of abiding by the license? The GPL ensures user have access to source code provided under the license, so I'm assuming by "commercializing" you mean hiding away source code that used to be public? The calculus is simple: if you want to make money by doing an open-source bait-and-switch, do not license your code under GPL.

Commercializing can happen in many ways. GPL code in itself can’t even be published on the app store without violating the license. If you are not the complete copyright holder you can run into issues very quickly.

> GPL code in itself can’t even be published on the app store without violating the license

Did you mean without violating the app store EULA? Because the GPL places no restrictions on how generated binaries are distrubuted, only that the source be transmitted to any user upon request.

If a single line was written and contributed without copyright assignment, than line is theirs. The project can be yours, but you no longer own 100% rights to it.

Precisely. Which is why releasing code under the GPL requires a lot of up front consideration.

> Something does not stop being my work when it hat contributions from others

Of course it does both from a legal and moral point of view. Composite work is the product of their authors plural. You are perfectly free to strip it from the contributions of others and relicense your actual work.

> The main issue of GPL comes from the risk to the original creator itself

You keep coming back to that but still have to explain what they are. Yes, the GPL prevents you from relicensing the work of your contributors. That's not a risk to the original creator itself.

Without GPL, people wouldn't be enjoying their Linux distribution, but naturally this is a moot point given how the BSD distributions have taken over the UNIX world.

Commenting on BSDs losing out to Linux seems like a weird dig in this context, considering that a large contributing factor to that was legal threats from AT&T.

Something that keeps being forgotten, those legal issues were settled in 1994, after USL also getting a counter lawsuit for their own use of BSD code, while Linux itself was a target of a lawsuit a decade later thanks SCO.

>while Linux itself was a target of a lawsuit a decade later thanks SCO.

The dust was settled then, Google and all were on linux. Compared to BSD era. Not to mention the legal threats were not in the same order of magnitude.

Yet the licence that provided an escape route gets bashed, so much gratitude.

I think there are many reasons for Linux 'winning', and it's not easy to attribute weights to each one. GPL is probably one, Linux having a better development model more open to outsiders is another, arguably more important, one.

> Linux having a better development model more open to outsiders is another, arguably more important, one.

Not to mention being easier to try out (the path to becoming a developer starts with trying it out). Back when Linux was growing, it was very easy to install, to the point of not even needing to repartition the disk; through the magic of UMSDOS and LOADLIN, you could install it to your DOS partition and treat it as if it were a DOS program (with the only difference being that you couldn't "exit" Linux back to DOS without rebooting). From what I've heard, not only was that not possible with the BSD distributions, but also they were more picky about the hardware. That was the path I took: when I wanted a true Unix-like (instead of just playing with DJGPP), I did some research, and concluded Slackware was the best option, mainly because it had UMSDOS and so if it didn't work out, I would just have to remove its directory (of course, once I noticed I wasn't even using DOS anymore, I dedicated a full partition formatted as ext2 to Linux, and later started installing Linux exclusively).

Walnut Creek CD-ROMs also provided a way, including live CDs.

It's not forgotten, it just doesn't matter in any meaningful way. We're talking about two years of legal issues that took place during one of the fastest moving eras in computer technology. In Linus' own words at the time that this was happening:

"Actually, I have never even checked 386BSD out; when I started on Linux it wast available (although Bill Jolitz series on it in Dr. Dobbs Journal had started and were interesting), and when 386BSD finally came out, Linux was already in a state where it was so usable that I never really thought about switching. If 386BSD had been available when I started on Linux, Linux would probably never had happened."

The SCO lawsuit that happened a decade after this is pretty much irrelevant.

And a couple of years later everyone turns their back to the license that made Linux and its userspace in two years happen in first place, it is forgotten.

>Racket had to do this to go from "lGPL"

Is that a typo of LGPL or does lGPL means something else? I even had to google it to make sure it was a "L" and not an "I".

> lGPL

I was googling "I" GPL. Maybe consider upper-casing the L next time so it's not as ambiguous?

I found at least one name I recognize in the list, and I'm emailing that person. Hopefully we can get the long tail shortened!

Thank you!

This kind of thing feels like such a waste of humanity's time. Is there an approach you can choose early in a project on that prevents ever getting in trouble later?

I guess if I start some big library I will hope that everyone assigns the copyright for their contributions entirely to the project so that I never have to go through that nonsense. But I guess that has other ramifications.

> Is there an approach you can choose early in a project on that prevents ever getting in trouble later?

1. Never accept outside contributions in principle. Works fine for SQLite, for example.

2. Pick a well-known copyleft license and just stick with it. Works fine for Linux, for example.

3. Use a well-known permissive license that allows redistribution of modified code under a different license without burdensome conditions. Works for lots of projects.

4. Force contributors to assign copyright to an entity that people will trust forever. Ostensibly works for FSF folks, academia, etc.

5. Don't worry about it. Let others pay for lawyers doing law stuff. You can delay making the decision until you have at least a dozen of actual contributors.

There is also

6. Have a CLA (contributor license agreement) that lets the project the right to change the licence. (Different from 4. because there is no copyright transfer).

CLAs are shaky, it might not be valid in some countries that e.g. do not allow reassigning copyright.

That's why CLA is not copyright assignment.

That's why you can't on a whim write a CLA, yes. That doesn't mean there aren't CLAs what try reassigning rights directly or indirectly that they really can not.

I think rolling your own license is like rolling your own crypto: just say no.

Is Rafael de Espindola on that list? He seems to have left on not that great terms and I can imagine him not being interested in supporting a license change. He was a prolific contributor.

I don't see why he would necessarily be against relicensing, frankly. His rejection of racial discrimination (which LLVM indirectly supported in that case) has nothing to do with licensing of the code.

I guess I should be, but I don't see myself there. I haven't agreed to changing the license from the beginning:

https://lists.llvm.org/pipermail/llvm-dev/2017-August/116370...

I have contributed to LLVM while working for INdT in Brazil, Google in Ireland and Canada, Mozilla and Sony Interactive Entertainment (both in Canada). I probably also got a few patches in between jobs.

Maybe they have tracked every patch to every employer and checked that the copyright is OK. Maybe they also rewrote the patches I did in between jobs, but I am not aware of any of that.

While my reason for leaving LLVM are indeed different from the license change, having to abandon what was a fairly successful career for refusing to accept racism does make it less likely that I will reconsider.

Thanks for your contributions, Rafael.

Do you ever regret your decision? I think I understand your perspective, but does it ever seem a bit impractical to move away over the CoC? It seems like Renato had similar misgivings but resolved to stay, for example. I can understand not wanting to agree to the CoC but what about continuing to contribute without agreeing? Also, the association with "outreachy" seems to have little impact on most developers work. Why let it bother you any more than the evils of companies who use llvm in their products supporting censorship or other things you might oppose?

The CoC I think I could live with, if it would stop there. The LLVM foundation supporting outreachy that was too much for me. It would indeed have little or no impact on me, since I was already an established developer, but I know that would not have been the case if I was starting now (I wrote a bit about it in https://quillette.com/2018/06/26/diversity-and-discriminatio...).

More importantly, Niemöller's poem always comes to mind when the argument is "it has little impact on you". So no, I don't regret it.

Is it really OK that the top of the license calls it "Apache License"?

https://foundation.llvm.org/relicensing/LICENSE.txt

You need to scroll to the bottom to see that its not.

Yes because it is the Apache license. You are free to disregard the exceptions if you do not want to use them.

Yes – the software is licensed under the Apache license and you are free to use it as such. It also separately grants additional rights on top of that license, which don't affect your rights under the Apache license. It's similar to the GPLv2 with the Classpath exception.

What happens if one of the contributors has died?

I think it’s highly unlikely you’re going to get agreements from even the majority of the long tail, so moving towards the “end-game” before 2023 might be prudent.

My personal issue with the LLVM re-licensing and its exception clause is that it made no effort to deal with a few projects which had used the LLVM core in an LGPLV2.1 context, only those projects in a GPLV2 context.

This screwed over a few projects which are unable to re-license to an apache2-compatible license. Offhand, I believe it affected the LGPLV2.1 licensed Wine/Codeweavers win32 emulation layer for running windows 32-bit programs on a 64-bit-only mac, and affected several other programs as well.

I knew LLVM was doing a relicensing for a long time. And it was great that MAMAA all had lawyers agreeing on Apache 2.0 with Exceptions. ( Which in itself is probably a multi million operation ).

I keep wondering they they did not make Apache 3.0 with all their problems solved. And instead becomes Apache 2.0 with Exceptions?

> We can check if copyright even applies to the particular contribution. Very small contributions may not be covered by copyright, and hence may not need a license agreement.

This is not the case in the United Kingdom, where the threshold of creativity for copyright is basically zero.

Thanks for posting. I filled out the form.

That's great, thank you!

I opened the spreadsheet, and now I can't remove it from my list of Google Sheets (unlike most shared spreadsheets). Am I missing some obscure way to remove it, despite the Remove option being grayed out? (It does respect the "Owned by me" filter so this isn't the end of the world.)

https://jakebinstein.com/blog/google-drive-remove-option-gra...

> The right-click menu option with the trash can symbol can’t be clicked, but dragging the file over to the trash can works just fine.

Thank you!

My question may sound naive, but why not use BSD zero close license from the start?

Apache-2.0 has corporate-friendly patent clauses missing from most other permissive licenses.

You should perhaps post this also on reddit.com/r/programming and on similar sites.

This sounds unsustainable. Will a death of a core contributor mean that the project is stuck on a license forever?

Last line of the article:

"If copyright does apply and the code is still in the code base, we can remove the contribution. Depending on whether current contributors and users still value the effect of that contribution, it may need to be reimplemented."

My question is more about the general case. Is this something project authors should rely on in their future?

Will it sometimes be easier to just fork? Would fork-relicensing be a good thing for the community?

Or should there be a different approach to ownership that does not allow for relicensing?

As a contributor to some projects that relicensed, I felt pressured to accept a change that was packaged up together with some major downsides.

Once again the FSF is shown to be prescient. Their copyright assignment policy completely eliminates this problem.

It eliminates this problem by creating another one. That you need to jump through a couple of hoops before you contribute.

It is arguable which method is better.

And you need to trust project and future project controllers far more.

> That made it impossible for some companies to contribute.

It did all right regardless. Why bother with coddling the companies? As someone who wants software patents to die in a fire, I think coddling of this kind is counterproductive in the long run. I do buy the rest of their arguments though.

Reply on news.ycombinator.com