Extracting the abstract syntax tree from GCC (2015)

I don’t think you can conclude that lawyer said anything about whether APIs are copyrightable.

I think that lawyer said “if you create that interface for the sole/main purpose to get away with having to license your code under the GPL, judges will consider it subterfuge”.

It’s like arguing “I didn’t take a cookie out of your cookie jar. I turned the jar around and later found a cookie lying on my desk”. Saying that’s stealing doesn’t imply that eating cookies you find lying on your desk is stealing.

I would think that, if a third party created a common interface to them to give users choice as to what UI they provide (releasing the GNU readline wrapper under the GPL, the BSD readline wrapper under a BSD license, etc), CLISP could say “feel free to replace the BSD readline we ship with with another one)

Stallman is saying he's surprised-- probably in the same way many on HN always are-- that a judge would, you know, use judgment. I.e., one program that would trip the GPL chopped into two in an attempt to not trip the GPL part of the program which is still there! His lawyers are telling him the judge would a) see the part with the license the person wants to avoid, b) see the subterfuge to do an end run around it (in both cases they are asking Stallman directly abou it), and c) judge harshly as a result. I don't know if his lawyers were right, but that's the argument.

With Google vs. Oracle, part 'a' doesn't exist. Google did a clean room implementation under the Apache license-- there's no Oracle-licensed software behind the curtain of the headers. So Oracle's only chance was to claim that an API is copyrightable. If it's not, that's the ballgame. But in the examples you gave wrt Stallman, API copyright doesn't matter-- it'd still be subterfuge to avoid triggering a license for the 2nd part of the program (at least according to his lawyers).

Edit: clarification

I don't think that's actually the argument being made. It's the standard "color of your bits"[1] distinction: intent matters. If you use GPL licensed code in your program (that does not fall into an explicit exception, eg. syscalls on linux) you must follow the GPL. No amount of technical trickery allows you to circumvent this. If however, you reimplement an API, that may or may not be copyrighted (watch for the final result on that google vs oracle case).

1: https://ansuz.sooke.bc.ca/entry/23

A couple years or so after that, Stallman seems to have changed his mind on compatible libraries.

Someone started distributing a program called RIPEM which was an implementation of the PEM (Privacy Enhanced Mail) standard, using RSA.

At the time RSA was patented and could not be legally used without permission in free software in jurisdictions that recognized the patent. RSA (the company) provided a library, RSAREF, that could be used for things like personal and noncommercial use, but could not be distributed on terms that were compatible with GPL.

RIPEM was public domain. The user was expected to get RIPEM, separately get RSAREF, and compile and link them on the BSD or Linux system. You also needed a bigint library.

The source code for RIPEM was written so it could work with either the BSD bigint library or the GNU bigint library. Something like this (but I'm making up the names):

  #ifdef BSD_BIGINT
  struct bsd_bigint_stricture * x;
  #endif

  #ifdef GNU_BIGINT
  struct gnu_bigint_structure * x;

  #endif

Same sort of thing at places that called the bigint library functions to operate on bigints.

Stallman objected. He said that the RIPEM author could not distribute that source code because on Linux systems the user would build it with GNU_BIGINT set, and link it with the GNU bigint library and RSAREF, and RSAREF licensing was incompatible with the licese of the GNU bigint library.

A lot of us thought that Stallman must be claiming some kind of interface or API copyright, because that was the only way we could see to try to make a copyright argument against distributing the RIPEM source code. Distributing a binary of RIPEM linked with RSAREF and the GNU library? Sure...that would clearly be not allowed. But source?

To be a derivative work of the GNU library, the RIPEM source code would have to incorporate some copyrighted elements of that library. Contrary to popular belief, it is not enough that work X is not useful without work Y to make X a derivative work of Y. It's got to actually take something from Y.

So unless the names of the library's functions, the calling sequences, and things like that are copyrighted (i.e., the API is copyrighted), RIPEM source could not be a derivative work.

What it turned out that Stallman was arguing is that when a Linux users ends up with a binary that combines RIPEM, RSAREF, and the GNU bigint library, that would not have have happened if not for the code in the GNU_BIGINT ifdef. Because that code has no use or purpose other than the building of those binaries, that code induces or causes people to make GPL violating binaries. The RIPEM author would be vicariously liable for those violations.

What finally resolved this was that someone wrote a library for BSD that implemented the GNU library's interface on top of BSD's bigint library. Now you could build RIPEM on BSD with GNU_BIGINT defined but not actually linking any GPL code.

This satisfied Stallman because now defining GNU_BIGINT had a use other than building a GPL violating binary.

There actually is vicariously liability in copyright law in the US. You can be found liable for enabling someone else's copyright infringement. That generally requires either you have control over them, or you provided them the means to infringe and there is no substantial non-infringing use for whatever it was you provided.

Vicarious infringement only works though if there is someone who is directly infringing so that there is someone whose liability you can be vicariously responsible for.

Stallman was not saying the the user who downloaded RIPEM, separately download RSARREF, and theb compiled them and linked to the GNU bigint library was infringing. GPLv2 generally allowed the user to whatever they wanted as long as they were not distributing any GPL code. Only when you distributed were GPL conditions imposed. But with no direct infringement on the part of that user, it is hard to see how you can hang vicarious infringement on the RIPEM developers.

The NetBSD libedit, which offers similar functionality, dates to 1994. Since 1997 it has implemented the readline API as well.

Another reason I love Rust. It’s very statically analyzable.

Preprocessing is the easiest part unless you are working on IDE functionality and need to map it back to exact position in original source code at character instead of line level. Then it gets confusing because single expression can have position in the place calling macro, inside the macro definition and inside the preprocessed buffer.

It does mean that you have to know exact compiler invocation before you can start parsing. You can even invoke the original compiler to preprocess the file and treat it as completely separate phase that can be mostly ignored after it's done. There is plenty of complexity making extracting AST difficult after preprocessing. You could argue of how much of analysis belongs to syntax and what's already semantic analysis. But in practice and possibly at least partially due nature of C++ language the parsers making AST also do a lot of type analysis. Due to features like constexpr it they even execute the logic of code.

> Extracting ASTs from C (or C++) is difficult in general, due to the preprocessor.

Years back doing code analysis tooling (and struggling with, and being discouraged by, the TFA issue), I downloaded "a lot" (in an old pre-github sense) of code, and IIRC, found preprocessor use was so stereotyped that almost all could be easily parsed and included in the AST. Using a backtracking parser though, rather than the usual "having chosen a cripplingly inexpressive parser tech, difficulties with parsing came as a surprise". ;)

Despite being burned by gcc's "hide the AST" policy, it's not clear to me when/if it became the wrong thing. It's so easy to underappreciate the contingency of history. We're on a timeline where open source, and the internet, more or less succeeded - many perhaps aren't so lucky. On the other hand, emacs, at least with lisp on lisp machine, could be an immensely powerful integrated experience, that perhaps needn't have been quite so stagnant and lost.

Apple used GCC for more than a decade. It wasn’t until LLVM came along that they had a viable choice and they took it.

This just sounds like "yes" to me.

While clang and LLVM is the set of compiler libraries that people write and extend developer tooling in:

* clangd

* clang-tidy

* clang error messages

* mlir

And others

Sometimes. GCC is also far older - about twice the age or more compared to llvm.

Do you think that your statement will be as true in 10 years?

My understanding is that for Intel cpus Intel compiler is substantially better than gcc.

Yes, libadalang, inspired by libclang, is 'it' for me. And I can write queries directly instead of parsing some intermediary shit and wishing I was after generic instantiation... I worked around gnat2xml but it's faaaaar better like this.

AFAIK the xml-ast was always just intended as a debugging tool for llvm developers, not an API for externals (and thus came with no stability promise). You always were supposed to just link against clang/llvm and use the APIs it specifically provides to access the AST.