It's really depressing to see these people not believe copy left is enough, and think we have to main our programs and make them less composible in addition. Intentional impediments to code interopt are absolute heresy given my own ideology of free software, and I wish rather than being on the defensive someone would argue that more forthrightly.
I hope in the last 5 years the situation has changed.
Richard Stallman's schtick with copyleft isn't so much to lock a particular program into a Free Software license, it's to use Free Software as a cudgel to demand licensing concessions from other software vendors.
An obvious example of this would be GPLv3's anti-TiVo clause, although in that particular case there's a direct connection between locking down hardware and your nominal right to modify the software being practically curtailed. The bargain the GPL tries to strike is "you can do whatever you like with the program as long as you don't restrict the user's freedoms to use, distribute, or modify the program". GPLv2 only talks about legal restrictions to user freedom, v3 extends that to curtail technical restrictions, too.
One oft-overlooked controversy is that of GNU readline. You see, RMS decided specifically to release readline as a GPL library so that anything that used it had to be GPL, too. This actually worked - for example, CLISP relicensed itself specifically to comply with GPL terms on readline. There's an old e-mail thread between RMS and CLISP's author, Bruno Haible, which I'm going to have to make an extended quote of as it's really telling:
Bruno: I could provide a libnoreadline.a and let the user choose to link lisp.a with either GNU's libreadline.a or my libnoreadline.a . Would that convince you that lisp.a "can be reasonably considered independent and separate work" ?
RMS: No, and I doubt it would convince a judge either. I'll have to insist that you stop using readline unless you make the program free.
Bruno: If someone was to turn the readline library into a shared library (a library that is needed at runtime by the executable, but not contained in the executable): Would that mean that any executable that uses a readline shared lib would have to be accompanied with full source?
RMS: Yes. The sum total of what you are doing is still tantamount to distributing one program which contains readline but is not under the GPL.
Bruno: So the only reason why you may object is that my lisp.a has an INTERFACE that allows it to be linked to libreadline.a . As far as I know, only the readline CODE is copyrighted, not its INTERFACE. (Would you object because my libnoreadline.a has a similar interface?)
RMS: I say this based on discussions I had with our lawyer long ago. The issue first arose when NeXT proposed to distribute a modified GCC in two parts and let the user link them. Jobs asked me whether this was lawful. It seemed to me at the time that it was, following reasoning like what you are using; but since the result was very undesirable for free software, I said I would have to ask the lawyer.
What the lawyer said surprised me; he said that judges would consider such schemes to be "subterfuges" and would be very harsh toward them. He said a judge would ask whether it is "really" one program, rather than how it is labeled.
---
RMS doesn't entirely answer the question about interfaces, because he responds with an example about NeXT, but I can smell the same logic here. Bruno is asking if APIs carry copyright, and Richard Stallman does not say no. He specifically argues that the existence of a version of CLISP that can be linked with readline is enough to trip the GPL. This is dangerously close to the Oracle v. Google case, played out 30 years ahead of it's time on a private mailing list between two people who really shouldn't be fighting.
The only reason why RMS doesn't explicitly say "yes APIs are copyrightable" is probably because...
1. Arguing against Free reimplementations is hypocritical - especially today when we have three non-GPL readline implementations.
2. Bruno decided to GPL CLISP anyway (because Linux was getting lots of contributions).
I'm surprised the FSF hasn't commented on this case further, though I can imagine why. Seeing the absolute stalwart of Free Software argue in favor of Larry Ellison has been a huge yikes moment for me. In fact, one way to interpret Oracle v. Google (in the light of OpenJDK existing), is that of a massive GPL compliance lawsuit. Free reimplementation is how we got GNU and BSD; but RMS being any kind of right here imperils the right to reimplement... all so that Steve Jobs couldn't extend GCC.
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).
Funnily enough, the current state of the art in understanding GPLv2 is completely opposite (albeit disputed, see SFC vs Canonical on ZFS in Linux).
The critical part is whether the software is derived, as that is the language used by GPL, and it can be hard to claim that optional line editor - as many other lisp implementations showed, you can really go far with dumb (loop (print (eval (read))))
However, RMS had an obvious agenda involved, and libreadline was one of the major cugels used by FSF for significant part of 1990s. There's a reason why the term "GPL virality" stuck.
I would not say this is "the current state of the art in understanding GPLv2", merely disputed (implying by a minority). A better representation would IMO to say that there is no concensus.
It's big enough for major projects like FreeBSD and Illumos - and for Linux itself (although due to no copyright assignment other than enforcing GPLv2 instead of "GPLv2 or newer" individual developers can and will dispute it).
But ultimately there's no ruling to fall back on, as far as I know all cases ended up without actually getting a court ruling.
Part A does exist: it's the J2ME license that Google did not want to follow, since doing so would require not being Android. Sun was entirely uninterested in Java being the programming language of other people's platforms, as Macromedia found out when they tried to license Java for ActionScript 3. They wanted to be a platform that subsumed everything else - "write once, run anywhere".
The entire point of using Apache Harmony was to evade a licensing regime, and in fact, Apache even avoided collaboration with other Free Java implementations specifically because they did not want to be covered by GPL. In fact, when the Apache Harmony team went to Sun to ask for a license to the Java 5 TCK (the thing you need to pass in order for Sun to license your JVM), Sun's response was to specifically announce the GPL-licensed OpenJDK and TCK terms that only extended to GPL-licensed JVMs. They specifically selected a license to exclude Harmony. So this case starts to look a lot more like readline!
Furthermore, I feel like the particularities of GPL copyleft might be confusing. The reason why the GPL is able to demand source code conveyance is because copyright law grants it exclusive ownership over derivative works. The GPL can't just say "you agree to release all software you ever write under GPL forever" - it can only talk about cases in which copies or derivative works are made of the software the GPL covers. Same with Java; Oracle only has a valid claim if a derivative work has actually been made - not merely that licensing compliance was demanded. If you change your program in such a way as to not make a derivative work, then you aren't engaging in subterfuge, you're just stopping the infringement!
What Bruno Haible was arguing, was that, if he wrote his own library implementing the same functions as readline, then he would be able to distribute CLISP with his own readline workalike library only. Then users would be able to take either library, with the caveat that distributing the combination of CLISP and GNU readline is forbidden by the GPL. The only way that RMS can be right is if some element of copyright extends beyond the implementation of GNU readline and into it's interface, such that anything that uses the interface can be reasonably expected to comprise a derivative work of the implementation. If RMS doesn't own the readline API, then he has no claim against CLISP.
The main difference between readline and Java would be the direction in which derivation flows: RMS is arguing that users of his interfaces are derivatives, while Oracle is arguing that providers of it's interface are derivatives. However, there is nothing stopping Oracle from also arguing that all Java-language programs are derivative works that need to now worry about license compliance. That's the Java trap, at it's most extreme!
In the readline example, the author was explicitly saying, "Let users decide to link against a thing so I can do an end run around licensing issues." Stallman is claiming the judge would be harsh because the judge knows prog1 with "choice" of subterfuge.a or inconvenientLicense.a is really just prog1 trying to get around an inconvenient license with which they must comply. "inconvenientLicense.a" is "Part A" of my example, and the author knew that users will link to inconvenientLicense.a. (Otherwise why have the choice at all?)
With the Google example, the devs said, "Let's do a clean room implementation so that the entire VM has our preferred license." There was no equivalent inconvenientLicense.a on any Android device. You can talk about J2ME existing in general, but that was what I mean by saying that "Part A" doesn't exist.
It's an important distinction-- it's the reason why Oracle basically was reduced to arguing copyright of an API. That's the only conceivable thing that could have inconvenientLicense on the device.
So, if I'm understanding this correctly, is the argument is that providing the user with a choice of library to link to, effectively "induces" the user to violate the GPL?
I'm using the concept of inducement as a theory of contributory copyright liability, even though it wasn't a concept of law at the time that RMS and Bruno had this discussion. It feels like an inducement argument, though - the idea that telling your users to break the license is just the same thing as breaking the license.
However, I don't think Bruno's argument hinges entirely on telling the user to break the GPL on his behalf. There is an API boundary, and in the time following this argument, people have written actual readline replacement wrappers that use BSD-licensed line-editing libraries (e.g. editline). The way I interpreted Bruno's argument was with the implication that he would actually reimplement readline instead of just, say, writing a functionality-free shim to induce the user to replace it with a functional but GPL'd library.
Not inducement but rather intent. The question would be what the genuine intent of the author was behind the decision to so conveniently choose to place an API boundary right in that particular spot. The precise layout of the API also seems like it would be relevant - if no non-GPL libraries conforming to that particular API existed at the time of the decision, then what would the non-infringing justification be for choosing to implement that specific API in the first place?
(Aside: In Google's case, IIUC the non-infringing justification is code portability. Also, there's the bit where they (re)implemented the entire system - I don't believe they were linking against or otherwise using anything owned by Sun. Other than the API layout itself ... allegedly.)
Presumably questions about the decision making process itself, the technical merit of the final decision, and the state of any alternative implementations would all need to be considered.
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)
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).
The language of the license doesn't talk anything about technical methods used, only whether the program is derived from GPLed code or not.
This has some !FUN! possibilities, in Dwarf Fortress meaning.
On one side, currently more common line of thought (promoted among other things by Linus, when non-GPLed code ended up in Linux through AFS) is related to actual functionality of the program being specifically dependant on GPLed code, vs. being a case where a common interface that existed in non-GPLed code might be used in between. This also makes moot any concern about syscalls that aren't linux-specific, as the programs using them have obvious defense of "I was following UNIX standards".
On the maximalist interpretation... well, it doesn't matter if the code runs on separate machine and you talk to it over IPC.
The trouble seems to stem from FSF itself misinterpreting derived to have direct application to technical specifics of linking. Whether by mistake or on purpose.
> anything that was written with Linux in mind (whether it then also works on other operating systems or not) is clearly partially a derived work
> Historically, there's been things like the original Andrew filesystem module: a standard filesystem that really wasn't written for Linux in the first place, and just implements a UNIX filesystem. Is that derived just because it got ported to Linux that had a reasonably similar VFS interface to what other UNIXes did?
> Personally, I think that case wasn't a derived work, and I was willing to tell the AFS guys so.
If we take this logic and apply it to this situation, we can see that the GPL always applies if you are intentionally designing for and using GPLed code in your program, even if you "run on separate machine and you talk to it over IPC".
Now, if there happened to be some common readline API, with readline_gpl.so and readline_mit.so, then you could use it. But making up a hypothetical about readline_doesnotexist.so, when the only implementation you actually are using is readline_gpl.so is not going to convince a judge that the GPL does not apply.
You could maybe get away with it if you originally designed for inputline.so, some non-GPL library that had similar functionality to readline but with a different API, and then ported to readline.so - it would be situation dependent and I'd probably talk to a lawyer here. However, that wasn't what happened here either.
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):
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 RIPEM author would be vicariously liable for those violations.
I don't think so?
As you noted, part of the source code would have no purpose other than interacting with GPL'd code. Therefore, the RIPEM source would necessarily be a derivative work and thus fall under the GPL itself.
So the RIPEM author would be guilty of distributing source code with a bogus and misleading licensing statement at the top. Which might get them into legal trouble I guess? If someone was misled and suffered damages as a result, they could presumably turn around and sue the RIPEM developer. Or maybe not. I don't know.
A thought experiment. Clone the Linux kernel repository. Add a single small changeset for something fairly trivial. Then change every instance of the GPL in the repository to the WTFPL instead. Build and redistribute the resulting binary alongside your adulterated sources.
Also (nitpicking) you used the phrase "GPL violating binaries" which AFAIK isn't a thing. To be fair, you do later acknowledge the fact that the existence of binaries themselves doesn't violate the GPL, just the act of redistributing them without the source code.
I remember reading an article about the difficulties of extracting AST from clang [1]. Even when there are less politics involved, seems like a hard problem. With GCC, the problem becomes an Stallman order of magnitude harder :-)
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.
But you aren't parsing the program. You're parsing a particular instantiation of the program for a particular set of -D defines and include files. Whole chunks of the program that were excluded by #ifdefs don't get parsed at all.
This is fine if you just want to analyze that particular instance of what the program can become, but it's not fine if you're trying to do something to the program as a whole.
> 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.
That's moving the goal posts. The important thing is that macro invocations can be found "statically" (with out knowing the implementations of macros at all let alone evaluating).
One way to look at this is that partial evaluation of Rust or Scheme macros is very tractable, because there are very few side effects / side channels. But if you have a lack of hygiene or the C preprocessor, it's very difficult and almost everything becomes a "stuck term" whose evaluation is contingent on earlier evaluation.
That's true about the pure act of parsing and generating an AST. Bit once we want to do semantic analysis, this is no longer true.
Because of procedural macro, it becomes practically impossible to find all occurrences or rename a particular symbol regardless of the #ifdef or #[cfg] or whatever.
So with true hygienic macros, this is not the case. Even with procedural macros, quoted identifiers are resolved where they are quoted not where they are expanded. Identifiers that are not in scope at the macro definition site would have to be parameters, and those are caught at the invocation site just like any other identifier (the quote and splice cancel out).
I am not sure whether Rust procedural macros are always that hygienic, so fair point if they aren't.
It's interesting to see Free Software try to enact the same kinds of moats (purposefully limited interoperability) as proprietary software to cement control of the ecosystem. All very "ends justify the means".
"We had to sacrifice your freedom in order to save it".
I'm more understanding of purposely limited interfaces for the kernel because of the support burden on maintainers caused by crashes from proprietary modules.
Yes and no. Stallman's asshattery created the need for a more flexible, scrutible, tool. We have LLVM now, the world is better off for it. Companies are free to extend it privately, and upstream bugfixes and features when it's in their interest. GPLv3 pushed many of us over to Apache or other more permissive licenses. Companies are free to develop software, APIs, and libraries that are free to use, extend, and repair without threatening their patent portfolio. The ecosystem is thriving, thanks to RMS's immovable opinions.
I think it's more complicated than that. He really inspired a lot of people with his passion, drawing us into the movement. But then the same passion pushed us out of his corner, but his previous adherents didn't lose sight of what was actually important to us. I kinda think his attitudes promoted a diversity of ideas in a way that he never intended to.
He's currently at the center of conflict between several organizations that are considered keystones of our community. What will become of it? I don't know, but I have faith that we'll route around the damage.
> My understanding is that for Intel cpus Intel compiler is substantially better than gcc.
It's not, except for super specific workloads. Intel's own Intel-CPU-optimized distro, Clear Linux, is built mostly with GCC as a conscious performance decision:
LSP was a pretty inevitable development in software IMO- there are increasingly many codebases where local compilation is a nightmare and you need some kind of remote/distributed build system to manage it for you, and once you have that you need to push xref and indexing out of the IDE as well.
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.
Stallman is looking more like FOSS' Stalin every day. There's no technical justification or even an overtly ethical one to use GCC over libclang, Stallman's ego just needs stroking every couple of years.
I long for the day that he stops making decisions.
I would say he is looking more like Lenin than Stalin: Having some ideal in his mind that he will apply no matter what. And people giving him authority like a God, everything depending on his opinion.
Lenin had his perfect idea on his mind, that did not work in the real work, he exterminated most farmers that opposed its perfect system and made tens of millions of people starve, producing way less food than in the WWI(usually as you end a war your production goes up a lot). All because in his mind, it was perfect.
Stallman is in a similar position with some people venerating him and using him as Messiah of the Pure Free software movement. But no single man is perfect or omniscient.
I hope in the last 5 years the situation has changed.