On 2013-10-28 18:33, Joakim wrote:

> I actually talked to the head llvm guy at Apple about this possibility a
> couple years back and he was adamantly against anyone outside closing up
> parts of the compiler.  Of course, he may not get to make that decision
> at Apple and we can't know the truth unless we peek at the source for
> the shipping compiler at Apple, but I haven't seen any evidence that
> llvm isn't developed in the open.
>
> Have you?

No, but LLVM shipped by Apple might not be the same LLVM you can access the source code to.

-- 
/Jacob Carlborg

On 2013-10-28 16:49, Joseph Rushton Wakeling wrote:

> Surely, but we should have sympathy for Apple's desire to be able to
> exert proprietary control over their products because ... ? :-)
>
> Don't get me wrong, LLVM itself is a fantastic project, and as long as
> people contribute great code to great free software projects I don't
> really mind what their motivation is, but if Apple's goal is to avoid
> the patent-related provisions of GPLv3, we could be in for a nasty
> surprise at some point in the future if compiler-related patents Apple
> holds become part of the battleground of the computing market.
>
> From a purely technical point of view, Apple doesn't need a compiler
> that supports a wide range of platforms, so GCC's much broader range of
> hardware support is irrelevant to it.  But it's an advantage GCC
> continues to have in the bigger picture.

From what I've heard and read (mostly from WWDC videos) Apple doesn't feel they can technically do what they want with a compiler with GCC.

I guess they technically can but it's too much work with the GCC code base.

-- 
/Jacob Carlborg

On 28/10/13 18:33, Joakim wrote:
> Do you have any evidence that they've exerted "proprietary control" over llvm,
> say by adding closed modules to their compiler?

I understand how you could interpret it that way, but my email didn't actually suggest that Apple had any plans to close-source the compiler.

My impression -- and I'm happy to be proven wrong -- is that Apple disliked the idea of a GPLv3-licensed compiler because its patent grants might have created problems for other parts of their software portfolio, which indeed _are_ proprietary.

> While I do not buy Apple products because of their odious patent stance, I
> highly doubt they would ever use such compiler patents, if they even have any.
> Microsoft has a patent on continually scanning a document for spelling errors
> and highlighting them (http://www.google.com/patents/US5787451), yet _as far as
> we know_ (and according to a former Microsoft employee -
> http://keithcu.com/wordpress/?page_id=1548), they've never asserted it on the
> dozens of applications with such spell-checking in their text editing controls,
> including this Chrome browser tab I'm currently typing into.

I think we've all seen enough software history to know that "highly unlikely" is not the same as "won't happen". :-)

> I agree that it is a problem that Apple doesn't do a patent grant for their open
> source projects, assuming they even have any compiler or other software patents
> on them, but I'm skeptical they'd ever enforce those anyway.  Also, IANAL, but I
> believe they'd never be able to extract any money from such a lawsuit anyway,
> since they don't make any money from clang or Safari and give them away for free.

I doubt they'd try to use their patents to extract money from anyone, but I could see them using them to put a competitor out of business.  If (say) Firefox OS or Ubuntu Touch become significant forces in the mobile/tablet market, I wouldn't put it past any of the traditional mobile players to pull out their patent portfolios to try and damage them.

On 28/10/13 18:48, Jacob Carlborg wrote:
>  From what I've heard and read (mostly from WWDC videos) Apple doesn't feel they
> can technically do what they want with a compiler with GCC.
>
> I guess they technically can but it's too much work with the GCC code base.

It certainly seems to be true that LLVM is moving faster innovation-wise.  I don't know how much of that is down to any architectural advantages, how much might be because they support less targets and so have a lower maintenance burden, and how much of it is just the scale of resources being put into it.

On 28 October 2013 18:38, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
> On 28/10/13 18:48, Jacob Carlborg wrote:
>>
>>  From what I've heard and read (mostly from WWDC videos) Apple doesn't
>> feel they
>> can technically do what they want with a compiler with GCC.
>>
>> I guess they technically can but it's too much work with the GCC code base.
>
>
> It certainly seems to be true that LLVM is moving faster innovation-wise.  I don't know how much of that is down to any architectural advantages, how much might be because they support less targets and so have a lower maintenance burden, and how much of it is just the scale of resources being put into it.
>

I don't see it that way.  Up until now at least I haven't seen anything they do that wasn't already do-able in GCC.  They just do a better job at PR (which is what you expect from Apple anyway).


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Monday, 28 October 2013 at 18:34:11 UTC, Joseph Rushton Wakeling wrote:
> On 28/10/13 18:33, Joakim wrote:
>> Do you have any evidence that they've exerted "proprietary control" over llvm,
>> say by adding closed modules to their compiler?
>
> I understand how you could interpret it that way, but my email didn't actually suggest that Apple had any plans to close-source the compiler.
No, I got it, I knew you said they'd be "able to exert proprietary control," not that they'd done it.  I was just wondering if you had evidence that they actually had done any of that already, since I don't follow llvm closely.

It is a valid concern, as Google has been closing up a bunch of their initially Apache-licensed Android apps:

http://arstechnica.com/gadgets/2013/10/googles-iron-grip-on-android-controlling-open-source-by-any-means-necessary/

But the source is still out there for the older versions, and these companies don't have any responsibility to keep giving their work away for free.

> My impression -- and I'm happy to be proven wrong -- is that Apple disliked the idea of a GPLv3-licensed compiler because its patent grants might have created problems for other parts of their software portfolio, which indeed _are_ proprietary.
Yeah, the GPLv3 is why Apple and FreeBSD stopped updating to the latest gcc after 4.2.1, which was the last GPLv2 release.  OS X 10.8 and iOS 6 were completely built by clang and FreeBSD 10, the next major release, is making clang the default compiler.  I don't know if it's because of patent grants or other aspects of GPLv3.

>> While I do not buy Apple products because of their odious patent stance, I
>> highly doubt they would ever use such compiler patents, if they even have any.
>> Microsoft has a patent on continually scanning a document for spelling errors
>> and highlighting them (http://www.google.com/patents/US5787451), yet _as far as
>> we know_ (and according to a former Microsoft employee -
>> http://keithcu.com/wordpress/?page_id=1548), they've never asserted it on the
>> dozens of applications with such spell-checking in their text editing controls,
>> including this Chrome browser tab I'm currently typing into.
>
> I think we've all seen enough software history to know that "highly unlikely" is not the same as "won't happen". :-)
Valid point.

>> I agree that it is a problem that Apple doesn't do a patent grant for their open
>> source projects, assuming they even have any compiler or other software patents
>> on them, but I'm skeptical they'd ever enforce those anyway.  Also, IANAL, but I
>> believe they'd never be able to extract any money from such a lawsuit anyway,
>> since they don't make any money from clang or Safari and give them away for free.
>
> I doubt they'd try to use their patents to extract money from anyone, but I could see them using them to put a competitor out of business.  If (say) Firefox OS or Ubuntu Touch become significant forces in the mobile/tablet market, I wouldn't put it past any of the traditional mobile players to pull out their patent portfolios to try and damage them.
How do they put them out of business if they don't get money out of them?  They could stop them from using that patented functionality, but you can usually design around such patents, unless they're overly broad, so it's a small hindrance, not really going to put you out of business.  Of course, "traditional mobile players" are a different issue, as they actually make money by selling the features they're patenting.

On Monday, 28 October 2013 at 17:45:39 UTC, Jacob Carlborg wrote:
> On 2013-10-28 18:33, Joakim wrote:
>
>> I actually talked to the head llvm guy at Apple about this possibility a
>> couple years back and he was adamantly against anyone outside closing up
>> parts of the compiler.  Of course, he may not get to make that decision
>> at Apple and we can't know the truth unless we peek at the source for
>> the shipping compiler at Apple, but I haven't seen any evidence that
>> llvm isn't developed in the open.
>>
>> Have you?
>
> No, but LLVM shipped by Apple might not be the same LLVM you can access the source code to.
Yep, that's why I mentioned that "we can't know the truth unless we peek at the source for the shipping compiler at Apple." :)

On Monday, 28 October 2013 at 19:02:35 UTC, Iain Buclaw wrote:
> On 28 October 2013 18:38, Joseph Rushton Wakeling
> <joseph.wakeling@webdrake.net> wrote:
>> It certainly seems to be true that LLVM is moving faster innovation-wise.  I
>> don't know how much of that is down to any architectural advantages, how
>> much might be because they support less targets and so have a lower
>> maintenance burden, and how much of it is just the scale of resources being
>> put into it.
>>
>
> I don't see it that way.  Up until now at least I haven't seen
> anything they do that wasn't already do-able in GCC.  They just do a
> better job at PR (which is what you expect from Apple anyway).
Really?  The claims that llvm has a cleaner codebase, is easier to use because it's all properly split up into different libraries, and introduces new features like better error reporting: that's all "PR?"

On 2013-10-28 19:33, Joseph Rushton Wakeling wrote:
> On 28/10/13 18:33, Joakim wrote:
>> Do you have any evidence that they've exerted "proprietary control"
>> over llvm,
>> say by adding closed modules to their compiler?
>
> I understand how you could interpret it that way, but my email didn't
> actually suggest that Apple had any plans to close-source the compiler.
>
> My impression -- and I'm happy to be proven wrong -- is that Apple
> disliked the idea of a GPLv3-licensed compiler because its patent grants
> might have created problems for other parts of their software portfolio,
> which indeed _are_ proprietary.

Apple uses libclang in Xcode, that is, the dynamic library. They can't do that with GCC from a license perspective?

-- 
/Jacob Carlborg

On 28 October 2013 20:22, Joakim <joakim@airpost.net> wrote:
> On Monday, 28 October 2013 at 19:02:35 UTC, Iain Buclaw wrote:
>>
>> On 28 October 2013 18:38, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
>>>
>>> It certainly seems to be true that LLVM is moving faster innovation-wise.
>>> I
>>> don't know how much of that is down to any architectural advantages, how
>>> much might be because they support less targets and so have a lower
>>> maintenance burden, and how much of it is just the scale of resources
>>> being
>>> put into it.
>>>
>>
>> I don't see it that way.  Up until now at least I haven't seen anything they do that wasn't already do-able in GCC.  They just do a better job at PR (which is what you expect from Apple anyway).
>
> Really?  The claims that llvm has a cleaner codebase, is easier to use because it's all properly split up into different libraries, and introduces new features like better error reporting: that's all "PR?"

GCC approach to libraries has not been to load them dynamically, take libiberty for example: http://gcc.gnu.org/onlinedocs/libiberty/Using.html#Using  - and the "better" error reporting was in gcc, just off by default (Clang added a little more with addition of ~~ tildas ~~).

>From what I've read and gathered from David over a period of some
conversations.  Clang infrastructure-wise is much like gcc-3.3/gcc-4.0 was - they have a well defined AST that is capable of representing everything you'd expect in a typical C-family language, with a backdoor to lower level register/assembly representations for target-specific implementations. The direction that GCC went in later versions was closing the backdoor and moving backend-specific code in various frontends to the middle end.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Monday, 28 October 2013 at 19:02:35 UTC, Iain Buclaw wrote:
> I don't see it that way.  Up until now at least I haven't seen
> anything they do that wasn't already do-able in GCC.

Have you looked at the quality of error messages in Clang or its explicitly designed tooling/IDE integration API?

The way I see it is that LLVM and Clang have certainly enriched the playing field, also pushing GCC forward in the process (and it is still in the lead in some areas – e.g. OpenMP, where even though Intel recently donated their code to LLVM, Clang still isn't quite there). You make it sound like GCC already did everything before that Clang/LLVM do now, and that's certainly not the case. ;)

David

On 2013-10-28 20:02, Iain Buclaw wrote:

> I don't see it that way.  Up until now at least I haven't seen
> anything they do that wasn't already do-able in GCC.  They just do a
> better job at PR (which is what you expect from Apple anyway).

I didn't say it wasn't doable. I can't say for sure since I haven't looked at the GCC code base and only looked briefly at the LLVM code base. But according to Apple it would be too much work to implement the features they wanted.

Also, Apple uses libclang in Xcode, that is, the dynamic library. They can't do that with GCC from a license perspective?

-- 
/Jacob Carlborg