When I do my ESR-the-famous-geek road show, I get two kinds of questions: the public ones from my auduence, and the private ones from people who buttonhole me afterwards because they politely don’t want to burden the audience with their particular concerns. Of these, the single most common one is probably “How do I attract developers to my project?”
Last Wednesday I was giving a talk at University of Pennsylvania, which I do once in most years because it’s near me and one of the professors there, Dr. David Matuszek, is an old friend who likes to have me in once a year as a treat for his students.
One of his colleagues approached me with the familiar question. There isn’t a good general answer to this one, because how you attract developers depends in subtle and complicated ways on which developers you actually want. But this particular pitch interested me because it could be part of a significant change in the open-source tools infrastructure that I see coming down the pike.
The Free Software Foundation’s Gnu Compiler Collection, and the toolkit around it (ld, gdb, etc.) pioneered open-source compiler technology and has served our community well for a quarter century. But it isn’t news to anyone that the GCC codebase has been getting old, tired, and sclerotic. The efforts required to fit new compiler technology onto an old framework have required increasingly heroic effort for diminishing returns. FSF policy decisions aimed at hindering reuse of its code by exclusively proprietary add-ons haven’t helped matters.
There’s been an upsurge of interest in alternatives to GCC as a workhorse compiler. An increasing amount of that interest has been focused on LLVM, and while the LLVM folks won’t talk about wanting to knock GCC off its perch, they are looking ever more like a competitive threat.
Now comes Softbound, an LLVM add-on that aims to produce “hardened” binaries that are rendered immune to buffer overflows by a compile-time transformation of generated LLVM code. This could have very large implications for the quality and security of C code,
and it’s a capability GCC cannot offer.
The project lead, Dr. Milo Martin, tells me he has a proof-of-concept that is not ready for production use. He needs developers to move it from lab demo to production tool. He’d prefer to do the whole thing in open source, but is considering any path to getting it done, including booting up a company around a proprietary version.
He’s even proposed a clever tactic that is sure to be controversial: use the new compiler to create “value-added” binaries by compiling open-source programs to create “hardened” versions that protect against buffer overflow attacks. The compiler would remain closed source and the company would charge for the copyrighted binaries. I told Dr. Martin that I think this end-run of the GPL might actually work legally and technically, but that there’d be an open-source community mob with pitchforks and peasants at his castle door if he tried it.
So, here’s my attempt at heading off any such dire confrontation. If you’re interested in compiler technology, formal methods, or security, please look at Softbound and consider joining up to help so the technology won’t wither on the vine or have to be taken proprietary.
That is all.
UPDATE: Oops: I’ll investigate GCC’s capabilities for bounds-checking.
“This could have very large implications for the quality and security of C code, and itâ€™s a capability GCC cannot offer.”
Considering that the paper itself mentions one of two gcc mechanism for doing something similar, perhaps the “cannot” above is overstated.
Awww…..hairy mutts nuts….I don’t know if I have time for this, but I’ll check it out.
I wonder if that approach would work for the PCC compiler.
If the GPL’d code remains open, and their proprietary code remains closed, I don’t see a problem.
They are building an independent tool to transform the open source code into an executable. The GPL has no claim on their code. Nor should it. If it did, it truly would be the toxic agent its FUD detractors claim it to be.
>The GPL has no claim on their code. Nor should it. If it did, it truly would be the toxic agent its FUD detractors claim it to be.
Dan is correct. Even if the GPL could be construed to infect anything it compiles with GPLness, for the FSF to attempt this would be suicidal. Corporate users are twitchy enough about GPL as it is; if the FSF floated this interpretation they’d flee GCC and any system that used it in droves.
I’m still deciding whether or not I agree with J. Lapin’s interpretation of the paragraph he cited, but you’re definitely misinterpreting. It’s clear that GCC being GPLed doesn’t prevent them from developing-but-not-distributing this proprietary fork, and it’s also clear that whatever license is applied to an unrelated C program can’t prevent you from making modifications to GCC. The question is whether the modified version of GCC is excluded from being considered “System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work” and therefore is part of the Corresponding Source for its output. If it is, then you’re violating the GPL by distributing the generated binaries without also distributing your GCC modifications.
err, s/GCC/LLVM/ everywhere above.
Also, looks like LLVM has a BSD-style license, not GPL. This shouldn’t alter the above analysis.
RE : Corporate response – I was thinking exactly the same thing. It would be suicidal.
@ Daniel – I think you need to look deeper into how this tool is constructed, to understand the licensing implications.
From their FAQ :
“Can I modify LLVM source code and redistribute binaries or other tools based on it, without redistributing the source?
Yes. This is why we distribute LLVM under a less restrictive license than GPL, as explained in the first question above.”
The GCC front-end is, of course, covered by the GPL. The LLVM code, and the Softsource modul, are under a license that allows for closed-source work. If merely utilizing GCC ‘infects’ everything with the GPL, there’ll be a stampede for the exit; this isn’t the case…as far as I’m aware.
Of course, the anti-cultural rending of the community would be unforgivable, were they to close their source….cue the pitchforks and fire ;)
PS. GCC is not, technically, compiling the executable here. Only the GCC front-end is being used (nice shortcut). The actual object compilation is being done by the LLVM/Softsource back-end…..non-GPL territory.
Dan, interesting, but I think we’re still talking past each other. I’m interested not in the implications of GCC being GPLed, but of the programs that GCC/LLVM is being used to compile being GPLed. Particularly, if you distribute a binary derived from GPLed code, what code does the GPL consider to be among the “Corresponding Source” of that binary. The GPL is pretty clear that if you use an off-the-shelf compiler that’s either freely-available or part of the operating system’s standard toolchain, then that compiler is not part of the Corresponding Source and therefore the particulars of its license are irrelevant. The question is whether Softbound’s modifications to LLVM disqualify it from being a “general purpose tool” in the eyes of the GPL. If so, then my interpretation is that is that if you use Softbound to compile GPLed source code, then you can’t distribute the generated binaries without also making Softbound available under the GPL.
Dammit….I’ve been calling it “Softsource” by mistake – I blame my head cold – I’m sure you all knew I meant “Softbound” really ;)
Incidentally, if GCC isn’t considered part of the ‘standard toolchain’ then i don’t know what is ;)
“…my interpretation is that is that if you use Softbound to compile GPLed source code, then you canâ€™t distribute the generated binaries without also making Softbound available under the GPL.”
That’s the “toxic” interpretation I was alluding to.
I understood that the GPL had refined itself to specifically avoid such toxicity. If I’m wrong, then this makes for an interesting test case in which I’d oppose the GPL (not that I’m a GPL fan anyway).
Whatever GPL source they distribute a binary of, its source is still open…you can go compile it yourself…you just have no right to their proprietary compiler. The fact that it uses the output of the GCC front-end is no more significant than if they’d invoked & used the output of “grep”.
If all this was performed on a proprietary OS, would they be forced to open that source too?
As already mentioned, imposing such a toxic license would be suicidal.
If I take some GPL’d source, and then use a script to apply a proprietary patch and compile binaries, I cannot distribute those binaries unless I GPL the patch.
It shouldn’t make a difference whether the patch is applied to the source, object, or binaries — I’m creating a derivative work.
The fact that the compiler’s acting as a code generator only complicates things a little. There’s a pretty clear bright line here — if the code generated by the compiler alters the behaviour of the program then you’ve modified the work.
>The fact that the compilerâ€™s acting as a code generator only complicates things a little. Thereâ€™s a pretty clear bright line here â€” if the code generated by the compiler alters the behaviour of the program then youâ€™ve modified the work.
SoftBound is intended to be semantics-preserving, so the behavior should be the same for C code whose behavior is defined.
It isn’t so much “acting as a code generator”, Pete. It’s acting as a virtual machine monitor, carefully tracking everything the original, unaltered, code does.
Far from having a “brigh line”, I think this pushes the GPL to the edges of its murkiness. Very interesting. In a legal challenge, I’d have to side with Softbound in all honesty.
>Very interesting. In a legal challenge, Iâ€™d have to side with Softbound in all honesty.
Me, too. And given that I co-wrote the Open Source Definition, that would carry some weight. Even with a court.
Anyway, as Dan and I have both pointed out, ‘winning’ this definitional battle would be more dangerous to the FSF’s goals than losing it. There’d be a mass flight from the GCC and all other GPLed tools that would make your head spin.
>Thereâ€™d be a mass flight from the GCC and all other GPLed tools that would make your head spin.
This doesn’t follow. The GPL you have to obey isn’t from the tool you’re using, it’s from the code you’re compiling.
>The GPL you have to obey isnâ€™t from the tool youâ€™re using, itâ€™s from the code youâ€™re compiling.
I don’t see any reason this should be any different to compiling with Visual Studio, since its translation may be behaviorally different to GCC for undefined programs.
>I donâ€™t see any reason this should be any different to compiling with Visual Studio, since its translation may be behaviorally different to GCC for undefined programs.
The difference with the Softbound case is that you’re relying on ‘undefined’ behaviour to achieve certain results.
I actually can’t see a problem with someone buying a proprietary version of Softbound and making their own hardened binaries — that’s just equivalent to modifying code for your own use.
>>Very interesting. In a legal challenge, Iâ€™d have to side with Softbound in all honesty.
> Me, too.
> And given that I co-wrote the Open Source Definition, that would carry some weight. Even with a court.
Though Bruce would probably take the other side, resulting in nullification.
> Anyway, as Dan and I have both pointed out, â€˜winningâ€™ this definitional battle would be more dangerous to the
> FSFâ€™s goals than losing it. Thereâ€™d be a mass flight from the GCC and all other GPLed tools that would make your
> head spin.
Where you and Dan have both made an error is assuming that the fight is about compiling code via gcc and turning the output into something covered by the GPL. Even the FSF doesn’t claim this.
What *is* covered is if you take GPLv3-covered (source) code (e.g. GNU emacs), and pump it through a proprietary compiler, then distribute the binaries. Now you have a GPL problem, because as Lapin points out, the GPLv3 specifically prevents you from locking up the binaries and giving away the source.
This clause was specifically aimed at companies like Tivo who protected the (linux) kernel on their box via measures some call DRM.
When Dan stated, “If the GPLâ€™d code remains open, and their proprietary code remains closed, I donâ€™t see a problem.”
he made a category error. The GPL’d code must remain *free* (in the FSF/’speech’ sense), and not just open (available).
When Dan said: “The GPL has no claim on their code. Nor should it. If it did, it truly would be the toxic agent its FUD detractors claim it to be.” and esr responded, “Dan is correct. Even if the GPL could be construed to infect anything it compiles with GPLness, for the FSF to attempt this would be suicidal.” they were both making the same category error. The code is *already* GPL(v3) licensed. Compiling it with a different compiler doesn’t take away the GPL(v3) rights that pass to the end-user no more than it inserts a new license.
The problem for Softbound only happens when they compile GPLv3 code. GPLv2 code and code covered via other Open Source licenses probably doesn’t incur this issue.
Eric, do you go out of your way to be wrong post after post?
>This clause was specifically aimed at companies like Tivo who protected the (linux) kernel on their box via measures some call DRM.
I’m well aware of that, because I was involved in the GPLv3 discussions before it was finalized. I think you and “J.E. Lapin” are putting a weight on the Tivoization clause that it will not bear.
Note that this is not because I’m opposed to the clause. I actually thought it was quite clever. Linus is opposed to it; I’m neutral. I actually tried to talk Linus into buying it for the sake of community peace. I almost — but not quite — succeeded, alas.
>> you canâ€™t distribute the generated binaries without also making Softbound available under the GPL.â€
> Thatâ€™s the â€œtoxicâ€ interpretation I was alluding to.
Nope. You don’t have to put the Softbound toolchain under GPL, you have to make it “commonly-available”.
What Softbound could do would be to generate a “Ubuntu: Softbound Edition” release, and include both the (binary) toolchain (or a way to get it at no cost) and the compiled distro with source, on a (set of?) DVDs.
Or, you could just follow what Apple, Google (with both Android and Chrome OS), FreeBSD and others are doing, and eliminate all GPL-covered code, as fast as possible.
Android and Chrome OS run a GPL-covered linux kernel, but nothing else in either distribution is covered by the GPL.
FreeBSD only needs to pull the compiler tool chain out to be GPL-free.
Apple is moving even faster to remove anything GPL-covered from its MacOS X and iPhone OS operating systems.
This is, of course, also the end of the ‘desktop linux’ dream, but linux (the kernel) will live on in Android and Chrome OS. And “linux: the distro” will live-on in the server room at least until FreeBSD finally eats its lunch should the day come when lawyers world-wide react in horror to the GPL.
Eric, I’m surprised you’re not already headed in this direction.
> Iâ€™m well aware of that, because I was involved in the GPLv3 discussions before it was finalized.
You and so many others…
The GPLâ€™d code must remain *free* (in the FSF/â€™speechâ€™ sense), and not just open (available).
I think you’re making the category error here, Jake. The GPL’d code remains free at all times. Softbound does not alter this. You are not forced into buying their binary. You can, at all times, access the source and build your own binary.
Essentially, they are charging a ‘service fee’, of sorts, for the added value of delivering a binary that has been processed by their proprietary code. Nothing that they do derives anything from the source, nor does it lock it down in any way. You remain at liberty to do whatever you wish with the source.
If the GPL can be correctly interpreted (and enforced in a court) to mean that “if you so much as sniff my code you must divulge all of yours” (which I doubt) then the GPL and Stallman’s dopey wonderland are fucked into a cocked hat.
This is, of course, also the end of the â€˜desktop linuxâ€™ dream…
Because Linus would never react to a changing legal landscape, would he?
No…I’m fairly confident you’d see a “get the fuck out of Dodge” stampede away from the GPL if such an interpretation were ever upheld…including linux. There’s far too much serious business at stake for linux to risk its future on Stallman’s nonsense.
If it takes hand-coding a GCC drop-in replacement, it will be done in a trice. No beardy fuck is crucifying my livelihood.
>Nothing that they do derives anything from the source
How is compiling a binary from source not deriving anything from the source?
How is compiling a binary from source not deriving anything from the source?
Simple. Another category error – Your use of the concept of ‘derivation’ is different from the GPL concept of ‘derivation’.
If this is incorrect, then add more magnesium powder to the GPL bonfire.
PS. Just to clarify – I’m not arguing against the right of anyone to saddle their code with a suicidally moronic license, only that I disagree that this kind of suicidal interpretation of the GPL is correct.
I do have a stockpile of popcorn, however, just in case…
>The difference with the Softbound case is that youâ€™re relying on â€˜undefinedâ€™ behaviour to achieve certain results.
Optimisation passes also change the behavior of the program (from an efficiency perspective) in a manner that is non-coincidental. Is it illegal to distribute binaries compiled with Visual Studio?
>Optimisation passes also change the behavior of the program (from an efficiency perspective) in a manner that is non-coincidental. Is it illegal to distribute binaries compiled with Visual Studio?
You’ve just convinced me that it is, at least with GPLv3 code.
> How is compiling a binary from source not deriving anything from the source?
Note that ‘compilation’ isn’t the trigger for causing the GPL to fire, ‘distribution’ is.
All your focus on gcc in this thread is … silly.
So far as I can see, there are only two options here. Either the secure, “value added” compiler is leaving the program unchanged, which leaves copyright intact, or it is creating a derivative from the source code, which should retain all GPL’d rights which were attached to the source.
Now, if I’m wrong, and just running somebody’s code through a “value added” compiler strips original copyrights from GPL’d code, then what’s stopping anybody from taking the catalog of “ESR’s Greatest Hits” and taking it closed? Or the linux kernel itself? Or Outlook?
I can see, maybe trying to add some of your own copyright to the other guy’s code, but I can’t see how you get permission to the other guy’s code in the first place. Now if somebody with GPL’d code of his underived own were to do this, it would seem to be a double license.
I can’t see any way in the world that the worry in the original article could possibly be correct. The compiler code is run through can’t strip ownership from code, or Microsoft, and everybody else, would simply run all the source it could find through it’s own ‘value add’ compiler, and not worry about a copyright conflict again. And Richard Stallman would be doing the same to GPL everything in the world.
Let’s face it, a ‘value added’ compiler is anything you say it is, wether it shortens code, lengthens it to make it appear more valuable, or simply adds a remark at the beginning saying “This code has been blessed by Saint Eric of the Parabolic Trajectory.”
No, the real discussion point of the article, which all you slackers have thus far ignored through sheer intellectual laziness, is the true “most popular private buttonhole question” which is undoubtedly “Master, how can I, like you, come to have intimate relations with multiple hot redhead babes?” Like so many other problems, it is trivially solved with some investment capital and a time machine.
>Note that â€˜compilationâ€™ isnâ€™t the trigger for causing the GPL to fire, â€˜distributionâ€™ is.
But distribution doesn’t trigger the GPL unless what is being distributed requires the GPL. The reason you need the GPL to distribute the hardened binary is that the source it was compiled from is covered by the GPL.
>All your focus on gcc in this thread is â€¦ silly.
This isn’t a problem for binaries compiled with GCC! It’s about binaries compiled with a hypothetical proprietary extension for LVVN.
The question is to what extent has the compiler modified the program. Has it performed a straightforward translation from source to executable, or has it modified the program to the point where the executable is a derivative work? And if the executable is a modified derivative work, what must be done to provide those modifications in compliance with the GPL?
Sorry Pete, I was talking to Dan, not you, and got the attribution wrong.
>Sorry Pete, I was talking to Dan, not you, and got the attribution wrong.
Aha, that makes more sense. You’re right, the prospect of GCC infecting anyone’s code is a red herring.
> then whatâ€™s stopping anybody from taking the catalog of â€œESRâ€™s Greatest Hitsâ€ and taking it closed?
In the case of the non-GPL’d ones, nothing. Proprietary varients of “ESRâ€™s Greatest Hits” (libpng) are in the xbox (esr even made the credits).
The only thing is there is rarely any benefit to making open source software closed, except when including it in a much larger piece of proprietary software. The xbox needs a png libary, but libpng isn’t a substitute for the xbox.
Jake, open does NOT mean available. It means open to all for modification and distribution.
Am I the only person around here aware of the <a href="http://www.fsf.org/licensing/licenses/gcc-exception.html"GCC Runtime Library Exception?
This is also located on any Debian or Debian-derived system with gcc installed, including Ubuntu, at /usr/share/doc/gcc-VERSION/copyright. (On Karmic, VERSION=4.4 if you ‘apt-get install gcc’ or install the kernel builddeps)
>Am I the only person around here aware of the <a href="http://www.fsf.org/licensing/licenses/gcc-exception.html"GCC Runtime Library Exception?
Of course not. They inserted that language specifically in order to foreclose the sort of infectivity that some commenters here are now claiming the GPL mandates.
No, Jake. Discussing the impact of using the GCC front-end is not “silly”, as it is an integral part of the process…and raises interesting licensing questions.
Nor have I ever argued that this process ‘strips’ the GPL license from anything it touches. Quite the opposite – the GPL remains intact, and the source remains unaltered and open.
The most contentious point is this : does the act of using a closed-source tool to produce a binary from a GPL project (where the GPL code is unaltered) cause the tool to fall under the GPL itself, thereby requiring that it is ‘opened up’ ? I, and ESR, argue “no”, and that if we’re wrong there will be severe consequences for the GPL’d world.
Some of the confusion evident in certain commenters is due, I suspect, to them not grasping what Softbound is doing to the code.
Tangent : How can the GPL be enforced anyway? Who is going to pay for the legal costs?
If a business has a GPL product, and another business makes a derivative product but closes their enhancements, I can see that there are 2 legal entities that can slug it out in court….if the benefit is apparent.
But what about the vast vaporlike OSS landscape? Who would fund such enforcement there?
It seems to me that the GPL is more of a ‘community code of conduct’, on the honor system (subject to community shaming/shunning), than anything legally enforceable.
>It seems to me that the GPL is more of a â€˜community code of conductâ€™, on the honor system (subject to community shaming/shunning), than anything legally enforceable.
While it is true that the GPL functions effectively as a community code of conduct, it is looking rather more likely to be looking legally enforceable in the U.S. than it used to. The recent decision in Jacobson vs. Katzer, though it didn’t specifically address the GPL, affirmed that open-source licenses as a class are enforceable against Katzer’s brief otherwise. The GPL itself has been ruled binding in Germany, where Harald Weite has been aggressively pursuing violators.
@Mogan – And Softbound doesn’t even use those libraries! So the criticism is doubly daft :)
What it does use, is the C/C++ front-end of GCC, as its pre-process before translating to a virtual RISC-like bytecode. I don’t think there’s an issue here, but there is at least legitimate room for debate.
Sorry, I wasn’t trying to imply that the GPL is inherently unenforceable – any lawful, conscionable agreement we enter into voluntarily can theoretically be upheld in a court, GPL included – but rather questioning whether it is practically unenforceable…who is going to make the risk/benefit assessment and then fund such legal actions? I am not familiar with the cases you cite…what are the circumstances of the litigants? Are corporate interests involved? Is money at stake?
>who is going to make the risk/benefit assessment and then fund such legal actions? I am not familiar with the cases you citeâ€¦what are the circumstances of the litigants? Are corporate interests involved? Is money at stake?
In the U.S. the Software Freedom Law Center periodically goes after GPL violators, corporate interests are definitely at stake, lots of money is involved, and so far the violators have always backed down rather than face a court test.
The issues in Jacobsen vs. Katzer are described here. This was a major victory, as the Federal Circuit court of appeals held that open-source licenses are enforceable – especially significant because the one at issue was the Artistic License, which is notoriously poorly drafted. The court looked past the technical flaws to the intent of the license, which was very bad news for anyone looking to break the GPL or other open-source licenses on narrow technical grounds.
I don’t know what Katzer and his lawyers were thinking, frankly. If I’d been asked to design a set of facts better calculated to produce this result, I don’t think I could have done better than Katzer’s obvious bad-faith maneuvering and barratry.
Thanks for the pointer :) An interesting read, albeit bewildering (WTF was Katzer thinking?)
I am glad to see that the court looked beyond technicalities into the intent of the license (yes, the Artistic license is a pitifully shabby mess), that they acknowledged the inherent enforceability of such licenses, and I am glad to read that there are those that care to help enforce such licenses.
@Dan: You don’t understand about demonstrating legal intent? My point is that I think the GCC Runtime Library Exception shows FSF’s legal intent with regard to output from GCC — it isn’t considered GPL. In the absence of an clear statement in the license, you can show the legal intent of the license by showing a different statement — like say in a license exception — that demonstrates that intent.
Probably Cathy Raymond can describe it better than I can; she’s an Imaginary Property attorney, while I just play one on the Internet. ;) (I am not a lawyer, this ain’t legal advice, if you want legal advice, go pay for it!)
No, I get it, Morgan :) I was just commenting on the absurdity of certain GPL-based objections. You’re right on the money.
“Imaginary Property” is your cheeky dig at “Intellectual Property”, I assume ;) May the lady spank you hard for that….
@Dan: My point about the term “intellectual property” is that it doesn’t exist. The term is intended be an umbrella for copyrights, trademarks, trade dress, patents, and (to a somewhat lesser extent) trade secrets; it only serves to confuse and obfuscate the differences. There is no such thing as “intellectual property law,” because there are no laws defining “intellectual property.” Similarly, copyright law is very different from patent law, and both are very different from trademark law. Hence, IMHO, the whole concept is imaginary.
Intellectual property attorneys can feel free to disagree with me, of course.
I wasn’t trying to be confrontational about “intellectual property”, Morgan…merely jocular ;)
As it happens, I’m considerably conflicted about the concept of “intellectual property” myself…especially as it relates to enforcement through the patent system. My jury is still out.
>The court looked past the technical flaws to the intent of the license, which was very bad news for anyone looking to break the GPL or other open-source licenses on narrow technical grounds.
That doesn’t look good for a hypothetically proprietary Softbound.
>They inserted that language specifically in order to foreclose the sort of infectivity that some commenters here are now claiming the GPL mandates.
No one is claiming that a compiler can infect the code it compiles. Where did you get that idea? The claim is that hardened binaries cannot be distributed legally. This is because the hypothetical compiler is not free software.
That’s because the legal basis of the GPL is copyright law. If you’re making copies of copyrighted material without a license to do so, you’re breaking the law. There is no way for the defendant to “beat” the GPL in court, because getting it declared invalid would mean they have no license.
What I don’t get is how the GCC Runtime Library Exception amendment to GPL3 in any way affects source code licensed under GPL2 and compiled under some proprietary compiler that inserts unfree object code into the binary. Unless the proprietary compiler has a free-as-in-beer license that allows you to give your customers who ask for it the ability to modify the source and recompile, I can’t see how it would be legal to do that.
> No one is claiming that a compiler can infect the code it compiles. Where did you get that idea? The claim is that hardened binaries cannot be distributed legally. This is because the hypothetical compiler is not free software.
code = free
compiler = proprietary
if( compiler + code & normal_binary ) then compiler need not be free
if( compiler + code & hardened_binary ) then compiler must be free
Can someone explain why people are arguing this is the case? I have a vague understanding of the reasoning, but I don’t buy it, and maybe I am missing something. The code stays free in either case.
>Can someone explain why people are arguing this is the case? I have a vague understanding of the reasoning, but I donâ€™t buy it, and maybe I am missing something. The code stays free in either case.
See The Monster’s comment above: the compiler “inserts unfree object code into the binary”. So they would effectively be mixing GPL’d and proprietary code in the one binary.
This doesn’t necessarily mean they’ve infected the compiler with the GPL; it probably just means they can’t distribute the hardened binary.
>See The Monsterâ€™s comment above: the compiler â€œinserts unfree object code into the binaryâ€. So they would effectively be mixing GPLâ€™d and proprietary code in the one binary.
This claim is nonsense on stilts. To see why, consider a proprietary compiler such as icc. You can sell binaries it makes from GPLv2 or GPLv3 code with it all day long without creating any obligation by anyone to disclose the source of icc. Intel and others hve been doing this for years.
The argument is that the “hardening” creates a “derived work”, which must be released under a GPL-compatible license. That in turn requires the recipient of the derived work to be legally able to modify the program. And that means being able to compile the modified source code. If the license of the compiler prevents the recipient from recompiling it, then whoever hardened, and then distributed, the code has violated the GPL in doing so.
In the case of the normal binary, no particular compiler is necessary to fulfill the obligations under the GPL. The very existence of GCC assures that some compiler is available to anyone who wants to modify and recompile the program. The resulting object code will have the same functionality regardless of the compiler used.
The problem is that the proprietary compiler has materially modified the binary, making it impossible to assure the recipients of the same legal rights to modify and redistribute. It may therefore be a GPL violation to distribute hardened binaries.
It may therefore be a GPL violation to distribute hardened binaries to anyone who doesn’t have a license to run the “hardening” compiler.
without creating any obligation by anyone to disclose the source of icc.NO ONE IS CLAIMING THIS.
The claim is that releasing the hardened binaries to someone who lacks the legal authority to recompile them could be a violation of the GPL. I specifically mentioned “free as in beer” license to run the compiler above.
>In the case of the normal binary, no particular compiler is necessary to fulfill the obligations under the GPL. The very existence of GCC assures that some compiler is available to anyone who wants to modify and recompile the program. The resulting object code will have the same functionality regardless of the compiler used.
Softbound does not alter the semantics of the C program, so it is not going to be adding new ‘functionality’. All the ‘non-free’ object code is derived in a completely application-generic manner from the original source code, which on the face of it does not appear to be any different to performing optimisations or adding debugging information. It seems that if you accept this position, you also have to accept that it is illegal to distribute binaries of GPL’d programs that were compiled with a proprietary compiler. As Eric points out, people have been doing this for a long time.
Let’s try it this way…
Suppose I create some proprietary code extensions to a GPLed program foo. But rather than releasing my code under the GPL, I modify but do not release a hacked GCC I’ll call mcc such that when the original source code is compiled under mcc, it inserts my proprietary extensions. So far, no problem, but the moment I distribute the binaries produced by this process, I’m in violation of the GPL. I haven’t violated the GCC license, because I never distributed mcc, but I have violated my license to use foo by distributing a derived work and not giving my recipients the ability to make changes and recompile them.
>The claim is that releasing the hardened binaries to someone who lacks the legal authority to recompile them could be a violation of the GPL. I specifically mentioned â€œfree as in beerâ€ license to run the compiler above.
So anyone has to be able to replicate the exact binary to distribute it? What if your compiler isn’t deterministic? We’re talking about deep implementation details, not code that has some application-specific purpose. I’m no legal expert, but my understanding is that court cases like this don’t hinge on complex technical arguments. Softbound is, in terms of intention, no different to running a binary with a kernel patch that makes buffer overflows more difficult to exploit.
>Suppose I create some proprietary code extensions to a GPLed program foo. But rather than releasing my code under the GPL, I modify but do not release a hacked GCC Iâ€™ll call mcc such that when the original source code is compiled under mcc, it inserts my proprietary extensions. So far, no problem, but the moment I distribute the binaries produced by this process, Iâ€™m in violation of the GPL. I havenâ€™t violated the GCC license, because I never distributed mcc, but I have violated my license to use foo by distributing a derived work and not giving my recipients the ability to make changes and recompile them.
In the Softbound case, you get the same application out the other end as defined by the source code whether you use Softbound or GCC. The scenario you’re describing is totally different.
But that “same application” adds some functionality (in the form of protection against buffer overflows) that the source code itself lacks. It is therefore not the same at all.
>But that â€œsame applicationâ€ adds some functionality (in the form of protection against buffer overflows) that the source code itself lacks. It is therefore not the same at all.
The “source code”, by itself, has no functionality at all. Ever. Under any circumstances.
Not, anyway, until it is fed to a compiler or interpreter that must make choices about what sorts of operational semantics it’s going to have. (For example, is char signed or unsigned?) In cases not specified by the C standard, it is perfectly legitimate for the compiler to make demons fly out your nose. Runtime behavior in the case of buffer overflows is not specified by the C standard. Q.E.D.
>But that â€œsame applicationâ€ adds some functionality (in the form of protection against buffer overflows) that the source code itself lacks. It is therefore not the same at all.
It’s not clear at all that a court would see this as ‘extra functionality’, seeing as it’s a completely application-generic implementation detail. If I compile vim with GCC and I compile it with Softbound, the end-user will not be able to tell the difference unless he triggers an erroneous condition that is never supposed to happen in any case. I don’t see how you can say that this is “not the same at all”; if anything, it’s almost completely the same.
No, it’s not clear. Courts have ruled in very strange ways over the years. In my personal opinion, the court that ruled that “copying” a computer program from disk to RAM can be a copyright violation is one of the strangest. No one can seriously say that the act of reading a book or watching a TV show or movie, and thereby “copying” it into my brain, is an act requiring a licence so that it is not a violation of copyright. (I better shut up and stop giving *AA ideas.)
But the argument is also far from “nonsense on stilts”. The reason I brought up “mcc” was to ask how we draw the line in such cases. How much customization does the compiler have to do before it is materially altering the machine code and making of it a “derived work”. If we stipulate that Softbound has not reached that threshold, then by what criteria does “mcc” cross it?
>the end-user will not be able to tell the difference unless he triggers an erroneous condition that is never supposed to happen in any case
“Attacker attempts a buffer overflow exploit” seems like a reasonable use-case. Obviously the end-user doesn’t think the attack succeeding is “almost completely the same” as the attack failing. In fact the hypothetical Softbound business model relies on the end-user placing a monetary value on this difference!
>But the argument is also far from â€œnonsense on stiltsâ€. The reason I brought up â€œmccâ€ was to ask how we draw the line in such cases. How much customization does the compiler have to do before it is materially altering the machine code and making of it a â€œderived workâ€. If we stipulate that Softbound has not reached that threshold, then by what criteria does â€œmccâ€ cross it?
I already addressed this; if you compile your code with GCC and Softbound, you get the same result insofar as the source code is defined. In your example presumably you cannot compile the program at all with GCC.
>â€œAttacker attempts a buffer overflow exploitâ€ seems like a reasonable use-case. Obviously the end-user doesnâ€™t think the attack succeeding is â€œalmost completely the sameâ€ as the attack failing. In fact the hypothetical Softbound business model relies on the end-user placing a monetary value on this difference!
That’s not what I said. I said that you get almost completely the same application out the other end. The application is not even intended to have buffer overflows. If we ignore implementation details, the end result is no different to the end user than running an operating system with buffer overflow protection. Again, your same argument can also be made for any other proprietary compiler, and most people don’t seem to think that is a problem.
>If we ignore implementation details, the end result is no different to the end user than running an operating system with buffer overflow protection.
The end result is very different. In the protected OS case the user can:
a) redistribute the binaries
b) modify the source and recompile, without losing buffer overflow protection
You presume incorrectly.
I said in my example that I do not modify the source code to foo at all, but instead modify GCC so that when the foo source is run through it, it merges in my changes as part of the compile process. Because I do not redistribute the modified GCC “mcc” program, I am not violating its license, and because I distribute my modified foo binaries with foo source, I’m not violating that license either, right?
But I am violating foo’s licence, because I’m compiling in something extra that isn’t available in the “source”.
>The end result is very different. In the protected OS case the user can:
>a) redistribute the binaries
I guess I got caught up in a specific part of the argument, and missed the part of Eric’s post where he was talking about copyrighting the binaries. I don’t see how this will work at all. By what means is the person compiling the binary able to add distribution restrictions to a GPL’d work?
>b) modify the source and recompile, without losing buffer overflow protection
I think this is a good point, but regardless of our semantic quibbling, I don’t think it’s clear whether or not ‘buffer overflow protection’ constitutes a functional extension of the original program. Existing practice is against the idea that it is (as evidence by the widespread distribution of binaries compiled with Visual Studio). I don’t care to argue the point any more, because frankly this is (clearly) outside my area of expertise. You have convinced me that you have a tenable stance, however.
>I said in my example that I do not modify the source code to foo at all, but instead modify GCC so that when the foo source is run through it, it merges in my changes as part of the compile process. Because I do not redistribute the modified GCC â€œmccâ€ program, I am not violating its license, and because I distribute my modified foo binaries with foo source, Iâ€™m not violating that license either, right?
Your changes that mcc merges in are part of the source code of the program. The fact that you move them into the compiler is irrelevant; I don’t think anybody, least of all a judge, is going to buy that argument.
>By what means is the person compiling the binary able to add distribution restrictions to a GPLâ€™d work?
There is at least one well-established way to do this: by asserting a compilation copyright on a collection that includes the GPLed work. Technically this doesn’t control any individual work, but it controls reproduction and redistribution of the collection as a whole.
I know it sounds perverse, but I don’t think the GPL prevents anyone copyrighting and restricting the distribution of binaries. Maybe it would have if this situation had been anticipated, but as I read it I see only constraints on the ability to lock up the associated sources.
>I donâ€™t think itâ€™s clear whether or not â€˜buffer overflow protectionâ€™ constitutes a functional extension of the original program. Existing practice is against the idea that it is (as evidence by the widespread distribution of binaries compiled with Visual Studio).
I might have missed something here. Does Visual Studio or ICC produce some kind of value-added binaries?
Dunno about ICC, but as for Visual Studio, of course it does. Aggressive optimization settings will reorder code to a different order that runs faster, for example. The basic buffer overflow checking catches many stack overflow exploits. But what you’re missing, pete, is that the code that a compiler is allowed to emit code that does absolutely anything in response to behavior not defined in the spec, and still be in compliance. It can ignore it, fix it, spawn tetris, all are allowed, as is literally anything else.
So in the one respect the Softbound executables are value added, but the behavior is perfectly allowed by any c/c++ compiler.
Thanks everyone for the lively discussion and insightful comments. Sounds like the legal implications of such a business model are far from cut-and-dried.
I also wanted to stress a few things about the SoftBound project:
First, the business model mentioned above is purely hypothetical at this point. As of now, the SoftBound prototype is available open-source. The website linked above contains a BSD-licenced version of the SoftBound tool.
Second, the current prototype isn’t really yet ready for primetime use; it just isn’t stable enough yet. So, I’m exploring various avenues for continued development to move it from academic artifact to a production-ready solid tool. This includes further governmental research grants, some sort of business venture to get the resources necessary to accelerate development, or evolving it into a collaborative open-source project. If anyone is interested in contributing to the open source project (testing, using it on their application, or improving the SoftBound code), please do let me know! (contact info is on my web page)
Third, GCC can support such checking tools. In fact, Mudflap is a checking tool as part of GCC. However, our experiments indicate that Mudflap both has enormous overhead and yet misses overflows that SoftBound catches. We considered building SoftBound on GCC, but LLVM’s really clean and easy-to-use typed intermediate format (and LLVM’s BSD license) made it the natural choice for building the SoftBound prototype.
So C will now enjoy some of the safety guarantees that have been inherent in Ada for decades! Neat!
The prior comment is less trollish than it sounds: I work in embedded systems and cringe when one of our C++ programs segfaults. If we could bring Ada-like safety guarantees to the C family, a whole class of potential problems common to my line of work disappears.
There is a 67% performance penalty when Softbound checks both reads and writes, or a 22% performance penalty for checking writes only. Can your embedded systems take the performance hit? Some can, some can’t – and performance is a big reason we keep using C/C++, right? Important note: I pulled those figures from skimming the paper, but I don’t know what they mean. 67 and 22 percent of what operations, exactly?
We’re not running hard real time, so for us, safety will probably trump raw speed each and every time.
“I know it sounds perverse, but I donâ€™t think the GPL prevents anyone copyrighting and restricting the distribution of binaries. Maybe it would have if this situation had been anticipated, but as I read it I see only constraints on the ability to lock up the associated sources.”
Copyright law itself is what prohibits distribution of binaries (which are derived works of the copyrighted source code). The GPL would need to intervene and explicitly permit such activity else the prohibition of copyright law applies. The permission to distribute compiled binaries IS granted by the GPL, but only conditionally — with one condition being that those distributed binaries (“works based on the Program”) be licensed under the same license (see GPLv2 Â§2a or GPLv3 Â§5c).