Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clang and FSF's strategy

gcc.gnu.org

Post reply on HN
Print view View original

131–140 of 143 posts

Re: Clang and FSF's strategy

#131

Post by anon1385 »

lazyjones wrote: post #128
anon1385 wrote: post #93

Earlier quoted context omitted.

It's not a conspiracy theory. Could you point to the 'debunking' because I don't see one that contains any actual evidence?. There are lots and lots of public mailing list posts by RMS and other GCC engineers explaining their reasoning for not making GCC more modular. The reasons were political. For example RMS vetoed the first attempts to add support for Java bytecode to GCC because he thought it would allow people…

Are posts from 2001 and 2007 really relevant for this discussion? Look at this for example: http://gcc.gnu.org/ml/gcc/2014-01/msg00182.html The "debunking" in this thread was the confirmation that plugins actually work now because the policies were relaxed in favor of them.

The Stallman post about LLVM being bad because it allows people to use it to build other tools was from 2012. Why did you ignore that?

Plugins are only part of the story. Without stable intermedia representations there is still no GCC equivalent to libtooling or LLVM IR. That is by design, and remains true.

No conspiracy theory. Just an ugly truth that some people want to deny.

Re: Clang and FSF's strategy

#132

Post by fafner »

protomyth wrote: post #130
fafner wrote: post #129

Earlier quoted context omitted.

They have to honour the license. Which provides and guarantees basic freedoms. But it allows the code to be reused in any project honouring the license. So your initial statement is false.

Nope, my basic statement is true. You didn't answer the question and by "code" you don't just mean the GPL code. The GPL tries to affect all code in the project not just the GPLed code.

Your basic statement is false: "GCC's parts cannot be included in other projects". That's simply a lie.

> You didn't answer the question

Because it's completely irrelevant.

Re: Clang and FSF's strategy

#133

Post by anon1385 »

teddyh wrote: post #115
anon1385 wrote: post #74

Earlier quoted context omitted.

Apple is not the largest contributor to LLVM, Google is. The various other non-Apple contributors also outweigh Apple. It would be hugely expensive for Apple to hire all those compiler developers from Google and Intel and dozens of other companies. Why would they do it? What would it gain them other than to be comically villainous. The reality is that GCC is stagnating because a lot of things people want to do are ju…

So substitute “Apple” with “Google, Apple, Intel, etc.” in my original dystopic vision. Should we trust them? The technical problems with GCC’s unstable plugin API can be fixed, and is, from what I understand, not something put there intentionally.

Substitute with FSF and GCC and same paranoid arguments apply. I don't have any reason to trust the FSF any more that those other organisations. At least when it comes to corporations they are just working to make money and I can reason about and predict their actions based on that. With political organisations like the FSF they are often quite prepared to shoot themselves in the foot or destroy the entire project just for ideological reasons. An "if it can't be just how we want it then nobody can have it" attitude.

Back in reality none of these projects are going anywhere. GNU zealots have spend the last 2 decades warning that BSD style licences would result in people making closed forks of things leading to the original open version dying. But it has hardly ever happened.

Instead of propagating paranoid conspiracies you should just accept the truth which is that BSD style licences have proven to be the most effective at getting people to contribute to open software.

Re: Clang and FSF's strategy

#134

Post by protomyth »

fafner wrote: post #132
protomyth wrote: post #130

Earlier quoted context omitted.

Nope, my basic statement is true. You didn't answer the question and by "code" you don't just mean the GPL code. The GPL tries to affect all code in the project not just the GPLed code.

Your basic statement is false: "GCC's parts cannot be included in other projects". That's simply a lie. > You didn't answer the question Because it's completely irrelevant.

They cannot be included because they take over everything else. It is not a lie and the questions I have asked backed that up. GPL imposes things on code that is not GPL.

Re: Clang and FSF's strategy

#135

Post by fafner »

protomyth wrote: post #134
fafner wrote: post #132

Earlier quoted context omitted.

Your basic statement is false: "GCC's parts cannot be included in other projects". That's simply a lie. > You didn't answer the question Because it's completely irrelevant.

They cannot be included because they take over everything else. It is not a lie and the questions I have asked backed that up. GPL imposes things on code that is not GPL.

They can be included in any project that can honour the GPL. Therefore it is a lie.

Re: Clang and FSF's strategy

#136

Post by protomyth »

fafner wrote: post #135
protomyth wrote: post #134

Earlier quoted context omitted.

They cannot be included because they take over everything else. It is not a lie and the questions I have asked backed that up. GPL imposes things on code that is not GPL.

They can be included in any project that can honour the GPL. Therefore it is a lie.

"They can be included in any project that can honour the GPL."

So, no and not a lie. Why should any license dictate what happens to code that was not written by the authors of that code? Why should I pay more honor to GPL code than any other? So, no, much like a relative that drinks all the beer when visiting, the GPL cannot be included except in limited circumstances.

Re: Clang and FSF's strategy

#137

Post by fafner »

protomyth wrote: post #136
fafner wrote: post #135

Earlier quoted context omitted.

They can be included in any project that can honour the GPL. Therefore it is a lie.

"They can be included in any project that can honour the GPL." So, no and not a lie. Why should any license dictate what happens to code that was not written by the authors of that code? Why should I pay more honor to GPL code than any other? So, no, much like a relative that drinks all the beer when visiting, the GPL cannot be included except in limited circumstances.

> So, no

So, yes. You are simply talking bullshit because of some irrational GPL hate. If you cannot honour the license of a piece of software then you can't use it. Doesn't matter if it's free software like GCC or some commercial library you paid a shitload of money for. Stop being dishonest and irrational.

Re: Clang and FSF's strategy

#138

Post by protomyth »

fafner wrote: post #137
protomyth wrote: post #136

Earlier quoted context omitted.

"They can be included in any project that can honour the GPL." So, no and not a lie. Why should any license dictate what happens to code that was not written by the authors of that code? Why should I pay more honor to GPL code than any other? So, no, much like a relative that drinks all the beer when visiting, the GPL cannot be included except in limited circumstances.

> So, no So, yes. You are simply talking bullshit because of some irrational GPL hate. If you cannot honour the license of a piece of software then you can't use it. Doesn't matter if it's free software like GCC or some commercial library you paid a shitload of money for. Stop being dishonest and irrational.

Last time, I have no problem honoring a license on code written by others EXCEPT when the license presumes to tell other developers that they must do something with code they wrote in separate and not patches made to the original code. This is not irrational or bull. This presumption that the GPL code should impose itself on other code to force it all to be GPL is impolite at best.

I have no hate for the GPL. It is a license for a community that loves it, but saying GPL code can be freely included in other works is a very strange definition of free. It is also poor for teaching as it brings a burden on the future works of students if they directly use the taught code directly. It is a license that should be evaluated like any other, but it imposes burdens on more than the source written under it.

Re: Clang and FSF's strategy

#139

Post by oso2k »

belorn wrote: post #124
oso2k wrote: post #86

Earlier quoted context omitted.

For one, ESR isn't asking that the FSF change (directly). He's asking that FSF change with respect to GCC and the audience it serves. There's many developers, and especially young developers, that feel the GPL & FSF are "over-principled". I think we can all agree that "Open Source" has largely won. But if you ask about "Free Software," and take github as data point, I'd say "Free Software" is losing, and is losing be…

The data made over repositories like Google code, debian and similar places where entries has some form of minimum standard, GPL licenses are a strong majority, and is increasingly used. So young people are either not serious enough to warrant inclusion in the 40 000 list of programs in Debian (doubtful), or your assumptions are incorrect. > To place restrictions on my gift is to have given the world a poison and not…

I'm a Google Code user myself. I prefer it (and inDefero) over the likes of bitbucket, github, savannah, berlios, etc. But that doesn't make github any less popular. I don't understand the analogy you're trying to make by bringing in the debian repositories into the discussion. It seems to me like you're saying making friends on Friendster are more legitimate than friends made on Facebook because it was an initial innovator in the social network. Here's a 2013 that states github has 50% more projects then the next repository (sourceforge)[1]. Here's a 2011 that discusses when github turned 1 million accounts [2].

My argument is that many young developers don't care where they get their code, what license it has, etc. They just want to build, create, collaborate [3]. A secondary argument is that many people feel the GPL is a barrier to collaboration.

When it comes to gifts and beer, I would hope my friend wouldn't hit me with it nor would I put poison in his beer. They're (implicitly) allowed to hit me with it, but I don't expect such a thing to occur. Nor should they expect me to put poison in it. That's all a matter of trust. And the GPL, proprietary licenses, DRM are instruments of distrust.

In the end, you always have choice. I choose to live by the philosophies that "Givers Gain" and people do want to be good people. I understand not everyone has as altruistic intentions, heck, I work for those people. But I also understand that if I want to see the world change, I need to start by changing myself.

[1] http://software.ac.uk/resources/guides/choosing-repository-y...

[2] http://www.theinquirer.net/inquirer/news/2076108/github-domi...

[3] http://developers.slashdot.org/story/13/07/16/0220240/github...

Re: Clang and FSF's strategy

#140

Post by fafner »

protomyth wrote: post #138
fafner wrote: post #137

Earlier quoted context omitted.

> So, no So, yes. You are simply talking bullshit because of some irrational GPL hate. If you cannot honour the license of a piece of software then you can't use it. Doesn't matter if it's free software like GCC or some commercial library you paid a shitload of money for. Stop being dishonest and irrational.

Last time, I have no problem honoring a license on code written by others EXCEPT when the license presumes to tell other developers that they must do something with code they wrote in separate and not patches made to the original code. This is not irrational or bull . This presumption that the GPL code should impose itself on other code to force it all to be GPL is impolite at best. I have no hate for the GPL. It is…

So you admit you were lying.
Post reply on HN