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:It's Linux, NOT GNU/Linux!!

[isorox]

why do people still try to attach GNU/ to Linux? It makes no sense.

Me? I run Gnu/KDE/Xorg/Gnome/vim/perl/rxvt/Fluxbox/Firefox/Java/Linux

Re:It's Linux, NOT GNU/Linux!!

[Anonymous Coward]

Given that nobody mentioned Linux in either the summary or the article, one can only assume you're trolling.

Re:It's Linux, NOT GNU/Linux!!

[hobbit]

Vim, eh? You spoiling for a fight? ;)

Re:It's Linux, NOT GNU/Linux!!

[samkass]

The article claims that GNU has produced an operating system, and that GCC is somehow the cornerstone of that "operating system". I don't think the word means what GNU thinks it means. And Stallman's insistence on calling Linux "GNU/Linux" is part and parcel of that misconception.

Re:It's Linux, NOT GNU/Linux!!

[Anonymous Coward]

Sure it does, considering GNU utils form the basis of the userland and Linux is just the kernel - hence GNU/Linux.

So why do I want plugins in my complier?

[NobleSavage]

Can someone explain what kind of plugins might be made? What extra functionality wold I want in a compiler?

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:So why do I want plugins in my complier?

[Anonymous Coward]

Hells yes! The number of times I've sat through a compile to be greeted by a typo on the first line of output!

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

[Anonymous Coward]

Sup dawg, we heard you like compiling, so we put a compiler in your compiler so you can compile while you compile!

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

[Anonymous Coward]

Can someone explain what kind of plugins might be made? What extra functionality wold I want in a compiler?

Static analysis.

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

[Anonymous Coward]

Clippy.

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

[Anonymous Coward]

Sup dawg, I heard you like plugins, so we put a compiler in your compiler so you can compile while you compile.

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

[RiotingPacifist]

It appears you are trying to compile the linux kernel, do you want to:
1) Start writing a letter to re-license the code to SCO
2) Inform SCO the code is theirs, using a fax document
3) Open Excel to compare the TCO of linux to windows
4) watch a PowerPoint presentation on the failures of communism
5) open up MSDN help for more options

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

[Anonymous Coward]

Wow, is that page for real? It's like it exemplifies everything that's wrong with GNU fanatics (besides the smell).
"Well, on one hand, this could aid research and experimentation, but on the other hand there's a slight chance that it could be vaguely useful to those closed-source people that we don't like, and them cud even insert teh EEVEEL PRORPIATARIES!! OMGWTF!! D: D: D:"
Actually, both the advantages and disadvantages mostly go "-: People could do TEH PORPATAYRY COED! / +: Well, they already can, anyway."

Really, weighing academic benefits against the possibility of people calling their code from self-written closed-source applications. It's like they consider it some sort of rape. What self-important petty bastards.

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

[chill]

Hey, some of us like our co-eds proprietary. A little too open and you could end up with a nasty virus!

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

[Anonymous Coward]

WANT MOAR NOW!

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

[UncleFluffy]

A GPL-licensed module that allows proprietary plugins to talk to GCC over a socket from a different process space. ... oops ...

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

[BZ]

Some of the Mozilla folks have existing static analysis and automatic code rewriting hacks built on top of gcc. These could easily become plugins.

So think a compiler plugin which you can use to rename a function in your code. Or change the signature of a function. Or verify code-flow invariants.

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

[Anonymous Coward]

And there are tons more use cases than that! My research group has a complete plugin system already implemented for GCC, and I've written a few plugins for it.

I've got plugins that put hooks in for all sorts of variable access, function call and lock events so I can put in custom debugging code. My current project involves collecting statistics and detailed logs for these events in the Linux kernel.

Because the compiler knows so much data-flow and type information, we also think that these plugins could be perfect for sophisticated static analyses.

Also, it's funny that another poster suggested trippy visualizations, since one of the projects in the group just so happens to be a visualization! It's not the trippy kind though. Actually, it shows you control flow graphs after compilation and lets you drill down into the compiled representation (a 3-address code known as GIMPLE). It's designed as a tool to aid in debugging new plugins, but it may also be useful for people who want to learn about compilers or people trying to figure out how to write code that optimizes better.

Check out the paper:
http://www.fsl.cs.sunysb.edu/docs/gccplugins-gccsummit2007/index.html

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

[userw014]

Rats. I should have replied here. I've got a similar question - what problems are Plugins trying to solve?

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

[tomtomtom777]

I for one, really would like support for edit-and-continue.

If a plugin on GCC would lay the framework for this, and it would be supported by the major editors, my productivity would double.

Back in the old days, when I was still programming on Windows using Visual Studio, I rarely left debugging mode.

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

[doti]

I heard a while back that they were planning to have the compiler working as a daemon. The internal representation of the code could be available to external tools, like the editor, allowing what you suggested and much more.

Also, this data is keeped between compilations, potentially speeding-up.

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

[bensch128]

someones probably already mentioned this but things like gccxml would be ALOT easier if there was a stable plug-in API for gcc.

This would make C++ meta-programming possible

I thought GCC

[n6kuy]

... was a plugin for emacs.

Re:I thought GCC

[Anonymous Coward]

... was a plugin for emacs.

Well, duh. Everything is a plugin for emacs.

Re:I thought GCC

[anonymous donor]

And Emacs is a plugin for what?

Re:I thought GCC

[Anonymous Coward]

skynet

Re:I thought GCC

[Professional Slacker]

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

Re:I thought GCC

[billius]

And Emacs is a plugin for what?

Woah, woah, let's not get into Metaphysics here ;-)

Re:I thought GCC

[Anonymous Coward]

RMS!!

Re:Operating System?

[Whiney Mac Fanboy]

you mean hurd?

No, the hurd is the kernel, GNU is the (still incomplete) Operating System.

GPL to plugins?

[jpmorgan]

Does this mean they want to force all plugins to use the GPL? How is that possible? I was under the impression that the GPL is purely a distribution license. It comes into force when you distribute software licensed under it, and requires you to distribute (or make available) source code and other things.

If I write a plugin and do not distribute it with GCC, what legal basis do they have to force me to GPL it? Nothing I distribute is copyrighted by the FSF, and so how can their distribution license apply to my code? I'm confused.

Re:GPL to plugins?

[Anonymous Coward]

Does this mean they want to force all plugins to use the GPL? How is that possible? I was under the impression that the GPL is purely a distribution license. It comes into force when you distribute software licensed under it, and requires you to distribute (or make available) source code and other things.

If I write a plugin and do not distribute it with GCC, what legal basis do they have to force me to GPL it? Nothing I distribute is copyrighted by the FSF, and so how can their distribution license apply to my code? I'm confused.

None, they are not claiming that as far as I know. If you don't distribute, the GPL doesn't apply to you at all (except for GPLv3 + affero, which is why GPLv3 is not liked by many).

Re:GPL to plugins?

[Anonymous Coward]

I think the thrust of the exceptions is towards plugins that are sold or distributed. If you want to write code in-house, and keep it in-house, good luck to you; that's not what the GPL is concerned about. After all, if it's in-house software, you have (pretty much by definition) the freedoms that the GPL is concerned with: the freedom to modify the code as you see fit.

But as soon as you pass the code around outside the company, and let others use it, that's when the exception becomes important.

Of course, IANAL ...

Re:GPL to plugins?

[cheater512]

Its if you distribute it at all, not if its distributed with GCC.

There is a clause in the GPL about how other software can interact with it.
Plugins have to be GPL.

Re:GPL to plugins?

[AvitarX]

I was thinking about this too.

I guess it amounts to:
1) they will not count any non-gpl plug-in as existing for their purposes
2) they can say that in their interpretation distributing a plug-in that is non-gpl is a violation of the gpl (this can influence behavior, but I would think that if they are totally separate than there is nothing FSF can do).

There are also some special clauses in the license for gcc, I guess those may be alterable somehow.

Re:GPL to plugins?

[QuantumG]

Umm.. no. This is exactly why RMS is so against GCC having a plugin framework. IF (and only if) you don't distribute GPL code with the plugin THEN you are free to place your plugin under any license you like.

Reminds me of this incident.

Re:GPL to plugins?

[CajunArson]

You actually raise an excellent point because the GPL can only be enforced on redistribution of either the original work OR a derivative work based on the original GPL'd code. In this case, the FSF wants to say that the plugins are derivative works... but unless you actually include GPL'd code in your plugin, there is no way for them to force you to distribute the code as GPL. Now, the GCC developers may try to entice developers into making a derivative work by giving out a GPL'd "skeleton" plugin that has enough code to be considered a copyrightable work that you would then modify and have to distribute under the GPL. However, if you just read the specs for how the plugins interoperate with GCC and wrote the plugin on your own without actually copying GPL'd code... there would be no requirement to distribute just the plugin under the GPL.

There may be a simpler explanation too: The summary might be misinterpreting the FSF, and what is really going on is that all "official" plugins that will come with GCC in the future will have to be GPL'd to gain inclusion with the "official" GCC distribution. This is something that the FSF could exercise control over.

Re:GPL to plugins?

[DragonWriter]

There is a clause in the GPL about how other software can interact with it.

Of course, since you don't need any license to distribute software that isn't a distributive work under copyright law, even if it "interacts with" another piece of software, such a license term has dubious effect.

Re:GPL to plugins?

[gnud]

The FSF could let the TIVO hole work _for_ them --
Require all plugins to link against a small (512 byte or so?) GPL'ed blob, and check for it at load time.

Re:GPL to plugins?

[MSG]

Does this mean they want to force all plugins to use the GPL? How is that possible?

A plugin uses the host application's API. It is, therefore a derived work. In the case of the GPL, derived works must be distributed under compatible licenses.

Some applications allow plugins or modules under incompatible licenses, but in those cases, it is the applications' authors prerogative to grant exceptions for plugins.

Re:GPL to plugins?

[Anonymous Coward]

No, using an API doesn't make software a derived work. It's an interface specification - you are not deriving from any code.

Re:GPL to plugins?

[Timothy Brownawell]

The FSF could let the TIVO hole work _for_ them -- Require all plugins to link against a small (512 byte or so?) GPL'ed blob, and check for it at load time.

That has been tried before, and the courts said it doesn't work that way.

News article that mentions an older case (while discussing one that was ongoing):

Pre-DMCA cases involving video game consoles concluded that it was legal to copy code for the purposes of interoperability, Litman said. In Sony v. Connectix, the 9th U.S. Circuit Court of Appeals concluded that it was legal for Connectix to copy the Sony PlayStation's BIOS for the purpose of interoperability.

The outcome of the case that article was about:

With these principles in mind, the majority opinion held that the district court had erred in three ways. First, it had held that the Toner Loading Program was copyrightable simply because it "could be written in a number of different ways", without considering the practical realities. [18] Second, because of this mistaken standard, it had refused to consider whether or not the alternative Toner Loading Programs proposed by Lexmark were practical.[19] Third, it had concluded that the Toner Loading Program was not a "lock-out code", because it had not sufficiently considered how difficult it would be for SCC -- without Lexmark's knowledge of the code's structure and purpose -- to alter the code and still pass the printer's authentication mechanisms.[20]

Re:GPL to plugins?

[againjj]

More precisely, the exception states that if the end compiled product is built with non-GPL compatible plugins, then the end compiled product is subject to the licenses of the linked libraries using the exception. As at least some of those linked libraries are subject to the GPL (being part of GCC) then the end product will be subject to the GPL. If you want to propagate (distribute) the end compiled product, it needs to be a GPL-compatible program, which then means that any libraries linked with it need to be GPL-compatible too, which prevents proprietary libraries linked in. If you do not propagate the end compiled product, then no problem.

So, long story short, if you have a non-GPL plugin, then either (1) the plugin must be GPL-compatible, (2) the plugin can't affect the end compiled product, or (3) the compiled program must be GPL-compatible and not be linked with anything non-GPL-compatible (say, a proprietary plugin). Basically, they want to prevent plugin writers the ability to lock down a GPL program by requiring that it be compiled with the proprietary plugin. I think there is a loophole in (3), so I hope I did not misunderstand it.

Re:GPL to plugins?

[Bruce Perens]

This is really bad advice. If your plugin is not distributed with the GPL software, it's still a derived work.

Re:GPL to plugins?

[Anonymous Coward]

And then I could write a translater that gets packaged with my plug in which is Lgpl licensed or something and publically state that I will waive any claims to requireing GPL compatible code only to be used with it.

So there we would have code that I owned being distributed under the GPL in which I have stated that I will not enfore the GPL on which will interact with GCC and I am the only one who can enforce my copyright on my code. It's still out of their hands and it still defeats them. I could actually wrap my disclaimer around the GPLed code stating that by opening the GPLed code (GPL only applies if you distribute it) and accessing it for any reason, you acknowledge that I will never attempt to enfore my copyright on that specific piece of code.

I wonder how the GPL and the FSF would actually work/react with something like that?

Re:GPL to plugins?

[jpmorgan]

How does using an API make your software a derived work? By that logic every program that runs on Windows is a derived work, since you're using Microsoft's API.

Does Microsoft get to dictate your license because your software runs on Windows?

Re:GPL to plugins?

[QuantumG]

No it's not Bruce. It's exactly what has been said by legal representatives of the FSF.. http://gcc.gnu.org/wiki/GCC_Plugins

Re:GPL to plugins?

[Bruce Perens]

That's "derived work" or "derivative work". If it's run-time linked to a GPL work, it's probably a derivative work anyway. The GPL doesn't concern itself with how two programs interact, you're just mistaken about that. It does say that an interactive user interface should be able to emit a statement about the license and where to get the source.

Re:GPL to plugins?

[jpmorgan]

Clever, so it's not the license of the GCC they're using to enforce this rule, but rather the license of the standard libraries.

Of course, one could always replace those GPL'd libraries with non-GPL'd ones, but that's starting to increase the amount of work required.

Re:GPL to plugins?

[Timothy Brownawell]

A plugin uses the host application's API. It is, therefore a derived work. In the case of the GPL, derived works must be distributed under compatible licenses.

It's only a "derivative work" of the application if it contains actual copyrightable stuff from the application. Things required purely for interoperability (like, say, function declarations or the data structures required by those functions) don't count.

Back when the IBM clone PCs came out, the clones had reverse-engineered and reimplemented BIOS code, very much derived from the original (copyrighted) BIOS. But it wasn't a "derivative work", because copyright covers the actual code itself, rather than what the code does.

Re:GPL to plugins?

[FishWithAHammer]

If it's run-time linked to a GPL work, it's probably a derivative work anyway.

As far as the plugin host is concerned, it's a data file that happens to run as code when run. The plugin just has to adhere to some specification (and I'm sure that somebody will reverse-engineer the spec, if it's not publicly available just as text). That doesn't make it a derivative work.

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?

[againjj]

Easy enough to get around that by having your "plugin" be a glue layer to a separately compiled binary with a command line interface, so your reason is useless. Besides, it has been suggested that rewriting a header file will get around copyright. See my post below for another analysis.

Re:GPL to plugins?

[QuantumG]

Sorry for the multiple replies.

Friend of mine once pointed out that practically the whole "let's GPL the library so any apps that use it have to be GPL too" strategy has been thoroughly dismantled by the BSD community.

Consider libedit. It's a BSD-like licensed replacement for libreadline - RMS's favorite example of "strategic" non-use of the LGPL. It's binary compatible with libreadline. So you can create your app and link it to libedit and happily distribute it under the BSD. To claim that libedit is somehow a derived work of libreadline because it has the same binary interface would be absurd. However, many installation scripts make a symbolic link from /usr/lib/libedit -> /usr/lib/libreadline.

That's the strong case for dynamic linking == derivative work.. plugin frameworks have always been the weak case. If the strong case doesn't stand up anymore, how can the weak case?

Don't get me wrong, I don't want to see proprietary plugins for GCC anymore than I like seeing all the proprietary modules for the Linux kernel. But claiming there is some clear legal principle that makes them a copyright violation is a joke.

Re:GPL to plugins?

[John.P.Jones]

Okay, so if I write a fairly configurable plugin that takes a configuration file (that just happens to be compiled machine code) and at run time (compile time that is) my plugin calls into this configuration file (read non-GPL library) to do its work well then I'll just make my plugin available under the terms of the GPL license. Of course it won't work to well without the configuration file but that is just data, obviously I don't need to redistribute my data under the GPL. Well sure my plugin isn't very useful without a configuration file, go ahead and write your own, from the source of the plugin its easy to see what the syntax is. Or you could buy mine, of course all the interesting logic of my new optimization happens to be contained within the configuration file not the plugin.

That is essentially why I think using the GPL in this fashion to limit the licenses of plugins is bunk. There isn't a problem that can't be solved by yet another level of indirection.

Re:GPL to plugins?

[Bruce Perens]

Reverse engineering is a means of avoiding trade-secret protection, not copyright. In the case of GCC, it's fully disclosed, and it's not at all clear to me that a document good enough to allow a working plugin would not be derivative.

But I suspect that this is all moot. If FSF puts a plugin mechanism in GCC, they're probably going to modify the license attached to it, too.

Re:GPL to plugins?

[Timothy Brownawell]

Reverse engineering is a means of avoiding trade-secret protection, not copyright.

What about the clean-room BIOS (re)implementation for the IBM PC clones?

Re:GPL to plugins?

[realxmp]

This is really bad advice. If your plugin is not distributed with the GPL software, it's still a derived work.

Mmm I suspect in the area of plugins at least this opens a serious can of worms. If the GCC team write a decent stable plugin architecture with a well documented API and then someone goes and writes a set of BSD header files from that documentation then the argument that it's a derived work gets a bit strained.

If the FSF continue to push that line then we start to move toward the territory of trying to copyright facts about interfaces which after the SCO fiasco most in the free software community might be wary of? Those of us with longer memories might remember how Compaq circumvented IBM's copyright on their BIOS API through clean rooming their interface. I wonder if it's applicable to this? If not, what's different?

Re:GPL to plugins?

[fbjon]

Why would proprietary plugins for GCC be bad? I can't really conceive of a similar situation to e.g. the Nvidia drivers.

Re:GPL to plugins?

[Bruce Perens]

There are a couple of problems with what the BSD folks think they have done. First, the BSD license is GPL-compatible, so nobody's going to sue them for infringement. Thus there is no case law to tell us if they are right or not. Second, the fact that libedit has the same binary interface as libreadline and perhaps does something that libreadline does (I haven't tried it) doesn't make it 100% clear that libedit is not derivative of libreadline. Third, if the distributor of proprietary software were to arrange for that software to be linked to libreadline, the distribution of the instructions to make the copy on the end-users system under control of the proprietary software maker is tantamount to the distribution of the copy.

Copyright law, unfortunately, gives us little help in this regard, because it is mostly written before the advent of software. We have to rely on case law, and to a great extent the cases have not yet happened.

Re:GPL to plugins?

[Zan Lynx]

it's not at all clear to me that a document good enough to allow a working plugin would not be derivative.

That is the point of the reverse engineering. For example, Wine is reverse engineered, and no one seriously claims Wine is derivative of Windows source code.

Re:GPL to plugins?

[Bruce Perens]

Reverse-engineering is a means to avoid trade-secret protection, not copyright. That's what is different.

If there is a requirement for modules to identify their licensing, as with Linux, it may be that FSF changes their license to require that such identification be accurate, and that the rejection of improper licenses by the software remain intact. This is a sort of anti-DRM. FSF turned copyright on its head, why not DRM too?

Re:GPL to plugins?

[QuantumG]

define "bad". RMS thinks proprietary plugins would be bad because he thinks everything proprietary is bad.

But let me give you an example. I once worked at a company called Codeplay in the UK. They made compilers, proprietary compilers, and one of their biggest markets was the Playstation 2. Everyone used GCC to develop on the PS2. Ok, a few people used Metroworks' compiler - whatever. So they were directly competing with GCC. Our C++ support was horrid. Our C support was better, but one of the things I did was write automated testing tools that compiled "random" C programs with GCC and out compiler and compared the warning/error messages and output from running the program if it actually managed to compile. Anyway, some of the guys there had written instruction schedulers for GCC that made the code generated by GCC for the PS2 actually half decent. This code never saw the light of day because it would have competed with Codeplay's offering. If GCC had a plugin framework (and wasn't so nazi about proprietary extensions) we would have completely changed our business model. Our customers most certainly would have preferred it.

Re:GPL to plugins?

[QuantumG]

According to the GPL, BSD-like-licensed code that is distributed in binary form must be accompanied by the full corresponding source code or an offer to provide the source code valid for 5 years (or whatever). That's what the BSD nerds are complaining about.

There's no case law that even suggests that copying an API can result in a copyright infringement. That's SCO all over again.

Re:GPL to plugins?

[AxelTorvalds]

I don't know that it has been fully established in court, my company's lawyers are scared enough by all of the language though. The intent is pretty clear, if you use GPLed code in some capacity of leverage it, they want you to GPL your code too. That's always been the idea. In the case of a compiler plugin, depending on how it is linked and other things, if you distribute it at all, you might need to make your code GPL compliant. GPL3 tried to make that all more clear and GCC is GPL3.

I'm not going to push the ideology here but the last decode or so has shown in more than a few cases the only time this seems to matter is when some company doesn't have the resources to build something but they want to put some tweak on it and sell that. If you're writing some kind of optimizer that you need to keep "secret" but you can't build a full compiler then it's hard to offer much sympathy. If you're building some sort of static analyzer or something that you need to keep "secret" again, I think there are more than enough holes here, you really just can't link to GCC, write your plugin, GPL it and just have it dump whatever intermediate form you need. Custom language or custom hardware support? There are probably some more treacherous areas, I'd imagine that some of the better ILs are somehow protected, and I'd also imagine more than a few compiler jocks would like to graft some of that stuff together, you know GCC's parser and Yoyodyne Corps optimizer and code generator, stuff like that.

Having worked with more than one chip vendor that "sold" a GCC derivative that supported their hardware, to be completely honest it would have helped our cause and theirs to just GPL the code to begin with.

Everyone thinks compiler plugins is cool for one reason or another and just about everyone will hate it when there is some interesting plugin that costs $2500 a seat and does some cool stuff but in only runs on Redhat's enterprise Linux in 32bit mode... with a version of GCC that is 2 revs back.

Re:GPL to plugins?

[Timothy Brownawell]

If there is a requirement for modules to identify their licensing, as with Linux, it may be that FSF changes their license to require that such identification be accurate,

Wouldn't that be about the same as solving the halting problem?

Re:GPL to plugins?

[Bruce Perens]

The binary BIOS was trade-secret. It's a whole different part of the law. The application of reverse engineering for avoidance of trade secret is known well in law. Trade secret information is unpublished. The same for Samba - it was unpublished information that they reverse-engineered, and they can use the "fair use" defense in copyright law (it's a defense, not an affirmative protection). GCC, on the other hand, would be published. It would even have an ISBN number, as part of some distribution if not on its own. It's not at all clear to me that you can use reverse engineering strictly for avoidance of copyright on published information.

Bruce

Re:GPL to plugins?

[Anonymous Coward]

Microsoft doesn't have a viral license for its API.

Re:GPL to plugins?

[Bruce Perens]

If Wine is truly reverse-engineered, the source is unpublished information. Not published information such as the GCC source or the Windows programming manual. I suspect that some of Wine is not reverse-engineered but made using a windows programming manual.

At this point we are not in the realm of reverse engineering any longer, but in the fair use defense in copyright law.

And I think we have to wait to see how FSF releases and licenses this interface before we can understand what will be fair use.

Re:GPL to plugins?

[QuantumG]

If there is a requirement for modules to identify their licensing, as with Linux,

That shit is so illegal and it's dangerous as hell too. The Lexmark case has broadcast loudly what the supremes think of technical measures being used to prevent interoperability like this. The court held that the use of the Toner Loading Program as a "lock-out code", within the sense established in the 9th Circuit's Sega v. Accolade opinion (not previously binding on the Lexmark panel, which is 6th Circuit), rendered it uncopyrightable as a matter of law and therefore fair game for copying without any license whatsoever, for the purpose of interoperating with Lexmark's printers. If the court found similarly for MODULE_LICENSE("GPL") then it could be disastrous. Anything from the module license checking code to the whole kernel could be found uncopyrightable.

Re:GPL to plugins?

[RiotingPacifist]

from a quick look at the mailing list it appears to me the problem is
1) company produces new hardware
2) company produces proprietary plug-in to produce asm for their hardware platform
3) they do not open their specifications
4) they are able to take advantage of GCC and its front ends while using a closed backend
5) ???
6) profit

I may by wrong as i said this is just a quick read of the javabyte code discussion somebody linked to from here.

Re:GPL to plugins?

[RiotingPacifist]

Second, the fact that libedit has the same binary interface as libreadline and perhaps does something that libreadline does (I haven't tried it) doesn't make it 100% clear that libedit is not derivative of libreadline

doesn't that make wine a derivative of windows

Re:GPL to plugins?

[Bruce Perens]

SCO wasn't an API case. Long before the SCO case was brought, that API was a US Government standard.

It's not just that the API is duplicated, it is that the duplicate is made to be dynamic linked to the main work. The closest thing we have had to a dynamic linking case was Nintendo v. Goloob Games. That was about the Game Genie plugging between the Nintendo console and the game cartridge. It's not entirely germane to what we're talking about here. Over the 20 years we've been talking about dynamic linking, there's still been no case law.

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.

Re:GPL to plugins?

[Bruce Perens]

I can't think of why. It's been a pretty clear issue with Linux modules. They have a string identifying their licensing. Some people fraud that string with an embedded null character, but it's still fraud.

Re:GPL to plugins?

[Bruce Perens]

I have not looked at Wine's use of 1) clean-room reverse engineering and 2) fair use under copyright law sufficiently to say it's not derivative of Windows, but it doesn't matter! That's because Microsoft has been compelled to release that infromation in a usable form as part of their consent decrees, and if they brought suit they'd create more anti-trust problems for themselves.

Re:GPL to plugins?

[QuantumG]

There's been a bunch of cases where interoperability has been singled out as desirable. It seems hard to believe that a case presented in that way would fail. Distributing GPL software with proprietary extensions is pretty clearly a violation, but distributing proprietary extensions separately is a much murkier matter.. The tolerance of it by the Linux devs is getting beyond a joke. Even Greg KH has stopped rattling his saber and is trying to play it political now.

Re:GPL to plugins?

[Bruce Perens]

I don't think you can connect the Lexmark case with this, the facts are too different. Nothing prevents you from creating a compatible GCC plugin, there are only restrictions that it must be available to others with certain rights. If Lexmark had only required that the cartrige program be under the GPL, there would have been no Lexmark case.

Re:GPL to plugins?

[Timothy Brownawell]

I can't think of why. It's been a pretty clear issue with Linux modules. They have a string identifying their licensing. Some people fraud that string with an embedded null character, but it's still fraud.

It also causes the identification to not be accurate, and I think it's required for (some) interoperability (EXPORT_SYMBOL_GPL). (I also question whether it can properly be called "fraud", who is being tricked out of what?)

Re:GPL to plugins?

[QuantumG]

You have to read the findings of the case. They court specifically says that copyright cannot be used to lock out competitors. Requiring that people agree to your licensing demands is a lock out.

Re:GPL to plugins?

[Anonymous Coward]

No, you need to realize what a tool you, apologize, and shut the fuck up.

Re:GPL to plugins?

[Anonymous Coward]

Reverse-engineering is a means to avoid trade-secret protection, not copyright. That's what is different.

This is wrong. Reverse-engineering is not a "means to avoid trade-secret protection." It is a lawful activity with as many purposes as their are reverse-engineers. A person can be contractually obligated to not divulge trade secrets, and therefore cannot participate (I am being on the safe side here, in case somebody thinks IAAL -- IANAL) in any project that will divulge in those secrets. That does not make reverse engineering primarily or fundamentally a "means to avoid trade-secret protection". It is incidentally a means to avoid trade-secret "protection", invoked in specific cases when an engineer under an NDA ends up working for a competitor. In this case, if the competitor wishes to reverse-engineer a product, the NDA-bound employee cannot participate -- a "clean room" reverse-engineering.

Even granting a very generous interpretation, you are splitting hairs, especially since the reverse-engineer intends to duplicate the functionality. If copyright law does not consider the new module a derived work (and it sounds like it doesn't in this case), then the goal is achieved. Just how Compaq re-implemented IBM's BIOS API.

Re:GPL to plugins?

[FishWithAHammer]

But I suspect that this is all moot. If FSF puts a plugin mechanism in GCC, they're probably going to modify the license attached to it, too.

And LLVM/clang will continue to rise and GCC will start sliding. Great ideas.

Re:GPL to plugins?

[quippe]

Following your point and your libedit example, the company developing a proprietary gcc plugin could only distribute it along with a "gcc-like - binary compatible build"; i mean all the collection not just the plugin framework. If in the real world they distribute a plugin which calls an api entrypoint in the gcc plugin framework, how would they tell it not being a derivative work? Isn't the lgpl there to allow exactly that, opposing the gpl?

Re:GPL to plugins?

[Lord Kano]

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

You sir do not understand what "derived" means.

As others have pointed out, much software uses the WIN32 API;that does not make them derived works. How about this. QT for Windows uses the WIN32 API. Does that mean that they've taken a derived work of Windows and made it LGPL?

No, of course not. There must be more to this. Maybe like an SDK that will be GPL only. Whatever the case may be, what's to stop some company from reverse engineering the SDK and putting out a plugin with whatever license they choose?

Re:GPL to plugins?

[Timothy Brownawell]

If in the real world they distribute a plugin which calls an api entrypoint in the gcc plugin framework, how would they tell it not being a derivative work?

Because work A being a "derivative work" of work B is defined to mean that A includes material from B. Program C calling a function in program D does not mean that C includes part of D, so it does not make C a "derivative work" of D.

Whether A is a "derivative work" of B from the perspective of copyright, and whether it is derived from B from the perspective of scientific/academic attribution are separate questions.

Re:GPL to plugins?

[Bruce Perens]

It's a system that is there to differentiate between purposely exported symbols for interoperability, and internals which are not providing an interface for interoperability. The fraud comes when a program that doesn't really have the the legal permission to use the internals provides a lie to do so. There isn't anything restricting the provision of a GPL device driver which would be fully compatible and interoperable except some internal intellectual property restriction of the organization providing the driver. So, who is on the side of interoperability here? The party that hides its driver internals and lies about its license, or the party that asks third parties to give rights to others.

Re:GPL to plugins?

[Bruce Perens]

LLVM/clang will rise if they convince people to both work on it and to actually release their work to others. Otherwise, we get stuck with a bunch of half-proprietary compilers. There is still a lot of work before we have any clue whether they'll get done or not.

Re:GPL to plugins?

[Bruce Perens]

You mean the 6th Circuit Appeals Court Opinion in Lexmark v. Static Control Components? It applies a number of metrics for determining when and how copyright is valid. The particular plugin situation we're discussing is not "locking out competitors", anyway, it's simply asking for a particular rights set in what is most likely a derivative work. But which of these particular metrics do you think locks out an insistence that the plugin provide the rights associated with the GPL?

Re:GPL to plugins?

[Anonymous Coward]

If wine uses the windows API, do I have to buy windows to run wine?

Re:GPL to plugins?

[Timothy Brownawell]

The fraud comes when a program that doesn't really have the the legal permission to use the internals provides a lie to do so.

How is such permission required? (Especially given that the end-user is permitted essentially arbitrary modifications so long as they don't redistribute, so no contributory infringement...)

Re:GPL to plugins?

[Anonymous Coward]

DRM for GCC plugins? It will never work!

If someone wanted to circumvent these requirements, all they would need to do is fork GCC, remove the DRM, and release your DRM free GCC under the GPL.

I imagine it would be difficult for GPL projects to implement DRM as well as closed source software projects.

Re:GPL to plugins?

[thesupraman]

That a load of rubbish, it is perfecty legal to use GCC to link a build in gcc library with a non GPL library, because the libraries in gcc are NOT GPL!, they are LPGL!

Otherwise GCC would be significantly less useful.

What they are doing here is trying to be viral, plain and simple - use FUD to scare developers that unless they force GPL plugins, somehow everyone will get tained - this is exactly as true as making it illegal to link any non-GPL library using GCC.

The big issue with this is that it would stop for example Intel from releasing a plugin vectoriser for their CPUs unless they GPL it, or NVidia from adding a non-GPL CUDA code generator, etc, etc.

It is another attempt by GNU to 'own' software, which is becoming increasingly clear as their aim - which one would have though would have been the opposite.

Perhaps they should remove LGPL from their libraries, lets see just how long GCC lasts...

Re:GPL to plugins?

[RightSaidFred99]

And this is bad because... they don't like seeing other people make money? It amuses me the same people who hate DRM get all uppity when someone may be using GPL'd work to make money.

Re:GPL to plugins?

[a_n_d_e_r_s]

The solution for the problem is very simple, if you don't to release your software as GPL code - don't use GPL code as a base for your software.

Thus if you don't want to write GPL code, don't write a plugin to GCC. Instead write some other software that has nothing to do with GCC.

If you want to write software and base it on GPL code, the least you can do is to return the favor and also release your own code as GPL code.

The GNU project is based on the old tradition that if you are nice to others so will hopefully they be nice to you too.

Re:GPL to plugins?

[sumdumass]

You obviously don't understand the issue here.

A plug in doesn't use GPLed software, it used an API which doesn't make it a derived work no more then running QT on windows makes QT a derived work of Microsoft windows. GCC can and has traditionally been used to compile code that isn't GPLed or even GPL compatible. What they are attempting to do here is sneak some attachment to the plug in architecture of GCC that inflict the GPL on anything that is made to use it.

Re:GPL to plugins?

[eggnoglatte]

Ah, but this is a plugin. At the moment of distribution, it isn't linked to anything. The end-user "links" it to a separately distributed gcc by placing the plugin in a specific directory (or whatever else the mechanism will be).

It is patently obvious that this doesn't fall under the "derivative work" clause of copyright law (and therefore cannot be prevented by the GPL).

Re:GPL to plugins?

[Bruce Perens]

That would only be the case if the module was created by the end-user and never distributed. The module use of the internals makes it a derivative work.

Re:GPL to plugins?

[Bruce Perens]

It is still itself a derivative work and is distributed. And then there is the whole issue of linking at the end-user's system with the purpose of circumventing the license. Distribution of instructions that cause that linking is tantamount to distributing the components themselves.

Re:GPL to plugins?

[Anonymous Coward]

At the moment the case is

1. company produces new hardware (so is obviously a chinese or taiwanese company).
2. company modifies gcc to work on hardware
3. they do not provide source to compiler but it just happens to have the same options as (an old version of) gcc.
4. tough luck debugging their compiler
5. Are you (as a developer) really going to sue your supplier under the GPL to provide source? I don't think so.
6. Profit

Re:GPL to plugins?

[Morten Hustveit]

It is bad because they don't want the compiler they've written for free to be exploited for profit by someone who's not willing to share their code. If you want to make proprietary software, don't use the hard work of someone who doesn't want to be a part of it.

I have no idea why you compared DRM to GPL. DRM is about restricting use otherwise allowed by copyright law. GPL is about allowing things otherwise disallowed by copyright law (if you don't accept the license, only copyright law applies).

Re:GPL to plugins?

[bug1]

It is another attempt by GNU to 'own' software, which is becoming increasingly clear as their aim - which one would have though would have been the opposite

More precisely "It is another attempt by GNU to 'control' the software it has copyright hold on."

You want a compiler, you want someone else to write it, and you want it on your terms, ingrate much ?

Re:GPL to plugins?

[bug1]

A plug in doesn't use GPLed software, it used an API which doesn't make it a derived work

WRONG.

If you make a GPL'ed libarary and i write an application that uses its API, then my application is very much a derivative work.

Thats software licensing basics, the only source of confusion i think you might have is if the API is a standard published interface, such as a C library.

If my application needs to link to a C library, it doesnt make it a derivative of glibc, as in theory it could be linking to another C library such as uclibc.

GCC is a single application so it cannot be a standard interface, and its certainly not being published asa standard interface as can been seen by the fact that they are clarifying the plugin license issue in this way.

Re:GPL to plugins?

[bug1]

Having the headers isnt the issue, its the linking stage that creates a dependency on the GPL'ed work and therefore makes it a derivative work.

Re:GPL to plugins?

[drinkypoo]

If you make a GPL'ed libarary and i write an application that uses its API, then my application is very much a derivative work.

Is this really clear? If so, would the GPL have needed an explicit clause to say that any software which won't function without another piece of software which is GPL must also be GPL?

Re:GPL to plugins?

[Anonymous Coward]

'don't use the hard work of someone who doesn't want to be a part of it.'

Then dont try to push your product by giving it for free till you kill any other solution....
Basically you act exactly like Microsoft, giving for free something till you kill any other solution cause you raised the entry ticket so high only a megacorp can compete.

RMS and Bill Gates are both fucking assholes, only the color of the shit is different.

Re:GPL to plugins?

[Anonymous Coward]

I have no idea why you compared DRM to GPL. DRM is about restricting use.

So is the GPL.

Re:GPL to plugins?

[Timothy Brownawell]

If you make a GPL'ed libarary and i write an application that uses its API, then my application is very much a derivative work.

Is this really clear? If so, would the GPL have needed an explicit clause to say that any software which won't function without another piece of software which is GPL must also be GPL?

I think you have it backwards: if that isn't the case, then that part of the license is meaningless. (But I tend to think that it is in face not the case, since "run this code from that library" is very different from "I've included here a copy of this code from that library", in the first case you still have to obtain that copy (presumably from the copyright holder) which is what copyright is all about.)

Re:GPL to plugins?

[RiotingPacifist]

no GPL extends use beyond normal copyright law. get a fucking clue. Sure GPL is more restrictive than BSD (which is in turn more restrictive than PD) but it defiantly doesn't restrict use over normal copyright.

Re:GPL to plugins?

[roystgnr]

Having the headers isnt the issue, its the linking stage that creates a dependency on the GPL'ed work and therefore makes it a derivative work.

Oh, that's certainly true - the combination of a GPL'ed work and anything else linked together is a derived work, which you can't redistribute without providing source code that's all under a GPL-compatible license.

So don't redistribute it. Just give out your own work, alone, not linked to the GPL'ed work. Problem solved. I can take two DVDs and create a derived work of both of them by appending one to the end of the other, interleaving scenes, etc.; that doesn't mean the publishers are violating eah others' copyrights by distributing them separately.

Re:GPL to plugins?

[Anonymous Coward]

I see why you may think so, but you're wrong.

The GNU project is based on the tradition of exploiting people's fears - in this case, the fear of "somebody getting the better of them", that is, the fear that somebody else might earn money from "their work" without them earning anything. So, the thing to do is to block the ability of anybody else to earn money in this fashion - even though it does not result in anything more for you, less for others is good, right?

So, you do what you can to make it impossible for others to do work that they could get paid for. So the other people, quite reasonably, choose not to do this work. And you get no contributions from them, something you *might* have gotten if they worked to make something from your code (as hardly all changes are worthwhile to sell), but you're *sure* to not get anything if they don't work on your code.

Re:GPL to plugins?

[sumdumass]

If you make a GPL'ed libarary and i write an application that uses its API, then my application is very much a derivative work.

Wrong, an application using a libray depends on the library for function. A plug in depends only on the host API to work in the same way that Mozilla depends on X or gnome to work. Mozilla does not become a program derived from KDE, Gnome, or Microsoft windows when it is designed to run on either using it's API. Similarly, Open office .org doesn't become a derived product of either nor does it become derived of Java because it relied heavily on Java libraries. Your talking about apples and orages when talking about the use of API and libraries compares to API and plugins. There is a line that separates them.

GCC is a single application so it cannot be a standard interface, and its certainly not being published asa standard interface as can been seen by the fact that they are clarifying the plugin license issue in this way.

I can say that the moon is made of green cheese. It doesn't make it so. Likewise, it wouldn't make GCC some proprietary app that only specific plugins can use just because they said so. And lets be honest, it would be a propriatary app if it locked others out of it. If they open the architecture to plugins, this is simply something they will not be able to control.

Re:GPL to plugins?

[DragonWriter]

That's "derived work" or "derivative work".

Quite. Sometimes, even preview doesn't help if your brain really knows what you meant to write and refuses to see anything else.

If it's run-time linked to a GPL work, it's probably a derivative work anyway.

If its statically-linked, I'd tend to agree with that. If its dynamically-linked, I'd say that's far less likely to be the case.

Re:GPL to plugins?

[Knuckles]

And this is bad because...

Because it violates freedoms 0 to 3? The whole reason for GNU's existence?

Re:GPL to plugins?

[sik0fewl]

What you're suggesting is that GPL licensing your code doesn't protect it at all because I can just isolate any GPL code from my non-GPL application and link to it dynamically.

That's a pretty strong statement to make.

The reason people can link to glibc and libreadline without GPLing their apps is because they are writing their application against a generic interface . Just because I happen to be linking to glibc doesn't GPL my app--it could just as easily compile against any other standard C library (quirks aside). The same goes for libreadline. libreadline used to be the only interface for "readline" but now it's become more generic since theirs a BSD clone of it. You can now link an app against libreadline without GPLing it, because it could just as easily have been linked against libedit.

Re:GPL to plugins?

[vakuona]

If the BSD guys had used a non GPL compatible license, they wouldn't be sued for infringement either (as long as they hadn't used any of the code from libreadline).

Works that are derived from libedit (if they exist) do not have to be made available under a GPL compatible license. Therefore the fact that libedit is under a GPL compatible license is not relevant to this.

Re:GPL to plugins?

[againjj]

That a load of rubbish, it is perfecty legal to use GCC to link a build in gcc library with a non GPL library, because the libraries in gcc are NOT GPL!, they are LPGL!

Otherwise GCC would be significantly less useful.

Actually, the libraries in gcc that are not GPL are not LGPL either. They are GPL with the runtime library exception. That runtime library exception states something to the effect of this: if this library is linked to the end compiled product, then this library may be distributed under any license whatsoever -- in particular, the source code distribution requirements of the GPL and LGPL do not apply. The new exception does not change this in the slightest. It only makes a difference if plugins exist, which they don't yet. Please reread http://www.gnu.org/licenses/gcc-exception-faq.html

What they are doing here is trying to be viral, plain and simple - use FUD to scare developers that unless they force GPL plugins, somehow everyone will get tained - this is exactly as true as making it illegal to link any non-GPL library using GCC.

Viral, yes, but FUD, no. They are being pretty clear as to what they intend. They want any distributed program compilable with a gcc with any plugin, proprietary or not, to be compilable to an identical binary with a gcc with only GPL-compatible plugins. If you don't distribute, they don't give a damn. If you do, the plugin had better not be required unless it is GPL-compatible.

Re:GPL to plugins?

[eggnoglatte]

Sorry, but you are letting yourself be blinded by ideology. Copyright law very clearly states that "derivative work" is only work that directly uses a certain percentage of the original work. Like a mashup in music, or taking a couple hundred lines from gcc and using them elsewhere.

Ask yourself this: assume somebody writes a compiler with the same plugin infrastructure as gcc. Now I am distributing a closed source plugin for that compiler, which also happens to work with gcc. Note that I am not distributing either gcc or the other compiler.

Is my plugin derivative work? Of what? gcc? The other compiler? Of course the answer is "no" in both cases! And since the legal status of my plugin does not depend on the existence of a third party software (the mythical second compiler), it should be very clear that distributing binary plugins is perfectly fine, even if they work just with gcc.

A plugin interface is an API, and API compatibility does not mean derivative work.

Re:GPL to plugins?

[ray-auch]

> If the FSF continue to push that line then we start to move toward the territory of trying to copyright facts about interfaces which after the SCO fiasco most in the free software community might be wary of?

This can of worms has been opened many times before, long ago, and indeed has upset people in the community.

eg. from 1993:

On the basis of rms current comments I won't be putting anything more
under the GPL/LGPL, in fact I'm sufficiently annoyed that rms is
claiming interface copyrights that I'm tempted to allow anything but
GPL/LGPL code to be linked with my stuff.

Quoted from http://groups.google.co.uk/group/gnu.misc.discuss/msg/c77a27c6303b49a4?hl=en.

And, yes, I think you will find that that is _the_ Alan Cox.

Re:GPL to plugins?

[Anonymous Coward]

You say that Codeplay buried the code, but FSF are the nazis? That's pathetic.

Re:GPL to plugins?

[Bruce Perens]

Well, I didn't understand yesterday that FSF had changed the license on the GCC run-time. So, they seem to have done an end-run around the entire derived work issue, and it doesn't matter how you connect to GCC, pipes, network server, whatever, if you're not GPL compatible you can't use the run-time.

Re:GPL to plugins?

[QuantumG]

No.. what I said is that if you don't distribute any GPL code then your code does not need to be GPL, even if the end user is intended to link it to GPL code to use it.

That is, what I'm saying is that Nvidia are smart enough not to be breaking the law.

Re:GPL to plugins?

[Raenex]

The particular plugin situation we're discussing is not "locking out competitors", anyway, it's simply asking for a particular rights set in what is most likely a derivative work

Really, it's a disgusting idea that writing code that interoperates with other code is somehow a copyright violation. If you read the PDF, the idea that plugins are derivatives works is argued against quite thoroughly. Start on page 7 of the PDF. Some quotes:

• "If specific words are essential to operating something, then they are part of a `method of operation' and, as such, are unprotectable."
• "In the computer-software context, the doctrine means that the elements of a program dictated by practical realities--e.g., by hardware standards and mechanical specifications, software standards and compatibility requirements, computer manufacturer design standards, target industry practices, and standard computer programming practices--may not obtain protection."
• "When 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."

Re:GPL to plugins?

[Bruce Perens]

So, this is an interesting case because Lexmark did not file a writ of certiorari. This is probably because they didn't want it to go to the Supreme court and have the Supes confirm the finding of the 6th circuit and have it apply across the entire U.S. Such is not unusual, leaving us deliberately with half-baked case law. The effect is that here in the 9th circuit, the Lexmark case may or may not matter. Depending on whether the judge wants it to or not. If it had gone to the Supreme Court, the judge would be compelled.

And it ends up that this doesn't matter, because the GCC run-time license changed in interesting ways. I didn't know that yesterday. To use the run-time you need a GPL-compatible code generation chain, and it doesn't matter how the pieces connect together.

Re:GPL to plugins?

[Timothy Brownawell]

To use the run-time you need a GPL-compatible code generation chain, and it doesn't matter how the pieces connect together.

With an "interesting" definition of GPL-compatible. You have to be allowed to combine the plugin with GCC, but I don't see anything about needing to be allowed to distribute (um, convey) the resulting combinations. Which is odd, since the GPL allows you to combine it with pretty much anything so long as you don't convey the result.

Re:GPL to plugins?

[bug1]

Your talking about apples and oranges when talking about the use of API and libraries compares to API and plugins. There is a line that separates them.

Will the plugin work without GCC ? The answer is no, so the plugin is dependent on GCC.

If you violate the terms of GCC's license (and GCC, not the plugin writer that gets define the GCC license) you lose the right to distribute GCC and probably all GPL'ed works.

Law isnt like software, you cant just create a shim to avoid the bits you dont like.

None of your examples are relevant as they are permissive, please cite an example where plugins are used on a GPL'ed app, and such plugins arent explicitly permitted.

Copyleft is a good thing and needs to be defended.

Re:GPL to plugins?

[Bruce Perens]

I think distribution permission is implicit. How could you be allowed to combine the plugin with GCC if you were not allowed to distribute it?

Re:GPL to plugins?

[Raenex]

This is probably because they didn't want it to go to the Supreme court and have the Supes confirm the finding of the 6th circuit and have it apply across the entire U.S. Such is not unusual, leaving us deliberately with half-baked case law.

Perhaps, but if you read all the arguments it's pretty clear that copyright isn't designed to protect computer interfaces, so I really object to statements like "what is most likely a derivative work". Most likely it is not a derivative work, and I wish the claims that it is would stop. Principled freedom is important even when it works against the GPL.

To use the run-time you need a GPL-compatible code generation chain, and it doesn't matter how the pieces connect together.

Which is totally moving in the wrong direction. This is dictacting to the user how he may use the toolchain, something which FSF has generally stayed away from. Really, at this point the suggestion to move to something like LLVM is sounding better and better.

Re:GPL to plugins?

[Bruce Perens]

Um, doesn't your argument about my principles sound just the least bit ad-hominem to you? I'm quite proud of my adherence to principles, and would place myself higher than many in the Open Source world in that regard. The courts have definitely not said the last word (or even many first words) on dynamic linking, and thus it's more than a bit soon for you to attack me on principle for my stance on it.

Before you recommend that folks move to the LLVM code chain, remember that the work on it so far has gone to support such things as the proprietary Flash VM environment, and that the license on the LLVM-based compiler for that prohibits reverse-engineering of the VM codes that it emits. In contrast, the goal of FSF is to keep all of the code in the open, certainly more benign than what Adobe is doing.

Bruce

Re:GPL to plugins?

[Raenex]

Um, doesn't your argument about my principles sound just the least bit ad-hominem to you?

Let's just say I vehemently disagree :) I haven't attacked you personally, just your position.

The courts have definitely not said the last word (or even many first words) on dynamic linking, and thus it's more than a bit soon for you to attack me on principle for my stance on it.

No, there's no "last" word yet. However, the principles and cases cited in the PDF clearly support the idea of that interfaces are not copyrightable and should not be copyrightable. Why have you have taken the position that writing to an interface via dynamic linking is derivative? Where's the case law in favor of your position? On what moral basis do you rest your argument?

Before you recommend that folks move to the LLVM code chain, remember that the work on it so far has gone to support such things as the proprietary Flash VM environment

Tools can be used for good and bad.

Re:GPL to plugins?

[Bruce Perens]

Why have you have taken the position that writing to an interface via dynamic linking is derivative?

My main goal here is to protect Free Software developers from being used as the unpaid employees of some proprietary software company. Those who have no problem being used in that way are free to apply gift rather than share-and-share-alike licensing to their work.

Where's the case law in favor of your position?

There is not yet pertinent case law. The existing cases are less than entirely germane. The one on which you base your argument, for example, is about software that connects in a different way than dynamic linking, and only applies in one circuit.

On what moral basis do you rest your argument?

I'm out to protect the developers.

Tools can be used for good and bad.

Yes. When I have my tools used to facilitate proprietary software, I like to be paid (or have the company that supported my work paid) for that. When my tools are used to facilitate Free Software, I feel that the increase in Free Software is the only quid pro quo that I need. I feel this is the best stance for most Open Source developers.

Bruce

Re:GPL to plugins?

[Raenex]

The existing cases are less than entirely germane. The one on which you base your argument, for example, is about software that connects in a different way than dynamic linking, and only applies in one circuit.

It cites many other cases as precedent. The principle is the same -- interfaces are not copyrightable, and writing to an interface is not a derivative work. You are claiming a special privilege for dynamic linking without any supporting argument.

I'm out to protect the developers.

That's "the end justifies the means". I don't like it when some company tries to make add-on products illegal. I don't like it when the FSF takes the same stand, just because it helps their causes. You seek to corrupt a good principle for your cause.

When I have my tools used to facilitate proprietary software, I like to be paid (or have the company that supported my work paid) for that.

Ok, but of course not everybody shares that opinion, and gcc was licensed to compile code for all projects, not just open source ones. The FSF also shied away from EULAs, which is what this new library exception amounts to. There are limits as to how much the FSF can legislate in the name of software freedom before people move elsewhere.

Re:GPL to plugins?

[Bruce Perens]

I think FSF's principle in regard to licensing is that they do not remove any rights that you would have had without the license. I haven't looked at the GCC run time license for very long yet, or discussed it with one of the responsible people. So, I can't yet speak about the rationale behind this license and how it conforms with that.

I know that FSF's answer would be that proprietary software is not ethical. My own position is that proprietary software is on its own - and shouldn't incorporate components that were built to be Free and to preserve software Freedom. I think you have to be careful to differentiate use of GCC, like building proprietary code with the compiler and the runtime - which FSF explicitly allows - from direct incorporation of GCC into some proprietary product - which FSF seeks to block.

Bruce

Re:GPL to plugins?

[sumdumass]

Will the plugin work without GCC ? The answer is no, so the plugin is dependent on GCC.

Actually, you don't know that. There is no reason to believe that the plug in cannot be an independent code optimizer that links the optimization on the fly as it's compiling or something. There is no reason to believe that the plug in couldn't be some sort of statistical analysis program that would work with any data input but in this case, keyed and controlled by GCC itself. There is no reason why a plug in couldn't just be a trap for the exit codes that page someone or emails them when whatever is complete. All three of those examples could run independently of GCC but with a plug in architecture, it could manipulate or receive data directly with GCC too.

More importantly, the plug in or GCC wouldn't work without a kernel to run on. Now GCC comes with a limited kernel to build a boot file but who it to say it has to use that? I couldn't use GCC on to build MyProgram for my setup whithout using the kernel installed, but that doesn't make it a derived program because it can run on my system now does it. Open office isn't a derived program because it run in KDE is it? I didn't think so either. The specific that runs in KDE couldn't even be considered a derived program.

If you violate the terms of GCC's license (and GCC, not the plugin writer that gets define the GCC license) you lose the right to distribute GCC and probably all GPL'ed works.

There is no probably about it. A license violation only applies to that specific version of software. A ban because of a violation couldn't apply to future versions or other versions. And even the current version, because there is no exception in the GPL for people who have previously been restricted in their use of a GPLed work, obtaining a new piece of software and agreeing to the new terms is enough to get new permision. However, I'm not saying that you can violate the GPL, I'm saying your attempting to apply it where it doesn't belong.

Law isnt like software, you cant just create a shim to avoid the bits you dont like.

Lol.. We are talking about a software license not law. And yes, you can create a shim in both, it's called loopholes. That's where you do things neither the license nor the law forseen and the spirit of the law or contract should make it a violation but because it doesn't violate the letter of either, it doesn't.

None of your examples are relevant as they are permissive, please cite an example where plugins are used on a GPL'ed app, and such plugins arent explicitly permitted.

It doesn't matter is something is permisive. They are that way because they can't be restrictive. Your the one making outlandish claims to the contrary of what I'm saying, you provide examples. The GPL makes no exceptions for plug in at all. If something can be permissive, it is specifically because the GPL does not apply otherwise it would not be a GPLed program.

You see, this just shows how confused you actually are. You cannot change the GPL and call it GPLed. You can give extra permissions according to the GPL but not honoring the GPL is not one of those abilities. If the GPL applies, it will apply regardless of someone claiming it doesn't in this specific instance. After all, that is what a permissive clause would do with plugins- it would say this is licensed under the GPL but you don't have to follow it. Now, either the plug in are covered or they aren't. If they aren't, then your wrong. If they are, then no one can give permision for plugins except the original author and those permissions would be null and void when someone other then the original author distributed the program. The GPLv3 has language specifically for that, it can't happen.

Copyleft is a good thing and needs to be defended.

I never said i

Re:GPL to plugins?

[MSG]

I apologize for not using the terminology from the appropriate license. Compiler plugins are definitely work "based on" GPL licensed code, and must be covered by a compatible license. Anyone who believes otherwise may have to defend that position in court.

Re:GPL to plugins?

[MSG]

If the license for Microsoft's DLLs specified restrictions on the applications that used them, then the question would be more relevant. I don't believe that Microsoft places any such requirements on applications that use their platform.

You should note that this is a different situation than glibc on GNU/Linux. Applications using glibc are generally not considered to be based on that library, since its API is similar to other POSIX systems.

Re:GPL to plugins?

[MSG]

Just give out your own work, alone, not linked to the GPL'ed work. Problem solved.

If your work, alone, doesn't do anything useful, then you probably will not be successful in convincing a judge that your work is not "based on" gcc, and subject to its license.

Re:GPL to plugins?

[MSG]

You sir do not understand what "derived" means.

Not only that, but I used the wrong term entirely. The correct term was "based on". I apologize.

Does that mean that they've taken a derived work of Windows and made it LGPL?

No, but they have created a work that is arguably based on the Win32 interface. If the license for the Win32 interface stipulated the terms that were suitable for works based on it, then QT would have to comply. I don't believe that any such license requirements exist for the Win32 platform, which makes it an unsuitable analogy.

Whatever the case may be, what's to stop some company from reverse engineering the SDK and putting out a plugin with whatever license they choose?

A court, I'd assume. If you create a plugin to an application and believe that your work is not based on said application, you might have to defend that view before a judge.

Re:GPL to plugins?

[bug1]

The GPL will not be forced onto a plugin because the program is GPLed. It might be depending on what the plugin does and how it works but it won't automatically cover all plugins.

If you think your legal opinion is better than the advice the FSF gets then there is no point me trying to explain it.

But seriously, how you can claim FSF is being deceptive when they are stating there intent prior to any actions that might take place ?

Re:GPL to plugins?

[Lord Kano]

Not only that, but I used the wrong term entirely. The correct term was "based on". I apologize.

I'm going to have to disagree with you here as well. IANAL, and apparently you are not either.

"Based on" is far too imprecise a term. The code that you write is yours. You can license it under whatever terms you want to. The GPL is only binding if you use someone else's code.

LK

Re:GPL to plugins?

[sik0fewl]

It's not the distribution part that makes your code have to be licensed under the GPL, it's the derived work part.

From my understanding, Nvidia wrote Windows drivers and then ported them to Linux, creating a GPL wrapper as an extra layer of protection. The drivers obviously aren't derived works of Linux if they were written for Windows.

I'll admit it's a complicated issue, but I have to disagree with you. I don't think anything can be said for certain until their is some case law to back either side.

Re:GPL to plugins?

[sumdumass]

They are being deceptive by claiming that all plugins will have to be GPLed. That simply isn't true. Some of them will, some of them won't. Some of them won't have to be but will be anyways.

In the least, there are a number of wars that they can be made which won't be by any definition, a derivative work.

Re:GPL to plugins?

[bug1]

Its not deception unless they know they are wrong.

Re:GPL to plugins?

[QuantumG]

Drivers are written for hardware.. the bulk of the driver is not the tiny bit of glue that joins it to the kernel. In any case, the NVIDIA drivers are not just "ports" of the Windows drivers to Linux.. that's a terribly simplistic view - in fact, NVIDIA has been criticized for failing to reuse much of the existing open DRI/DRM infrastructure. I recently looked at another binary-only driver for ISDN cards. They do something similar to NVIDIA in that they release an "open source" wrapper for their binary-only .a lib. So you can see exactly the parts that anyone could possibly argue are "derivative" and the parts that are proprietary. I estimate it is 99.9% new code which has nothing to do with Linux. To claim that this driver is a derivative work of Linux is just absurd, but if it fits with your world view, people tolerate it.. and moan when reality doesn't conform.

Re:GPL to plugins?

[sumdumass]

They are wrong.

Re:GPL to plugins?

[bug1]

They are wrong.

Being wrong doesnt make it deception.

Re:GPL to plugins?

[sumdumass]

It does if they knew they are wrong.

Fuck, can't you follow your own post? You laid it out, I said they were wrong just after saying they were wrong and knew it by claiming deception.

Re:GPL to plugins?

[bug1]

I said they were wrong just after saying they were wrong and knew it ... I think you must be reading your mental notes.

Re:GPL to plugins?

[sumdumass]

I think you must be reading your mental notes.

That could be. Anyways, that's the intent of my statement. They know that not all plugins will be derived works and therefor they can't force the GPL onto them yet they are claiming they can.

I was thinking, if I created a plugin that was nothing more then a socket extending the API from GCC to the api for my socket which allowed commercial plugins to use GCC by proxy of my socket, then promised to never enforce the GPL requirements if you download the plugin from me, we could bypass the "GPL only" inferences altogether. I'm the only one who can claim copyright on my works and I'm the only one who can enforce it so non-compliance wouldn't be a problem.

Re:GPL to plugins?

[bug1]

I was thinking, if I created a plugin that was nothing more then a socket extending the API from GCC to the api for my socket which allowed commercial plugins to use GCC by proxy of my socket, then promised to never enforce the GPL requirements if you download the plugin from me, we could bypass the "GPL only" inferences altogether. I'm the only one who can claim copyright on my works and I'm the only one who can enforce it so non-compliance wouldn't be a problem.

The FSF would still expect you to put your plugin (that transfers functionality through a socket) under a GPL compatible license, as such anyone you distribute that plugin to would have a right to the source, but the other end of the socket would be "clean" (afaik anyway).

If they wanted to stop such a scenario they would try and relicense some of it under the AGPL.

Re:GPL to plugins?

[MSG]

I'm not a lawyer, that is true.

However, the text of the GPL forbids you from (for instance) building an application which depends on a GPL licensed library and distributing that application under terms that are not compatible with the GPL. If you do so, you will soon find that you need a lawyer.

Re:It's Linux, NOT GNU/Linux!!

[Anonymous Coward]

lol, do not feed.

Re:It's Linux, NOT GNU/Linux!!

[hobbit]

GNU has produced an operating system. It's nowhere near as advanced in functionality as Linux, but it exists, and GCC one of the largest parts of it.

It's true that Stallman is a self-important man who makes himself look arrogant by delineating that GNU tools are part of the operating system but not making the same claim for a whole slew of other important tools.

But however correct the OP's statement, I agree with the reply made to it that the fact it comes apropos of nothing indicates it's a troll.

Re:It's Linux, NOT GNU/Linux!!

[CannonballHead]

I am aghast. Please use proper capitalization of "GNU." Your lack of respect for the roots of your operating system is disgusts me.

:P Seriously, I read the GNU website stuff (some of it) and ... ok, I get the point, but it's almost like they're on an ego trip, whining about how people are giving them proper credit, and wanting everyone to know how important they are. Frankly, I don't honestly care that much about Linus. And why not give credit to people who created Unix, since it's hard to write an OS that isn't influenced by current OS's?

Meh. If "Free Software" and "Open Source" and "GNU/Linux" means that sort of elite "you need to remember your roots and never use non-free software no matter how much it costs you or anyone else! Refuse to make money using any non-free software! And don't forget who we are!" attitude... well, even Microsoft doesn't seem that bad :) And I LIKE free software. And donations. And Magnatune. And dislike Apple. And iTunes... [continue list of Slashdot Qualifications]

Re:It's Linux, NOT GNU/Linux!!

[Shakrai]

nuff said.. why do people still try to attach GNU/ to Linux? It makes no sense.

Oh god. Can't we stick to something non-controversial like GWB's legacy, gun control, abortion or the Middle East? Nothing good will come of this....

25 years of ....

[fm6]

This year marks the 25th anniversary of the GNU Operating System.

No, this year marks the 25th year of work on the GNU OS. There is still no GNU OS as such, and it's pretty obvious there never will be.

I'm not saying that there's nothing to show for all that work. The GNU libraries and many GNU utilities are key components in many projects, not the least of which is Linux. (<Sarcasm> Oh, excuse me, GNU/Linux.</Sarcasm> ) These are real achievements, and so is the introduction of a new collaborative model of joint software development.

But the original goal of GNU, to create a free alternative to Unix, has never been achieved. No big loss, there are other free Unix alternatives and even true Unixes for free. I just wish that GNU and its fanboys would stop and ask themselves why they never achieved their primary goal.

Re:25 years of ....

[Creepy Crawler]

That's because it takes thousands of people to make an OS.

Look at Microsoft and their lines of OSes.. They have what, 50k people on staff at any one time with perhaps 2/3 of them doing programming work? Most of their code is already written from buy-oughts, so they now provide mostly maintenance and scripting. There's maybe 20-50 people doing *interesting* stuff at any one time, it being 10 years away.

Look at OSX now. They have a similar issue, but leveraged theirs away by choosing a FreeBSD-like platform which to design everything on top of. They also reduce features for their core GUI programs to reduce testing and errors. They also focus much more aesthetically, in direct comparison to Linux GUIS and Windows. And their equipment is much higher priced (can buy 2-3 laptops of the same quality of 1 mac laptop), considering they discourage Hackintoshes.

The Linux guys ad to design everything from the ground up, because of the choice in license. It was also a NiH kind of "I can do it better" kind of game, because Linux was new and exciting. But development still requires large resources. Linus happened to be the appropriate coder/manager to herd the cats at the bottom. Then everything else fell into place: some by luck and others by necessity.

FreeBSD: Its THE academic system, and it works well. It's a traditional fork from SYS I which they license it very openly. There's work done on it, but the "cool" work is Linux. The BSD's are perfect for stability, file sharing, and network code. It has a healthy set of adherents and users, but mostly is relegated to core network technologies.

Now, we look at HURD.. It's there, with a Debian/HURD system install possible. It's there's few device drivers, even fewer developers, doesnt work with basic equipment, buggy as hell (because few developers), and there's something that's "Just As Free", and works to boot (Linux). Would the FSF be better off on discontinuing the HURD? Probably, but it's their choice, and we dont know what its possible uses are yet either.. There's always a critical mass which things like these hit that make them explode, and they might be right about making their own kernel.

Re:25 years of ....

[thermian]

This year marks the 25th anniversary of the GNU Operating System.

No, this year marks the 25th year of work on the GNU OS. There is still no GNU OS as such, and it's pretty obvious there never will be.

I'm not saying that there's nothing to show for all that work. The GNU libraries and many GNU utilities are key components in many projects, not the least of which is Linux. (<Sarcasm> Oh, excuse me, GNU/Linux.</Sarcasm> ) These are real achievements, and so is the introduction of a new collaborative model of joint software development.

But the original goal of GNU, to create a free alternative to Unix, has never been achieved. No big loss, there are other free Unix alternatives and even true Unixes for free. I just wish that GNU and its fanboys would stop and ask themselves why they never achieved their primary goal.

Having tried to get involved a few years back, I think I know why. While I don't deny the extree skill of some of the gnu programmers, GCC, Emacs and Gnuplot are ample evidence of this, they lack, or seemed to lack then, any form of cohesive organisation.

There was a distinct impression that if you didn't code in C, you weren't good enough, and that little use should be made of widely available, and equally free technology, because it wasn't 'hard core' enough, or so it seemed. There certainly was no logical reason for it. They spent, in my opinion, far too much time trying to write clever code, and not enough time trying to make things easily accessible for prospective new members. Since those new members would probably bring in new ideas and fresh impetus, I'd have thought this was a priority. Attracting some managers would have helped.

Their mailing list for Hurd showed their problem quite well. In spite of there being plenty of solutions available for spam filtering, they used nothing, which took me somewhat by surprise. This meant I ended up having to sift through literally hundreds of viagra and porn emails each week to try and follow something.

I asked someone else about it, and he had a script he ran himself to clear the spam. Very clever, very geeky, but very useless for those who think they shouldn't have to do that themselves to make such a mailing list usable.

I gave up after a couple of months, with a much better idea why we never got Hurd.

Re:25 years of ....

[fm6]

Huh? You're saying GNU didn't have enough resources? Then how did Linux ever achieve critical mass? Which certainly doesn't have much more in the way of resources, given that their code bases overlap so much.

The difference between GNU and Linux is not resources. The difference is the people running the show. RMS is on a holy mission; Linus just wants to get the job done.

Re:25 years of ....

[BumpyCarrot]

NO NO NO! They do NOT need to ask themselves that! If they do, they'll form a committee to go about finding a way of answering the question. After years of deliberating, that committee will decide another committee is better suited, and send them off into the desert for 30 days and nights, to search for their spirit guide.

Upon their long-hair-bearded-and-sandalised return, they shall proclaim that the original committee was mistaken in their decision, and call for a review on the whole process.

Years down the line, the final decision will be made:

We never should've tried to create a Unix alternative in the first place. All work on GNU is meaningless and void. From this day forward, we shall concentrate all our efforts on the creation of a wholly new, original OS based around the same open source principles of the GNU.

It's name?

UNG is Not GNU (UNG).

Re:25 years of ....

[MichaelSmith]

That's because it takes thousands of people to make an OS.

AST debunked that years ago. And now that minix is available under a free license there is nothing to stop the FSF calling it the GNU OS.

Re:25 years of ....

[Drishmung]

Having tried to get involved a few years back, I think I know why. While I don't deny the extree skill of some of the gnu programmers, GCC, Emacs and Gnuplot are ample evidence of this, [snip]

Ah, gnuplot has nothing to do with GNU or the FSF. From the gnuplot FAQ

Any reference to GNUplot is incorrect. The real name of the program is "gnuplot". You see people use "Gnuplot" quite a bit because many of us have an aversion to starting a sentence with a lower case letter, even in the case of proper nouns and titles. gnuplot is not related to the GNU project or the FSF in any but the most peripheral sense. Our software was designed completely independently and the name "gnuplot" was actually a compromise.

and

1.7 Does gnuplot have anything to do with the FSF and the GNU project?

Gnuplot is neither written nor maintained by the FSF. It is not covered by the General Public License, either. It used to be distributed by the FSF, however, due to licensing issues it is no longer.

Gnuplot is freeware in the sense that you don't have to pay for it. However it is not freeware in the sense that you would be allowed to distribute a modified version of your gnuplot freely. Please read and accept the Copyright file in your distribution.

Re:25 years of ....

[Tragek]

The FSF are the fundamentalists of the software world, in all fashions.

Read the rationale for this: "Developing nonfree software is not good for society, and we have no obligation to make it easier." No mention of the possibility that developers may be able to decide on their own.

Re:25 years of ....

[Anonymous Coward]

Having tried to get involved a few years back, I think I know why. While I don't deny the extree skill of some of the gnu programmers, GCC, Emacs and Gnuplot are ample evidence of this, they lack, or seemed to lack then, any form of cohesive organisation.

Despite gnuplot's name, it is not part of or related to the GNU system (hence the decision to use a lowercase 'g') and it is not distributed under the GPL. However some GNU packages do use gnuplot.

The title of this program was originally chosen to avoid conflicts with a program called "newplot," and was originally a compromise between "llamaplot" and "nplot."

Source

Re:25 years of ....

[Anonymous Coward]

can buy 2-3 laptops of the same quality of 1 mac laptop)

Woah.. Desktops sure, but laptops?? seriously? links, please.

Re:25 years of ....

[scientus]

FreeBSD i believe was also the first to support SMP, but yeah, linux does all the cool experimentation, and it has the development modal that works is designed for collaborative development, where linus's tree is really only 1 of many.

Re:25 years of ....

[scientus]

also, hurd uses linux for drivers, however its obvious its going nowhere, and really why? Linux is a great GPL kernel that can do everything, there is no real reason for it. development by many parties is what Free software is all about.

Re:25 years of ....

[Anonymous Coward]

Uhm, just a small thing: gnuplot has nothing at all to do with GNU. It isn't even licensed under the GPL.

Re:It's Linux, NOT GNU/Linux!!

[shish]

You can run a useful open source computer without xorg, you can run a useful computer without java, now that we have things like nexenta (ubuntu userland with opensolaris kernel) we can even go without linux -- but trying to run an open source based box without any of the software that gnu has touched is pretty hard~ (I think some of the BSDs do their own thing for the core, but most of the third-party software which gets installed on top has been touched by the hand of gnu somewhere along the lines)

Re:It's Linux, NOT GNU/Linux!!

[Anonymous Coward]

Why do idiots keep calling it Linux when there is no such operating system? There is Red Hat, SuSE, Debian, etc which are operating systems.

Re:It's Linux, NOT GNU/Linux!!

[Anonymous Coward]

Wow. You're ass must be sore.

Wow I never knew that it was an OS

[Anonymous Coward]

I have used GCC and a few other GNU tools for years now and I never knew that it was an OS.
My bad. I must really get around to downloading and installing it sometime.

Re:It's Linux, NOT GNU/Linux!!

[CarpetShark]

why do people still try to attach GNU/ to Linux?

The only logical reason to object to this is on grounds of practicality. If you think it makes no sense, you don't understand the issue.

Re:It's Linux, NOT GNU/Linux!!

[samkass]

But however correct the OP's statement, I agree with the reply made to it that the fact it comes apropos of nothing indicates it's a troll.

Only in as much as the original poster is a troll, then. The plugin system for GCC could have been discussed in a purely neutral manner if the article hadn't been submitted with the business about GCC being part of an operating system. GCC may be what compiled the operating system, or what developers use to develop for the operating system... but it's not part of an operating system. The fact that we're even discussing this implies the submitter's comments were trollish, IMHO.

If the article was supposed to be about the plugin system, maybe the submission should have led with that.

GNU Operating System

[DragonWriter]

GNU has produced an operating system.

That depends on your definition of "has produced". GNU certainly is actively developing an operating system, but I would say that an OS project that has managed to go 25 years without a stable kernel release cannot fairly be said to "have produced" an operating system.

Re:GNU Operating System

[hobbit]

To this, RMS would say that if it weren't for the GNU components, most other OSes wouldn't have been "produced" either...

Re:GNU Operating System

[DragonWriter]

To this, RMS would say that if it weren't for the GNU components, most other OSes wouldn't have been "produced" either...

So? The issue isn't whether GNU has produced lots of useful free components that have been incorporated in various OS's. Its the claim that it "has produced an operating system".

Re:GNU Operating System

[hobbit]

Well... (again, playing devil's advocate with Stallman in the role of the devil) it has produced an operating system, it's just running with an interim kernel at the moment.

Re:GNU Operating System

[larry bagina]

ATT Unix/BSD existed just fine before GNU. DOS/NT/Windows exists just fine without GNU. VMS exists just fine without GNU. MacOS (classic) existed just fine without GNU. Minix existed just fine without GNU.

Re:GNU Operating System

[Anonymous Coward]

I understand that the GNU kernel will be used to run the physics engine for Duke Nukem Forever.

Re:GNU Operating System

[Anonymous Coward]

386BSD was released in 1992 without GNU components. Linux was originally bootstrapped with Minix, basing much of its code on their algorithms (e.g. filesystem) though not the design. The GNU toolchain was not added until later, and not part of the standard Minux distribution.

In fact, its hard to say that GNU components were involved in the creation of any successful operating system. They helped them during growth, but not creation.

Re:GNU Operating System

[Anonymous Coward]

C-u 10000 M-x hail-emacs

Nothing More Than GNU/Panic Over LLVM/Clang

[Anonymous Coward]

All the exciting complier action going on now is with LLVM and Clang. It's incredibly clean and modern code. It has an free and open non-viral license.

The GNU crowd sees it as a massive threat to the stranglehold GCC has over open source compilers. This is nothing but a desperation move by GCC to try to fend off the massive migration to LLVM that is going on. The GNU crowd has been acting in ways that would put Microsoft to shame in their efforts to keep their stranglehold on compliers. All the way from the way GCC is coded to anonymous trolling of everything they see as a threat to non-GPL complier tech.

LLVM is going to be the one of and perhaps the single most important thing in the history of compliers. The academic world, business world, hardware manufactures are migrating to LLVM.

Re:Nothing More Than GNU/Panic Over LLVM/Clang

[QuantumG]

hehe, sure they are.

Re:Nothing More Than GNU/Panic Over LLVM/Clang

[Anonymous Coward]

LOL, what an idiot...

Re:Nothing More Than GNU/Panic Over LLVM/Clang

[chromatic]

Apple is, anyway.

Re:Nothing More Than GNU/Panic Over LLVM/Clang

[Ant P.]

And Linux, once they start using it as a core part of the OpenGL stack.

Re:Nothing More Than GNU/Panic Over LLVM/Clang

[Anonymous Coward]

LLVM is a non-issue. History will run its course, Apple will get another proprietary product to sell (like Mac OS X), and BSD zealots will get another pile of unmaintained code which they maybe could get to compile, but not use for anything practical (like Darwin). I pity the guys who wasted their time contributing while not on Apple's paycheck, but those who don't learn from history are doomed to repeat it.

Re:Nothing More Than GNU/Panic Over LLVM/Clang

[chromatic]

I'm eager to see Gallium too, but that's not the same as Apple dropping GCC for LLVM/Clang entirely for Snow Leopard.

Re:Nothing More Than GNU/Panic Over LLVM/Clang

[bconway]

Sure, like CUPS. Apple-owned and completely unmaintained or compilable. Right.

Re:It's Linux, NOT GNU/Linux!!

[gnarlin]

but most of the third-party software which gets installed on top has been touched by the hand of gnu somewhere along the lines

I delight in reminding your that gnus don't have hands, they have hoofs!

Arrogance

[Anonymous Coward]

To quote the rationale document:

Developing nonfree software is not good for society, and we have no obligation to make it easier.

This is the kind of ideological arrogance that drives me up the wall with the FSF and GPL. There is this over riding presumption that they're right, and further more, anything contrary to their aims is "Bad for society". What childish bullshit.

  It's not even as if they soften it by making it a question of belief. They could just as easily say "We believe developing non-free software is not good for society". The absolutism in their position reminds me of religious fundamentalism. Which also bugs the shit out of me.

Re:Arrogance

[Anonymous Coward]

Amen to that!

Re:Arrogance

[Anonymous Coward]

Of course, this was posted anon to avoid reprisals from the faithful.

Re:Arrogance

[bky1701]

So, putting "believe" into their statement would somehow make it politically correct, and they should do that, because you said so?

Sorry, no. They stated their opinion. Here is a newsflash for you: nothing is absolute. Should everyone prefix their opinions, assumptions and even what they think is a fact, with a disclaimer that it's just their opinion, and not to worry, but there is no free software god that is going to send all Microsoft devs to hell?

Lets see;
"I believe evolution is the best explanation."
"I believe you need 3 AAA batteries."
"I believe my hair is on fire."

I am sorry to have to point this out to you, but it's the FREE SOFTWARE FOUNDATION. I think that anyone capable of understanding the English language would be able to recognize that it is their opinion, politically-correct belief disclaimer or not.

Re:Arrogance

[Anonymous Coward]

Bill Gates and RMS are running on the same philosophy. They both want people roped into their own little philosophy and worldview: Bill Gates wants everyone running on his proprietary little OS coded in .NET while RMS wants everyone using his license which he controls while coding in straight C. The only difference is that Bill Gates wants to promote slavery to his OS while RMS wants Freedom to be the ONLY way. Isn't that how America has been pushing democracy in the middle east?

Y'know, at least the rationale for Linux kernel tainting makes sense pragmatically - it keeps people with modules that Linus can't fix from sending bug reports relating to those broken proprietary modules.

Re:Arrogance

[Anonymous Coward]

I believe I'm sorry, but I believe I take offence at your post, since I believe you're arrogant, too. I believe you'd better have written it like this:

I believe this is the kind of ideological arrogance that drives me up the wall with the FSF and GPL. I believe there is this over riding presumption that they're right, and further more, anything contrary to their aims is "Bad for society". What childish bullshit, I believe.

I believe it's not even as if they soften it by making it a question of belief. I believe they could just as easily say "We believe developing non-free software is not good for society". I believe the absolutism in their position reminds me of religious fundamentalism. Which I believe also bugs the shit out of me.

Seriously, I believe that when you are chastising people for having an opinion (one that I believe differs from yours) without qualifying it with terms such as "we believe", then I believe that you should take care not to make the same mistake as well. I believe that otherwise, people may believe that you are guilty of the same arrogance I believe you decry.

Re:Arrogance

[Anonymous Coward]

Thanks for reminding us of the great success of Americas mission to push democracy in the middle east.
Thanks for establishing the dictatorship of Saddam. Without that you could not possibly end his dictatorship.
So establishing dictatorships seems to be the first step to freedom.

Re:Arrogance

[skeeto]

nothing is absolute

Just nitpicking something here. For that to be true, there has to be at least one truth that is absolute (your statement), which would make the statement wrong. It's a contradiction.

Re:Arrogance

[Anonymous Coward]

eh, I speak english and I agree with the original poster- it is an arrogant way to state ones opinion as fact. There was absolutely no intention in the statement to imply its an opinion or a point of view. It was intended to state, much like a fanatical religious statement, that this is the truth and all must accept it.

I like the idea of Free software, but I don't like the GPL, especially V3. I don't think calls to a public API make the callee a derivative work or extend any license. If the library is private and distributed only through registration to approved parties who have a signed agreement, that's a different argument.

But if you put candy in your candy dish and sit it out for all to see, don't expect any obligation from those who partake.

Re:It's Linux, NOT GNU/Linux!!

[wild_quinine]

why do people still try to attach GNU/ to Linux?

Ah, the great Gnu/Linux naming controversy. It's a long page for a short issue, but if you really want to kill a tree, try printing the talk page, instead.

You know that there's zealotry involved when the argument for justification of a single sentence is longer than the entire article.

That means all that's left is to build a framework

[Lars T.]

That is clearly the easy part, should only take a few years, much shorter than the decision at least. I'll bang my head against the wall while I wait.

Re:It's Linux, NOT GNU/Linux!!

[MoellerPlesset2]

I don't think the word means what GNU thinks it means.

Well, the meaning of the word 'operating system' is subective of course. But the goal of GNU since the start was always to produce a UNIX-like operating system. And the UNIX operating system was always a lot more than just a kernel, it included tools, a shell, a compiler, etc. From the UNIX perspective, the GNU definition of 'operating system' makes perfect sense. Now if you're coming from the microcomputer persective, where an "operating system" was nothing more than the kernel and possibly a shell, you'd obviously be more inclined to simply label the kernel as an operating system. On the other hand, back when DOS was created, it barely would've been considered an operating system by the folks using UNIX and VMS. Indeed, DOS would barely qualify as an operating system today, especially considering what modern BIOSes can do.

Re:Operating System?

[DragonWriter]

No, the hurd is the kernel, GNU is the (still incomplete) Operating System.

More precisely:

No, the hurd is the (still incomplete) kernel, GNU is the (still incomplete) Operating System.

Re:It's Linux, NOT GNU/Linux!!

[Anonymous Coward]

The only logical reason to object to this is on grounds of practicality. If you think it makes no sense, you don't understand the issue.

Point me to the clause in the GPL where it says if I or my software benefits from your software being used in conjunction with mine I have to prefix your name to the resulting project? I can't find one, so that means this is bullshit. The GPL guarantees certain things about code and also makes provisions for giving you recognition for your code in the source - it makes no such guarantees about your recognition in the name of the software. Stallman and the other FSF zealots can bitch and moan all they want about not getting the recognition they "deserve" but if they wanted it so bad they should've made it part and parcel of the licence, not expect everyone to bend to their will for the sake of their egos.

Re:It's Linux, NOT GNU/Linux!!

[hobbit]

There are two stories here:

1) 25th anniversary of GNU OS project
2) GCC plugin approach agreed

They coincide, and both relate to the FSF, so why shouldn't they be brought together in a single article?

Re:It's Linux, NOT GNU/Linux!!

[CarpetShark]

Point me to the clause in the GPL where it says if I or my software benefits from your software being used in conjunction with mine I have to prefix your name to the resulting project?

Point me to the planet on which that's relevant to the issue at hand.

We're talking about "GNU/Linux" vs. "Linux". "Linux", as defined by its creator, is an operating system kernel. By definition, using that name refers to an operating system kernel, not to ANY "project" including GNU.

GNU, on the other hand, is a project to create a Unix replacement. It would be a functional unix environment, except for the lack of a kernel. By definition, "GNU" refers to this, not a distro project, and not a kernel.

Put the two together, and you get a distro (albeit a minimal one). Therefore, the logical thing to do is combine the names. The only reason to disregard this logic (a reason which I think is perfectly valid, you should know) is that "Linux" is more pronounceable and user-friendly than "GNU/Linux".

Re:It's Linux, NOT GNU/Linux!!

[idontgno]

In software engineering, it's called "coincidental cohesion". It's bad. Slapping things together because they seem related when, functionally, they are not is careless and potentially confusing.

Re:It's Linux, NOT GNU/Linux!!

[orlanz]

Emacs. There, I fixed the finger spasms for the both of you. ^_^

Re:Operating System?

[Arker]

No. The HURD, like Linux, is a kernel. NOT an Operating System.

How spell check could work in a C compiler

[tepples]

Spell check for identifiers might actually be useful. When you get an "undefined symbol 'plyaer'" error, it'd be nice if GCC could search the symbols in scope for with the shortest Levenshtein distance. The error message could look like this: "undefined symbol 'plyaer': did you mean 'player'?"

Re:How spell check could work in a C compiler

[poopdeville]

Eh, GCC's error messages on that kind of thing make debugging pretty easy. And if you're using a predictive/distributed compiler system with GCC (like XCode does with GCC/distcc), you will only have to recompile the buggy module once fixed.

And how am I going to go to the arcade after sending my manager "compiling, @ arcade for an hour" if I have to sit there watching it?

Re:How spell check could work in a C compiler

[lysergic.acid]

that sames more appropriate for an IDE. if you have the spell check in the IDE, you can easily identify and immediately fix typos as you code. waiting for the compiler to spell check your code is like building a spell-checker into your printer driver or PostScript interpreter.

since most modern IDEs already feature syntax highlighting, which typically comes with function lists, symbol databases, and a live parser, it would just be a simple matter of integrating an additional user dictionary to the parser so that misspelled variables, comments, literals/output messages, etc. get highlighted.

the parser could even make sure that your variables are named consistently according to naming conventions you specify. so if you have a long named strAge or you forget to use CamelCase, or use it incorrectly (e.g. fetchNExt() instead of fetchNext()), on a function or variable, the parser should be able to point that out to you. that would be more useful than getting warnings from the compiler about lexical code issues.

Re:How spell check could work in a C compiler

[gzipped_tar]

The error message could look like this: "undefined symbol 'plyaer': did you mean 'player'?"

That may sound fantastic for you and I don't mean to bash the idea. But for me it sounds like a nightmare involving Clippy.

Re:How spell check could work in a C compiler

[Schraegstrichpunkt]

"Referer"

Re:How spell check could work in a C compiler

[DragonWriter]

The error message could look like this: "undefined symbol 'plyaer': did you mean 'player'?"

It's not the Google Compiler Collection, you know.

Re:It's Linux, NOT GNU/Linux!!

[Anonymous Coward]

Around here, we discuss the same topic in multiple articles, not the other way round.

Re:It's Linux, NOT GNU/Linux!!

[TheRaven64]

It's a lot easier than it used to be. You can compile at least one of BSD kernel with PCC now, and I think two of them now build with LLVM/clang. The big remaining hurdle is GNU binutils. There was a FreeBSD libelf-based replacement underway, but it's largely stalled.

Essential plugin

[symbolset]

DWIM

Re:It's Linux, NOT GNU/Linux!!

[TheRaven64]

The meaning of a UNIX operating system is well defined here.You will notice that it does not define anything about the kernel other than two device nodes. It does, however, specify a C compiler and a large number of C standard library functions. On a GNU/Linux system, these are provided by GNU libc, which calls into the Linux kernel for some functions, but can also support HURD and FreeBSD kernels.

Sega v. Accolade

[tepples]

Require all plugins to link against a small (512 byte or so?) GPL'ed blob, and check for it at load time.

The wiki article mentions this legal theory. Search for "A gcc-based scripting interpreter could by default check for a mandatory license statement". But other companies have tried this in the United States, and courts have rejected the originality (and therefore the copyright) of such magic cookies. Look up Sega v. Accolade (pre-DMCA) and Lexmark v. Static Control (post-DMCA).

Re:Sega v. Accolade

[Bruce Perens]

A license statement is different from a magic cookie. A magic cookie is in general intended to force the use of some copyrighted or even trademarked element. A license identification doesn't do that, it just is a required accurate identification of the license. None of the existing cases have dealt with such a thing.

Re:Sega v. Accolade

[tepples]

A license statement is different from a magic cookie. A magic cookie is in general intended to force the use of some copyrighted or even trademarked element.

It's not so clear-cut. In Sega v. Accolade, the magic cookie was a piece of code that, when executed on a Sega Genesis video game console, calls a BIOS function that displays "PRODUCED BY OR UNDER LICENSE FROM SEGA ENTERPRISES" for two seconds on the connected monitor. So if you have to forge a machine-verified license statement in order to get your code to interoperate with a system, the US Court of Appeals for the Ninth Circuit has held that this forgery might not violate law.

Re:Sega v. Accolade

[Bruce Perens]

I'm still not sure. Asking for a honest representation of your own license is a lot different than asking for a string that represents you have a license from a third party.

Re:Sega v. Accolade

[ray-auch]

> Asking for a honest representation of your own license is a lot different than asking for a string that represents you have a license from a third party.

I'm not sure how it is different.

Since the arguement was that your code needed to be GPL to satisfy the GPL (on the other, third-party, code), your representation that your own license is GPL is representing compliance with a third party license. Since the GPL grants license only on condition of compliance, by representing that you are in compliance you are therefore representing that "you have a license from a third party".

Re:Sega v. Accolade

[Bruce Perens]

The GPL is not necessary, only a GPL-compatible license. BSD for example. A license from a third party isn't necessary.

Re:Sega v. Accolade

[ray-auch]

GPL or GPL-compatible doesn't change the argument - you are still saying there is a requirement to license your code to comply with a third party license - GPL. Otherwise why is GPL compatibility necessary at all ?

In the case of a GCC plugin that third party would be the FSF, and its license the GPL. The only (copyright related) reason you would have to be compliant with the GPL would be in order to be licensed under the GPL - because you have no licence otherwise. So, in the case of the GPL, saying you comply with the license is the same as saying you have license.

Or in other words, I don't see the difference in this context between being required to state, for example:

      "this plugin is distributed under a license from SEGA" (among other licenses)

and

      "this plugin is distributed under license A which is compatible with the GPL, in order to comply with license for GCC, which is distributed under license (GPL) from the FSF"

In both cases you are being required to state that you have (= comply with, in GPL case, see above) a third party license.

In SEGA vs. Accolade it was ruled that if you have to effectively make that statement beacuse it is the only way to make your code compatible with the host environment, it is permissible to lie.

Re:Sega v. Accolade

[Bruce Perens]

I did not see yesterday that FSF had already changed the run-time license. It's entirely independent of how you connect to GCC - all the pieces have to be GPL compatible no matter where they are or you don't get to use the run-time.

Re:It's Linux, NOT GNU/Linux!!

[Enderandrew]

Hurd was released in a working state?

I must have missed it.

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:It's Linux, NOT GNU/Linux!!

[Enderandrew]

Except, that we don't call it Grub/GNU/Xorg/KDE/Linux. We don't call it by everything we attach to make a minimal distro. We simply call it Linux, because for the people that use Linux, the kernel is the only completely consistent aspect. The GNU tools are probably the second most consistent aspect of any Linux usage, but Linux does not completely depend on using the GNU tools.

Re:It's Linux, NOT GNU/Linux!!

[MoellerPlesset2]

That's not a definition of a word, that's a standard. A standard which did not exist in 1983.

It's GNU/Linux if it's not uClinux

[tepples]

but trying to run an open source based box without any of the software that gnu has touched is pretty hard

I for one say "GNU/Linux" to distinguish an operating environment designed for a workstation or server from embedded Linux. It's possible to run a useful box, especially one handling embedded style workloads such as IP packet routing, with very little FSF-owned code. A "uClinux" environment might use uClibc or Newlib instead of glibc, uClibc++ instead of GNU libstdc++, and BusyBox instead of Bash and GNU Coreutils.

Re:It's GNU/Linux if it's not uClinux

[mblaney]

Busybox is a recompile of mostly GNU tools into a single executable.

Re:It's GNU/Linux if it's not uClinux

[Anonymous Coward]

I for one welcome our GNU overlords!

gnulix, bitches

[Anonymous Coward]

You remember that?

Re:It's Linux, NOT GNU/Linux!!

[CarpetShark]

The kernel is far from completely consistent; it's patched and selectively built on almost every distro. If anything, libc, bash, and the gnu core utils and toolchain are the main consistencies.

But this is a silly thing to argue about, since we're obviously not going to agree. Let's agree to disagree :)

Re:It's Linux, NOT GNU/Linux!!

[H3g3m0n]

Perhaps the spasm was due to an injury obtained from the Emacs shortcuts.

The real question is

[ClosedSource]

Who gives a shit about writing plugins for GCC? It's just a compiler for God's sake!

Re:The real question is

[Anonymous Coward]

Stallman's viewpoint is that giving anything that would make proprietary code easier to make is bad.

Then again, Microsoft takes the same viewpoint, but for GPL'd code instead of proprietary.

Re:The real question is

[ClosedSource]

Of course MS is even less interested in GCC than I am.

Re:It's Linux, NOT GNU/Linux!!

[hobbit]

From the link you posted:

"Coincidental cohesion is when parts of a module are grouped arbitrarily (at random); the parts have no significant relationship (e.g. a module of frequently used functions)."

Certainly these two stories did not appear together entirely at random. It's temporal cohesion, at worst!

Windows in the compilation process?!

[mysidia]

GCC project, and some universities are already working on building windows into the compilation process, with the intent of releasing plug-ins."

The last thing GCC needs is Windows OS dependence.

Windows isn't reliable enough to run ordinary desktop software, why should we trust it to compile important things with?

Re:Windows in the compilation process?!

[Malc]

Poppycock. That's utter BS, and you know it. If Windows wasn't reliable enough, then it wouldn't be so popular, even for servers. I find Windows to be more reliable and stable than my Mac Book Pro running OS X 10.5.x, and that's based on UNIX. Stop the childish FUD.

Re:Windows in the compilation process?!

[thesupraman]

You know, I just cannot tell if this is trolling or humour - it just about defines the line between the two ;)

Re:It's Linux, NOT GNU/Linux!!

[Ethanol-fueled]

Much like slapping together the words "software" and "engineering" to describe a pompous clusterfuck of buzzwords and fad development practices.

Re:It's Linux, NOT GNU/Linux!!

[Anonymous Coward]

Indeed this is like saying visual studio is part of windows. As MS uses that to compile it.

Re:It's Linux, NOT GNU/Linux!!

[Lord Bitman]

While I agree that "GNU" is not an operating system in any sense of the word (unless you include poorly-designed experimental attempts like HURD), it should be said that a compiler is an absolutely essential component to any operating system.

That popular operating systems ship without a compiler is only a sign of those systems being broken. If you aren't provided with a tool that lets you tell the system how to operate, you haven't got an operating system.

Re:.. all that's left is to build a framework

[fbjon]

I'll bang my head against the wall while I wait.

Careful. The reason developments in GNU are so slow is because they've been banging their heads against the wall.

Greg on dynamic linking

[Bruce Perens]

It is not in Greg's employers interest for him to push this issue. Remember, they've tried to play fast and loose with the GPL before.

Re:Greg on dynamic linking

[QuantumG]

One week he had his employers behind him.. and he had some IBM lawyers too. The next week it was silence.. then the whole "Free Linux Driver Development" campaign started. It's kinda annoying.. Greg, like many other people in the Linux community, extols the virtues of openness.. but as soon as a lawyer tells them to keep quite on something, they do. We may never know the legal advice (or legal threats) he received. That's a shame.

Re:Greg on dynamic linking

[Anonymous Coward]

Keep arguing with Bruce, I want to see him humiliate you some more!

... was that wrong?

Re:Greg on dynamic linking

[Anonymous Coward]

No, just inane.

Re:It's Linux, NOT GNU/Linux!!

[Anonymous Coward]

I think the FSF is somewhat crazy, but at the same time I can understand their position, because the typical "Linux" system includes tons of GNU software. In order to alleviate my guilt at calling the system "Linux", I decided to port over BSD tools instead. Now I have BSD which, whois, rcng, newsyslog, netcat, gzip, ed, yacc, init, pax, cpio, findutils, inetd, ftp, ping, telnet, libedit, and coreutils (findutils and coreutils being all the tools that are in the GNU packages of the same name).

I still have lots of GNU stuff, of course (crossing my fingers about clang, though), but I've replaced a good number of GNU programs with BSD programs.

Although I have to admit that the main reason I did this was because GNU's manpages are shit, and the BSDs' are great. The ability to drop the "GNU" prefix was just a bonus.

Re:It's Linux, NOT GNU/Linux!!

[CarpetShark]

Me? I run Gnu/KDE/Xorg/Gnome/vim/perl/rxvt/Fluxbox/Firefox/Java/Linux

You should check out Gnu/KDE/Xorg/Gnome/emacs/perl/rxvt/Fluxbox/Firefox/Java/Linux

Re:It's Linux, NOT GNU/Linux!!

[Daemonax]

GNU has produced an operating system. It's nowhere near as advanced in functionality as Linux, but it exists, and GCC one of the largest parts of it.

Woah woah, let's be a bit more accurate here. The GNU project has produced a kernel, it's nowhere near as advanced in functionality as Linux, but it exists...

GNU and Linux go together to form the base of a GNU/Linux distribution, you can get a running system going with GNU and Linux and virtually nothing else, those are the two main parts.

I see no decent reason to call it 'Linux' rather than 'GNU'. Sure it might differentiate between a system with a Linux kernel and a HURD kernel, but virtually everyone that uses GNU, uses it with the Linux kernel.

Not being a great fan of Linus and being very appreciative of GNU and agreeing with Stallman, I call it GNU/Linux.

I also think that Freedom with software and computers is important, I just recently came across a story about a guy who was trying to scan some stuff, but the scanner refused to do it because it recognized some anti-copying marks. This is pathetic, when I buy hardware, I expect it to be mine, and to be in charge of it. With more and more hardware based restrictions coming out, that may or may not be able to be circumvented in software, then the basic principle of Freedom is going to be the best objection to these restrictions. The free market can only solve these problems when there are alternatives, if hardware based restrictions become standard, then people will not be able to vote with their money, it will simply be an issue of whether you value freedom.

So I say GNU/Linux because the GNU project is dedicated to raising awareness of freedom with regards to software and computers.

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.

Re:Nice

[Whiney Mac Fanboy]

Nice. The Linux kernel guys did this and look at the result--it is a bitch for hardware guys to write drivers for Linux

Bullshit. The result is that it's a bitch for proprietary guys to write binary only drivers for linux.

And you know - why should the GCC & Linux projects make things easy for the proprietary guys? It's not like the proprietary guys go out of their way to make life easier for OSS.

Re:Nice

[Anonymous Coward]

To be fair, that page is a Wiki page anyone can edit and that explicitly welcomes contributions by anyone, it's not some sort of official statement from the FSF.

It is entirely possible that the suggestion you cited was contributed by some FSF official but it might as well come from a random troll. Blaming the FSF for this idea without at least some amount of investigation is naive at best and flamebait at worst.

Re:Nice

[Anonymous Coward]

"I'd be pretty nervous if I was the FSF."

You wish.

What you don't like is that you can't take the work of people who have contributed to a GPL project, close source it,pretend that it's your own work, and profit off the backs of the real developers.

The GPL prevents dinosaurs like your good self from profiting off the backs of others.

If you want a closed source application, either buy one, or write it yourself. Either way you'll end up playing all by yourself.

Shared source is here to stay.

Re:Nice

[Anonymous Coward]

Because the proprietary guys hold all of the cards. The reason Linux hasn't and won't be adopted by the masses is because GPL proponents insist on throwing temper tantrums about proprietary hardware/software instead of getting things working.

Sorry to break this to you, but proprietary rules the world.

Re:Nice

[Whiney Mac Fanboy]

I was going to write a serious answer to you, but instead:

Because the proprietary guys hold all of the cards

HAHAHAHAHAHAHAHAHA!

Sorry to break this to you, but proprietary rules the world.

HAHAHAHAHAHAHAHAH*cough*youfuckingdumbass*cough*HAHAHAHAHA!

Re:Nice

[W2k]

why should the GCC & Linux projects make things easy for the proprietary guys?

Because biting the hand that feeds you have never been a good strategy. There's not enough open hardware - free operating systems are still dependent on the goodwill of proprietary vendors to be able to support mainstream hardware with anywhere near the same features and performance as users of proprietary OS take for granted.

Granted, this may well change soon, but until then making it hard for hardware developers to provide good Linux drivers is just making things harder for Linux users who have no interest in being dragged into your religious wars.

Re:Nice

[Anonymous Coward]

That sounds suspiciously like "if we don't allow binary versions, we don't have any backwards compatibility to regard, and it is business as usual (IOW every major gcc version breaks everything on top of gcc)".

That that also frustrates genuine GPL loving developers doesn't matter. They shouldn't whine, but keep patching forever.

Re:Nice

[Whiney Mac Fanboy]

Because biting the hand that feeds you have never been a good strategy.

Providing a closed source driver/gcc plugin is not feeding Linux/gcc.

Re:Nice

[Whiney Mac Fanboy]

That sounds suspiciously like "if we don't allow binary versions, we don't have any backwards compatibility to regard,

Not true. The APIs tend to be backwards compatable (to a point), the ABIs tend to not.

Re:Nice

[Geoffreyerffoeg]

The result is that it's a bitch for proprietary guys to write binary only drivers for linux.

Not true. Think about the technical means by which this is achieved: there is no stable driver API, and you're encouraged to get your code into mainline. This means two things:

1. If you have a Free Software driver that isn't GPL-compatible, you get caught in the collateral damage. This is why OpenAFS isn't in the kernel -- because before the GPL had its katamari influence that it does now, IBM released the code under another Free but GPL-incompatible license, and it's basically impossible to pursue everyone relevant now and make them sign off on a relicensing. OpenAFS is at least as old as Linux and was developed on a half a dozen other OSes, so arguments that it's secretly a derivative work because it's a module don't apply.

2. If for whatever reason your code isn't in mainline, be it that you want to be gatekeeper over its development or that the kernel people reject it, then you're also out of luck in the same manner. For instance, the GPL is explicitly okay with a company maintaining a hacked version of Linux internally without having to release the source to the public. The unstable API makes this incredibly difficult. And if you look at the commits to the Linux kernel, most of it is from the "proprietary guys" -- maybe you could have even more of them contributing bug fixes upstream if it were easier for them to customize.

The promise the kernel guys make is not that your code is easy to maintain if it's Free Software -- it's that your code is easy to maintain if and only if it's part of Linux.

Now don't get me wrong; I understand there are excellent technical reasons for not having a stable in-kernel API, such as the ability to rearchitect things when you get a better idea and not have to support compatibility interfaces forever. I'm not at all asking for Linux to grow such an API. But to consider it a worthwhile legal tool in favor of Free Software is to completely fail to understand the Free Software ecosystem.

Re:Nice

[Anonymous Coward]

"Biting the hand that feeds you"?

Um, hello? When someone rips of GCC development by writing a proprietary plugin, what exactly would make that person "the hand that feeds GCC developers"? Isn't it more like the opposite?

I don't want to go into whether proprietary plugins would be legal or illegal, ethical or unethical, or justified, or justifiable, or whether deliberately keeping the API unstable to stick it to proprietary plugin developers is a good idea (note, BTW, that the Linux kernel doesn't do this: they merely make no guarantees about a stable API, but they don't change it without actual technical reasons), but your argument makes absolutely no sense at all whatsoever.

Re:Nice

[Anonymous Coward]

*cough*90%ofthesoftwaremarket*cough*
*cough*100%ofthehardwaremarket*cough*

I won't say anything more to interrupt your little daydream fantasy world.

Re:Nice

[W2k]

When someone rips of GCC development by writing a proprietary plugin, what exactly would make that person "the hand that feeds GCC developers"? Isn't it more like the opposite?

Not the developers; the users of GCC benefit (are "fed") by the availability of plugins, proprietary or no. I assume that most developers of GCC are also users, so this benefits the developers as well.

Also, I would hope that the developers of a popular software package would see fit to act in the best interests of their users, rather than fight stupid religious wars over which of proprietary/open is better. Fact is we'll always have both kinds of code, so we should try to get along with each other rather than fight pointlessly.

Unfortunately many free software advocates are more than happy to fight these wars, because they put ideology above the goal of creating great software, making them no better than the greedy corporations they so despise.

Re:Nice

[brackishboy]

*cough*90%ofthesoftwaremarket*cough* *cough*100%ofthehardwaremarket*cough*

Not quite 100%.

Read on!

Re:Nice

[Knuckles]

The Linux kernel guys did this and look at the result

A kernel that can actually be debugged instead of having binary modules crapping all over the place! Subsystems that can actually be completely rewritten without supporting legacy APIs for binary drivers! TEH HORROR!

Re:Nice

[againjj]

Nice. The Linux kernel guys did this and look at the result--it is a bitch for hardware guys to write drivers for Linux

Bullshit. The result is that it's a bitch for proprietary guys to write binary only drivers for linux.

And you know - why should the GCC & Linux projects make things easy for the proprietary guys? It's not like the proprietary guys go out of their way to make life easier for OSS.

It's also a bitch if someone writes open source code, because the users of the code do not necessarily know how to modify the source if the API changes and the source is not updated. I remember on my laptop a while back I had the choice of sound or wireless, but not both, since one compiled under 2.4 and the other under 2.2. The GCC guys say the solution is to host the plugins in the GCC tree, but that is not going to happen with every plugin, just as it doesn't for every kernel driver.

Re:Nice

[metamatic]

Not the developers; the users of GCC benefit (are "fed") by the availability of plugins, proprietary or no.

That's your opinion. Speaking as a user of GCC (and Linux, I don't want to see either project make it easy for proprietary blobs of code to become a critical part of using them.

It's probably because of the pain of maintaining proprietary drivers that we ended up with open video hardware drivers from VIA and ATI. That has benefited me more than the minor pain of dealing with proprietary driver installation for a few years.

Furthermore, my observation--again, as a user--is that open source drivers are less buggy and less likely to crash your system.

Re:Nice

[Anonymous Coward]

That is bullshit. You are not making it hard for the proprietary guys, you make it hard for everyone.
The proprietary guys writing binary only stuff don't have any more problems adopting the changes than any open source guy. In deed the same work is involved here. But who is royaly fucked is the customer.

And by requiring constant change for nothing you are stealing workforce from project that could really improve something.

Re:Nice

[Anonymous Coward]

And you know - why should the GCC & Linux projects make things easy for the proprietary guys? It's not like the proprietary guys go out of their way to make life easier for OSS.

Uhm, thats exactly what its like -- writing a driver is hard work and definitely qualifies as going out of your way.

As someone who has used the NVIDIA blob for a LONG time I am glad they worked hard to suppport me and sorry that other people from the OSS community wants to spit in their face.

Re:Nice

[Anonymous Coward]

Should you write Linux code, you would know Linux guys do that when they have a technical reason to do that, not just to piss off writers of proprietary bits. Indeed most just plain don't care about proprietary bits, they just change what they want to change in Linux to make it better.

The GCC situation is completely different: brain fucked people are just talking about how to annoy those who do not praise RMS 3 times a day. From a technical point of view, this is an extremely retarded method to build some software, but this kind of people have a political agenda, they are just doing that to fulfil it, not to look plain stupid to the rest of the world (with the side effect that they nevertheless just look plain stupid to the rest of the world anyway...)

Re:Nice

[Anonymous Coward]

What? That god modded insightful? He just pulled some accusation out of his ass. He never said anything against the GPL. The GPL just does not apply here. That is why the GCC developers suggest to use dirty tricks to push others in that direction.

Re:Nice

[bug1]

I think he meant to say propriety rules his world.

"You have to understand, most of these people are not ready to be unplugged. And many of them are so inert, so hopelessly dependent on the system that they will fight to protect it." - Morpheus, The Matrix

Re:Nice

[Whiney Mac Fanboy]

*cough*90%ofthesoftwaremarket*cough*

Source? I'd believe 90% of the desktop market - 90% of software? Bollocks.

Re:Nice

[Anonymous Coward]

Open hardware might exist but nobody uses it.

Build my own MP3 player? Pfft. I'll just buy one for less money and time than it would cost to make one.

Build my own CPU? Yeah, let me just fire up my personal wafer fabrication plant here...

Re:Nice

[Anonymous Coward]

It's funny watching you morons try to "fight the system". You're like a bunch of little dogs hopelessly yanking on your chains.

Like it or not, we live in a society. That society is ruled by money. Money is generated by products. Product competition forces improvement. Improvement sells product. Sales generate revenue. Revenue is used to fund new products. If everything were simply given away, that cycle could not exist and progress would cease.

I'll bet you anything that the majority of the products you use are proprietary. Have a car? Proprietary. Have a television? Proprietary. Have a computer? Proprietary. Oh, and your Matrix films? Proprietary. It's both hilarious and pathetic that you would try to use copyrighted dialogue to promote your little interests.

This may not be a Star Trek utopia of enlightenment, but at least I can see the whole picture. You're sitting so blind that you don't even know what it is that you want to fight.

Re:Nice

[Anonymous Coward]

Because biting the hand that feeds you have never been a good strategy.

How will I eat it whithout biting?

Linux/GCC?

[thesupraman]

And running any of the GNU tools without a suitable kernel is kind of difficult also - so should we call it Linux/GCC? perhaps BSD/Linux/Windows/GCC?

And yes, of course I know it runs also on windows, even though that makes the 'pure blood' GNU aims seem somewhat odd, but does that actually help things?

Call me when HURD becomes workable for every day purposes (you know, like supporting hardware other than that of the core developers..) and we can talk.

Re:Linux/GCC?

[WNight]

It's not GNU/Linux when Linus writes it, it's GNU/Linux when Redhat packages it with the GNU tools. The same GNU tools you'd rush to install on a Sun, Windows, etc.

Simply saying "Linux" is simplistic, ignoring many possible configurations for Linus's software, from a standalone OS to an entire platform with windowing system, etc.

Besides, if you use GNU you're using a different flavor, the --options, etc. Partly it does give credit to RMS, but mainly it's just a proper identifier. So you can discuss your system and know what will be compatible.

Re:Operating System?

[TheSunborn]

No Mach is the kernel. Hurd is part of the posix env that run above the kernel.

Re:It's Linux, NOT GNU/Linux!!

[dfghjk]

"...and GCC one of the largest parts of it."

If that's true then it's not an operating system.

Re:It's Linux, NOT GNU/Linux!!

[scientus]

ulinux and busybox, most routers run it, i know mine does. It does use GNU software. Its all GPL/LGPL, its all based on GNU tools, but there is no GNU.

GNU isnt bad, and i dont think giving them credit is wrong, but such systems do exist, for example: android.

Re:It's Linux, NOT GNU/Linux!!

[x2A]

*lol* fantastic

What problems are Plugins trying to solve?

[userw014]

While the idea of GCC having plugins has a great "cool" factor, I don't understand what problem they're trying to solve.

As best as I can tell, people who are not GCC developers want to be able to take advantage of all the effort that has gone into GCC to make new and nifty things - but the interfaces in GCC (primarily the IR/intermediate representations) are poorly documented and change frequently from version to version.

Plugins are an attempt to replace create a new API to solve problems tangental to another API - where the problems are a lack of documentation and instability of the API. As development of the GCC continues, new features and methods are going to quickly reveal problems with the plugin API - either the existing APIs will not be able to take advantage of the new features, or they will need t change, or they'll even be removed. And, of course, the interaction between the APIs and the compilation process will need to be documented too in order for them to be useful. And lastly, if the idea of requiring plugins to be GPL'd is to strongly encourage them to be placed in the GCC repository, then that increases the maintenance effort on the GCC developers to keep the donated plugins up to date - or make the unpleasant decision to discard them.

So, not knowing what problems that Plugins are trying to solve, I wonder if solving this another way wouldn't be a good idea - such as resigning the IR format to encourage easier and better documentation or something like that. The GCC was initially created a long time ago before more contemporary methods of keeping code and documentation in sync were developed. Using modern methods would pretty much require a complete, almost clean-room rewrite of GCC which would nullify the benefit of taking advantage of all of the skill and knowledge embedded in the GCC.

So, can someone tell me what Plugins are trying to do?

Re:What problems are Plugins trying to solve?

[userw014]

Ok, I searched for "use cases" in the GCC Plugin Wiki and I saw a few. The most interesting applications seemed to be the Edoc++ and Mozilla ones, and I saw mention of something called MELT but wasn't sufficiently curious to pursue it at 1:30am local time.

It seems like these would require different APIs. Indeed, most Plugin needs would seem to require different APIs, or one huge complicated Plugin API.

Mozilla wants some call-back hooks and a way to add passes to the compiler. Edoc++ want to explore the call-tree, especially for C++ exceptions. And as I said, I wasn't curious enough about MELT.

I don't see an API here. I see very different needs.

Enforcing GPL ...

[Anonymous Coward]

so, how long will it be before gpl'd plugins arrive that allow interfacing with arbitrary non-gpl plugins? ;)

gcc is dead

[Anonymous Coward]

gcc is dead. long live llvm!

Plugins for GCC...

[noppy]

...marks the beginning of homebrew C/C++ fork...

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

[Anonymous Coward]

Which demonstrates just how much Sun loved the GPL in the first place.

Sun, like one or two other corporations, were forced crying and kicking down the open source path because their users were installing and compiling GPL'd software on Sun systems instead of buying Sun's vastly over priced versions. If they hadn't embraced it, the migration of their users to Linux would have become a stampede.

LLVM is being supported by Sun because they see an opportunity to reverse software history. If LLVM ( which is not covered by the GPL ) replaced GCC - they think - GCC would die off, and then they will be able to close source the project and return to happy land where they can charge the earth for their product.

It ain't gonna happen.

Re:It's Linux, NOT GNU/Linux!!

[W2k]

If you aren't provided with a tool that lets you tell the system how to operate, you haven't got an operating system.

Yeah, Windows and OSX are broken because neither ship by default a tool that would be useless to >99% of its userbase but whose presence on every PC would be utterly adored by malware authors. Doh!

Besides you can get a compiler for most any OS in five minutes on the 'net nowadays. Only for systems that actually compile parts of themselves during install is it necessary to include one.

Re:It's Linux, NOT GNU/Linux!!

[Anonymous Coward]

wow imagine that. the only insightful comment to this entire article doesnt get a single reply. trolls? please?

Or just do what the rest of us are doing...?

[Anonymous Coward]

It says on the LLVM website FAQ, "GCC is licensed under the GPL license. clang uses a BSD license, which allows it to be used by projects that do not themselves want to be GPL"

The LLVM site is registered in the name of Chris Lattner who works for Apple.

What the FAQ ought to have said is, "clang uses a BSD license, which allows it to be used by projects which wish to take the source code, close it, and profit off the backs of those who contributed without rewarding them."

Go ahead and hack on LLVM, but don't kid yourself that "the rest of us" are doing it too.

Re:Or just do what the rest of us are doing...?

[TheRaven64]

What the FAQ ought to have said is, "clang uses a BSD license, which allows it to be used by projects which wish to take the source code, close it, and profit off the backs of those who contributed without rewarding them."

The source is held in a subversion repository hosted by the University of Illinois at Urbana-Champaign. The site was registered by Chris Lattner who was a PhD student there; he was hired by Apple based on his work on LLVM. Clang is primarily (although far from exclusively) developed by Apple engineers. They develop their code in the UIUC svn server, which anyone can access. It is used for syntax highlighting and refactoring tools in XCode, and an LLVM back end is used for the CPU paths in Apple's GLSL implementation.

The BSDL means they don't have to open XCode or their GLSL stack, but that doesn't make any of the code that other people have contributed to LLVM or clang any less free. You can use LLVM to target recent ARM chips because Apple developers wrote the ARM back end for the iPhone. You can link clang with your Apache licensed or CDDL IDE and use it for syntax highlighting. The Mesa folks are using LLVM for their GLSL code in much the same way as Apple - they aren't able to use Apple's front-end code, but they can use the back end.

Sure, people don't have to release everything, but they don't with the GPL either. If you don't distribute your changes, the GPL doesn't apply to you, so companies like Google can take GPL'd code and add their own in-house extensions without anyone being able to object. Personally, I'd rather focus on what people and organisations do give to the community than what they don't.

Pascal, D, Eiffel

[krischik]

it is a compiler collection after all.

GNU Ada allready got that

[krischik]

The GCC Ada compiler already does it - even used the very same wording ;-)

Re:It's Linux, NOT GNU/Linux!!

[Schraegstrichpunkt]

You can run GNU without running Linux (e.g. Debian GNU/kFreeBSD), and you can run Linux without GNU (mostly in embedded systems).

The term has legitimate uses, just like "i486-linux-gnu".

Re:It's Linux, NOT GNU/Linux!!

[Schraegstrichpunkt]

the kernel is the only completely consistent aspect

You're kidding, right? Linus killed off the idea of "stable" and "development" versions of Linux largely because hardly anyone was using the "stable" versions as-is anyway.

Re:It's Linux, NOT GNU/Linux!!

[that_itch_kid]

Yeah, Windows and OSX are broken because neither ship by default a tool that would be useless to >99% of its userbase but whose presence on every PC would be utterly adored by malware authors.

I'm not 100% certain, but I think you'll find that gcc has shipped with all versions of Mac OS X. In fact, Windows is the only modern system I know of that DOESN'T ship with a C compiler.

Secondly, how does having a C compiler on a system help malware writers at all? I know it's easy to think, "BECAUSE IT CAN MAKES THE CODES GO" and stop there, but do try to think about the logic of what you're saying. Malware compile code? What's the point? Why go to the trouble of transferring C code over the net to the infected computer, bearing in mind that plain text C code is significantly larger than the corresponding machine code, along with the possibility of the user noticing system slowdown as a result of the lovely CPU spikes that go with compiling a program?

Re:It's Linux, NOT GNU/Linux!!

[Anonymous Coward]

It is bretty hard to run any GNU tools without operating system. Even the C-library needs an operating system to work. Without operating system, you can not use C-library for anything.

Problem is just that GNU people should understand that Linux is operating system because it is monolith kernel. Monolith kernels are operating systems in the original structure.

GNU project has tried to build own OS now over 25 years and still the OS is lackin features. The problem was that they choosed microkernel structured OS (where the kernel is not the operating system but microkernel + kernel modules = operating system) and the microkernel, Hurd is still out of date.

But hey! GNU project has got lots of important software what are needed for development platform (GNU/Linux) and for complete software systems like Debian.

For some people it is just too great crack on their dreams when they realise that Linux kernel is the operating system and GNU/Linux is development platform. And complete software systems are then these "funny" Linux/GNU/Xorg/Java/KDE/Firefox/... etc.

GNU fans were even so big fans that they rewrote the POSIX standard about uname application what prints the operating system names and version. But GNU peope just did not change "operating system" > "kernel" but added the -o option what tells the "real" "operating system" name.

Sorry, but thats why GNU-fans are targets for jokes and laughs. I tought they would had big need for freedom. Especially when you should understand that you can not get true freedom without truth. And that is not coming untill they can accept the truth that Linux kernel is the operating system alone because it is monolith.

Re:It's Linux, NOT GNU/Linux!!

[W2k]

I'm not 100% certain, but I think you'll find that gcc has shipped with all versions of Mac OS X. In fact, Windows is the only modern system I know of that DOESN'T ship with a C compiler.

While I don't have a Mac handy to confirm this, a quick Google suggests that OS X does not include GCC. Rather, it's included with XCode, which is a free download from Apple, much like the free version of Visual Studio from Microsoft.

Malware compile code? What's the point?

It's just another attack vector. Malware could potentially use a compiler to recompile itself on the fly to avoid detection from heuristic algorithms; it could also conceivably fool some detection schemes by transporting its main payload as code (anti-virus programs typically only care about executables) and compiling it later. Furthermore, a system like Linux where lots of software is compile-on-install is potentially vulnerable to the compiler itself being replaced by a malignant version which poisons the executables it compiles.

All these are just my guesses; I don't know enough about hacking to construct all the possible attacks exploiting the presence of a compiler on the target system. However, as a general rule, every additional piece of software you include with your OS is an additional exploit vector.

Re:It's Linux, NOT GNU/Linux!!

[Fri13]

it should be said that a compiler, just like the operating system, is an absolutely essential component to any development platform.

There, fixed for you!

Re:It's Linux, NOT GNU/Linux!!

[Anonymous Coward]

Woah woah, let's be a bit more accurate here. The GNU project has produced a kernel, it's nowhere near as advanced in functionality as Linux, but it exists...

Woah woah, let's be a bit more accurate here! The GNU project has produced a microkernel, it's not an operating system or as advanced in functionality as Linux what is monolith kernel and thats why Linux is alone the operating system without GNU software.

Not being a great fan of Linus and being very appreciative of GNU and agreeing with Stallman, I call it GNU/Linux.

And thats why you follow blindly a lie, not truth. And so on you cant never help others to be free, because you are just trying to get them believe lie about freedom!

GNU/Linux demanders can not even accept basic logic OR technical evicende why Linux kernel is operating system without any GNU tools!
http://www.topology.org/linux/lingl.html

GNU-project has created great things, but they have nothing to do with other Operating Systems than Hurd!

Re:It's Linux, NOT GNU/Linux!!

[hobbit]

I'm not 100% certain, but I think you'll find that gcc has shipped with all versions of Mac OS X. In fact, Windows is the only modern system I know of that DOESN'T ship with a C compiler.

While I don't have a Mac handy to confirm this, a quick Google suggests that OS X does not include GCC [tech-recipes.com]. Rather, it's included with XCode [apple.com], which is a free download from Apple, much like the free version of Visual Studio from Microsoft.

It's somewhere in between. XCode comes on the Leopard DVD, but is not installed by default.

Re:It's Linux, NOT GNU/Linux!!

[Chaos Incarnate]

XCode is now included with the OS, but it's an optional install from the second disc as opposed to an automatic installation.

Re:It's Linux, NOT GNU/Linux!!

[brackishboy]

While I don't have a Mac handy to confirm this, a quick Google suggests that OS X does not include GCC. Rather, it's included with XCode, which is a free download from Apple, much like the free version of Visual Studio from Microsoft.

XCode is also included on the OS X install media, and is an optional install when you first set up your Mac or upgrade the OS.

GCC has already experimental plugins

[Anonymous Coward]

GCC is organized with releases (the usual GCC compiler versions), with the future release called "trunk", and branches (experimental code which may, if accepted, be later merged in into the trunk.

There are already experimental branches for plugin.

In addition, there is the MELT branch, which provides a Lisp dialect (internally tranlated into C) to code plugins with.

Plugins could do many things, which for one reason or another, don't fit easily into the trunk. In particular, "extra compilatory" activities, i.e. any processing of internal GCC representation which is not directly related to machine code generation, fits into this scheme. Think of code refactoring tools, code style checkers, whole program static analysers, specialized code generators (e.g. generation of serialization routines from data structures), etc.

Regards.

--
Basile Starynkevitch (main author of MELT branch)

Re:It's Linux, NOT GNU/Linux!!

[Anonymous Coward]

But shouldn't an OS contain a kernel? I mean, GNU by itself can't be an OS without a kernel (be it opensolaris, linux). Thus, this "GNU OS" is non-sense.

Re:It's Linux, NOT GNU/Linux!!

[partenon]

GNU has produced an operating system. It's nowhere near as advanced in functionality as Linux

I don't get it... GNU guys says that Linux is not an OS, just a kernel. Linux guys (the ones who bother to answer this questio) says that GNU is not an OS, as it doesn't have a kernel. And you say that both are OS ?

Well, don't use GCC then

[Anonymous Coward]

And you get to use whatever the EULA lets you (like, oh, "no benchmarking" or "no writing a competing product" or "You agree to use using whatever you produced for our own purposes without needing any license agreement other than 'you used this product'".

etc.

PS, for the entire frigging thread:

The problem isn't the GPL or any license. The problem is that copyright doesn't work well with source code compiled as binary.

E.g. copyright talks about "expressive works" but the binary object is not expressive so shouldn't be copyrightable.

It is, though.

A book is derived if it follows too closely another book. But software is full of "when this occurs, do this", which, from the olde worlde copyright would be a derived work.

A derived work includes significant parts of the original. Well, a shared library when executed is including a significant part of the library, so, by copyright, it IS a derived work.

Copyright and code doesn't fit.

Re:It's Linux, NOT GNU/Linux!!

[anothy]

you can get systems with more or less GNU on them, just like you can get systems with more or less xorg or Sun on them. running "open source based box" without GNU isn't nearly as hard as you think it is (see, for example, Inferno and Plan 9). granted, people writing under the GNU banner are prolific, but many systems ship by default with very little, and at least some can be had with none.

you're also setting up a very convenient double-standard. you'd have just as much trouble (if not more) finding a system (open or closed) that BSD code hasn't touched; that doesn't mean there ought to be systems called BSD/Windows95 or BSD/OS/2.

Re:It's Linux, NOT GNU/Linux!!

[anothy]

(pardon the self-reply)

of course, the reality is that all these naming discussions are stupid. they're all really describing the system, not naming it, and from that perspective "GNU/Linux" is exactly as correct as "Linux" or "BSD/Linux" or "xorg/GNU/apache/perl/Bell Labs/Apple/Linux" - they just choose to describe different parts. the name of the system is "Slackware Linux", "Debian GNU/Linux" (because Debian said so), or "Knoppix". saying "GNU/Linux" does not name a system; people who make systems get to name them.

Re:It's Linux, NOT GNU/Linux!!

[cant_get_a_good_nick]

1) "some of the BSDs do their own thing for the core"
All of the BSDs have their own core. Well, except for the FSF KFreeBSD. KFreeBSD is a weird hybrid, made by some FSF folks to prove that the GNU userland can run on something other than Linux. It's a needless fork to prove some point that escapes me. I can run GNU userland on Windows (cygwin) why muddy up the BSDs with this.

2) the reason why people get bugged by is this is somewhat silly and hypocritical from the FSF. One of the reasons that the BSD license 'sucked' from the FSF point of view was the 'advertising clause', meaning the BSD folks dared ask for credit when someone used their work. The FSFs claim; having to add this was unwieldy. Yet they want to add this GNU/ to Linux all the time. The BSDs request for it to be somewhere, even in the docs. But FSF wants GNU in the name.

Part of many people's issue with the FSF is inconsistency like this. No 'advertising', well, unless it's us. People followed the rules for GPLv2 but didn't act the way we want, well, GPLv3 to stop those people from doing what we said we could. It's a mess some times.

Re:It's Linux, NOT GNU/Linux!!

[jonaskoelker]

Dude, you're running three window managers!

Re:Operating System?

[Zwicky]

Exactly! HURD is the kernel, Emacs is the operating system.

Sean Callanan...

[dhasenan]

Sean Callanan, a graduate student at Stony Brook University, has created a plugin system for GCC. It's been languishing in a branch for the past year or so.

Many people have wanted this branch to be merged from trunk, but a few people with licensing concerns have blocked it in the past.

Re:It's Linux, NOT GNU/Linux!!

[Knuckles]

In your world a minimal distro includes X and KDE?

Recursive stupidity

[Anonymous Coward]

When Richard Stallman began writing Bison in 1983, he was only trying to build the bits of an operating system he would need to write an operating system. But that recursive goal was no stranger than the recursive name he would create for the software he would eventually create: GNU is Not Unix (GNU).

Please please please give up with the stupid bullshit of recursive names which are like *hyuk hyuk* clever *snort*.

It's not funny. It's fucking stupid and is a sign of a much bigger problem. Free software doesn't catch on because everything is named by programmers. GIMP is a stupid name. GNU is too. What about bbnfc, ctm or wmbp6? They're all too esoteric, like they've been constructed by programmers mashing their hands on the keyboard and picking out a random sub string.

Linus is right to stand back and avoid such evangelism. The whole thing about purposely changing the API to hobble proprietary ('enemy') software puts RMS and his band of merry followers on the same par as everybodys favorite monopoly.

RMS and his self important paisanos are elitist assholes. The good work they do is dwarfed by their arrogance. They need a mishapen turnip in the ass.

Re:It's Linux, NOT GNU/Linux!!

[Frosty Piss]

ok, I get the point, but it's almost like they're on an ego trip, whining about how people are giving them proper credit, and wanting everyone to know how important they are. Frankly, I don't honestly care that much about Linus.

The whole "GNU" thing isn't about Linus, it's about Richard.

Re:It's Linux, NOT GNU/Linux!!

[stim]

granted, But when was the Linux kernel created?

Re:It's Linux, NOT GNU/Linux!!

[isorox]

gnome provides grip, as well as "gnome-power-cmd.sh", which I link to from fluxbox, and gnome-display-settings when I plug my laptop into a strangemonitor (I have a script for work and home which uses xrandr)

kde provide amarok and kdesvn

But fluxbox is my windowmanager

Re:It's Linux, NOT GNU/Linux!!

[oatworm]

Real enlightenment is in GNU/Vista. Of course, it's nowhere near as brilliant as GNU/Me, but what do you do?

Re:It's Linux, NOT GNU/Linux!!

[CannonballHead]

I know that. I was unclear, but I was pointing out that I neither care about GNU/Stallman nor Linux/Linus. It could be called the "Pickle Kernel" and I wouldn't particularly care.

Yeah, Stallman and Torvalds are both pretty cool guys and I'm glad they wrote what they did, but if they didn't, probably someone else would have... so in the spirit of the whole free software thing, I don't think I am obliged to bow down before their names or anything like that, whether the 'name' created the Linux kernel, GNU stuff, Windows, Mac, etc. I'm one of those annoying consumers that just uses it, I guess. :) If "Linux" ended up being called "Strident" or something, I wouldn't care. Even if a guy name Linus Torvalds created it. Or Stallman. Or whatever.

Seems to me that "free software" should be able to be called whatever 'it' wants to be, too, hehe.

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

[LizardKing]

Sun, like one or two other corporations, were forced crying and kicking down the open source path

You're clearly one of those ill informed twats who got their history of Sun from PJ at Groklaw when she was still drinking the IBM kool aid. Sun has supported open source software since before Linux existed, and when GNU was just a manifesto.

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

[LizardKing]

And to reply to my own comment ... the grandparent poster may want to read this article which reports on a study showing Sun has contributed more than three times as much code to open source projects than IBM, and is the leading commercial entity to have done so (way more than RedHat for instance).

It's so cute

[harlows_monkeys]

It's so cute how they think that they get to say what license plug-ins use.

People with real lawyers and a lot of money on the line have settled this question a long time ago, when various commercial software producers tried to stop third-parties from making unauthorized add-ons. Those trying to stop unauthorized plug-ins lost, for a few reasons.

1. A plug-in is generally not a derivative work of the thing it plugs into. (The FSF is sometimes confused here, because they often confuse "derivative work" with "is useless without").
2. To the extent that a plug-in has to incorporate code from the thing it plugs into in order to work (e.g., structure definitions, function call sequences, constants), the copyright on the host program does not cover those, as they are procedures or methods of operation.
3. The courts have found that there is a strong public policy interest in disallowing authors to use their copyright monopoly to get patent-like protection for their works.
4. Fair use.

See the gcc exception as well

[mdupont]

The plugin architecture is based on an "gcc exception" that
in my humble opinion, and I am not a lawyer, is very shaky.

See my article on this :
http://rdfintrospector2.blogspot.com/2009/01/gnu-gcc-compiler-introspector-reloaded.html

mike

Google Summer of Code: GCC

[tepples]

It's not the Google Compiler Collection, you know.

That was, until Google sponsored improvements to GCC as part of Google Summer of Code.

Re:Operating System?

[Arker]

Meh, Slackware is the OS. And I'll believe HURD is ready when Patrick says it is.