Plug-In Architecture On the Way For GCC

VonGuard writes "This year marks the 25th anniversary of the GNU Operating System. A major part of that system has always been the GNU Compiler Collection. This year, some of the earliest bits of GCC also turn 25, and yet some of the collection's most interesting years of growth may still be ahead. The GCC team announced today that the long-standing discussion over how to allow plug-ins to be written for GCC has been settled. The FSF and the GCC team have decided to apply the GPL to plug-ins. That means all that's left is to build a framework for plug-ins; no small task to be sure. But building this framework should make it easier for people to contribute to the GCC project, and some universities are already working on building windows into the compilation process, with the intent of releasing plug-ins."

Comments

Re:So why do I want plugins in my complier?

[Nimey]

Spell check.

Re:So why do I want plugins in my complier?

[Hatta]

So you can watch trippy visualizations while you compile.

Re:So why do I want plugins in my complier?

[Whiney Mac Fanboy]

Go to the GCC Plugins Wiki & search for "Potential use cases".

Re:I thought GCC

[Professional Slacker]

Emacs, in fact it's Emacs all the way down.

Re:That means all that's left is to build a framew

[TheRaven64]

Or just do what the rest of us are doing, and hack on LLVM. It's BSDL, so you can license your plugins however you want, and it's very modular so it's easy to reuse parts of it. Oh, and it's actively backed by Apple, Adobe, Sun, Cray, and a few others including a number of universities.

Re:GPL to plugins?

[Bruce Perens]

I think you need to look at that more carefully. First, it's not a legal statement. It seems to be written by engineers and no counsel is identified. Also, FSF knows better than to make such a statement. Looking at the content of the page, they give the arguments a defendant could make, and the fact that plugins might make it easier to connect proprietary software to GCC, and that they could make the plugin a demarcation between programs if they wanted to. But nothing on the page settles the issue.

Bruce

Re:GPL to plugins?

[roystgnr]

A plugin uses the host application's API. It is, therefore a derived work.

From Sega V. Accolade:

Computer programs pose unique problems for the application of the "idea/expression distinction" that determines the extent of copyright protection. To the extent that there are many possible ways of accomplishing a given task or fulfilling a particular market demand, the programmer's choice of program structure and design may be highly creative and idiosyncratic. However, computer programs are, in essence, utilitarian articles - articles that accomplish tasks. As such, they contain many logical, structural, and visual display elements that are dictated by the function to be performed, by considerations of efficiency, or by external factors such as compatibility requirements and industry demands. Computer Assoc. Int'l, Inc. v. Altai, Inc., 23 U.S.P.Q.2d (BNA) 1241, 1253-56 (2d Cir. 1992) ("CAI"). In some circumstances, even the exact set of commands used by the programmer is deemed functional rather than creative for purposes of copyright. "[W]hen specific instructions, even though previously copyrighted, are the only and essential means of accomplishing a given task, their later use by another will not amount to infringement."

Even if the header file can't be legally copied verbatim, you can write a new header file that's API-compatible and not be infringing. Good thing, too, or the Wine folks would be in some serious trouble.

Nice

[coryking]

Mod me as a troll if you must but... People ought to read the link given by the parent. Wow.

So, how do we permit plugins while prohibiting proprietary plugins, and how do we do it while staying within the bounds of copyright law which is the basis of the GPL

Nice. You know, in a very funny way, the FSF and their jiahad against the evils of proprietary software are basically creating their own twisted form of DRM. Witness this brilliant idea:

most people participating in the related discussions on the gcc mailing list, suggested already that an unstable plugin API would bring all major advantages of plugins in gcc, while complicating the scenario of proprietary plugins. Indeed, it would probably even make sense to consider having a default policy of the plugin API to be modified for each major release, this could be achieved using automated scripts-which would also increase the motivation for plugin authors to keep their plugins in the main repository

Nice. The Linux kernel guys did this and look at the result--it is a bitch for hardware guys to write drivers for Linux. I'm sure deliberately altering the API with a script will work really well for the GCC guys! Makes me want to participate. Not! In truth, it makes me feel like I'm some kind of criminal--only guilty until proven innocent.

Sadly, the FSF did some very nice things, but I think they are becoming so extreme they are going to marginalize themselves and fade away. You know what the biggest hurdle for the BSD guys go separate themselve from GPL? The compiler. The compiler really is the last bit of power the FSF holds over the open source world as a whole. Pretty much every other bit of the toolchain has been replaced with a non-GPL lisence except a good compiler.

LLVM seems to be coming along nicely with major players backing it. I'd be pretty nervous if I was the FSF.