Slashdot Mirror

Ubuntu provides specific repositories of nonfree software, and Canonical expressly promotes and recommends nonfree software under the Ubuntu name in some of their distribution channels. Ubuntu offers the option to install only free packages, which means it also offers the option to install nonfree packages too. In addition, the version of Linux, the kernel, included in Ubuntu contains firmware blobs.

Ubuntu's trademark policy prohibits commercial redistribution of exact copies of Ubuntu, denying an important freedom.

Instead, just send him a laptop. In fact, why even send him an expensive MacBook - he may not like it if it has an UEFI BIOS. If you can, mail-order a Lemote Yeeloong. It is not all that lackluster, and it has everything he wants - 'system source files(BIOS, kernel, drivers etc.) are free software, no close (sic) firmware needed.'. Heck, it even calls the OS GNU/Linux. Ask them to preload it w/ GNewSense, and arrange to have it sent to rms.

Only question - do you want to send him the laptop while he's still in Argentina1, or do you want to wait for him to get back? ;-)

Why also, do people totally miss the point of FOSS and focus on price rather than freedom of choice?

Well, I don't know, but if it's not a big point why is it #1 on the list?
http://www.opensource.org/docs/osd

Depending on which flavor you drink, it's also third out of four here.
http://www.gnu.org/philosophy/free-sw.html

You ask why do people ignore all the other points? Honestly? Why would a non-technical person give a damn, and why should they? Expanding the scope more, why would most technical people care, they are not all software developers, don't all have the skills to utilize a project's code, or consciously choose not to have the responsibility of inspecting and modifying a free project's code because that has dick to do with operations.

The OSI's definition of Open Source, at least the _bottom_ half of their wishlist _tries_ to appear sincerely altruistic - "No Discrimination Against Persons or Groups/Fields of Endeavor" etc. The Free Software Def. fairly clearly says "do what I want and give it away".

Neither mention anything about quality, or improving the state of the art, things people DO care about and will PAY FOR.

However, I personally am more interested in the ability of organise my desktop in such a way that maximises my ease of use

How software functions has _NOTHING_ to do with this. Write your own software that does what you want. I can say that _fully_ within the spirit of free open software, so you can't complain. Or are you really telling me you wrote a custom patch for complex desktop software, and maintain it or fight with the original authors to accept it, just to organize your desktop... for your "ease of use"? Why would other people care?

I recommend replacing "Call of Duty: Modern Warfare 2" which can be interpreted either as an FPS supporting realistic guns, an FPS with good graphics, a generic FPS, or a rehashed FPS.

I was using it as an example of a first-person shooter with 1. realistic guns, 2. good graphics, and 3. compatibility with a computing device already connected to the user's living-room TV monitor. Apart from hardcore geeks and trailer trash, nobody wants to connect a gaming PC to a TV. Any replacement of console games with freely licensed games would have to include replacement of the console with a device capable of running freely licensed games.

Wow, did someone use the "you write them" argument?

The anon who posted in the thread from two years ago isn't the only one to use that argument. Mr. Stallman is using that argument too, promoting free vaporware over non-free releases. From the article: "If you want to promote freedom, please take care not to talk about the availability of these games on GNU/Linux as support for our cause. Instead you could tell people about the Liberated Pixel Cup free game contest" (that is, claim that a freely licensed game that doesn't exist yet is a substitute for the thousands of non-free games that do exist) "and the LibrePlanet Gaming Collective free gaming night" (whose playlist consists of one game).

And also ignoring that he mentioned it to someone who already released open source software?

Yes, I have released a few free NES games, including competent alternatives to Tetris and Missile Command, which run in the free emulator FCEUX. Some Slashdot users (especially CronoCloud) claim that they're a net negative on my CV because they're close substitutes for commercial games.

Since the 1980s, free software developers have tried various methods of finding funds, with some success. There's no need to make anyone rich; a typical income is plenty of incentive to do many jobs that are less satisfying than programming.

This is another example of ESR ignoring the dangers of closed-source software in his devotion to "pragmatism." There is always a role for the monks of society, and RMS is the monk of free software. It's relatively easy to be a pragmatist. It takes something special to be a monk.

I don't live like RMS, but I find his insights to be important. The dystopian future from The Right to Read, especially, is being carried out in terms of years instead of decades. The secret to RMS's "fanaticism" is his long-term planning. Pragmatism seems to work now, but sooner or later closed-source is going to hurt you.

The elevator example is not that good. ESR has forgotten about elevator breakdowns. Elevators also usually include surveillance and phone-home equipment, which have implications for reliability, privacy, and vendor lock-in.

The microwave example is not that good, either. Many modern microwaves have an insanely complicated user interface, and I wouldn't mind replacing it with a more intuitive one. Not to mention what silly things you could do with a microwave if you could network it.

Please don't quote RMS. if you have a quote from Torvalds or Perens or frankly anybody else then great, but RMS tried to claim "if you can't update its a circuit" so the man's logic isn't even consistent with itself anymore. hell if you go by that then the PS2 is FOSS friendly since you can't update it so its a circuit and if you disabled updates for the PS3 and X360 then they'd be circuits as well. The man honestly doesn't even make sense with his own logic anymore (you can see and modify JavaScript but its bad if its not GNU, but locking down a chip so it can't be updated and you can't see the code is GNU-friendly) so please don't use him to bolster an argument, as he gets older he just contradicts himself. At least Torvalds has been consistent in his views over the years.

As for TFA...what is the odds we are gonna end up with another Rambus mess all over again? Because i really don't want to go through that, the prices went all over the place and it seemed to take forever to get it all straightened out. hell this company only has 60 million in revenue a year so why don't Micron or a couple of the big boys just get together and buy the damned thing and make their patents RAND. As we saw with Rambus it would probably cheaper in the long run just to buy 'em and RAND it than it would be to pay lawyers for years worth of court dragging, if this tech is really that important frankly the big four memory makers could buy this corp with what they make in profits in the average month with plenty of change left over.

As a result they are only produced by one source which is facing some hurdles justifying their copying of IP.

I am the only one who's annoyed by the poster's complete lack of critical reflection on those "IP" claims? Are the IP lawyers and lobbyists now getting their anonymous postings on slashdot, too? I'm close to deleting my /. account.

BTW I'm also annoyed by the fact that people got so used to the somewhat nonsensical oxymoron "Intelectual Property".

And from the FAQ:
"But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL."

You are technically correct in that we could use the library and not release our software and not release our source code. I don't know why you would make that point though (and you might not be), as it is useless. What would be the point of developing software if we couldn't release it?

http://www.gnu.org/philosophy/open-source-misses-the-point.html

Those are rather unusual cases - under normal use (direct linking or use as a shared library), a GPL library imposes GPL on the entire application that uses it. Yes, it may be possible to use a GPL library without imposing GPL terms on the application, but it takes a good deal of effort to try and do so, like running the library in a separate process space and highly constraining communications with it...

See FAQ entry: http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins

Maybe, maybe not...it depends on how the library is used. See Prelinking and Aggregation.

Maybe, maybe not...it depends on how the library is used. See Prelinking and Aggregation.

Under the GPL, only people that the executable was distributed to are allowed to request the code

It's perhaps a little more nuanced than this, to my mind.

Under GNU GPL 2.0, a distributor of a binary of the Program has two main options for distributing the source code:

• a.) Accompany it with the complete corresponding machine-readable source code ... or,

• b.) Accompany it with a written offer ... to give any third party ... a complete machine-readable copy of the corresponding source code...

If the source code does not accompany the binary, the binary must be accompanied by a written offer to give the source to "any third party" — it does not say "to give any third party who possesses the object code" or similar.

However, the GPL FAQs (which I'd treat as one interpretation of the licence), comment that:

The offer must be open to everyone who has a copy of the binary that it accompanies. This is why the GPL says your friend must give you a copy of the offer along with a copy of the binary—so you can take advantage of it.

However, this is not what the wording says — that the offer must be open to "any third party." If I get the binary directly from you, the status is clear, as is the situation in which I get the binary from my friend, who got it from you — but it's unclear, to my mind, what happens when I do not have the binary. I'd probably leave it that you have an obligation to provide the source code to me — an obligation to provide the source code to "any third party" — but that, without a copy of the offer myself, I'd likely have a very difficult time enforcing the obligation.

GNU GPL 3.0 clears this up, with clause 6(b) providing that a non-source distribution on a physical medium can take place if

accompanied by a written offer ... to give anyone who possesses the object code [the source or access to the source]

However, the fact the words are *not* in GNU GPL 2.0 but *are* in GNU GPL 3.0 does not necessarily mean that they should be read in...

YVMV, of course :)

Under the GPL, only people that the executable was distributed to are allowed to request the code

It's perhaps a little more nuanced than this, to my mind.

Under GNU GPL 2.0, a distributor of a binary of the Program has two main options for distributing the source code:

• a.) Accompany it with the complete corresponding machine-readable source code ... or,

• b.) Accompany it with a written offer ... to give any third party ... a complete machine-readable copy of the corresponding source code...

If the source code does not accompany the binary, the binary must be accompanied by a written offer to give the source to "any third party" — it does not say "to give any third party who possesses the object code" or similar.

However, the GPL FAQs (which I'd treat as one interpretation of the licence), comment that:

The offer must be open to everyone who has a copy of the binary that it accompanies. This is why the GPL says your friend must give you a copy of the offer along with a copy of the binary—so you can take advantage of it.

However, this is not what the wording says — that the offer must be open to "any third party." If I get the binary directly from you, the status is clear, as is the situation in which I get the binary from my friend, who got it from you — but it's unclear, to my mind, what happens when I do not have the binary. I'd probably leave it that you have an obligation to provide the source code to me — an obligation to provide the source code to "any third party" — but that, without a copy of the offer myself, I'd likely have a very difficult time enforcing the obligation.

GNU GPL 3.0 clears this up, with clause 6(b) providing that a non-source distribution on a physical medium can take place if

accompanied by a written offer ... to give anyone who possesses the object code [the source or access to the source]

However, the fact the words are *not* in GNU GPL 2.0 but *are* in GNU GPL 3.0 does not necessarily mean that they should be read in...

YVMV, of course :)

Why not? It's a library, as in (most probably) a stand-alone binary file, is it not? Provided "lzo.dll" or whatever it was called was shipped as part of the package and only linked against, then there is no need to distribute the rest of the source code in order to achieve GPL compliance. Or am I misunderstanding the GPL FAQ?

the legal they use in the is "convey":
To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.
http://www.gnu.org/copyleft/gpl.html

A company carrying out work on the code and keeping it for them selves (same party), does not convey the code and does not run into any GPL clauses. If they they are legally two parties then as long as the second party can be trusted (you cant legally enforce it, as per the license) to not further convey the source, i think your fine as well.

How do you persuade a company legal team that GPLv3 is not poison and let the techies use GPLv3-licenced software ?

Get them to read the license. It only covers conveying of the source code as far as i can see. If you want to use it in a product you want to sell then they have every reason to get worried about it.

http://www.gnu.org/licenses/gpl-faq.html#ClickThrough

Dude, the GPL is one of the most simple licenses out there. Perhaps this isn't an issue with the other licenses because everyone just assumes that they will not be enforced, which strikes me as odd. But I still do not get how people miscontstrue the GPL in such a variety of ways.

If you make an image with GIMP the image does not need to be released under the GPL! You are free to use the GPLed program, in this case GIMP for any purpose (seriously, for *any purpose*). An image created using GIMP is not a derivative work of GIMP, since no part of GIMP exists in the image. If you were to modify the source code of GIMP, then that would be a derivative work, but so long as that work is not distributed, you still do not have any oblications under the GPL. If you release your modification of GIMP then you must provide the source code licensed under the GPL and not use patents/copyrights to sue anyone over their use of your modified GIMP.

So the GPL is completely viable for software that is used to create content, because it has absolutely no restrictions on that created content. You do not need to give people a copy of GIMP with every image you create with it, that is not what the text of the license says. Seriously, where did you get that idea? And just in case you need a citation, behold the GPL FAQ!

Seriously, where do you get this sort of misinformation?

On a side note, the ffmpeg issue is not as clear cut as you claim, since they don't use a normal GPL, but use a modified LGPL v2. I haven't read the ffmpeg license, but the LGPL allows linking, so they don't have to distribute ffmpeg, and it most likely doesn't properly exist in their software product anyways (remember, linking).

Is it a program by a contractor, as opposed to one made by an employee of the Federal government while on duty? Contract software is not (necesssarily) auto-PD, but the contract can require it to be copyleft free software, etc.

Reading section 6 of GPL3, there is this section in it

If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).

In other words, GPL3 ain't as pure as it proclaims either. If it can waive the condition where it is useless - such as use in a ROM - why can't they include a locked down flash device in it? After all, functionally, a ROM, a PROM, an EPROM, an MTP and a lockable flash (like ones coming out of Spansion and Micron) are the same. A PROM allows programming in assembly, an EPROM allows it to be erased, an MTP does the same as an EPROM except that it is electrically altered out of system, and a flash, after programming, can have any or all portions of the device locked for protection. But from an end user standpoint, they'll all look the same - like ROM.

Some vendors may move to masked ROM for the cost savings, others may decide that they don't have the volume to justify it, so they keep it in flash, but lock it down. For the license to make a distinction b/w the 2 cases is ridiculous. The way TiVo does it could have been treated exactly like it puts it on ROM, since that exception is there anyway. Or else, GPL3 should have decreed that 'Thou shalt not use ROMs', making the license even more worthless.

Linus could, if he so desired, declare he will no longer accept GPL2 patches or code, and in probably just 10 or 20 years there would be no remaining GPL2 code in the kernel, probably. Aside from whatever personal views Linus has about the GPL3, re licensing linux just isn't going to happen, at least not any time soon.

You do know it's against the GPL to combine GPLv2-only with GPLv3-only code, right? Even the FSF says so. You can combine GPLv2+ with GPLv3 no issues, but using v3 code will violate the license of v2-only code!

The only thing that's come out of the GPLv3 license is that companies are now going through their software licensing policies, demanding the same scrutiny over open-source code as they are over commercially-licensed code. Including stuff like license reviews and software approvals. I've seen them mandate that if you wish to use software outside of a pre-approved list, it has to be reviewed by Legal - and it applies whether the software is for internal use only, or to be incorporated into the end product. Heck, even an edict came down along the lines of "No GPLv3 software will be approved - don't even try".

Nearly all the problems you describe can be solved by using a mailing list with a central archive. Virtually all open source projects use this approach, and it works wonderfully. Sadly, the most popular corporate groupware application (*cough*Exchange*cough*) never has and likely will never support this notion in a satisfactory fashion. I really can't imagine the productivity gains that could be had if more places would ditch their enterprise shovelware for mailman or similar.

Actually, that's a very good example. Yeah, food cannot be replicated on multiple plates for little to no effort, like software can, but that misses the point of what software creators - people who do that for a living - do.

Let's say S creates a software title. It takes S several months to create it, during which S pays the salaries of the software writers, and also buys equipment like computers, printers, and also has to pay the lease on their office space. So all this gets aggregated into the cost of the software, which turns out to be $X. Add to that whatever margins S needs to make in order to satisfy its investors, cover its taxes and other expenditure, and lets say that that total cost is $Y. S then makes an estimate of how big its market will be, and let's say that it's N. S then comes up w/ a price tag of $(Y/N) and puts it out on shelves.

Now, if you have any number of people pirating that software of S, then it essentially erodes S's capabilities of covering its initial costs, and is unfair to those who legitimately bought the disks. Even in the event that S has sold enough to cover its costs, it still doesn't justify piracy. If one thinks that software creation is trivial enough that it doesn't deserve to be paid for, then look at the GNU software page, and see how many of those are actually usable. GIMP is a rare exception, as is GCC, Emacs, but the bulk of them flounder. Why do you think that is? It's b'cos there ain't a continuous, regular revenue stream that can make it worth the while of anybody to make it his daily living.

Which is why we should all avoid use of the term 'intellectual property'. Use of the term promotes precisely this sort of confusion.

If Apple wasn't having a resurgence, would anyone be paying attention to Ojective-C?

You mean like the GNU project?

http://www.gnu.org/software/gnustep/resources/ObjCFun.html

Is anyone paying attention to GnuStep?

With those new chips, will it be VAXorcist, the Sequel?

To be entirely correct neither Ubuntu nor Fedora are OS's...they are distributions of the GNU/Linux OS. You are, however, quite right in pointing out that may of the postings on this topic misuse the term "Linux" to mean GNU/Linux. The FSF has a very readable explanation of this issue http://www.gnu.org/gnu/why-gnu-linux.html

I'm not going to bother reading every post made here. The premise of the question is wrong and either needs to be rethought or have the wording corrected and re-posted. I'm seeing arguments here about patents. Who said IP was a patent? Could it be copyright? Maybe trademark? Do any of these seem to have anything to do with each other? No. Quit using the term Intellectual Property. If you mean copyright then refer to copyright. If you mean trademark then refer to it. Don't screw up the debate by confusing the issue from the beginning. See RMS: https://www.gnu.org/philosophy/not-ipr.html

If you care this much about freedom, use one of the FSF-endorsed distros.

GNU typically follows pretty closely to the standards for the various languages; the "superset" is typically in the compiler space reserved by each language (e.g. __attribute()__ in C/C++).

True. But for code using __attribute()__, such as code running in certain embedded architectures, a third-party parser is still going to have to recognize those attributes. And attributes aren't the only extension to C that GCC implements; other things include statement expressions, nested functions, 128-bit integer types, the binary ?: operator that acts like or in Scheme or Python, named address spaces, and ranges in case statements and array initializers.

Aside from the __attribute__() - which typically should be ignored any way - those are all things that a parser could easily pick up, and GCC/G++ is not likely the only one that supports them. So that shouldn't necessarily be an issue.

If CLang isn't doing that, then (i) it's limited in what languages it can support on the front end (evidenced by their sole focus on C, C++, Objective-C, and Objective-C++)

Clang is a frontend to LLVM. Other frontends exist for other languages.

True. And LLVM still relies a lot on GCC for those other languages, and back-end work.

I also don't see anything mentioning architecture support for CLang - compared with GCC's multitude of architectures.

LLVM targets at least these architectures. Production-quality backends include x86, ARM, PowerPC, SPARC, MIPS, and Hexagon (whatever that is).

That's still a relatively small list compared to GCC's list of architectures.

GNU typically follows pretty closely to the standards for the various languages; the "superset" is typically in the compiler space reserved by each language (e.g. __attribute()__ in C/C++).

True. But for code using __attribute()__, such as code running in certain embedded architectures, a third-party parser is still going to have to recognize those attributes. And attributes aren't the only extension to C that GCC implements; other things include statement expressions, nested functions, 128-bit integer types, the binary ?: operator that acts like or in Scheme or Python, named address spaces, and ranges in case statements and array initializers.

Aside from the __attribute__() - which typically should be ignored any way - those are all things that a parser could easily pick up, and GCC/G++ is not likely the only one that supports them. So that shouldn't necessarily be an issue.

If CLang isn't doing that, then (i) it's limited in what languages it can support on the front end (evidenced by their sole focus on C, C++, Objective-C, and Objective-C++)

Clang is a frontend to LLVM. Other frontends exist for other languages.

True. And LLVM still relies a lot on GCC for those other languages, and back-end work.

I also don't see anything mentioning architecture support for CLang - compared with GCC's multitude of architectures.

LLVM targets at least these architectures. Production-quality backends include x86, ARM, PowerPC, SPARC, MIPS, and Hexagon (whatever that is).

That's still a relatively small list compared to GCC's list of architectures.

GNU typically follows pretty closely to the standards for the various languages; the "superset" is typically in the compiler space reserved by each language (e.g. __attribute()__ in C/C++).

True. But for code using __attribute()__, such as code running in certain embedded architectures, a third-party parser is still going to have to recognize those attributes. And attributes aren't the only extension to C that GCC implements; other things include statement expressions, nested functions, 128-bit integer types, the binary ?: operator that acts like or in Scheme or Python, named address spaces, and ranges in case statements and array initializers.

Aside from the __attribute__() - which typically should be ignored any way - those are all things that a parser could easily pick up, and GCC/G++ is not likely the only one that supports them. So that shouldn't necessarily be an issue.

If CLang isn't doing that, then (i) it's limited in what languages it can support on the front end (evidenced by their sole focus on C, C++, Objective-C, and Objective-C++)

Clang is a frontend to LLVM. Other frontends exist for other languages.

True. And LLVM still relies a lot on GCC for those other languages, and back-end work.

I also don't see anything mentioning architecture support for CLang - compared with GCC's multitude of architectures.

LLVM targets at least these architectures. Production-quality backends include x86, ARM, PowerPC, SPARC, MIPS, and Hexagon (whatever that is).

That's still a relatively small list compared to GCC's list of architectures.

GNU typically follows pretty closely to the standards for the various languages; the "superset" is typically in the compiler space reserved by each language (e.g. __attribute()__ in C/C++).

True. But for code using __attribute()__, such as code running in certain embedded architectures, a third-party parser is still going to have to recognize those attributes. And attributes aren't the only extension to C that GCC implements; other things include statement expressions, nested functions, 128-bit integer types, the binary ?: operator that acts like or in Scheme or Python, named address spaces, and ranges in case statements and array initializers.

Aside from the __attribute__() - which typically should be ignored any way - those are all things that a parser could easily pick up, and GCC/G++ is not likely the only one that supports them. So that shouldn't necessarily be an issue.

If CLang isn't doing that, then (i) it's limited in what languages it can support on the front end (evidenced by their sole focus on C, C++, Objective-C, and Objective-C++)

Clang is a frontend to LLVM. Other frontends exist for other languages.

True. And LLVM still relies a lot on GCC for those other languages, and back-end work.

I also don't see anything mentioning architecture support for CLang - compared with GCC's multitude of architectures.

LLVM targets at least these architectures. Production-quality backends include x86, ARM, PowerPC, SPARC, MIPS, and Hexagon (whatever that is).

That's still a relatively small list compared to GCC's list of architectures.

GNU typically follows pretty closely to the standards for the various languages; the "superset" is typically in the compiler space reserved by each language (e.g. __attribute()__ in C/C++).

True. But for code using __attribute()__, such as code running in certain embedded architectures, a third-party parser is still going to have to recognize those attributes. And attributes aren't the only extension to C that GCC implements; other things include statement expressions, nested functions, 128-bit integer types, the binary ?: operator that acts like or in Scheme or Python, named address spaces, and ranges in case statements and array initializers.

Aside from the __attribute__() - which typically should be ignored any way - those are all things that a parser could easily pick up, and GCC/G++ is not likely the only one that supports them. So that shouldn't necessarily be an issue.

If CLang isn't doing that, then (i) it's limited in what languages it can support on the front end (evidenced by their sole focus on C, C++, Objective-C, and Objective-C++)

Clang is a frontend to LLVM. Other frontends exist for other languages.

True. And LLVM still relies a lot on GCC for those other languages, and back-end work.

I also don't see anything mentioning architecture support for CLang - compared with GCC's multitude of architectures.

LLVM targets at least these architectures. Production-quality backends include x86, ARM, PowerPC, SPARC, MIPS, and Hexagon (whatever that is).

That's still a relatively small list compared to GCC's list of architectures.

GNU typically follows pretty closely to the standards for the various languages; the "superset" is typically in the compiler space reserved by each language (e.g. __attribute()__ in C/C++).

True. But for code using __attribute()__, such as code running in certain embedded architectures, a third-party parser is still going to have to recognize those attributes. And attributes aren't the only extension to C that GCC implements; other things include statement expressions, nested functions, 128-bit integer types, the binary ?: operator that acts like or in Scheme or Python, named address spaces, and ranges in case statements and array initializers.

Aside from the __attribute__() - which typically should be ignored any way - those are all things that a parser could easily pick up, and GCC/G++ is not likely the only one that supports them. So that shouldn't necessarily be an issue.

If CLang isn't doing that, then (i) it's limited in what languages it can support on the front end (evidenced by their sole focus on C, C++, Objective-C, and Objective-C++)

Clang is a frontend to LLVM. Other frontends exist for other languages.

True. And LLVM still relies a lot on GCC for those other languages, and back-end work.

I also don't see anything mentioning architecture support for CLang - compared with GCC's multitude of architectures.

LLVM targets at least these architectures. Production-quality backends include x86, ARM, PowerPC, SPARC, MIPS, and Hexagon (whatever that is).

That's still a relatively small list compared to GCC's list of architectures.

GNU typically follows pretty closely to the standards for the various languages; the "superset" is typically in the compiler space reserved by each language (e.g. __attribute()__ in C/C++).

True. But for code using __attribute()__, such as code running in certain embedded architectures, a third-party parser is still going to have to recognize those attributes. And attributes aren't the only extension to C that GCC implements; other things include statement expressions, nested functions, 128-bit integer types, the binary ?: operator that acts like or in Scheme or Python, named address spaces, and ranges in case statements and array initializers.

Aside from the __attribute__() - which typically should be ignored any way - those are all things that a parser could easily pick up, and GCC/G++ is not likely the only one that supports them. So that shouldn't necessarily be an issue.

If CLang isn't doing that, then (i) it's limited in what languages it can support on the front end (evidenced by their sole focus on C, C++, Objective-C, and Objective-C++)

Clang is a frontend to LLVM. Other frontends exist for other languages.

True. And LLVM still relies a lot on GCC for those other languages, and back-end work.

I also don't see anything mentioning architecture support for CLang - compared with GCC's multitude of architectures.

LLVM targets at least these architectures. Production-quality backends include x86, ARM, PowerPC, SPARC, MIPS, and Hexagon (whatever that is).

That's still a relatively small list compared to GCC's list of architectures.

The GPL is not a software licence and it would not have been affected at all by a pro-Psystar ruling in this case.

Really!?
Because the FSF says

The GNU General Public License is a free, copyleft license for software

GNU typically follows pretty closely to the standards for the various languages; the "superset" is typically in the compiler space reserved by each language (e.g. __attribute()__ in C/C++).

True. But for code using __attribute()__, such as code running in certain embedded architectures, a third-party parser is still going to have to recognize those attributes. And attributes aren't the only extension to C that GCC implements; other things include statement expressions, nested functions, 128-bit integer types, the binary ?: operator that acts like or in Scheme or Python, named address spaces, and ranges in case statements and array initializers.

If CLang isn't doing that, then (i) it's limited in what languages it can support on the front end (evidenced by their sole focus on C, C++, Objective-C, and Objective-C++)

Clang is a frontend to LLVM. Other frontends exist for other languages.

I also don't see anything mentioning architecture support for CLang - compared with GCC's multitude of architectures.

LLVM targets at least these architectures. Production-quality backends include x86, ARM, PowerPC, SPARC, MIPS, and Hexagon (whatever that is).

GNU typically follows pretty closely to the standards for the various languages; the "superset" is typically in the compiler space reserved by each language (e.g. __attribute()__ in C/C++).

True. But for code using __attribute()__, such as code running in certain embedded architectures, a third-party parser is still going to have to recognize those attributes. And attributes aren't the only extension to C that GCC implements; other things include statement expressions, nested functions, 128-bit integer types, the binary ?: operator that acts like or in Scheme or Python, named address spaces, and ranges in case statements and array initializers.

If CLang isn't doing that, then (i) it's limited in what languages it can support on the front end (evidenced by their sole focus on C, C++, Objective-C, and Objective-C++)

Clang is a frontend to LLVM. Other frontends exist for other languages.

I also don't see anything mentioning architecture support for CLang - compared with GCC's multitude of architectures.

LLVM targets at least these architectures. Production-quality backends include x86, ARM, PowerPC, SPARC, MIPS, and Hexagon (whatever that is).

GNU typically follows pretty closely to the standards for the various languages; the "superset" is typically in the compiler space reserved by each language (e.g. __attribute()__ in C/C++).

True. But for code using __attribute()__, such as code running in certain embedded architectures, a third-party parser is still going to have to recognize those attributes. And attributes aren't the only extension to C that GCC implements; other things include statement expressions, nested functions, 128-bit integer types, the binary ?: operator that acts like or in Scheme or Python, named address spaces, and ranges in case statements and array initializers.

If CLang isn't doing that, then (i) it's limited in what languages it can support on the front end (evidenced by their sole focus on C, C++, Objective-C, and Objective-C++)

Clang is a frontend to LLVM. Other frontends exist for other languages.

I also don't see anything mentioning architecture support for CLang - compared with GCC's multitude of architectures.

LLVM targets at least these architectures. Production-quality backends include x86, ARM, PowerPC, SPARC, MIPS, and Hexagon (whatever that is).

GNU typically follows pretty closely to the standards for the various languages; the "superset" is typically in the compiler space reserved by each language (e.g. __attribute()__ in C/C++).

True. But for code using __attribute()__, such as code running in certain embedded architectures, a third-party parser is still going to have to recognize those attributes. And attributes aren't the only extension to C that GCC implements; other things include statement expressions, nested functions, 128-bit integer types, the binary ?: operator that acts like or in Scheme or Python, named address spaces, and ranges in case statements and array initializers.

If CLang isn't doing that, then (i) it's limited in what languages it can support on the front end (evidenced by their sole focus on C, C++, Objective-C, and Objective-C++)

Clang is a frontend to LLVM. Other frontends exist for other languages.

I also don't see anything mentioning architecture support for CLang - compared with GCC's multitude of architectures.

LLVM targets at least these architectures. Production-quality backends include x86, ARM, PowerPC, SPARC, MIPS, and Hexagon (whatever that is).

GNU typically follows pretty closely to the standards for the various languages; the "superset" is typically in the compiler space reserved by each language (e.g. __attribute()__ in C/C++).

True. But for code using __attribute()__, such as code running in certain embedded architectures, a third-party parser is still going to have to recognize those attributes. And attributes aren't the only extension to C that GCC implements; other things include statement expressions, nested functions, 128-bit integer types, the binary ?: operator that acts like or in Scheme or Python, named address spaces, and ranges in case statements and array initializers.

If CLang isn't doing that, then (i) it's limited in what languages it can support on the front end (evidenced by their sole focus on C, C++, Objective-C, and Objective-C++)

Clang is a frontend to LLVM. Other frontends exist for other languages.

I also don't see anything mentioning architecture support for CLang - compared with GCC's multitude of architectures.

LLVM targets at least these architectures. Production-quality backends include x86, ARM, PowerPC, SPARC, MIPS, and Hexagon (whatever that is).

GNU typically follows pretty closely to the standards for the various languages; the "superset" is typically in the compiler space reserved by each language (e.g. __attribute()__ in C/C++).

True. But for code using __attribute()__, such as code running in certain embedded architectures, a third-party parser is still going to have to recognize those attributes. And attributes aren't the only extension to C that GCC implements; other things include statement expressions, nested functions, 128-bit integer types, the binary ?: operator that acts like or in Scheme or Python, named address spaces, and ranges in case statements and array initializers.

If CLang isn't doing that, then (i) it's limited in what languages it can support on the front end (evidenced by their sole focus on C, C++, Objective-C, and Objective-C++)

Clang is a frontend to LLVM. Other frontends exist for other languages.

I also don't see anything mentioning architecture support for CLang - compared with GCC's multitude of architectures.

LLVM targets at least these architectures. Production-quality backends include x86, ARM, PowerPC, SPARC, MIPS, and Hexagon (whatever that is).

GNU typically follows pretty closely to the standards for the various languages; the "superset" is typically in the compiler space reserved by each language (e.g. __attribute()__ in C/C++).

True. But for code using __attribute()__, such as code running in certain embedded architectures, a third-party parser is still going to have to recognize those attributes. And attributes aren't the only extension to C that GCC implements; other things include statement expressions, nested functions, 128-bit integer types, the binary ?: operator that acts like or in Scheme or Python, named address spaces, and ranges in case statements and array initializers.

If CLang isn't doing that, then (i) it's limited in what languages it can support on the front end (evidenced by their sole focus on C, C++, Objective-C, and Objective-C++)

Clang is a frontend to LLVM. Other frontends exist for other languages.

I also don't see anything mentioning architecture support for CLang - compared with GCC's multitude of architectures.

LLVM targets at least these architectures. Production-quality backends include x86, ARM, PowerPC, SPARC, MIPS, and Hexagon (whatever that is).

Actually, not BSD, but APSL, which is slightly closer to what the FSF can live with. Not quite free enough, but better than BSD, according to Stallman and Co.

"Very much strongly" in favor of copyright? Not quite. At least Stallman is in favour of experimentation to reduce the strength of copyright laws. http://www.gnu.org/philosophy/misinterpreting-copyright.en.html

No, they're doing it to make sure that you can't extend GCC in any way, shape or form without those extensions themselves being under GPL. That's why Stallman always hated the idea of a publicly documented intermediate language - because it would allow third-party authors to write tools to process that IL (e.g. optimizers), which, because they don't link with GCC, wouldn't be 'derived works' in legal sense.

It's all laid out pretty clearly in their license for the runtime library - have a read.

Now now, even I've called RMS a zealot for some of the stuff he's said and done re. GCC (e.g. telling someone who wrote a JVM backend for GCC to delete it not tell anyone he wrote it) along that line.

But my understanding is that GPL v3 introduced some change (that I now forget) to make the license stronger, which means that the FSF is now comfortable with that sort of thing. GCC has had a legitimate plugin interface for quite some time now.

Here is what I personally don't get, maybe someone can explain it to me, but WTF was it with RMS and the TiVo?

Tivo did exactly what RMS started the Free Software Foundation to prevent (The Printer Story). What did you expect would happen?

By making it all but impossible to make money out of liberated software in a manner that the FSF approves,

[citation needed]

Just because YOU can't manage it doesn't mean that it's impossible or even difficult. It just means you can't get your head around it.

Here is what the FSF has to say about some common Linux distros, which follow the GPL:
http://www.gnu.org/distros/common-distros.html
Essentially, no company outside the FSF does 'Free software' in a way that the FSF approves.

Stallman has done more damage than good to users of software.

[citation needed] again. You're making a lot of declarative statements and then leaving them unsupported. Support them, or admit your prejudice.

Great example like I argued yesterday - TiVo. By railroading them in public for putting GPL code into a read-only configuration, Stallman made it clear that his software has no problems violating Freedom 0 of GNU. That's one of the key things built into GPL3. Also, a lot of software vendors deliberately avoid the GPL due to legal complications that may arise due to combination of differently licensed software. Result of that is that software that might have been licensed under the GPL is licensed differently, and so there are less choices to choose from for GNU users.
What does it tell you when a number of software makers, who until now had been happily using GCC, have suddenly decided to switch to a relatively new LLVM/Clang?

The Open Source people have done good in limiting the damage

Fucking Microsoft is Open Source in many cases. So was SunOS4, in practice, although they clamped down on SunOS5 sources. The Open Source people have mostly done a good job at claiming victory where there is none, and at claiming trademarks they don't own, not to mention designing their logo to make it look like they hold trademarks they don't hold. Frankly, they are today riding RMS' coattails. Their world would barely exist without him. Normal people run Linux today, they run it on tablets and they run it on laptops and they run it on desktops and it is on more and more embedded devices every day. Remember the old days of BSD? A few neckbeards in poorly-cleaned offices and apartments dominated the scene. I know some of them personally, but have fallen out of touch — I'm a Linux user and they are fanatics. They actually think less of you if you don't run BSD. That's prejudice, kind of like yours.

The open source people are not riding RMS's coattails. If anything, RMS refuses to associate w/ them, and in turn, they do not associate w/ him when they are dealing w/ businesses that they want to have supporting their movement. They know what a lightning rod he is, and that's one of the reasons they separated themselves from 'Free Software'. Even Debian, which previously used to be very close to the FSF, recently joined the OSI. Given how RMS has slammed them (see above link) for including unliberated software to users who might be interested, who can blame them?