Stallman on GCC, LLVM, and copyleft
During a discussion on the GCC mailing list about the comparative
performance of GCC versus Clang, Richard Stallman weighed
in to argue that LLVM's permissive license makes it a
"terrible setback
" for the free software community, because
contributions to it benefit proprietary compilers as well as free
ones. The original topic was Eric S. Raymond's suggestion that GCC
should allow non-free plugins—an idea which, unsurprisingly,
Stallman does not find appealing. "To make GCC available for such use would be
throwing in the towel. If that enables GCC to 'win', the victory
would be hollow, because it would not be a victory for what really
matters: users' freedom.
"
Posted Jan 24, 2014 23:32 UTC (Fri)
by heijo (guest, #88363)
[Link] (16 responses)
Adding support for non-free plugins or changing GCC's license won't change that fact and won't make it much more attractive.
Hence, Eric Raymond's goals (make GCC popular for plugin writers) are unachievable.
On the other hand, Stallman's goals (having the best compiler technology be foverer a copylefted one) is perhaps achievable by having the GCC developers abandon GCC, switch to working on a fork of LLVM/Clang relicensed to GPLv3 with continuous merging of Apple's work, and make that fork far superior to Apple's version.
Posted Jan 24, 2014 23:51 UTC (Fri)
by coriordan (guest, #7544)
[Link]
One recent enough change is that GCC is now compiled with g++ instead of gcc. They won't be using all the features of C++, but they're using some.
Regarding plugins:
> There are people working right now on improvements to modularity in GCC,
source: https://lists.gnu.org/archive/html/emacs-devel/2014-01/ms...
Posted Jan 25, 2014 0:22 UTC (Sat)
by Vile_Coffee (guest, #93511)
[Link] (14 responses)
Yeah, not allowed by copyright law. They aren't the authors, so they could only GPL code they wrote.
Posted Jan 25, 2014 0:42 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (3 responses)
If GCC is modular, it makes it much easier to write plugins that are not, in law, derivative works. And again, for Free Software folks, that is highly undesirable.
Cheers,
Posted Jan 25, 2014 9:21 UTC (Sat)
by coriordan (guest, #7544)
[Link] (2 responses)
This interaction-interface could of course be removed, but then the plugin maintainer has to maintain a forked version of GCC.
Modularisation carries risks alright, but RMS is being cautious.
Posted Jan 25, 2014 22:39 UTC (Sat)
by nybble41 (subscriber, #55106)
[Link] (1 responses)
Even if a plugin is obviously designed to "work with" GCC, that doesn't mean that it's derived from the GCC codebase. Derivative works are about copying or transforming other copyrighted works, not compatibility. Otherwise e.g. every program capable of running on Windows or iOS or Linux would be a derivative work of the target OS.
Copyright in general is also supposed to be about expression, not functionality. The courts have not looked favorably in the past on attempts to abuse copyright to prevent interoperability (e.g. copyrighted firmware in inkjet cartridges to prevent compatible third-party replacements).
The only real question would be whether you could distribute the plugin together with GCC, or if the combination of the two on the same media ("mere aggregation") would be considered a derivative work. In the worst case, that's simple to work around--just distribute them separately.
Posted Jan 26, 2014 14:30 UTC (Sun)
by coriordan (guest, #7544)
[Link]
Correct. That's why I didn't say that. I said GCC's plugin interface can require intimate communication, such as sharing of data structures. After a certain point (for which there's unfortunately no clear line), a judge will decide that the new code is an extension of the existing GCC code rather than being a separate work which simply interacts with GCC.
> The only real question would be whether you could distribute
No. The relationship between two works depends on things that happen when the second work was being written, not what happens at the moment of distribution.
Posted Jan 25, 2014 1:16 UTC (Sat)
by rahvin (guest, #16953)
[Link] (2 responses)
This would be no different than a proprietary company adding proprietary code to the codebase and taking the result closed source.
Posted Jan 25, 2014 13:37 UTC (Sat)
by notofyourconcern (guest, #95197)
[Link] (1 responses)
http://en.wikipedia.org/wiki/University_of_Illinois/NCSA_...
Posted Jan 25, 2014 14:25 UTC (Sat)
by pboddie (guest, #50784)
[Link]
(It's true that the original bits in isolation would be considered as having that permissive licence - indeed, such licensing information would need to be retained in any modified work - but since that licence is GPL-compatible, the new code could be combined with the old code without making the result ineligible for distribution.)
Posted Jan 26, 2014 21:26 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (6 responses)
> Yeah, not allowed by copyright law. They aren't the authors, so they could only GPL code they wrote.
The LLVM license explicitly includes the right to sub-license. It took me 2 minutes to find it and read it.
Here is a challenge for you: design a (fictitious) license which lets proprietary software use LLVM in pretty much any way they want, yet prevents GPL software from doing the same.
Of course tricks like licensing to everyone except Richard Stallman are not allowed :-) the license must be fair because generic.
Posted Jan 26, 2014 21:33 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (3 responses)
Add a clause that prevents that right to sub-licence from being taken away.
Because the GPL explicitly eschews sub-licencing ...
Cheers,
Posted Jan 26, 2014 23:08 UTC (Sun)
by xtifr (guest, #143)
[Link] (2 responses)
And that allows the proprietary versions how?... (I've never seen any proprietary software that freely allows sublicensing. If it's not an actual contradiction in terms, it's surely the next best thing.)
Making a permissive license that's incompatible with the GPL is easy. Making one that allows all the other stuff the BSD license allows at the same time (which is what was requested)—not so easy.
Posted Jan 27, 2014 20:35 UTC (Mon)
by ewen (subscriber, #4772)
[Link] (1 responses)
Ewen
Posted Jan 28, 2014 2:01 UTC (Tue)
by xtifr (guest, #143)
[Link]
Posted Jan 27, 2014 14:17 UTC (Mon)
by james (subscriber, #1325)
[Link]
Posted Jan 28, 2014 13:28 UTC (Tue)
by clopez (guest, #66009)
[Link]
Easy: The OpenSSL License
Posted Jan 24, 2014 23:35 UTC (Fri)
by boklm (guest, #34568)
[Link] (3 responses)
Oh, so for Stallman, anybody who does some non free code is an adversary.
Posted Jan 24, 2014 23:41 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Jan 25, 2014 11:04 UTC (Sat)
by zyga (subscriber, #81533)
[Link]
Posted Jan 25, 2014 13:47 UTC (Sat)
by sebas (guest, #51660)
[Link]
I know, Stallman-bashing is a popular sport, but let's keep ourselves to higher standards over here.
Posted Jan 24, 2014 23:59 UTC (Fri)
by landley (guest, #6789)
[Link] (8 responses)
Posted Jan 28, 2014 23:00 UTC (Tue)
by Del- (guest, #72641)
[Link] (7 responses)
I totally agree that having GPLv2 and v3 incompatible is incredibly stupid, so if there ever is a GPLv4, I hope it fixes it. Since practically all GPLv3 projects has the +, it is hopefully even doable. It seems that the anti-Tivo part is the only contentious part. I believe it serves an important purpose, but agree that it is not a critical part of GPL, so it could even be removed.
With regards to the patent clause, it seems you don't even see the value in that. I find that surprising. In today's landscape it seems everybody with knowledge is turning their backs against the BSD license due to patent concerns, with the possible exception of the patent trolls. I consider both Apple and Sony to belong to that category. For the rest of us, we want whatever protection we can get from patents.
You mentioned Cisco not touching linux after their ordeal with FSF. I am having trouble confirming your account of the events, so any clarification is welcome. It seems to me that FSF went after Cisco over Broadcom in 2003 (see e.g., http://slashdot.org/story/03/10/14/1317251/the-fsf-linuxs... ) about the time when the Linksys code release came about and OpenWrt started (ref. http://en.wikipedia.org/wiki/Openwrt#History ). Moreover, Cisco embraced linux for their Linksys devices until they quite recently gave up the consumer market. I am not able to see how this is compatible with your statement that they went over to Windows and/or OSX/IOS? This was also well before GPLv3 I believe, so does this mean you came to the conclusion that GPLv2 also was bad in the long run?
With respect to Broadcom, they did finally cave in and opened up their driver development. Today all wireless vendors seem to try to make decent linux drivers. Do you honestly think we would come to that point if it was all public domain and BSD licensed? I can at least talk for myself. Without copy-left I would not have spent my countless hours over OpenWrt. The fact that the OpenWrt web-interface is permissively licensed was enough to push me away from contributing. I know many of us feel that way, so without copy-left many of us would simply not contribute. The stories you tell about people taking one year off without pay to get a file system into linux, do you believe permissively licensed projects will ignite that amount of devotion even close to what we see for copy-left projects? You have worked on linux for quite some time, do you have the impression that copy-left is an important aspect for many developers?
Personally, I would love to see a world where permissive licensing would thrive on its own and provide us with competitive alternatives. Unfortunately I don't think humans are even close to make that happen yet. There are some signs of course, with larger corporations realising that they can achieve more together, and are willing to do it under a permissive licenses. However, only on predominantly copy-left platforms are we able to compete, where servers today is the prime example. With Android I am incredibly disappointed how little open development it has spurred. Sure the apps are coming, but not from Google. If any , Google is going the other direction with closing stuff up. I haven't seen any of the vendors open up any of their GUI stuff. If anything I believe the last decade showed us that copy-left is very much needed for the next decade. I am incredibly grateful for all the people who ensured that we can have open platforms from A to Z. Apple and Sony has only showed us how to prevent it as far as I am concerned. You may be content with the low level bits being open, but I have a hard time seeing even that happen without copy-left.
Posted Jan 29, 2014 5:01 UTC (Wed)
by khim (subscriber, #9252)
[Link] (6 responses)
It's funny that you can not even get your facts straight when eveyrhing was already discussed on LWN. FSF went after CISCO in 2008 and GPLv3 was published in 2007 (year before). I don't know why you are bringing up totally irrelevant bits and pieces. You are king of right on one point: overzealous GPL enforcement and GPLv3 are independent developments although they bost severely made GPL “damaged goods”, but then Landley never claimed that they are directly related. They are only [correctly] related in minds of corporations via the fact that FSF is behind both. This made FSF-governed packages problematic at first and then later it made GPL as whole spurned by corporations.
Posted Jan 29, 2014 6:47 UTC (Wed)
by Del- (guest, #72641)
[Link] (5 responses)
Thanks, that was what I wanted to know. No, even I don't read and remember everything from six years back, sorry. In any case, that still leaves the need for an explanation as to Cisco moving away from linux. I believe Cisco even after that used the fact that Linksys devices came with linux in their marketing. Moreover, I believe that places the event closer in time to when Broadcom finally started contributing drivers to linux (no, I don't bother checking dates now, I am a bit tired of it).
> You are king of right on one point: overzealous GPL enforcement and GPLv3 are independent developments
Well thank you, never thought I would see a concession in this thread. Indeed, Rob himself demonstrated very clearly that overzealous GPL enforcement was possible with GPLv2, so it is not clear to me that v3 changed everything.
That brings me to another issue from the talk. Rob, you mentioned Apple going away from GPL over version 3. From what I have seen this not correct. The Webkit story is quite telling, and shows a clear tale that Apple tried to circumvent copy-left years before, actually dating back to 2001. Moreover, from reading the mailing list posts surrounding LLVM, I can only conclude that Chris Lattner failed in acquiring copyright transfer agreements from LLVM to FSF, and that was before version 3 came about. Chris should be able to confirm or defuse it though. In any case, Apple was never a friend of copy-left AFAIK, and I believe they would have gone for a permissively licensed solution sooner or later anyway. Their App Store is quite telling in that respect.
My main grievance today is that Apple and Microsoft is so successful in creaing schisms in the open community.
Posted Jan 29, 2014 9:33 UTC (Wed)
by khim (subscriber, #9252)
[Link] (4 responses)
Posted Jan 29, 2014 12:06 UTC (Wed)
by Del- (guest, #72641)
[Link] (3 responses)
This is where we see the historic events differently I believe. I don't think Apple ever accepted GPLv2, or any other copy-left license. I believe it was only a matter of time before they moved over to alternatives. Moreover, I believe they would get rid of bash, WebCore and JavaScriptCore in a heartbeat if something like LLVM surfaced for it, or if the license creates an inconvenience of any sort. I have provided examples supporting that view, but you are of course free to reach another conclusion.
In any case, why does Apple's opinions weigh in on what restrictions we should put on licenses? When it became clear that Apple refuse GPL altogether from their app store, I took it as a clear sign. A signal that Apple no longer needs us, and now wants to get rid of us. If any , this has just reinforced my belief in the importance of copy-left. Remember Cicero and his "cui bono". These things matter, at least to me.
Posted Jan 30, 2014 0:04 UTC (Thu)
by landley (guest, #6789)
[Link] (2 responses)
Apple built MacOS X with gcc, and shipped gcc as the system's compiler, for most of a decade, through gcc version 4.2.1. Version 4.2.2 was the first one containing GPLv3 code, and Apple did not ship that version (or later versions) but instead remained on gcc 4.2 for the next 5 years, while sponsoring development of a replacement until said replacement could take over:
http://caiustheory.com/install-gcc-421-apple-build-56663-...
But feel free to see these historic events differently.
Rob
Posted Jan 30, 2014 0:23 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Jan 30, 2014 11:11 UTC (Thu)
by Del- (guest, #72641)
[Link]
I have tried to dig into the events surrounding GCC and LLVM to understand what went on, and the most I have found is Chris Lattner's posts on the GCC mailing list. Chris is still active on said mailing list, so he may or may not be able to confirm or correct my perception.
First up two mails proposing LLVM as an optimizer for GCC:
In any case, it is very easy to agree that Apple strongly dislikes the GPLv3 on general grounds. Both the patent part (they don't seem very fond of any license providing any sort of patent protection, copy-left or not) and the anti-Tivotization part.
Still, following the webkit story evolving from 2001, ending up with only minimal parts having the original LGPL license, the rest having a BSD license. Moreover, the BSD parts opened up a full four years later. To me at least, it seems quite clear that Apple did not like copy-left long before GPLv3 came about (and quite frankly I cannot see how anybody reach another conclusion). This also leads me to the conclusion that they may very well have made their own compiler out of LLVM regardless of GPLv3. The fact that they stopped contributing after GCC 4.2 seems clearly related to v3, but they may very well have stopped at 4.5 or something if v3 never came about. Actually, with the kind of resources that came into Apple's hands during the last decade, my only surprise was that they continued contributing under copy-left as long as they did.
I understand that there is a lot of emotions around this issue, so it quickly becomes personal, at least for some. For me it is actually a reality I need to figure out. Licensing matters if you want successful projects, where I believe Linus made the prime example of (yes I know some argue that copy-left had little to do with it, but I have now idea how one can reach such a conclusion).
I feel that I have come more or less to the bottom of the patent clause in GPLv3, and it really puts a rather strange light on many of the discussions. I think it is very helpful to think through the "cui bono" on that.
On the tivotization clause, the most interesting information I have found is actually from Upstart's mailing list. Upstart was licensed to GPLv3 in June 2009, and it made a lot of stuff crawl out of the wood work. Here is a reference: https://lists.ubuntu.com/archives/upstart-devel/2009-June...
Posted Jan 25, 2014 0:04 UTC (Sat)
by jgg (subscriber, #55211)
[Link] (10 responses)
The add on tools like clang format and the modernizer are useful and very much unique.
Sadly it provides the missing element to give Emacs the sort of incredible code-context-sensitive 'tags' and other features that things like XCode and Visual Studio have had for years. The sort that is only possible if you strongly couple Emacs and clang's libraries. I guess based on these comments that will never happen :(
Unfortunately I think the main thing that has kept gcc going for so long was that it was the compiler code base of choice (out of necessity, not sanity) for research level compiler projects. It is hard to see how that would be true going forward when clang/llvm is so much more accessible to that community.
Posted Jan 25, 2014 7:36 UTC (Sat)
by patrick_g (subscriber, #44470)
[Link] (3 responses)
Performances.
Posted Jan 25, 2014 17:34 UTC (Sat)
by duvelb (guest, #95199)
[Link]
Posted Jan 27, 2014 3:51 UTC (Mon)
by jgg (subscriber, #55211)
[Link] (1 responses)
The reality is that they are close enough now that many users won't care or notice.
Posted Jan 20, 2015 12:28 UTC (Tue)
by pbonzini (subscriber, #60935)
[Link]
Posted Jan 25, 2014 9:37 UTC (Sat)
by coriordan (guest, #7544)
[Link]
The licence.
> give Emacs the sort of incredible code-context-sensitive 'tags' and other features
There's some discussion on emacs-devel about how to get this through GCC. It might be a lot of work.
Posted Jan 25, 2014 12:09 UTC (Sat)
by suy (guest, #81959)
[Link] (3 responses)
I am quite surprised of reading that Emacs doesn't have such support, since even Vim, with it's bad support for asynchronous task (only through complex hacks) has several plugins that interact with clang or libclang to provide completion and more.
Posted Jan 25, 2014 23:49 UTC (Sat)
by deepfire (guest, #26138)
[Link] (2 responses)
Posted Jan 26, 2014 14:22 UTC (Sun)
by jwakely (subscriber, #60262)
[Link]
Posted Jan 27, 2014 3:57 UTC (Mon)
by jgg (subscriber, #55211)
[Link]
Nobody will work on the core support if there is no supportable back end module :(
Posted Jan 25, 2014 12:15 UTC (Sat)
by ballombe (subscriber, #9523)
[Link]
Posted Jan 25, 2014 0:22 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (25 responses)
And proprietary compilers based on LLVM are pretty much a scary fairy tale. There might be a few, but the major players are more than happy to collaborate.
Posted Jan 25, 2014 0:36 UTC (Sat)
by wahern (subscriber, #37304)
[Link] (9 responses)
WebKit is a perfect example of how things might work out. Companies will collaborate until they get tired of the power plays. Then they'll fork and that'll be the end of the grand bargain.
For all the headaches the GPL causes, it puts every player on an equal footing. You can't just fork and walk away, because you can't fool yourself with walled garden fantasies. That's a significant long-term advantage of a copy-left ecosystem.
I don't know where LLVM will be in 10 years, but I'm very confident about where GCC will be--modern and open.
But I have less invested in these things because I value portability and not being locked into a relationship with a single vendor--be it LLVM, GCC, Linux, systemd, etc.
Posted Jan 25, 2014 0:39 UTC (Sat)
by wahern (subscriber, #37304)
[Link] (1 responses)
I still there's a good chance LLVM will end up the same, but not strictly because it lacks copy-left.
Posted Jan 25, 2014 8:35 UTC (Sat)
by tcrever (guest, #69157)
[Link]
Posted Jan 25, 2014 1:15 UTC (Sat)
by silvas (guest, #87887)
[Link] (4 responses)
Google, Intel, Qualcomm, Sony, NVidia, ARM, AMD, MIPS, to name a few that have multiple full-time developers contributing to LLVM/Clang. I would be surprised if Apple was even 1/3 of the development lately.
Posted Jan 25, 2014 15:33 UTC (Sat)
by Del- (guest, #72641)
[Link] (1 responses)
Posted Jan 25, 2014 22:08 UTC (Sat)
by jwakely (subscriber, #60262)
[Link]
They've implemented loads of C++ front-end support, especially C++11 and C++14 features, and the tsan/asan/ubsan etc. libraries (which are also supported by GCC) and probably tons more I'm not aware of. I think they rely on clang for loads of internal projects, so we'll never know most of what they use it for.
Posted Jan 26, 2014 13:49 UTC (Sun)
by RamJam (guest, #95209)
[Link] (1 responses)
Posted Jan 27, 2014 22:09 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Posted Jan 25, 2014 15:43 UTC (Sat)
by fw (subscriber, #26023)
[Link] (1 responses)
Posted Jan 25, 2014 18:36 UTC (Sat)
by bconoboy (guest, #80928)
[Link]
Posted Jan 25, 2014 1:11 UTC (Sat)
by pizza (subscriber, #46)
[Link] (14 responses)
Actually, you're quite wrong there; Nvidia and ATI/AMD (and likely everyone else at this point) both use LLVM in their drivers to compile things like OpenCL and OpenGL shaders -- and those frontend parsers and backend code generators are as proprietary as it gets.
In other words, proprietary compilers based on LLVM have been around for some time now.
Posted Jan 25, 2014 12:53 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (13 responses)
Posted Jan 25, 2014 13:52 UTC (Sat)
by robert_s (subscriber, #42402)
[Link] (12 responses)
http://www.llvm.org/Users.html suggests it's used for their OpenCL implementation (but not CUDA possibly?)
Posted Jan 25, 2014 14:20 UTC (Sat)
by Trelane (subscriber, #56877)
[Link] (1 responses)
Posted Jan 26, 2014 3:52 UTC (Sun)
by Trelane (subscriber, #56877)
[Link]
I *think* nvcc (like mpicc) before this wrapped gcc, but I don't know for certain.
Posted Jan 25, 2014 14:23 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (9 responses)
So I stand by my assertion that closed-source compilers are simply a non-issue. They are either pointless or of little interest. Usually both.
Posted Jan 25, 2014 15:49 UTC (Sat)
by deepfire (guest, #26138)
[Link] (8 responses)
Posted Jan 25, 2014 17:22 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (7 responses)
Posted Jan 25, 2014 23:52 UTC (Sat)
by deepfire (guest, #26138)
[Link] (3 responses)
Posted Jan 26, 2014 12:59 UTC (Sun)
by deepfire (guest, #26138)
[Link] (2 responses)
Which makes me think -- wouldn't _exactly_ same be possible to do with GCC - today?
Can't think of anything to stop it.
Posted Jan 26, 2014 20:49 UTC (Sun)
by stevenb (guest, #11536)
[Link] (1 responses)
More information:
Posted Jan 26, 2014 20:59 UTC (Sun)
by deepfire (guest, #26138)
[Link]
What's the remaining practical difference between restrictions that GCC and LLVM put on extensions then?
Heck, what's the fuss all about?
Posted Jan 26, 2014 11:39 UTC (Sun)
by robert_s (subscriber, #42402)
[Link] (2 responses)
Exactly - not usable without nonfree software.
Posted Jan 26, 2014 22:26 UTC (Sun)
by renox (guest, #23785)
[Link] (1 responses)
Given that some CPUs are also not usable without non free software (microcode)
Posted Jan 27, 2014 18:39 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Jan 25, 2014 0:23 UTC (Sat)
by JoeBuck (subscriber, #2330)
[Link] (38 responses)
Some gcc developers agree with RMS's vision, others don't. Some sit more on the "free software" side of the argument, others on the "open source" side. This doesn't impede their ability to work together, especially since RMS isn't involved in GCC development and hasn't been for a long time. Outsiders launching software-ideology flame wars based on bad or outdated information (like comparisons between llvm and gcc error messages that use gcc 4.2, seven major releases ago) aren't helping. Neither does cross-posting between development lists of competing compilers to get their developers to argue with each other.
The competition between llvm and gcc has greatly improved both compilers. It's a good thing, I think. But any comparisons made between the two should be accurate and current.
Posted Jan 25, 2014 0:51 UTC (Sat)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
http://gcc.gnu.org/wiki/ClangDiagnosticsComparison
However, there are still many places where GCC could be more helpful. A trivial one I filed a few days back just as an example:
Posted Jan 25, 2014 20:29 UTC (Sat)
by pbonzini (subscriber, #60935)
[Link]
Posted Jan 25, 2014 9:42 UTC (Sat)
by coriordan (guest, #7544)
[Link] (34 responses)
Only if GCC wins.
Posted Jan 25, 2014 14:06 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (33 responses)
Only if NEITHER wins!
And also, its world view will prevail, which is a bad thing - the loss of diversity in views is not a good thing. I gather CLang takes a very different view of how things should be done, which is refreshing, and while not all those views may be right, they're unlikely all to be wrong.
Cheers,
Posted Jan 25, 2014 22:03 UTC (Sat)
by coriordan (guest, #7544)
[Link] (32 responses)
Nonsense. GCC made massive progress for decades before LLVM arrived.
While it's true that LLVM has incited the GCC developers to make extra progress in certain areas, it is also leading companies to hire developers to work on LLVM when they probably would have hired them to work on GCC, and some developers with interesting ideas are trying them out in LLVM instead of GCC.
So GCC, which gives an advantage to free software, has fewer developers, and all the effort put into LLVM ends up helping proprietary software as much as it helps free software.
If you're primary interest is technical progress in compilers, then fair enough, the competition is only a good thing. But if, like me, your primary interest is for free software to improve, and to displace proprietary software, then we need GCC to win (or at least always be in the lead).
Posted Jan 25, 2014 22:16 UTC (Sat)
by rahulsundaram (subscriber, #21946)
[Link] (13 responses)
https://www.youtube.com/watch?v=NURiiQatBXA
It appears Google wanted to improve GCC to make it work better with IDE's and other tooling and the technical decisions done to preserve the goals of GCC licensing ending up pushing them towards Clang. A more modular GCC would probably have kept them in the GCC world and it was technically always a better choice. It appears GCC is moving towards that goal now anyway.
When GCC was the really the only player in town, they could push vendors to play by their rules but when there is a competition with Clang, they have to focus on the technical aspect more since the licensing gambit may not work as well as before.
Posted Jan 26, 2014 17:00 UTC (Sun)
by coriordan (guest, #7544)
[Link] (7 responses)
There were many ways to do what they wanted, without donating their code to proprietary compilers. But Google didn't care enough about that.
(I don't understand why so many people ignore all the choices of third-parties and instantly jump to the accusation that RMS should be doing more for them.)
Posted Jan 26, 2014 17:07 UTC (Sun)
by rahulsundaram (subscriber, #21946)
[Link] (6 responses)
I find it somewhat disturbing that you characterize any code contributions to a permissively licensed project as "donating" to proprietary compilers. I don't think Google is concerned about proprietary compilers and you shouldn't expect them to do that. They will work with projects they find easier to work with and in this case, it was LLVM.
GCC could have been made more modular if not for the fact that RMS didn't want it to be more modular because he was concerned about the impact of licensing. Nobody is asking RMS to do more. They were asking RMS not to get in the way of technical decisions that was better for the project. RMS's perspective is understandable but ultimately I don't think it has helped GCC.
Posted Jan 26, 2014 17:31 UTC (Sun)
by coriordan (guest, #7544)
[Link] (5 responses)
GCC could have been turned into a platform for non-free compilers if not for the fact that RMS stood firm against this. That would be catastrophe.
GCC now has a plugin interface, and it's currently being improved, and there are plans for the interface to expose more of GCC's internals, but this has to be done carefully to avoid catastrophe.
> Nobody is asking RMS to do more
People want a more stable plugin interface, they want more internal status to be exposed. Look, here's a mail by RMS saying that GCC could expose more without inviting any problems:
"making available the symbol table (identifiers and their types)
But instead of offering to do some of this work, some people just complain about RMS not waving his magic wand and doing it for them.
Posted Jan 26, 2014 18:02 UTC (Sun)
by rahulsundaram (subscriber, #21946)
[Link] (4 responses)
You sound like a fanboy now. Nobody has ever asked RMS to do anything for them with relationship to GCC. I bet you can't find any references backing up your claim. This is a mischaracterization of what happened and is just not true.
You should recognize that there is a big difference between wanting GCC to be easier for tooling and wanting it to be a platform for proprietary things. This is precisely why I gave you a clear example of Google. Google is NOT interested in proprietary compilers or proprietary tools around GCC. They just wanted GCC to be more usable for the tooling they needed. ex: clang-format. Jumping through hoops to navigate the licensing restrictions which in turn imposed technical restrictions was an additional burden. This has cost contributors to the project and led to more Clang adoption which GCC now has to respond to.
Posted Jan 26, 2014 18:53 UTC (Sun)
by coriordan (guest, #7544)
[Link] (3 responses)
In your next comment you said RMS was to blame for the lack of modularity, so you're saying Google's decision is RMS's fault. I pointed out that this is also wrong, and I gave you a link to RMS suggesting ways to increase the modularity of GCC. He's not holding up the work - if someone wants to do it, it has his blessing right there.
> Google is NOT interested in proprietary compilers or proprietary tools
That's good to hear. I hope they help out with the modularisation RMS suggested, and I hope they understand when some things aren't possible or have to be done slightly differently to avoid GCC being used by other companies as a platform for non-free compilers or tools.
Posted Jan 26, 2014 21:04 UTC (Sun)
by deepfire (guest, #26138)
[Link] (1 responses)
Reposting links by stevenb:
Posted Jan 26, 2014 23:04 UTC (Sun)
by coriordan (guest, #7544)
[Link]
Posted Jan 27, 2014 21:54 UTC (Mon)
by rahulsundaram (subscriber, #21946)
[Link]
Nope. Your choose to interpret it that way. My point was that licensing affects technical choices and the technical choices affected Google's participation. That is merely a statement of fact. Now whether losing some of the contributions that would resulted in a better GCC from an organization which seems to have been inadvertently affected those technical choices despite them having no interest in doing what the licensing restrictions was supposed to prevent is worth pondering over. Instead of jumping in thinking I am trying to blame a specific person, I suggest you focus on the broader issue at play here.
Posted Jan 26, 2014 18:24 UTC (Sun)
by pbonzini (subscriber, #60935)
[Link] (4 responses)
Posted Jan 26, 2014 18:37 UTC (Sun)
by coriordan (guest, #7544)
[Link]
Posted Jan 26, 2014 18:54 UTC (Sun)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
Posted Jan 27, 2014 10:10 UTC (Mon)
by pbonzini (subscriber, #60935)
[Link] (1 responses)
Posted Jan 27, 2014 15:21 UTC (Mon)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Jan 26, 2014 1:29 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (17 responses)
Where today's GCC is actually a *fork* of the old GCC, because the old GCC was stagnating badly? (And the original GCC was scrapped when the two re-merged.)
I think history shows that without competition, most things stagnate - and GCC is no exception.
Plus, as should have been obvious from my post, I am not a fan of group-think. "Winner takes all" is *not* good. Monoculture is dangerous ...
Of course interesting ideas are being tried out in LLVM rather than GCC. And how many of those ideas are incompatible with GCC? Do you want to see those ideas still-born? I certainly don't!
Cheers,
Posted Jan 26, 2014 14:25 UTC (Sun)
by jwakely (subscriber, #60262)
[Link]
Posted Jan 26, 2014 15:09 UTC (Sun)
by coriordan (guest, #7544)
[Link] (15 responses)
Not really. If you look into it, it's kinda par for the course for such a big, long-running project.
The facts are that for two years, out of GCC's 28 years of development, a bunch of developers developed the GCC codebase in a parallel repository. Both projects were GPL'd, and both development teams strongly supported free software and the FSF. The EGCS fork lead to a bunch of technical improvements, and they are now part of GCC.
That's healthy competition. GCC never stagnated. And this didn't harm the free software community or the advancement of free software. It didn't cause people to start helping proprietary compilers.
> "Winner takes all" is *not* good
I want GCC to improve, but I won't be hoping for improvements in Intel's compiler or some proprietary Apple compiler based on LLVM just as a way to light a fire under the feet of the GCC devs. RMS said it well:
"For GCC to be replaced by another technically superior compiler that defended freedom equally well would cause me some personal regret, but I would rejoice for the community's advance."
Competition can be great, but I want free software compilers to always be in the lead.
Posted Jan 26, 2014 18:48 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (8 responses)
Oh, and it's dead easy, AND PERFECTLY LEGAL, to make a closed compiler based on GCC. Thing is, it's not very practical.
And as others have pointed out, it just turns out it's equally impractical to make a closed compiler based on LLVM/Clang.
Trouble is, I think this thread is turning into a GPL2/3 type argument, where we have the Free Software Fanatics on one side, and the engineering pragmatists on the other (Linus vs RMS).
Anyway, what's to stop GCC pinching ideas from LLVM/Clang? If they're good, I'm sure they will.
Cheers,
Posted Jan 26, 2014 20:06 UTC (Sun)
by oldtomas (guest, #72579)
[Link] (7 responses)
Please, stop that. Fact is, LLVM wouldn't be where it is now were it not for those you call "Free Software Fanatics".
As much as you may despise them, I know I owe much more to RMS than I owe you.
Posted Jan 26, 2014 20:48 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (6 responses)
But when "you" tell "me" what licence I have to use for *my* software (which is what a lot of these comments are - people complaining that someone else has made a "wrong" choice of licence), I think I'm well within my rights to use the word "fanatic". Fanatics think they have the right to tell other people what to do, and that is what is happening here.
I'm a casual LibreOffice developer. Given the opportunity, I want to contribute much more. But that doesn't give me the right to complain that the other developers went along with the wrong licence when they chose MPL. That's their decision, their choice, their right.
And indeed, I *really* *can't* see what's wrong with Google et al choosing to contribute to LLVM/Clang under the BSD licence. It's free and open for GCC to take if they want. You have NO RIGHT WHATSOEVER to complain about what eg Google choose to do with their own property/code - if they choose to give it away to all and sundry that is THEIR RIGHT AND FREEDOM!
Cheers,
Posted Jan 26, 2014 20:54 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (1 responses)
I did not call RMS a fanatic, which you implied in what you said. In fact, I generally refer to him as a prophet. It's his followers who demand that the world must follow "the way of RMS" ...
Cheers,
Posted Jan 27, 2014 9:17 UTC (Mon)
by oldtomas (guest, #72579)
[Link]
> I did not call RMS a fanatic,
No. You talked loosely about "the Free Software Fanatics".
> which you implied in what you said.
No. I just was miffed at this (deliberate or not) tactics of invoking such a nebulous group of people and leaving to each one's phantasy who you are actually talking of (coriordan put that more succintly as "red herring").
> But when "you" tell "me" what licence I have to use for *my* software (which is what a lot of these comments are [...]
I'll assume that this is the "generic you". Would you mind pointing at least to an example of someone telling you what license you have to use on your projects?
Posted Jan 26, 2014 23:18 UTC (Sun)
by coriordan (guest, #7544)
[Link] (3 responses)
Strawman. No one told you you have to do anything.
I and others have pointed out that the best way to support free software's future is to use copyleft licences.
> It's free and open for GCC to take if they want.
And it's open for Apple and Intel to take too. GCC used to have an advantage in certain domains, and LLVM is (or could in the future be) neutralising those advantages by providing them to Intel, Apple, etc. Those advantages lead to people contributing to GCC. Being able to use LLVM as a platform to start from, certain companies are now more likely to make their own proprietary LLVM-based compiler than contribute to any free software project.
Posted Jan 27, 2014 9:33 UTC (Mon)
by ibukanov (subscriber, #3942)
[Link] (2 responses)
As it was pointed above there is no big difference between GCC and LLVM in this regard. One just needs to follow NVidea example where they create a proprietary virtual machine and use GCC to generate code for it. That requires more work, but it just means it is harder for a small company to use GCC in a proprietary code, a big company have enough resources to pay lawyers to find loopholes and developers to implement workarounds.
Posted Jan 27, 2014 9:53 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Jan 27, 2014 10:06 UTC (Mon)
by coriordan (guest, #7544)
[Link]
There obviously is since companies are building proprietary compilers on top of LLVM, and no one (or almost no one, if the Nvidia example is correct) is building proprietary compilers on GCC.
> a big company have enough resources to pay lawyers to
GCC has been everywhere for 25 years. Show me the list of big companies paying lawyers and developers to make proprietary compilers from GCC. Why did NeXT/Apple release their Objective-C compiler under GPL? Did they not have enough lawyers or developers?
Reality contradicts your theory.
Posted Jan 27, 2014 11:52 UTC (Mon)
by dakas (guest, #88146)
[Link] (1 responses)
Posted Jan 27, 2014 22:21 UTC (Mon)
by nix (subscriber, #2304)
[Link]
What was worthwhile, and what I think you may have meant, was that the egcs project continued to use the same copyright-assignment rules as GCC, so the FSF would not refuse to call it 'GCC' if the experiment were to prove successful.
Posted Jan 27, 2014 22:17 UTC (Mon)
by nix (subscriber, #2304)
[Link] (3 responses)
It was a 'fork' more of governance than of codebase and more of codebase than of developers. "Both development teams" were the same people (except that only Kenner could commit to GCC, which effectively explains why EGCS won). The same mailing lists were used: the same everything was used except for the rules about who could commit.
I'm not sure this even counts as a fork. An experiment, yes, but not a fork.
Posted Jan 28, 2014 3:43 UTC (Tue)
by coriordan (guest, #7544)
[Link] (2 responses)
I didn't follow the EGCS story at the time, but I always jump in when someone claims that after managing a dozen large-scale software projects, each for years or decades, the two-year EGCS story from fifteen years ago is somehow proof that RMS has poor project management skills.
Posted Jan 28, 2014 11:27 UTC (Tue)
by dakas (guest, #88146)
[Link] (1 responses)
Posted Jan 30, 2014 0:00 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Jan 25, 2014 11:42 UTC (Sat)
by mjw (subscriber, #16740)
[Link]
It looks like it is dead-easy to write plugins that do fun stuff with GCC these days, even for people not wanting to write in C but in something like Python.
Posted Jan 25, 2014 1:13 UTC (Sat)
by silvas (guest, #87887)
[Link] (126 responses)
The reason is that LLVM's development practices create a strong disincentive for keeping any code private because LLVM's C++ API's (which is where 99.999% of development happens) has no backwards compatibility and changes very rapidly, which means that anything that isn't upstreamed bitrots. We've heard tales of it taking months to merge the changes in a single release, or straight up abandoning private branches.
We don't do everything in public purely because of internal constraints of the companies that we work for and those won't go away without significant *societal* changes (i.e., the necessary changes vastly transcend the developers' own attitudes on the issue: we're talking changes at the levels of entire business models).
Now, you may say that "that's the wrong reason" to be pushing things upstream (i.e. it's pragmatic, not dogmatic), and I won't argue with that: it *is* pragmatic. Nonetheless, it is *very* effective in minimizing the deviation of the derived proprietary programs from the fully-free equivalent that you can build on your own from the public repository[*]. Realistically, this means that it maximizes the competitiveness of free programs with their proprietary counterparts[**]. I think is a win for free software.
[*] Note that copyleft has nothing to do with freedom. If you download the LLVM source code from the public repository and build it yourself, you can verify that the resultant program satisfies the Four Freedoms <https://www.gnu.org/philosophy/free-sw.html> and is therefore free software.
[**] Realistically, they are just as competitive along every technical dimension. For example, you'll never see an Apple compiler with better C++1y support than the public Clang.
Posted Jan 25, 2014 9:20 UTC (Sat)
by lkundrak (subscriber, #43452)
[Link] (3 responses)
Why wouldn't you want your licensing term to reflect this practice then?
> [**] Realistically, they are just as competitive along every technical
What about better ObjC support? What about iPhone platform support?
Posted Jan 25, 2014 10:28 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
Just because you WRITE the code, doesn't mean you OWN the code. In the case he describes, the code is a "work for hire" so belongs to his employer.
Cheers,
Posted Jan 26, 2014 0:28 UTC (Sun)
by silvas (guest, #87887)
[Link] (1 responses)
Because keeping private branches is a necessary evil. They are a pain, but the alternatives are much worse.
> What about better ObjC support?
As far as I've seen they just work on it in the public tree.
> What about iPhone platform support?
I assume you mean that the platform is locked down?
Well, that's their platform. They make the rules for who gets to compile for it. Now, you may say "well, they shouldn't restrict who gets to compile for their platform!" and that's fine, but it's a different issue, one which goes to the core of Apple's business model and the society that enables it and the individuals that make up that society. Even if LLVM/Clang were to magically become GPL'd tomorrow, the platform would still be locked down.
Posted Jan 26, 2014 18:25 UTC (Sun)
by pbonzini (subscriber, #60935)
[Link]
Posted Jan 25, 2014 9:52 UTC (Sat)
by coriordan (guest, #7544)
[Link] (12 responses)
You're probably right. Apple wouldn't have any interest in a proprietary fork with better C++1y support.
But when they (be it Apple, or IBM, or whoever) have some super new optimisation, or support for their latest platforms, or some other feature that can't be found in GCC, then they'd have an incentive to only offer it in their proprietary version.
Knowing them, I can't see why they spurn such an incentive.
With GCC, I know that forks will never be non-free, and I can say "never" with confidence.
Posted Jan 25, 2014 20:21 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (4 responses)
Likewise IBM is a service company nowadays - if their innovations are taken closed but it lets IBM sell more hardware, then fine. And if IBM get paid to create these innovations as a "work for hire", then equally fine.
This "free/open" kerfuffle has most relevance when we're worried about software companies. As far as hardware or service companies are concerned, I think we've won the argument - write the software, plonk it in the public domain, and walk away.
We just need to win that argument in Hollywood, and the big software companies are toast.
Cheers,
Posted Jan 25, 2014 22:27 UTC (Sat)
by jwakely (subscriber, #60262)
[Link] (3 responses)
e.g. if the Xcode compiler has clever optimisations not available in the upstream llvm then that is an incentive to use Xcode, which is only available for Apple hardware, so it sells more Apple hardware. If the clever optimisation is in upstream llvm then it's available to GNU/Linux users on non-Apple hardware and doesn't help sell Apple hardware.
Posted Jan 25, 2014 22:48 UTC (Sat)
by raven667 (subscriber, #5198)
[Link] (2 responses)
Posted Jan 26, 2014 14:35 UTC (Sun)
by jwakely (subscriber, #60262)
[Link] (1 responses)
Except Apple :-)
They have a proprietary OS based on FreeBSD (and also iOS, whatever that's based on), and a proprietary compiler based on LLVM, and the rest of the community does not get to enjoy the goodies they add to their proprietary versions.
Posted Jan 26, 2014 18:12 UTC (Sun)
by raven667 (subscriber, #5198)
[Link]
Posted Jan 26, 2014 0:58 UTC (Sun)
by silvas (guest, #87887)
[Link] (6 responses)
Basically, you're saying that GCC would rob them of an opportunity to gain a business advantage. I'm all for software freedom, but even to me that doesn't sound like a compelling argument to adopt GCC.
It's myopic to think that the software is somehow the key factor here: the assault on freedom in this situation is the incentive to keep it proprietary, and that is a much larger issue. There is a similar assault on freedom from the fact that their hardware designs are proprietary as well, and the incentives are similar.
I'm amazed that so many people are up in arms about software freedom when it is such a small part of larger issues with broad societal ramifications. As a simple example, many/most people (and in particular the people "in power", and our predecessors who made today's laws) think that you can own a sequence of 0's and 1's and prevent somebody else from having that sequence of 0's and 1's on their computer (or charge them money/send them to jail for doing so).
Posted Jan 26, 2014 17:18 UTC (Sun)
by coriordan (guest, #7544)
[Link] (5 responses)
I didn't say that. GCC would require them to play by the same rules as everyone else. It prevents parasitism. Some (big) companies might be disappointed that they can't parasite GCC. I think it's twisted and inaccurate to repaint this as "being robbed of a business advantage".
> when it is such a small part of larger issues
This is misleading for two reasons. The first is that it suggests that we should give up on one fight simply because other fights exist. There will always be other fights, so that logic would just lead to giving up on every fight.
(Some people love finding excuses to do less.)
Secondly, it's missing the point that we are actually winning this fight. Human rights and sensible tech policy have been retreating in almost every domain in the last twenty years. The free software movement has actually made progress. It hasn't won, and there's a mountain of work left to do, but it's stronger now then it was in 2000, and it was stronger in 2000 than it was in 1990.
If you want to campaign against other abuses of copyright, that's great! I wish you success. But you're not helping those causes by telling people to go limp on free software.
Posted Jan 26, 2014 21:26 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (4 responses)
Regards,
Posted Jan 26, 2014 23:28 UTC (Sun)
by coriordan (guest, #7544)
[Link] (2 responses)
We're discussing the effects of licensing strategies on free software's future. Some people are pointing out that copyleft helps free software more.
You're ignoring the substance of the discussion and instead saying that people who express their opinion on this matter are fanatics that are trying to boss people around. I disagree, I think this is important and should be discussed.
Posted Jan 27, 2014 19:58 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (1 responses)
And Google has never been particularly enamoured with copyleft.
Especially when a certain person expressed the desire for one free software program to triumph over another! :-) As I said, I'm no fan of monoculture. You only have to witness my diatribes about the brokenness of First Normal Form to know that !!! :-)
Cheers,
Posted Jan 28, 2014 3:58 UTC (Tue)
by coriordan (guest, #7544)
[Link]
The point was if they want to help free software, they should contribute to copylefted projects. You're saying everyone should stand idly by while Google does whatever they want with "their" code. That's a recipe for failure.
Like any push for social change, getting to a society where computer users have freedom and control of their computers involves direct action (writing our own code), lobbying our governments, and pressuring companies.
> It's their code!
I don't agree. If they want to own it, they can keep it to themselves. Same for music, same for food.
Years ago, food was sold without the ingredients being listed on the wrapper. When food labeling was proposed, the food industry complained, "It's our food!", but governments decided that when you distribute food, you have responsabilities. It's no longer "your" food, it's food that's circulating in society.
I view software (and cultural works) similarly.
Posted Jan 27, 2014 21:48 UTC (Mon)
by jwakely (subscriber, #60262)
[Link]
Posted Jan 25, 2014 14:06 UTC (Sat)
by robert_s (subscriber, #42402)
[Link] (1 responses)
Just have to point out the selection bias here. No, of course you don't like maintaining private branches, because you consider yourselves LLVM developers.
The people who _will_ be maintaining private branches won't consider themselves LLVM developers, just developers working on their proprietary projects (who probably don't talk about it much).
And since they wouldn't really care about the health of the wider LLVM project, strict "maintenance" of their branch would probably be a lot slacker ("do we care if we break obscure feature x? nah...").
Posted Jan 25, 2014 14:14 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
Because one of two things is almost inevitable ... either
(1) the private fork will rapidly stagnate, or
In either scenario, I don't think the Free version has much to worry about. In scenario 1, the private branch won't be competitive. In scenario 2, the employer will have difficulty retaining staff.
Cheers,
Posted Jan 25, 2014 14:40 UTC (Sat)
by pboddie (guest, #50784)
[Link] (3 responses)
But what if you modify the software and distribute it only as a binary to other people? Which of the four freedoms remain for those people? The whole point of copyleft is that the four freedoms remain, and it seems disingenuous to claim compliance with those freedoms by just observing the software at a given snapshot in time (when you were able to take advantage of those freedoms) and to disregard the process that guarantees them for everybody. That's what copyleft has to do with freedom.
Posted Jan 25, 2014 15:46 UTC (Sat)
by drago01 (subscriber, #50715)
[Link] (1 responses)
Then this specific software is non free same if said vendor has written one from scratch.
> That's what copyleft has to do with freedom.
Copyleft just ensures that derived work is free as well. (which isn't a bad thing at all) but this in itself is a restriction so you cannot really argue that copyleft is free while non copyleft open source isn't (which actually allows the user to do more).
Posted Jan 26, 2014 14:18 UTC (Sun)
by pboddie (guest, #50784)
[Link]
Yes, that's what I wrote. Yes, it has to be a restriction in order to guarantee something: the continued availability of the four freedoms for any future form of the code and for any recipient. Without that, the immediate recipient can enjoy the benefit of shipping a binary at the expense of the subsequent recipients who may then only get one or two of the freedoms. So much for user freedoms then! (I'm not arguing that copyleft-licensing is the only way to release Free Software: that's a classic misportrayal of copyleft advocacy and isn't even a position of the FSF.)
Posted Jan 25, 2014 15:47 UTC (Sat)
by dakas (guest, #88146)
[Link]
A pessimist is one who knows it.
Copyleft has shown itself to be an effective and robust tool against software freedom either getting eroded or evaporated. Since it has to balance conflicting goals, one has to adapt this tool as the world changes and reevaluate the compromises taken and their respective drawbacks.
That involved both the license itself as well as how to make sure that its coverage of "the work as a whole" manages to actually affect what it is designed to be good for. That will always remain an issue, even though the current facts are, uh, not quite the state that Eric Raymond assumed to be working with.
Posted Jan 25, 2014 16:00 UTC (Sat)
by Del- (guest, #72641)
[Link] (99 responses)
Thanks for sharing! I really mean it, and in advance apologies for my rather confrontational approach.
> The reason is that LLVM's development practices create a strong disincentive for keeping any code private because LLVM's C++ API's (which is where 99.999% of development happens) has no backwards compatibility and changes very rapidly,
This sounds incredibly stupid. Stable API's is the back-bone of any successful open project. If this is your way of copy-left, then I suggest you use licensing instead. It is already causing a lot of pain for legitimate usage of LLVM:
> We don't do everything in public
Thanks for confirming my suspicion. I seems like LLVM/Clang is well on its way down a slippery slope. I predict that it is only a question of time until either the likes of Google give it up, or they fork it.
The real problem with projects like LLVM/Clang is that they attract developers that otherwise would have contributed to a sustainable open ecosystem. The idea of forking LLVM/Clang into some copy-left project is a pipe dream, there are very strong forces that will fight against it. Building open communities is heavy lifting and takes time, it is vulnerable (as the khtml story demonstrates).
Unfortunately few developers seem to know the legal implications (I am referring to patent protection here) of the license their project has. They may very well take you on your word and see contributing to LLVM/Clang is just as good for the open ecosystem as contributing to GCC. I am afraid that is very far from reality, and I am terribly afraid that it will become clear to all of us within a decade, or maybe not, many seem to see webkit as a success story for permissive licensing. I just hope that GCC manages to keep up, anything else will most probably be a catastrophe for all of us.
Posted Jan 25, 2014 23:45 UTC (Sat)
by silvas (guest, #87887)
[Link] (59 responses)
That's a different discussion... It's an interesting dynamic to be sure :)
> If this is your way of copy-left, then I suggest you use licensing instead.
It isn't done with the goal of being a form of copyleft. It's just how the community operates, and as a byproduct it creates a strong disincentive for keeping code private.
> Thanks for confirming my suspicion. I seems like LLVM/Clang is well on its way down a slippery slope.
Like I said, it's not the developers that make this choice. The people who write our paychecks make those rules. It's really disingenuous to talk about this as a property of LLVM/Clang: it's a property of the businesses that finance the project, their business models, and society as a whole.
In my experience, Stallman's view is extremely myopic because the real impediments to free software are larger societal issues[*]. Within the hacker community these issues don't really exist (Eric Raymond's essays cover this well), and so the default is that code is free software (four freedoms), but the other 99.99% of society is still stuck with archaic principles, and any time that a hacker's paycheck comes from "the rest of society", they are subject to a world where these issues exist.
> The real problem with projects like LLVM/Clang is that they attract developers that otherwise would have contributed to a sustainable open ecosystem.
Not exactly. We have to eat: somebody has to pay our paychecks. That's the reality. LLVM/Clang's development model has a nice balance of accommodating the demands of the people who have the money (so that they will pay (lots of) hackers to hack on it full time) while maximizing the competitiveness of free software alternatives to their proprietary offerings (which are just slight modifications of the free versions).
[*] The GPLv3 "anti-Tivo-ization" wording is a perfect example that shows that confining your view just to software is myopic. Why shouldn't we want the entire device and all its chips to be free also? Why shouldn't the company's internal discussions be done in public? The answer to these questions is the same as the answer to "why does non-free software exist?".
Posted Jan 26, 2014 12:16 UTC (Sun)
by dvdeug (subscriber, #10998)
[Link]
Calling him extremely myoptic is absurd; there is no reason to think that him attacking a broader problem would have brought him nearly the success that he has had.
Posted Jan 27, 2014 11:38 UTC (Mon)
by pboddie (guest, #50784)
[Link] (4 responses)
So what's your point here? Stallman is just focusing on stuff he knows a lot about: it's pretty unreasonable to expect him to reform all aspects of society; I think that's actually down to other people if they think his ideals are compatible with other domains. And in fact, people including Stallman have tried to encourage open hardware, arguably with less success because the development of hardware is somewhat different to that of software, because "the demands of business" combined with rampant patenting conspire to put hardware producers on the defensive, and because it is difficult to translate some aspects of copyleft into hardware and not have people complain about the translation. But it remains very possible that we'll see similar changes to the way hardware is made and licensed over time as well. What you seem to be saying is that businesses have reasons for doing things a certain way and that they should be able to call the shots. What Stallman is doing is basically "consumer advocacy": when people buy a product, he's saying that it should really be theirs and they should be able to use it mostly as they wish and not how someone else dictates it should be used. Even then, he's only arguing on the basis that the hardware producer is reneging on a deal that they made with the authors of some software that gave them a viable product in the first place. And people are demanding more transparency in business and society, and consumer rights groups have been active for decades. Telling people that "this is how things are done" and expecting them to just live with it is becoming an increasingly inadequate excuse for the status quo.
Posted Jan 27, 2014 21:39 UTC (Mon)
by ibukanov (subscriber, #3942)
[Link] (3 responses)
Yet GPLv3 anti-Tivo provisions are exactly the example where FSF tried to expand its influence to another domain (hardware design) with bad results. Consider Chromebooks. They use a verifiable boot where Google holds a private key. Yet a user can replace the bootloader with pretty doable hardware tinkering without any need for special tools. So Google does not take away the freedom, but the code cannot be GPLv3 due to that anti-Tivo provision.
Posted Jan 27, 2014 21:58 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Posted Jan 28, 2014 7:47 UTC (Tue)
by ibukanov (subscriber, #3942)
[Link] (1 responses)
I was not talking about enabling developer mode on the Chromebook that disabled kernel verification, I meant a possibility to install a custom boot loader. The developer mode still does not allow that, one has to tinker with the hardware. And I do not even see how enabling developers mode fits with the “Installation Information” section in GPLv3:
To stay within GPLv3 either the Google should provide a way to sign the code with their keys or Chromebook should allow to install custom keys (like with Windows 8 x86 hardware).
In any case, hardware changes to get a custom boot loader are outside “Installation Information” as otherwise anybody can claim that one can always disable a verified boot using a probing station or something to change a value in the register at the runtime.
Posted Jan 28, 2014 10:24 UTC (Tue)
by khim (subscriber, #9252)
[Link]
Are you sure that argument will be bought by layman in court? Because this is where such things are determined. And I'm pretty sure Joe Avarege will see the difference between step-by-step instruction published on verndor's website and vague allusions to some complex and obviously illigal procedure.
Posted Jan 27, 2014 14:28 UTC (Mon)
by Del- (guest, #72641)
[Link] (51 responses)
Well, only partly true. An increasing number of individuals are full-time paid for making copy-left code. It seems you are taking the "nothing I can do about it" approach. Please do not degrade yourself like that. There is a good chance that somebody is willing to pay you the same amount you receive today to work on copy-left software. Maybe even your current employer. GPL is as much about putting the power into the hands of developers (i.e., out of the hands of managers) as anything else.
> In my experience, Stallman's view is extremely myopic because the real impediments to free software are larger societal issues[*].
Not at all sure why you can reach the myopic conclusion here, but I assume what you are saying is that GPL is too restrictive for society to accept it. You may be correct, but then again we are starting to see a rather overwhelmingly evidence of copy-left being a success for everybody, particularly those companies who made it big time the last decade (not thinking of Microsoft here). Let us look a bit closer at the anti-Tivotization expample. Linus repelled GPLv3 over it (which I believe was very unfortunate, because he lost the patent protection part too). One may of course speculate that he was in a tough situation, possibly seeing important backers of linux pull out. The most important of those had to be Google I guess, since they are the ones who took linux to its ultimate success. It may of course be that Google would not use linux had it been GPLv3, but I really struggle to see why. If any, it would help some of the litigation chaos we see now. Heck, even Microsoft puts patent protection into its most popular open license. The lack of any patent protection in BSD has made everybody with knowledge jump on the Apache bandwagon for their permissive license (including Google with Android), so it is clear that Google would prefer GPLv3 over GPLv2 on the patent part. Hence we are down to the Tivo story as the only problematic point. What exactly does it do for Google? Nothing, they make all their devices hacker friendly, even to the point where they are now the most prominent backer of coreboot, and open source bios. HTC provided some shitty tools to circumvent their own Tivo solution based on popular demand. Their market performance went from bad to worse when the pulled the tool back. Samsung and the rest sees their most popular devices getting hacked, so anybody so inclined can install Cyanogenmod on them. It is all a display of human stupidity, creating unnecessary obstacles for your own customers. Does anybody really believe that iphones sell better because they are locked down? I am pretty sure Google would have gone with linux even with GPLv3, and I do believe it would make the world somewhat better for all of us. It is also very clear from the Android example that we do need to use the license to make these things happen (i.e., open devices). I am sorry, but Stallman is not myopic here. Permissive licensing on the other hand is. The real question is, do you want to be part of the solution?
Posted Jan 27, 2014 20:39 UTC (Mon)
by khim (subscriber, #9252)
[Link] (50 responses)
Makes it non-starter. Google does not mind GPLv3 for the developer tools, but (L)GPLv3 is not something they ever want to consider for the Android (that's why Android comes with no libstdc++.so.* and there are talks about switching to LLVM and libc++: this will make it possible to actually ship shared C++ library). This is true, but they also know that they need phones lockable by carriers to be successull in the smarphone market (they only company which gets away without such lock-in is Apple and this partially because it offers it's own lock-in which means that tethering is still not allowed if carriers don't want it to be allowed). Oh yeah. Lock-down is vital for iPhone success. No, not directly, but indirectly: without carrier subsidies iPhones are too expensive in many parts of the world and carriers will not support them if they can not gurantee they'll not work as carriers want. Carriers want to control everything and Apple is adamantly against some changes (e.g. with most phones carrier's logo is placed on the phone case while Apple is ready do abandon particular carrier if this is the price it'll pay for the subsidies) and this is why they talk long and hard about the exact terms which are imposed on user, but fully-user-controllable device is not something they ever want to contemplate. And that's Apple! It drives hordes of most profitable customers to carriers! Android will not get such treatment, that's for sure. Really? Why are you so sure? We know that Google tries to reduce amount of GPLed code in Android and GPLv3 is banned in principle, why do you think GPLv3 kernel would make a difference? I think they would have just picked GPLv2 fork or even BSD kernel. Really? From Android example we see that all such tries will lead to rejection of software (most GPLed software is already removed from Android except for kernel and GCC is well on it's way to deprecation partially because of the same issue). Is that the result you want to see? Just how it'll help developers or users? AFAICS GPLv3 gambit was risky and it failed. Failed quite spectacularly. I don't see how you can advocate “more of the same” after such a failure. It a pity. I for one, expected for this gambit to work. But it didn't. It's time to accept new reality and think about it.
Posted Jan 27, 2014 22:34 UTC (Mon)
by Del- (guest, #72641)
[Link] (30 responses)
> Google does not mind GPLv3 for the developer tools
OK, but the gambit failed, so I guess it is everybody else that saw GPLv3 as a little too much for GCC then. Exactly who are we talking about? Apple? From all I have found it was the copyright transfer of LLVM to FSF that stopped them from collaboration, before GPLv3 was a reality. AFAIK, Apple going for LLVM outside GCC had nothing to do with version 3. Do you have *any* information to back up your undocumented stream of statements?
> that's why Android comes with no libstdc++.so.*
Care to enlighten me, exactly what legal issues are there related to using libstdc++? AFAIK it is linked in just about any proprietary application out there.
> there are talks about switching to LLVM and libc++
Yes, but that may have many reasons, and may or may not materialize, and if it does, it will be because somebody regards it as technically superior. The license of LLVM is about as primitive as BSD, and lacks any reference to patents. With Google opting for Apache, I am pretty sure any switch to LLVM will be despite its license, not because of it.
> they need phones lockable by carriers to be successull in the smarphone market (they only company which gets away without such lock-in is Apple and this partially because it offers it's own lock-in which means that tethering is still not allowed if carriers don't want it to be allowed).
Please provide documentation that HTC lost carriers over offering tools to root their phones. I don't believe you will find any, and that basically nullifies you theory right there. Next time read my post before answering, I have provided explicit examples documenting my statements, I really appreciate if you counter them in a more scientific manner.
> Oh yeah. Lock-down is vital for iPhone success. No, not directly, but indirectly: without carrier subsidies iPhones are too expensive in many parts of the world and carriers will not support them if they can not gurantee they'll not work as carriers want.
It seems most of the world has the opposite conclusion, that Apple with Iphone demonstrated that they could strip carriers of their demands and make a great commercial success of it. I would actually say that not allowing carriers to control software on Iphones is the main reason why Iphone was a success. I want you to document your claim here, and tethering just doesn't cut it. It is a really minor point in this setting, nothing that anybody seriously believes would cut Iphones out of the market.
> From Android example we see that all such tries will lead to rejection of software (most GPLed software is already removed from Android
Google choosing linux as kernel has been a tremendous success for both Google and linux. Choosing any other kernel would be plain stupid, we have enough driver issues on Android as it is. I think Google would have done the smart thing and gone with linux whether GPL2 or 3. Would be good if somebody from Google could comment on that though, since we seem to be in a dead-lock on this one.
> most GPLed software is already removed from Android except for kernel and GCC is well on it's way to deprecation partially because of the same issue
This is getting very annoying. Have you changed the whole subject from GPLv3 being a mistake, to claiming that copy-left/GPLv2 is a mistake, and that GCC should be permissively licensed? This is starting to look like drivel.
You seem to believe GPLv3 failed, while arguing that GPLv2 also is a failure when it comes to Android, making the whole v2, v3 discussion moot. Make up your mind, do you believe that copy-left makes sense? If not, then your whole gambit comment is just stupid deception. For your information Black duck posts statistics on license usage, here:
Posted Jan 27, 2014 23:46 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (21 responses)
Turns out that industry can do just fine without GPLv3 software. So now we have lots of non-GPL tools that are comparable or better than FSF's ones. Exceptions exists, like Samba, but even that gets worked around.
Posted Jan 28, 2014 9:22 UTC (Tue)
by Del- (guest, #72641)
[Link] (19 responses)
No they did not, there were several drafts and the industry was consulted. In particular, the anti-Tivo clause was changed to only protect ordinary consumers. As already mentioned, the patent clause is already adopted by the whole industry. The only indication I have seen of GPLv3 being one too many, was Linus refusal and consequently linux and git using a GPL2 only approach. I am sure there are other following that example, but I have yet to see any. Maybe you can provide some examples of GPL2 only projects?
> Turns out that industry can do just fine without GPLv3 software. So now we have lots of non-GPL tools that are comparable or better than FSF's ones. Exceptions exists, like Samba, but even that gets worked around.
Did you just wake up or something? The industry has *always* done fine without GPL software regardless of version. BSD and Apache have been around for quite some time you know. However, it seems GPL has opened the minds of corporations towards open development. They basically want the developers, but not the commitments, hence permissive licensing. Hence, many companies are now investing in open software. Software houses tend to like permissively licensed code or dual licensing, since they want both ends of the deal. Customers and communities are typically best served by copy-left. Both have their place, and there is no drama in it. In fact, you and khim more and more appear to me as astroturfers. Exactly what is your take in this? Are you here just to sabotage copy-left, or do you actually believe that the world is best served by abandoning copy-left altogether?
Posted Jan 28, 2014 13:12 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (18 responses)
> Did you just wake up or something? The industry has *always* done fine without GPL software regardless of version. BSD and Apache have been around for quite some time you know.
Well, not anymore. Gcc is being replaced by clang+LLVM, gdb is being replaced by lldb and so on. All of the replacements are under permissive licenses (Apache or BSD).
>However, it seems GPL has opened the minds of corporations towards open development.
>The only indication I have seen of GPLv3 being one too many, was Linus refusal and consequently linux and git using a GPL2 only approach. I am sure there are other following that example, but I have yet to see any. Maybe you can provide some examples of GPL2 only projects?
BTW, can you name a single GPLv3 project that is used consistently across all the architectures? I can't.
>Exactly what is your take in this? Are you here just to sabotage copy-left, or do you actually believe that the world is best served by abandoning copy-left altogether?
Posted Jan 28, 2014 16:16 UTC (Tue)
by Del- (guest, #72641)
[Link] (17 responses)
They surely did not, GPLv3 code is used everywhere in all industries. Major contributions are being made by industry to various GPLv3 projects too. BTW, why are you pounding that dead horse, you do not believe copy-left is a good idea in the first place (otherwise you would probably be evangelising usage of GPL2-only or LGPL licensing by now).
> Not really. GCC, gdb, glibc, busybox and others used to be indispensable. So indispensable that RMS used to call Linux as GNU/Linux.
They were always dispensable, there used to be many operating systems around remember? are you so quick to forget the BSDs and the Unix variants? Or windows, or OSK or OSX or IOS or .. This is getting boring. You are a smart guy, stop saying things you know are stupid. Actually, the last years copy-left has conquered HPC world wide, it is about to conquer the web-servers, and the BSDs need to turn to copy-left for the three most popular desktops. How about end-user applications, show me your permissively licensed apps? Don't be naive, without copy-left many of us would not be able to work with open source at all. We all need it. Its usage is growing, and it is fuelling the current growth of permissively licensed projects. Make no mistake though the majority of projects are still copy-left, and they are growing stronger despite Microsoft and Apple doing their best to sabotage it. Stop helping them please.
> Be that as it may, it's not the point of the argument. Large organizations figured out that collaborating on non-essential software is better than reinventing the wheel all the time. They are also absolutely allergic to GPLv3 which denies them ability to keep ESSENTIAL software controlled.
Large organizations are not allergic to GPL regardless of version. To the contrary they gladly pay Red Hat for it. Moreover, many of them are smart enough to see the benefits of copy-left. For some software houses it is different, but I hope and believe that the two most prominent ones (Microsoft and Apple) will pay a hefty price for their hostility towards copy-left and consumer rights in general.
> BTW, can you name a single GPLv3 project that is used consistently across all the architectures?
You mean operating systems not architectures, right? Of course, GCC and Gimp are used across all desktop OS families successfully by many. But you probably want me to name GPLv3 projects distributed by Microsoft and Apple for their operating systems, right? Why limit yourself to that, neither of the are fond of copy-left at all, so simply say GPL instead. Unless you have an invested interest in creating confusion.
> Basically, I think that copy-left is a nice idea in small quantities.
Thanks for showing colours. That basically leaves you with Microsoft and Apple as your goto place for software. Copy-left is very hard to get by without on any other platform if you want any kind of user experience. I suggest you run along to Apple and ask them for a permissively licensed desktop and apps. See how far your ideology takes you. Yes, ideology. I am afraid I am the pragmatic one among the two of us. Right now, it seems Apple's hostility towards copy-left is costing all ios users access to a wave of new apps:
Posted Jan 28, 2014 16:29 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (16 responses)
iDevices and Androids have no GPLv3 software. Whatsoever. And they outnumber personal computers by now.
> Major contributions are being made by industry to various GPLv3 projects too.
> BTW, why are you pounding that dead horse, you do not believe copy-left is a good idea in the first place (otherwise you would probably be evangelising usage of GPL2-only or LGPL licensing by now).
> They were always dispensable, there used to be many operating systems around remember?
> Large organizations are not allergic to GPL regardless of version. To the contrary they gladly pay Red Hat for it.
But no large company produces devices with GPLv3. And just how many end-user devices with RHEL are being produced?
>You mean operating systems not architectures, right? Of course, GCC and Gimp are used across all desktop OS families successfully by many.
>Yes, ideology. I am afraid I am the pragmatic one among the two of us.
Posted Jan 28, 2014 18:30 UTC (Tue)
by Del- (guest, #72641)
[Link] (15 responses)
It is one industry, one datapoint. There is more in this world than smartphones. Stop making wide ranging statements when you really mean very specific usage. Android certainly do have GPLv3 licensed software in numbers, but you may refer to the operating system? Well Android is pretty stripped down, with only a custom Java engine to run the apps. The choice of using apache was maded specifically because HTC and the rest wanted to use an open core model from my recollection. It is an interesting dynamics, and shows a natural usage of permissive licensing. This may have nothing to do with version 3.
Let me help you out a bit. First up there is the boot-loader. Recall how lilo was very popular, but now all distros use Grub? Guess what licenses those two have? Does Google use Lilo for Android? Nope, of course not, they don't use Grub either, and mostly because Grub has a ton of functionality Android does not need. Same with SurfaceFlinger, do you think they did it because of the xorg license? Wow, Google really must hate the X11 license, wonder why Apple likes it... Now over to your favourite glibc, well do you remember the ordeal with Ulrich Drepper refusing patches for using glibc in an embedded setting? Debian forking glibc over to eglibc. Do you think maybe that could have somewhat more to do with bionic than the license? You are a smart guy, I am sure you get the drift. Again, somebody from Google speaking up would be nice. Not saying I know the priorities, but your conclusions are not very convincing to me.
> LGPL with static link exception is fine. GPL for end-user software is also OK-ish.
Hm, I cannot make any sense of what you are trying to say here.
> Nope. Even FreeBSD was built using gcc, there literally was no free alternative. Remember?
Let me help your memory. BSD used to have *drums*, a BSD licensed compiler: http://en.wikipedia.org/wiki/Portable_C_Compiler
>But no large company produces devices with GPLv3. And just how many end-user devices with RHEL are being produced?
and you know why, don't you? Does the name Elop ring any bell with you, at all? Did you have the pleasure of using the N9? A part from that GPLv3 has made success in network routers, Linksys (yes that was Cisco, do they count as large you think?) even marketed it. Any NAS box these days come with Samba, does Hewlett Packard count as large in your book by any chance? This is just getting stupid, I think I will stop here.
Posted Jan 28, 2014 20:56 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (14 responses)
>Well Android is pretty stripped down, with only a custom Java engine to run the apps.
And gcc is only a translator from C++ to machine code. And Linux is merely a wrapper over hardware-provided services. And Google is simply an indexer.
>The choice of using apache was maded specifically because HTC and the rest wanted to use an open core model from my recollection.
>Well Android is pretty stripped down, with only a custom Java engine to run the apps. The choice of using apache was maded specifically because HTC and the rest wanted to use an open core model from my recollection.
> Let me help your memory. BSD used to have *drums*, a BSD licensed compiler: http://en.wikipedia.org/wiki/Portable_C_Compiler
No they didn't. The first attempts to use PCC to compile FreeBSD were made in 2007 or so. It has never been used in anger, unlike Clang.
> and you know why, don't you? Does the name Elop ring any bell with you, at all? Did you have the pleasure of using the N9?
> A part from that GPLv3 has made success in network routers, Linksys (yes that was Cisco, do they count as large you think?) even marketed it. Any NAS box these days come with Samba, does Hewlett Packard count as large in your book by any chance?
So yes, it only reinforces my point: GPLv3 failed miserably.
Posted Jan 28, 2014 22:13 UTC (Tue)
by Del- (guest, #72641)
[Link] (8 responses)
GCC is a compiler collection, it can do much more than Java.
> Android was designed this way to allow carriers to lock down phones, and total avoidance of GPL was a pre-emptive step to avoid being forced to support GPLv2 forks indefinitely.
Sloppy again are we. There is plenty of GPL code in Android as I am sure you know. You mean version 3 I guess. You may or may not be right. Like already mentioned, Android avoids GPL in user space due to it's open core model.
> So there's no phone with GPLv3 software out there. Even the new Jolla phone does NOT have GPLv3 anywhere, though they have quite a lot of GPL and LGPL software on it.
Actually I do believe you will find GPLv3 software on N9, basically from the Debian stuff. But you are right when it comes to Jolla not shipping GPLv3 in shipping images, here I found the documentation for you:
> Again, it's either isolated or used in non-core parts. Or in situation where GPLv3 has no bite at all.
You were flat out wrong, and are back-paddling desperately. May I suggest that you just admit it, GPLv3 is not that big of a deal on devices. Sure, there are manufacturers that want to lock-down devices, and they will probably avoid Grub. That's no biggie, Uboot serves them fine.
Just listened to Langley's talk, and it makes me depressed.
Posted Jan 28, 2014 22:33 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
>However, GPLv3 software is easily available in abundance on Sailfish, Meego and Android.
>On a related note, Jolla does ship glibc, did you know that?
> You were flat out wrong, and are back-paddling desperately.
>May I suggest that you just admit it, GPLv3 is not that big of a deal on devices.
>Sure, there are manufacturers that want to lock-down devices
Posted Jan 28, 2014 22:49 UTC (Tue)
by khim (subscriber, #9252)
[Link]
Posted Jan 28, 2014 23:12 UTC (Tue)
by Del- (guest, #72641)
[Link] (4 responses)
I believe linux is still GPL, and it is a part of Android.
> Sure. They don't limit third-party software, so they can't care less.
They provided it in repos themselves I believe.
But now I am afraid I have to call it a day..
Posted Jan 29, 2014 1:14 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
Ah yes, apart from Linux itself, of course. But Linux is an exception somewhat - it has a non-existent GPL enforcement and it's also firmly in GPLv2 only camp.
However, there _are_ Android implementations that do not even use Linux - Blackberry runs their own Android simulator atop QNX.
> They provided it in repos themselves I believe.
Posted Jan 29, 2014 3:08 UTC (Wed)
by josh (subscriber, #17465)
[Link] (1 responses)
Not true. netfilter is enforced by its copyright holder, and several other kernel copyright holders have thrown their lot in with the SFLC. I'd guess that the only piece of GPLed software with *more* license enforcement than the Linux kernel is busybox.
Posted Jan 29, 2014 3:16 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Jan 29, 2014 6:55 UTC (Wed)
by Del- (guest, #72641)
[Link]
Down to semantics are we. U-boot not being part of the image you mean? What are you trying to prove, that what Google forked and made themselves in user space on Android was permissively licensed? We agreed on that already. Just forgot, Uboot is GPLv2+ so available under GPLv2, but also available under GPLv3. A tiny fact you jumped over earlier in this thread.
> Links?
Dig yourself, I cannot fathom that detail making any difference for you at all.
Posted Jan 29, 2014 12:04 UTC (Wed)
by jani (subscriber, #74547)
[Link]
Nokia did not ship GPLv3 software on the N9.
Posted Jan 20, 2015 17:38 UTC (Tue)
by jra (subscriber, #55261)
[Link] (4 responses)
>> A part from that GPLv3 has made success in network routers, Linksys (yes that was Cisco, do they count as large you think?) even marketed it. Any NAS box these days come with Samba, does Hewlett Packard count as large in your book by any chance?
So let me get this straight. You're saying that in a NAS box, Samba - the GPLv3+ SMB1/2/3 implementation that ALLOWS THE BOX TO FUNCTION AND IS THE ENTIRE PURPOSE OF THE PRODUCT is a 'non-core part'.
Hmmmm. I think you might want to look at the lifeboats. The argument is desperately listing and taking on water at an alarming rate :-).
Posted Jan 20, 2015 17:41 UTC (Tue)
by jra (subscriber, #55261)
[Link]
Please accept my apologies :-).
Posted Jan 20, 2015 20:56 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Your core part is something that you differentiate on from your competitors. For SAN the most interesting part is their core storage management which is far out of reach of GPLv3.
For end-user NAS boxes companies usually have no differentiating features at all (except the components price that you can get from your Chinese suppliers). So the vendors don't mind putting GPLv3 on them.
Posted Jan 21, 2015 16:09 UTC (Wed)
by paulj (subscriber, #341)
[Link]
Posted Jan 21, 2015 17:32 UTC (Wed)
by dgm (subscriber, #49227)
[Link]
Nope. That's your code *competency*, which is a business/management term http://en.wikipedia.org/wiki/Core_competency.
The usual engineering interpretation of the term is very different, and more in line with the FEMA definition: https://www.fema.gov/core-capabilities. Basically a core "part" is something you *require* to achieve a goal, not something that distinguishes you from the rest.
At least that's how I see it.
Posted Jan 20, 2015 17:29 UTC (Tue)
by jra (subscriber, #55261)
[Link]
Another one just bit the dust - NetApp just bought HvNAS (hvnas.com now redirects to NetApp), probably to try and shore up their increasingly creaky SMB2 implementation (leaving HvNAS's existing licensees holding a flaming bag of %*$# of course, but them's the breaks when you rent your code :-). Same thing happened to Likewise, but more proprietary companies got burned there.
Posted Jan 27, 2014 23:56 UTC (Mon)
by khim (subscriber, #9252)
[Link] (7 responses)
But it's not distributed with these applications, right? Big difference. You see, libstdc++ uses straight GPLv3 (not LGPL!) which means that if libstdc++.so.* is shipped on device one will need to privide some means of installing it. Now, why can “normal” proprietary programs can ever use libstdc++ if it's under GPL, not LGPL? Because they don't ship libstdc++ by itself and thus are covered by the appropriate exception. Said exception may or may not cover distribution of libstdc++.so.* as part of the Android image (it's not clear which part of exception will play if we are talking about libstdc++.so.* distributed in isolation), but Google is not taking any chances. In fact Google is busy bringing LLVM and Clang to the condition where they could replace GCC. GPLv3 is big part of the reasoning. Not exactly. Google prefers Apache, sure, but if choice is between GPLv3 and BSD then choice is obvious (BIONIC was based on BSD libc, after all). Why would it lose carriers if it's all too ready to lock phones again at their request? Yes, HTC made a mistake and issued unlocker which was usable for carrier-subsidized phones. Mistake is rectified so no biggie. I'm pretty sure someone at HTC got pretty good cheving over said mistake, but in the end status quo is restored. It was available in the wild for exactly one day—recall that usually updates take months till they are rolled out in the wild (that's true for HTC at least, some other manufacturers are faster) and this will say everything you need to know about the situation. Once upon time it made sense. Not anymore. Landley gave tech talk which explains what happened and why. In nutshell: GPLv2 was kinda-sorta-accepted by industry and it was loved by open-source and free-software folks, too which basicallu put the situation at the uneasy truce. But GPLv3 became a land-grab attempt and this gave clear signal to the industry: you can not trust FSF (and ideally need to drop GPL altogether if possible). The backlash was stricking: not only GPLv3 failed to achieve it's objectives (I know exactly zero devices which were opened up because of GPLv3; the most I've seen are some proprietary programs designed to inject GPLv3 binary in otherwise tightly locked firmware) it made GPLv2 weaker. Linux is kind of exception: it's developers were pretty vocal about their thought on said land-grab which means that industry don't need to fear Linux because it'll remain where it started WRT licensing. Other projects are not so lucky… well, Blink and WebKit are fine, too (they use BSD license for all new files and only use LGPLv2.1 for old files which may even eventually disappear). Some other projects could be trusted, too, but in general GPL went from “this is the beast we know” to “this is something we need to discuss on case-by-case basis”. Right. <sarcasm>Let's add Apache and BSD liceses to the list, too (because, you know, they are GPLv3-compatible).</sarcasm> When this article was written almost 70% of projects were GPL. Straight GPL! Not GPL+LGPL+BSD+whatever-you-want-to-repaint-as-your-ally. Today… six years after release GPLv3 is still used by many times smaller number of projects than GPLv2 and even if you combine GPLv2 and GPLv3 you still have much smaller number that GPLv2 had ten years ago.
Posted Jan 28, 2014 2:15 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link] (3 responses)
If the GPLv2 had the GPLv3 terms would it be the same situation we're in now, or was the act of adding the terms to all projects which used '+' the problem?
Posted Jan 28, 2014 2:55 UTC (Tue)
by dlang (guest, #313)
[Link] (2 responses)
I think the problem is a combination of both the terms and the change
on the one hand, if GPLv2 had the GPLv3 terms, I don't think it would have been as popular
but the fact that the terms changed in a way that many people consider very significant has also made it so that people don't trust the FSF to not make other changes in the future that could cause them even more problems, so they are much more paranoid about trusting GPLv3/GPLv3+ code than if the terms had been there from the start
Posted Jan 28, 2014 13:37 UTC (Tue)
by pboddie (guest, #50784)
[Link] (1 responses)
It's a shame, though, that these people didn't appreciate that some of the additional measures in GPLv3 - thinking of the strengthening of patent litigation protection - were becoming the norm even in permissive licences, whilst other things - thinking of access to the four freedoms in "consumer devices" - may already be governed by the GPLv2, although bkuhn can probably say more about these things (as I believe he mentioned the latter in particular at one point).
If anything can be said about attitudes towards the GPL, perhaps it can be concluded that the "look the other way" mentality about various edge cases in GPLv2 couldn't be sustained with GPLv3 applied to works, and those benefiting from that mentality were obviously upset as a result. But I hardly think that selective enforcement of licences and discretionary grey areas of licensing are a sustainable way of delivering Free Software to wider society: there's always the risk that someone will get away with something undesirable (making patents a "kill switch" for licensing conditions, for example) and then use some ill-advised discretion by a project to legitimise doing so, without exception and without limit, for all Free Software.
Posted Jan 29, 2014 1:31 UTC (Wed)
by dlang (guest, #313)
[Link]
The anti-tivo clause is a perfect example. Linus stated that requiring that the code for the device be provided is good, requiring that you be given enough info to modify the software on the device was over the line.
that's not a misunderstanding of terms, that's a different requirement.
If you look at the angst that people have about secure boot and how some features need to be disabled or else the key will be revoked it seems very reasonable for companies who are building devices to be very worried about what the content providers would do to them if they gave out the info that let hackers modify the software on their devices to ignore any restrictions that are built in to the software.
you may not like that, but either it's a reasonable thing to do or this entire secure boot brouhaha is meaningless.
The FSF got a lot of feedback opposing this policy, but they decided that it was important enough to include even with all the opposition from opensource developers. And then they made it very clear that if this didn't end up with the result they wanted, they would make further changes going forward as they thought best.
this is the "I have changed the deal, and I will change it again if I want" attitude that many people saw that pushed them away from GPLv3
Posted Jan 28, 2014 10:07 UTC (Tue)
by Del- (guest, #72641)
[Link]
Please provide documentation. If you are only making this up as you go along, then please be honest about it. LLVM taking over GCC has been talked about for eight years now, and I see no sign of that happening yet. Actually, LLVM taking over GCC does not even make sense. LLVM is not a compiler, it is a project for creating compilers. If it out-competes parts of GCC, there is little preventing GCC from using LLVM as an optimizer tool. What I have seen over these years is GCC out-competing all proprietary compilers, with Intel as the last hold out. Yes GCC, not Clang, it doesn't even have openmp yet, so it will only be a real contender in a year or so.
> it's not clear which part of exception will play if we are talking about libstdc++.so.* distributed in isolation
So you don't know, and I am getting a bit tired of doing all the digging for you. Before you spout more statements, I suggest you dig further and figure out if bundling libstdc++.so with Android is a license violation or not. Maybe the Necessitas guys at Digia can help you out.
Why Google did bionic I don't know, but it can very well be for other reasons than license. Again, I have not seen any issues building proprietary stuff with glibc. After all, all applications on linux does it.
> Why would it lose carriers if it's all too ready to lock phones again at their request? Yes, HTC made a mistake and issued unlocker which was usable for carrier-subsidized phones.
Sorry, but I am starting to feel really grumpy. Let us sum up your findings:
Actually this reminds me of when Netflix claimed that they could not make a version for linux because they needed the whole system locked down. Only silverlight could do the trick, and it was a demand from Hollywood. Finally, TI made a chip where they hard-wired DRM into it to satisfy the claimed demands of Hollywood so that the first Android device finally got Netflix. Fast forward a few months later, Netflix was available on all Android phones (apparently they could not withstand the anger of all the customers being left out). Only weeks later they started to provide patches for Netflix on CyanogenMod, at the time a totally DRM free version of Android.
I am sick and tired of intelligent people telling me that it is all hopeless, and that we should just give up. Giving up is not an option.
> Right. <sarcasm>Let's add Apache and BSD liceses to the list, too (because, you know, they are GPLv3-compatible).</sarcasm>
This is beneath you, you should know GPLv2+ provides the code "at the recipients option" under GPLv3. That is very different from blending in GPL compatible code. For all practical purposes you can regard GPLv2+ as providing the same rights as GPLv3+, only differnces is that you can mix it with GPL2-only code, and fork it to GPL2-only code.
> Today… six years after release GPLv3 is still used by many times smaller number of projects than GPLv2 and even if you combine GPLv2 and GPLv3 you still have much smaller number that GPLv2 had ten years ago.
And why do you think this is? I can only see two important factors in keeping GPL2 alive. One is that Linus fought it, and he is pretty influential. The other is that FSF made GPLv2 and GPLv3 incompatible, a terrible mistake that makes me want to cry.
Posted Jan 29, 2014 23:54 UTC (Wed)
by nix (subscriber, #2304)
[Link] (1 responses)
See any file at all in libstdc++, and the Runtime Library Exception.
A license with this exception is GPL- and LGPL- and for that matter BSD-compatible, but it's not the GPL any more.
Posted Jan 29, 2014 23:56 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Jan 27, 2014 22:39 UTC (Mon)
by tialaramex (subscriber, #21167)
[Link] (18 responses)
Those aren't subsidies. As with similar deals in the used car industry what's happening is that you're paying over the odds for a small unsecured loan, but it "feels" like you got something for free.
Cell service is worth maybe $15-20 per month. If you're paying more (or if your carrier tries to persuade you that shouldn't include say, text messages or Internet access which are clearly just service) then they are making a lot of money off you. If you're paying more to get a "free" phone then the phone wasn't free, was it? If you find you're paying $30 per month over two years for the "free" phone over and above what the actual service is worth, that phone cost you about $700 AND locked you into a deal you might have wished to change.
If you can afford a "subsidised" phone you could have more easily afforded to borrow money to pay for the phone outright.
Posted Jan 28, 2014 0:05 UTC (Tue)
by khim (subscriber, #9252)
[Link] (17 responses)
Posted Jan 28, 2014 0:19 UTC (Tue)
by dlang (guest, #313)
[Link]
Let's hope t-mobile is successful and the other big carriers end up doing the same.
Posted Jan 28, 2014 10:41 UTC (Tue)
by Del- (guest, #72641)
[Link] (10 responses)
Please document this.In reality, tethering can be blocked in numerous ways, locking down a device is not necessary.
Posted Jan 29, 2014 7:12 UTC (Wed)
by dlang (guest, #313)
[Link] (9 responses)
Not really. If the mobile device doesn't tell the carrier that it's doing tethering, and instead uses the kernel masquerading functionality, the carrier can't tell what data originated from the phone and what originated from the network.
The most they can do is to be a mitm and look for things like user-agent values and block ones that they think are not on the phone (which breaks things for people who need to change their phone's user-agent to deal with a broken website)
David Lang
Posted Jan 29, 2014 18:32 UTC (Wed)
by Del- (guest, #72641)
[Link] (8 responses)
It is quite easy to have the phone delivered with various software locks to the consumer. Of course, hackers can circumvent it, especially if it is open source. For instance the carriers over here preloads the phones with their own apps, and you can not remove them in the app manager. How many go through the trouble of circumventing it? I did, but I am willing to bet very few. A hacker easily circumvents just about any lock on an iphone too, and this is fairly well known.
What I am trying to say is that all you need to do is to make it awkward to enable tethering, and the lock will work for 95% of the users. Even make it a breach of the contract, and even fewer will attempt circumventing it. Among those 5% circumventing it at least a couple of them would circumvent it regardless of what you do. In conclusion, I don't see any real issue for vendors/carriers. They get their money typically through two year contracts, and who really needs to lock down anything when you have a two year contract securing all payback.
There is no question that many of the device vendors want the freedom to lock down devices, and hence do not want GPLv3 in parts of the software stack like boot-loader or init-system. Still, from what I have seen (which may or may not be representative), the vendors of network routers and NAS devices have no more issues bundling Samba than they have bundling linux. This leads me to believe that they would bundle linux too even if it was GPLv3. I may of course be wrong, and since nobody called the bluff we will probably never know.
Posted Jan 29, 2014 18:58 UTC (Wed)
by dlang (guest, #313)
[Link] (7 responses)
I say that without locking down the phone, it's easy to have tethering enabled by loading things on the phone
you reply that if the vender puts things on the phone that the user can't remove, they can prevent tethering. In my book, that's locking down the phone. If it's not locked down, the user can remove those things.
Posted Jan 29, 2014 23:01 UTC (Wed)
by Del- (guest, #72641)
[Link] (6 responses)
Posted Jan 30, 2014 1:51 UTC (Thu)
by dlang (guest, #313)
[Link] (5 responses)
I'm saying that unless you do a tivo-type lockdown of the phone, your other bundled apps won't matter (if you decide to cripple the kernel that may be harder to fix)
If users can install their own stuff without a tivo type lockdown, then they can and will override whatever lockdown your bundled apps try to force.
Posted Jan 30, 2014 8:05 UTC (Thu)
by Del- (guest, #72641)
[Link] (4 responses)
I believe we disagree here. I believe very few people will alter the OS image shipped with a smartphone, even with access to all source code. Therefore, I believe simply disabling stuff in the shipping image is sufficient to block most customers from tethering.
> If users can install their own stuff without a tivo type lockdown, then they can and will override whatever lockdown your bundled apps try to force.
As I said, people do this to iphones today, so even with a tivo type lockdown they can and will override. For a company (be it vendor or carrier), I believe the real issue is how many would do it given a certain level of inconvenience.
Posted Jan 30, 2014 10:20 UTC (Thu)
by dlang (guest, #313)
[Link] (3 responses)
Posted Jan 30, 2014 14:43 UTC (Thu)
by Del- (guest, #72641)
[Link] (2 responses)
Of course, that was why I used it as example. It is an example showing that in practise it is often impossible to lock down the device. Hence for any practical concerns whether you lock it down Tivo style or just make it inconvenient for the consumer to use it in unintended ways (like removing the tethering possibility from the system, requiring somebody to patch system internals to enable it again), can amount to the same end result for the vendor. They get their money, and they get fine grained control on what functionality the user has access to.
I have one very real life example of how ridiculous the Tivo stuff can be. As already mentioned HTC actually provides tools to unlock their devices, so you could say that those devices are not locked, but there is a level of inconvenience if you want to swap out the image it came with from the carrier. Now my daughter got a HTC Desire, and I wanted to flash a newer version of Android on it because HTC stopped providing newer versions of Android for it. I would say this is a prime example of what we are talking about here. I knew HTC provided tools, went over there downloaded the tools and started looking for documentation. I found the whole thing quite confusing, especially since it seemed geared towards windows users, and I only had linux. I ended up just deleting all of it, headed over to CyanogenMod and used their un-official tools to unlock the boot-loader, just as I did for my Tivotized Galaxy S2 earlier. You see, whether the device is Tivotized or not doesn't necessarily amount to much. Most funny part of the story? When I finally got the boot-loader unlocked, my daughter didn't want me to flash the device anyway. I usually follow the nerd slogan "if it works, fix it!", that may have something to do with it. I didn't even succeed in making my own daughter take advantage of the possibilities provided by an open device, simply because she did not trust anything but the official image from the carrier.
Moral of the story? Tivotization is plain stupid when it comes to consumers. I see no benefits for anybody. Even worse, as long as there is no software license pushing it away, I am afraid the madness will just continue for decades.
Posted Jan 31, 2014 0:04 UTC (Fri)
by dlang (guest, #313)
[Link]
I am very aware that it's impossible to stop someone who's really determined.
However, lawsuits (or threats of lawsuits) against manufacturers are frequently based on how easy they make it to get at the data
and with the DMCA making it illegal to bypass even the most inept protections, there really is a point to them from a legal point of view.
Do not get me wrong, I think that these sorts of lockdowns, along with DRM are bad for customers, they don't stop the real bad guys and hurt legitimate users.
Posted Feb 3, 2014 11:34 UTC (Mon)
by nye (guest, #51576)
[Link]
To be fair, HTC's version of Android 2.2 is far better than any stock Android I've ever used. Compared to the 4.x on my N7, it's faster, slimmer, easier to use, and less buggy. Plus all the features added in later versions are either completely worthless to me, or outright antifeatures.
Also, reflashing always comes with some degree of risk, especially if you hope to do so without resetting the device to factory defaults. Case in point: an OTA update to the aforementioned N7 a couple of months back rendered it unbootable, and I've not yet found the time to work out how to fix it without wiping it completely.
If you actually want to *use* a device for its intended purpose, rather than just having it as a toy, it's perfectly reasonable to want to keep to the path.
Posted Jan 30, 2014 22:44 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link] (4 responses)
In the EU probably a regulator would have told them to stop the "discount" bullshit years ago, but this is the US we're talking about.
Posted Jan 30, 2014 22:58 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
Posted Jan 31, 2014 0:05 UTC (Fri)
by dlang (guest, #313)
[Link]
but at T-mobile and smaller companies it has.
Posted Jan 31, 2014 11:30 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link] (1 responses)
It's hard to tell when this actually began, their "pay-for-the-phone separately" approach copying T-mobile was launched late last year, and the discount applies to people doing that too (because again, it's not really a "discount" it's just the real price without the cost of your "subsidised" phone) but it may have existed for a lot longer, that's just when they last announced a change to it.
It is (inevitably for the US carriers) more complicated than a straight $15, that's just the simple case where you have a phone and want service and keep saying "No" as they offer to pile on a tablet, a wireless dongle, international calling packages, a landline, streaming music, a sheepdog, the concept of marital fidelity, and whatever else they're selling today.
Posted Jan 31, 2014 20:55 UTC (Fri)
by dlang (guest, #313)
[Link]
Posted Jan 27, 2014 23:55 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
> It isn't done with the goal of being a form of copyleft. It's just how the community operates,
OMG, do you mean you did not even consider this issue?
What next, atheism?
Posted Jan 27, 2014 11:35 UTC (Mon)
by jezuch (subscriber, #52988)
[Link] (2 responses)
*External* APIs, yes. I think they're talking about internal APIs. Just like Linux explicitly does not support stable internal API, for [I suppose?] exactly the same reasons.
Posted Jan 27, 2014 20:29 UTC (Mon)
by Del- (guest, #72641)
[Link] (1 responses)
In the case of linux you are probably referring to the lack of an ABI to drivers, which is done quite deliberately since it is copy-left and hence drivers are supposed to also be GPL. The case for LLVM is quite different.
That said, Octave actually uses LLVM as a JIT library. This is AFAIK the usage scenario where LLVM really shines today, and hence could hardly count as an "internal" API. Are you just guessing in the dark here, or have you actually checked it out? I am glad to be proven wrong, but then I appreciate a bit more content in your post.
Posted Jan 28, 2014 8:02 UTC (Tue)
by jezuch (subscriber, #52988)
[Link]
Just guessing, sorry. I'll admit mistake and let more knowledgeable people speak :)
Posted Jan 27, 2014 22:28 UTC (Mon)
by nix (subscriber, #2304)
[Link] (35 responses)
This sounds incredibly stupid. Stable API's is the back-bone of any successful open project.
Posted Jan 28, 2014 11:44 UTC (Tue)
by Del- (guest, #72641)
[Link] (34 responses)
Maybe you did not read my answer two posts above? If you have anything to add, please answer there. I am not fond of repeating myself in the same thread.
Posted Jan 28, 2014 15:36 UTC (Tue)
by PaXTeam (guest, #24616)
[Link] (33 responses)
Posted Jan 28, 2014 18:40 UTC (Tue)
by Del- (guest, #72641)
[Link] (24 responses)
Posted Jan 28, 2014 23:11 UTC (Tue)
by PaXTeam (guest, #24616)
[Link] (23 responses)
Posted Jan 29, 2014 7:01 UTC (Wed)
by Del- (guest, #72641)
[Link] (22 responses)
Posted Jan 29, 2014 9:43 UTC (Wed)
by PaXTeam (guest, #24616)
[Link] (21 responses)
> This sounds incredibly stupid. Stable API's is the back-bone of any successful open project.
then nix told you about gcc (and you surely know about the linux way of not having a stable kernel API) to which you responded with:
> Maybe you did not read my answer two posts above? If you have anything to add, please answer there.
in other words you didn't say anything useful, you neither provided evidence against nix's claim nor did you agree with it (and hence take back your original nonsense claim).
now that i spoonfed your feeble mind, can you provide some coherent thoughts on this stable API thing? do you know what an API is? do you know what it is in gcc/etc? do you know whether they're stable or not? do you know why? all interesting questions but then i shouldn't expect much from a troll.
Posted Jan 29, 2014 10:33 UTC (Wed)
by Del- (guest, #72641)
[Link] (20 responses)
Yes I said stable APIs are the back-bone of successful open projects, and I mean it. Linux has a rock stable API, as does glibc. Breaking backwards compatibility is typically seen as a bug. I just wish that had been common practise for the rest of the GNU/Linux stack, whether it is sound, gui-toolkits, process communication, etc.
When it comes to linux drivers, we are not talking about an API, but about an ABI. It is somewhat different, but as I said, there is not supposed to be an API for external use there. People are expected to include the drivers as part of the distribution. This is different.
Talking about GCC, it does make sense to share what you mean with API. For most people I believe they are occupied by linking issues, which in the case of C++ refers to the ABI implemented by GCC that was originally specified by Intel for their Itanium architecture. It made it possible for the likes of Intel to make compilers that could even link in statically compiled GCC stuff. There were issues preventing this from being rock solid with C++, but I believe it worked out reasonably well. You find a reference here: http://refspecs.linuxbase.org/cxxabi-1.83.html
In the case of nix, I can of course guess that it is a reference to the newer plugin API, for which you find documentation here: http://gcc.gnu.org/wiki/GCC_PluginAPI
You see, the example from Octave using LLVM as a JIT library, is AFAIK, and intended usage of LLVM by an external project, and then whether the API is stable or not is a rather important issue, at least for me. I may of course be wrong, that Octave's usage was never intended for external usage of LLVM, so that we are more talking about an internal API, which in my mind is a different ball game.
Posted Jan 29, 2014 15:43 UTC (Wed)
by andreasb (guest, #80258)
[Link] (2 responses)
That the ABI for kernel modules changes is so far out of the question that it is hardly noteworthy. Even a simple configuration change can change the ABI.
Posted Jan 29, 2014 19:23 UTC (Wed)
by Del- (guest, #72641)
[Link] (1 responses)
Sigh, yes. Linux has two APIs, the internal and user space. APIs are at the source code level. The concept is quite general, but it often consists of calls to library routines. An ABI is an interface between binaries where one is typically a library or an operating system. In the case of linux there has been a lot of focus on that lack of an ABI towards drivers, or kernel modules in linux lingo. The lack of a stable ABI for drivers typically means that you need access to source code for the drivers in order to support upcoming kernels, since you often need to recompile. Regarding the linux drivers, most people care about the ABI, not the internal linux API, so I thought that was more relevant for the discussion. People often mix the concept of API and ABI, but as I already have said, they are not the same although they are clearly related concepts. Not sure how this confusion came about, but I guess I had one post where I was unclear.
Posted Jan 29, 2014 20:32 UTC (Wed)
by PaXTeam (guest, #24616)
[Link]
there's no lack of ABI, it's mostly defined by the usual GNU toolchain and some kernel side decisions and it doesn't really change, certainly much much less than the API.
> or kernel modules in linux lingo
no, not all kernel modules are drivers.
> The lack of a stable ABI for drivers typically means that
you don't know what you're talking about again. the ABI is quite stable, what is not stable is the API and no amount of recompilation will help if the source code itself is not patched to accomodate the changed API.
> Regarding the linux drivers, most people care about the ABI, not the internal linux API, so I thought that was more relevant for the discussion.
most people who care about the API actually understand the difference.
> People often mix the concept of API and ABI,
you don't say ;).
> but as I already have said, they are not the same although they are clearly related concepts.
this will be a fun day, keep it coming! ;)
Posted Jan 29, 2014 19:23 UTC (Wed)
by PaXTeam (guest, #24616)
[Link] (3 responses)
that's about the only statement you got right ;).
> Please avoid the ad hominems.
not before you learn to follow your own advice.
> Yes I said stable APIs are the back-bone of successful open projects, and I mean it.
so according to you linux and gcc are not successful.
> Linux has a rock stable API
wrong. the kernel's API has nothing to do with the syscall interface it provides to userland. the former is for kernel code, modules included, not userland and is intentionally not stable.
> Breaking backwards compatibility is typically seen as a bug.
linux does it all the time. please submit your bugreport to lkml. we all need a good laugh every now and then after all ;).
> When it comes to linux drivers, we are not talking about an API, but about an ABI.
wrong. you don't have a clue what these words mean, do you ;).
> It is somewhat different,
they're not somewhat different, but very different things. they refer to different levels of abstraction.
> but as I said, there is not supposed to be an API for external use there.
this sentence makes no sense whatsoever.
> People are expected to include the drivers as part of the distribution.
what does being in-tree vs. out-of-tree even have to do with the kernel API?
> This is different.
what is different?
> Talking about GCC, it does make sense to share what you mean with API.
are you saying that you didn't understand nix's response about said API? why did you even respond then? besides trolling, that is. and i did point you at said API, you can read the code or references to the code in that header.
> For most people I believe they are occupied by linking issues,
wrong, the API is not about 'linking issues'.
> which in the case of C++ refers to the ABI implemented by GCC
wrong, the gcc API that nix talked about has nothing to do with any C++ or other ABI. but then you already knew that difference, didn't you? ;)
> In the case of nix, I can of course guess that it is a reference to the newer plugin API
there's no gcc plugin API. there're a few plugin specific functions to register callbacks but other than that all public gcc symbols are available for plugin (ab)use. and this interface (functions and data structures, macros, etc) is not stable at all as you can see from my feeble attempt.
> By now I should have checked of course, but maybe you can share with me, is this the API you are struggling with?
i'm not the one struggling here with anything ;).
> I haven't worked with that API myself,
then on what grounds did you react to nix's statement?
> but I have seen GCC developers being sorry for not having it more stable.
that's because you don't understand anything about this whole programming business yet it seemingly doesn't prevent you from posting nonsense after nonsense. you're still back at square one: figure out what API means, figure out what it is in the gcc world (never mind linux and others) and then figure out how stable they are and why. so do your homework before you spread your stupid claims about API stability.
> You see, the example from Octave using LLVM as a JIT library, is AFAIK, and intended usage of LLVM by an external project,
i can't imagine how anything programming related could be important for you ;). as for the API exposed by LLVM, it's the same deal as with gcc, all public symbols are there to take (over 40k of them at last count) and there're changes in there every day.
> I may of course be wrong, that Octave's usage was never intended for external usage of LLVM, so that we are more talking about an internal API, which in my mind is a different ball game.
what is LLVM's internal API? and what is 'external usage of LLVM'? and how's this 'external usage' different from LLVM's internal API?
Posted Jan 29, 2014 21:20 UTC (Wed)
by Del- (guest, #72641)
[Link] (1 responses)
"The kernel user-space API is the API that allows programs in user space to access system resources and services of the Linux kernel. This API, by choice, never breaks."
> wrong, the gcc API that nix talked about has nothing to do with any C++ or other ABI.
For GCC the APIs most people are interested in are in the libs. I showed the ABI part, but there is also an API for C++ too of course, here you are: http://gcc.gnu.org/onlinedocs/libstdc++/api.html
You'd better run along and edit wikipedia though, my patience with you is up.
Posted Jan 29, 2014 22:36 UTC (Wed)
by PaXTeam (guest, #24616)
[Link]
that's the *userland* API (syscalls), and not the kernel's API (which is used by kernel code, including modules, both in-tree or out-of-tree). which part of it is not clear to you? ;)
> For GCC the APIs most people are interested in are in the libs.
irrelevant, you were not biching about this kind of API regarding LLVM either, so don't try to change the subject. and the C++ ABI (i bet you don't know what that is either) was irrelevant here as well, noone was discussing it.
> Does even GCC define an internal API?
what is an 'internal API'? what makes it 'internal'?
> AFAIK, internal APIs are typically not stable, so not sure how relevant they are for this discussion at all.
because you were bitching about the unstable nature of the same kind of 'internal API' of LLVM as something bad. you can't have it both ways, that's what everyone's been trying to explain to you.
> The starting point for this discussion was usage of LLVM by external projects.
no it wasn't. rather it started with you making this claim:
> This sounds incredibly stupid. Stable API's is the back-bone of any successful open project.
and you were shown counter-examples (all GPL projects btw) and you still didn't recognize how idiotic your claim is. in other words, you were trolling and i'm having great fun at exposing it ;).
> So no, I have no clue as to what GCC API you go on about.
that's because you don't know what an API is. go educate yourself, it'd be a much better use of your time than trolling.
Posted Jan 30, 2014 0:17 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Jan 30, 2014 0:15 UTC (Thu)
by nix (subscriber, #2304)
[Link] (12 responses)
The GCC plugin API described on that page is merely a way by which dlopen()ed libraries can interpose themselves into the compiler's execution. Once there, they can (and generally must) inspect the program's intermediate representation and (possibly) modify it. The generation and manipulation of that intermediate representation is the true API that plugins must conform to, and it is *huge*. I mean, really huge, particularly if the plugin tries to change anything.
We're not just talking GENERIC and GIMPLE <ftp://gcc.gnu.org/pub/gcc/summit/2003/GENERIC%20and%20GIM...> (obsolete, of course, it is more complex now) and the lower-level RTL IR, we're not just talking the explicit dependencies expressed in the pass manager (many of which have names like 'late interprocedural optimization' where you have to know what 'late' means to understand it), we're not even talking just about the dependencies expressed in comments in the code, of which there are many -- but there are also wholly *implicit* dependencies, e.g. that a later pass implicitly expects particular properties of the representation provided by an earlier pass. Sometimes (much less often than in the past, but still true) the earlier pass doesn't even *know* it's providing those properties: they are only there by chance, and the later pass is also depending on them by chance: this is particularly likely to be true of any pass dating from the early 90s or before. That means they can be broken by chance! Worse yet, some properties are depended upon by only some machine definition files, which means they can be broken for *particular ports*, which you probably can't build.
Plus, of *course* it's continually changing: virtually anything other than a bugfix or a simple target or very simple language is going to add *some* new requirement somewhere, or perturb something somehow, and since plugins are necessarily exposed to virtually everything (not just 'can see virtually everything' but 'need to use a lot of it to be of any real use'), plugins can be, and are, perturbed by virtually everything.
(Now I'm overstating things here: lots of changes don't break any plugins at all, and lots of plugins will not be broken by a large percentage of changes that may break some plugins. But there are changes, and they are not rare, which necessarily break the lot, and possibly in quite subtle ways. This is true of the rest of the compiler as well, of course, since plugins are literally just dynamically loaded bits of the compiler: but the rest of the compiler has a 50,000+ test testsuite to make sure it doesn't regress. Plugins don't.)
Posted Jan 30, 2014 0:51 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Jan 30, 2014 1:11 UTC (Thu)
by PaXTeam (guest, #24616)
[Link] (2 responses)
unless of course you run said regression tests with your plugins loaded :).
Posted Jan 30, 2014 13:56 UTC (Thu)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Jan 30, 2014 19:11 UTC (Thu)
by PaXTeam (guest, #24616)
[Link]
Posted Jan 30, 2014 7:27 UTC (Thu)
by Del- (guest, #72641)
[Link] (7 responses)
In the sense that I have not used the GCC plugin API, and cannot vouch for it's implementation. I thought I made that clear already, so I see no reason for you to fall down to Pax level in your rhetoric. I do very well know what an API is, but realise that bringing ABIs into the discussion should have been accompanied by a long explanation to avoid any possible confusion. I could of course repeat about three times more that I am sorry for any confusion caused, and that I should have thought twice and thrice how to formulate any sentence related to ABIs. Sorry.
When it comes to GCC it seems fairly well accepted that it is not a particularly modular code base, and this seems to be one of the key areas being prioritized for the next releases (making it more modular that is, I really cannot be too clear here if I want to avoid ad hominems). I believe this should enable an easier implementation of a stable and useful plugin API (I am making the assumption that you actually referred to usage of the plugin API to hook into GCCs optimizer routines in your post, terribly sorry if you did not). I appreciate your notes in this post, and find them infinitely more interesting than your first post. It also seems to portray how using GCCs plugin API can lead to similar cases as experienced by the Octave guys (I said similar not identical mind you, I really hate when I have to make this kind of comments because the whole discussion turns into an unpleasant witch hunt with strawmen on each corner).
Now please bring the discussion out of the pit hole instead of mud bathing with pax. Again, sorry for any confusion I may have caused, but this thread has continued a bit too long with a bit too many sloppy posts for me to stay sharp at every corner.
Posted Jan 30, 2014 14:00 UTC (Thu)
by nix (subscriber, #2304)
[Link] (6 responses)
Posted Jan 30, 2014 15:46 UTC (Thu)
by Del- (guest, #72641)
[Link] (5 responses)
Yes, I can see two posts where I was very unclear, but unfortunately there is no edit button here, and I really did not get what pax was aiming at.
> This is not a stable API in any real sense, nor do I see how it can ever become one.
Thanks for the information. Sounds like the api does little more than expose the internals of GCC. Such an approach creates full flexibility for the plugins, but I do not think it s a sustainable design for a plugin API. As I said, I believe stable *external* APIs is one of the trademarks of successful open projects. But then somebody would need to design that API for GCC plugins as a stable layer between the plugins and the GCC internals.
Posted Jan 31, 2014 15:10 UTC (Fri)
by nix (subscriber, #2304)
[Link] (4 responses)
Posted Jan 31, 2014 15:46 UTC (Fri)
by Del- (guest, #72641)
[Link] (3 responses)
Posted Feb 3, 2014 10:16 UTC (Mon)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Feb 3, 2014 18:20 UTC (Mon)
by PaXTeam (guest, #24616)
[Link] (1 responses)
Posted Feb 4, 2014 14:54 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Posted Jan 30, 2014 0:03 UTC (Thu)
by nix (subscriber, #2304)
[Link] (1 responses)
The GCC API is *huge*, and probably every tenth commit to GCC changes it in some subtle way. :)
(gods. I'm agreeing with PaXTeam. Just gotta check outside to see if the stars are falling from the sky: the world is clearly overdue for ending.)
Posted Jan 30, 2014 0:38 UTC (Thu)
by PaXTeam (guest, #24616)
[Link]
yeah, it's kinda implied since without knowing all the data types/etc you can hardly make use of these functions/etc ;). that said in my experience the churn in say linux causes a whole lot more extra work for me than changes in gcc. i wish i could get most of my forward ports done with a simple compatibility header like i have for gcc (at least until they turn gimple and tree into classes :).
Posted Jan 30, 2014 0:19 UTC (Thu)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Jan 30, 2014 1:04 UTC (Thu)
by PaXTeam (guest, #24616)
[Link]
Posted Jun 4, 2014 12:28 UTC (Wed)
by mlopezibanez (guest, #66088)
[Link] (3 responses)
There are several functions in that header that could be in GCC and several comments that point out to inefficiencies of the API. Open bugs in GCC bugzilla and/or post patches in gcc-patches.
All the discussion above about licenses and what RMS does or says is a red herring. The only reason why GCC is lagging behind LLVM is lack of developers, and more concretely, a lack of full-time overall leader developers with a clear vision for the whole compiler. The number of contributors to the whole GCC including Ada, Fortran, C/C++, libstdc++, all backends, all middle-end, optimizers, and various tools in the GCC repository is LESS than the number of people that contribute to just Clang.
Posted Jun 4, 2014 13:07 UTC (Wed)
by andresfreund (subscriber, #69562)
[Link]
Posted Jun 4, 2014 14:16 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
My previous company contributed to LLVM because it's being used in-house for several projects (as a JIT for a certain matching engine). They had zero interest in contributing to GCC because its license wouldn't allow to use this JIT in products shipped to their customers.
Posted Jun 4, 2014 16:08 UTC (Wed)
by PaXTeam (guest, #24616)
[Link]
as for my compat header, see #61176. i think such a compat header doesn't belong into gcc per se. if anything, at most more attention could be paid when changing the exposed API, headers, etc so that plugins have less churn but i'm not really complaining here, it's been quite managable so far (perhaps my only real gripe is that #41757 was ignored at the time).
Posted Jan 26, 2014 13:35 UTC (Sun)
by RamJam (guest, #95209)
[Link] (2 responses)
Also Apple themselves are obviously running a private branch/plugin since they have yet to contribute the A7 soc support back to the open LLVM branch (or did I miss it? I read about this back in early september 2013), meanwhile it's supported in the proprietary LLVM/Clang version shipped with XCode on OSX from what I understand.
Posted Jan 29, 2014 1:47 UTC (Wed)
by silvas (guest, #87887)
[Link] (1 responses)
That's a good question. The answer is that LLVM/Clang do not have an effective plugin system. The rapid API churn means that plugins are just as tightly coupled (from a development perspective) to the mainline as a private branch, so there's no real benefit. Any code that isn't in the public repository needs constant supervision since at any moment it may break due to an API change; the only safe place for code is in the public repository.
Also, the plugin system really doesn't support much. LLVM can load IR-level optimization passes as it was originally designed to do and is very modular in that regard, but the things that are kept on private branches are not optimization passes. Clang's plugin API is a joke and not really useful beyond maybe providing an extra compiler warning (and it's a deployment nightmare).
> Also Apple themselves are obviously running a private branch/plugin since they have yet to contribute the A7 soc support back to the open LLVM branch (or did I miss it? I read about this back in early september 2013), meanwhile it's supported in the proprietary LLVM/Clang version shipped with XCode on OSX from what I understand.
I'm not sure what you mean by "A7 soc support". Besides the AArch64 core (see below), I doubt that there is anything else of general public utility that they would need in LLVM for the A7. Realistically, you can only compile for A7 with the Apple-provided tools (whether this is good or not is a separate discussion).
ARM developed an AArch64 backend in the public tree. Chris Lattner wrote that Apple will integrate their private backend "the right way" with the public one <http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-September...>. I'm sure it is going to be a nightmare for them to maintain that private branch. I can only assume that Apple gained a large business/marketing advantage (millions of $'s) from keeping it a secret in order for them to expend so much developer time developing the backend (and now the merge pain of keeping two backends in parallel). I assume that once the upstream backend supports what they need and they have qualified it, their private backend will just be thrown away. Alternatively, their private backend may be technically superior (Apple has many of the most experienced LLVM backend devs), in which case they will probably (at great cost to them in developer time) incrementally improve the upstream backend to bring it up to parity and then throw away the private one.
Posted Jan 30, 2014 0:27 UTC (Thu)
by nix (subscriber, #2304)
[Link]
You can impose useful properties that everything expects (being in SSA form, for instance) but that doesn't mean that you can dictate *all* properties. So the problem of adding or reordering compiler passes, particularly passes that change the program rather than just emitting warnings or spying on the compiler's state, remains an intractable bugger.
Posted Jan 25, 2014 18:55 UTC (Sat)
by freealter (guest, #4335)
[Link] (9 responses)
It makes contributing to GCC harder, as for some organisations transfering copyright is unusual and not so easy. For individual developpers, it means administrative work also.
It also weakens the strength of the GPL licence of GCC. If for any reason the Free Software Foundation wishes to change the licence of Gcc, she can. Obviously, it is a very low probability scenario. Nevertheless, it is possible.
Anything slowing down the easyness to take part to Gcc development is bad from a collaboration point of view. And to some extent, it may explain the dynamism of the developments around LLVM.
Posted Jan 25, 2014 19:17 UTC (Sat)
by foom (subscriber, #14868)
[Link] (1 responses)
Posted Jan 25, 2014 20:31 UTC (Sat)
by pbonzini (subscriber, #60935)
[Link]
Posted Jan 25, 2014 20:31 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (6 responses)
Actually, if I understand correctly, the FSF can *N*O*T* change the licence of GCC (very much). Part of the copyright assignment is a "promise" by the FSF that any new licence will support the four freedoms.
Any new licence that breaks that promise, breaks the copyright assignment, and means the new licence is not valid.
Cheers,
Posted Jan 25, 2014 21:46 UTC (Sat)
by gdt (subscriber, #6284)
[Link] (5 responses)
Posted Jan 25, 2014 22:15 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (4 responses)
And it was pointed out that another judge rewrote a contract when a publisher went bust, that effectively gutted an author's rights. The original contract gave the author a cut of the gross income. The Judge changed the contract to give him a cut of the net after the buyer's expenses...
What's to stop a bankruptcy judge pulling the same stunt if they get their hands on the FSF's assets?
Cheers,
Posted Jan 26, 2014 13:23 UTC (Sun)
by hummassa (guest, #307)
[Link] (2 responses)
With some five-minutes googling, I found this:
http://dreamsongs.com/ihe/IHE-110.html
that seems to confirm my recollections.
Posted Jan 26, 2014 19:31 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (1 responses)
Which was that - in at least TWO cases documented on Groklaw - the assets sold by the bankruptcy judge included a whole bunch of rights that the bankrupt entity didn't actually have!
Cheers,
Posted Jan 27, 2014 15:43 UTC (Mon)
by hummassa (guest, #307)
[Link]
Posted Jan 26, 2014 15:48 UTC (Sun)
by bkuhn (subscriber, #58642)
[Link]
A bankruptcy situation with a charity is very different from that of a for-profit company. I suspect most lwn reads are very familiar with the latter but not with the former. The situations are quite different.
Posted Jan 26, 2014 18:02 UTC (Sun)
by bkuhn (subscriber, #58642)
[Link]
Posted Jan 27, 2014 2:40 UTC (Mon)
by aboutthebsds (guest, #95107)
[Link] (1 responses)
Posted Jan 27, 2014 8:36 UTC (Mon)
by cortana (subscriber, #24596)
[Link]
Posted Jan 31, 2014 4:14 UTC (Fri)
by cmccabe (guest, #60281)
[Link] (14 responses)
The reality is, though, there are lots of very long-running open source projects with permissive licenses. Hadoop is less than a decade old, of course, but the BSDs are far older.
Building a sustainable open source project is more about good project leadership, building a community, and solving a problem that people care about. Licenses only give you the ability to do one thing-- sue people. You can't sue people into loving you, or build a community with lawsuits. You don't improve your marriage by filing a divorce lawsuit. Once the lawyers get involved, it's over.
Some people (not all) seem to think that copyleft somehow helps to avoid forks-- which is nonsense, of course. Gcc itself had a very famous fork, which ended up replacing the mainline. If you want to prevent proprietary forks (or even just regular old forks), the best thing to do is to manage the project sensibly, so that mainline is something people like and want.
I do agree with a lot of stuff RMS has written over the years, including the four freedoms. But I don't think licenses are a good way to achieve those goals.
As for patents-- they are a problem, but licenses don't solve them either. For example, a company that's legally forbidden from asserting patents on GPLv3'ed software that it contributes to can simply sell the patent to a troll. Bingo. The troll litigates, and the company's hands are clean. It's better to have patent grants in licenses than not (and Apache v2.0 does), but we shouldn't pretend they will solve all of our problems. The best approach to patents is just to raise awareness of the need for reform (and hopefully abolition) of software patents. The second-best is to release a lot of open source software that can serve as prior art.
Posted Jan 31, 2014 4:32 UTC (Fri)
by dlang (guest, #313)
[Link] (3 responses)
Posted Jan 31, 2014 21:04 UTC (Fri)
by cmccabe (guest, #60281)
[Link] (2 responses)
The biggest issue with kernels has always been getting drivers for all the hardware out there. I have to admit that the GPLv2 might have been helpful in giving a few hardware companies a shove in the right direction in this regard. Of course, their true interests lie in getting a good driver for their code upstream, but a lot of big hardware companies (not naming any names here) are shockingly bad at developing drivers, let alone looking towards their long-term software interests. I remember one company that had multiple forks of an enormous, poorly written proprietary driver code base, just to support a single device that came in a few very similar configurations. Over time, the forks drifted apart as bug fixes were applied to one and not the other, or parts were rewritten.
On the other hand, licensing wasn't very effective in getting NVidia to open up to the community. Only Linus giving them the finger could do that :)
Posted Jan 31, 2014 22:15 UTC (Fri)
by Del- (guest, #72641)
[Link]
Then please explain Debian's success, or Samba's success, or Red Hat's success or OpenWrt's success or KDE's success. It is not about the dictator. Other models can work, including consensus or democratic.
> Only Linus giving them the finger could do that :)
He could give them the finger because linux is GPL. Without GPL, the finger would just be rude.
Posted Jan 31, 2014 23:46 UTC (Fri)
by dlang (guest, #313)
[Link]
I was just talking about the reasons for people preferring the GPLv2 to BSD and why using the BSDs as an example of they the GPLv2 giveback is actually pointing to something that GPL people use an example of why it's needed and the BSD approach isn't good enough.
There have been a LOT of BSD based appliances over the years, many of them doing amazing things, but there has been extremely little that has come back from those to the community.
Meanwhile, the GPL enforcement (and the threat of it) has caused the manufacturers of many Linux based devices and appliances to provide drivers back to the community.
Posted Jan 31, 2014 12:22 UTC (Fri)
by Del- (guest, #72641)
[Link] (9 responses)
Thank you, I am very grateful for all your hard work, and I hope I get hands-on with code from both projects in the years to come.
> The reality is, though, there are lots of very long-running open source projects with permissive licenses. Hadoop is less than a decade old, of course, but the BSDs are far older.
I think that is the point. There is an overwhelming empirical evidence demonstrating that copy-left is the more efficient way to go if you want to build a community. HDFS and Hadoop seems to be a playground for the global companies. I believe independent developers still is the largest contributor to linux, even with all the heavy investment from big companies. Move over to Debian, and it seems Canonical is the only player in danger of corrupting anything. The code really is in the hands of the developers, and there is no company that can change that.
There are successful projects from the BSD camp, Apache and OpenBSD being the prime examples. I don't know too much about the history behind Apache, but for OpenBSD I am pretty sure you are absolutely right, one persons devotion and idealism made it happen. Problem is, there are very few people in this world with Theo De Radt's devotion to being open. Even within GNU projects you will probably find developers that don't really care whether the code is copy-left or not, and who easily could go and do some proprietary additions for a company. Whenever people get together there are differing views. This thread has demonstrated very clearly that even among open source developers there are wildly different conceptions about what is OK or not. It is also fairly well established that people working together are more efficient when they know what the ground rules are and what their role is. The GPL really helps establish both, the BSD on the other hand is more akin to anarchy. You could of course just appeal to people knowing what the right thing to do is, and that everybody understands that proprietary development is stupid or evil or something. Or spend a lot of time trying to convince everybody about what your project is about (which I believe Theo does). You can think of the GPL as a contract, it is your guaranty that what ever happens, you can take your code with you and still be part of the community. Chris Mason is a very good example of that I believe.
I am not saying GPL is sufficient. When companies require exclusive copyright, then GPL quickly faces many of the same dangers BSD projects do. As I mentioned earlier in the thread, it is basically the open core model that is the issue here, and it's tendency to drive away collaborative efforts.
> Building a sustainable open source project is more about good project leadership
Sorry, here I think you are being naive. Good project leadership is necessary, but not sufficient. I do not want to take any credit away from Linus, he has shown excellent leadership skills and deserves all the credit he can get. However, a major part of good leadership is to establish ground rules for everybody that enables efficient collaboration and devotion. That is where copy-left is fundamental. It makes the project management much easier.
> Some people (not all) seem to think that copyleft somehow helps to avoid forks-
Of course it does. BSD is specifically designed to enable forks, GPL is specifically designed to make people contribute. Just the choice of license sends out a signal to everybody about the ground rules. There is no reason to go around the bush here, HDFS and Hadoop is permissively licensed specifically because the main players want to enable forking. It is not because of some higher moral or idealogical stand. It is business as usual, make no mistake about that. If you don't agree on the principle, then there is three decades of empirical evidence to look at.
> Licenses only give you the ability to do one thing-- sue people.
Unfortunately suing is a necessary part of making people and companies respect the license terms. The suing itself doesn't do any good, although as Rob commented in his talk it did enable OpenWrt (and DD-Wrt for that matter). I also believe Unslung and some other less known projects could be added to that list. Since I am using OpenWrt for all my networking needs, I for one is very grateful that Rob took one year off the programming to do suing. Actually, I don't think Rob ever had a year where he contributed nearly as much to open source, he should be proud of it. It opened up copy-left to a whole new world of devices. However, that is not the important thing, the important thing is the contract it sets, people participating knows what the ground rules are. It is the collaboration it enables that is important, not the suing when people break the rules. With your analogy, you are saying marriage is meaningless because it only gives you the ability to divorce. While I know many will actually agree on that, you probably get the drift.
> But I don't think licenses are a good way to achieve those goals.
Permissive licenses has its use, and Android is a good example of its usage. HDFS and Hadoop likewise. If you want to contribute to that it is certainly your prerogative, and I am grateful for your contributions. However, for me it is out of the question spending my spare time on a permissively licensed project. It is also out of the question donating to a permissively licensed project. If I am to devote my spare time or hard earned money, I want the ground rules to be set right, and I want them to be fair. Just as importantly, I want those ground rules to be such that it maximises the success probability of the project. Licenses is in my experience one of the keys to enable that.
Posted Jan 31, 2014 20:41 UTC (Fri)
by cmccabe (guest, #60281)
[Link] (8 responses)
If we're just talking about the Linux kernel, LWN.net has done many breakdowns of who wrote what in the kernel. Paid developers are in the majority now. (There's a "75% are paid" number floating around which I think came out of a talk that Mr. Corbet gave in 2010.)
The kernel is probably a best-case scenario for independent developers, since it runs on hardware anyone can buy, and solves problems that everyone has. For things like Hadoop, independent devs just don't have a motivation to run a 1000-node cluster.
> There is no reason to go around the bush here, HDFS and Hadoop is permissively licensed specifically because the main players want to enable forking
Well, the company I work for is "one of the main players," and we have no intention of forking anything. I don't know any of the other big players who want to fork, either. Probably the closest thing is MapR, who produced a fork with a proprietary filesystem. But they have not been popular in the marketplace, since companies are reluctant to trust their data to a proprietary data store.
> Unfortunately suing is a necessary part of making people and companies respect the license terms. The suing itself doesn't do any good, although as Rob commented in his talk it did enable OpenWrt (and DD-Wrt for that matter).
Based on skimming his blog, I'm pretty sure Mr. Landley has a quite different recollection of how useful suing was... but I will let him speak for himself.
Posted Jan 31, 2014 22:02 UTC (Fri)
by Del- (guest, #72641)
[Link] (7 responses)
Indeed, with 25% I believe it is the largest contributor with some margin.
> The kernel is probably a best-case scenario
I don't think so. I'd be very surprised if even close to 75% of developers on OpenWrt are paid to work on it. I can actually only think of one, and he certainly seems independent. Have a look at various GPL projects without CLA, and I think you will find out that it is the other way around. Linux is really well funded, I cannot think of any well-known project as fortunate when it comes to corporate involvement. Please do check around, if you like I can of course try to dig up a couple of cases for you.
> Well, the company I work for is "one of the main players," and we have no intention of forking anything.
I believe you are just being naive, really. All it takes is for one of the financial crowd to take over shop, if the incentives to make a quick buck by differentiation is there. It happens everywhere. Let us take a good look at the core of the Apache project you invest your best years in. The Apache web-server. It is a prime example of a successful permissively licensed project. Yet, it still lacks a good built-in proxy solution. Varnish is one of the solutions that specialised in providing a high performance proxy solution for Apache. Among others it is used to accelerate wikipedia. The company behind Varnish make a nice profit. Sunshine story. Only about a week or so ago their new management figured out they should increase their profits (have you ever had your management pushing you to improve profits?). They got an excellent idea, let us make parts of Varnsih proprietary, then many of the freeloaders will sign up and we will increase profits over night. There is nothing wrong with that, it is simply business as usual. If there is a financial incentive, then it is very hard to fight is in the long run.
Since we are still talking about the Apache web-server, it makes sense to also look at how it fares against competition. Just like GCC it has more or less taken over all proprietary competitors, but we have this project nginx. A BSD licensed open source project that has now surpassed Apache as the most used web-server for the worlds largest deployments. Varnish actually sees nginx as a fierce competitor since it does include a performant web-cache. How did this come about, and how has BSD-licensing worked out for nginx? Well, some investors came with a lot of money a couple of years ago. Fast forward to today, it is an open core development model with hefty subscription prices if you want the really juicy parts:
> Based on skimming his blog, I'm pretty sure Mr. Landley has a quite different recollection of how useful suing was...
Yes, that is one of the reasons I took the opportunity to give him a virtual tap on the shoulder. I really believe that all the litigation that was ongoing was instrumental in opening up the network routers. I am also of the opinion that Rob's efforts really made an impact, we are talking a volume of law suits enough to wake up the players. I consider the opening of routers more of an achievement than Rob's code contribution to busybox. OpenWrt is strict about preferentially supporting devices with open drivers. Back in the days of the original wrt-54 router Broadcom was what we had and drivers were closed. For years OpenWrt had to ship images including the closed drivers. Finally things started to improve, the current list of supported devices by OpenWrt is a testament of the huge success it has been:
Posted Jan 31, 2014 22:18 UTC (Fri)
by dlang (guest, #313)
[Link] (2 responses)
no, look at https://lwn.net/Articles/578767/
it's down to 2nd or 3rd place most kernel releases and ~10-12% of development.
Posted Jan 31, 2014 22:39 UTC (Fri)
by Del- (guest, #72641)
[Link] (1 responses)
Posted Jan 31, 2014 23:16 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
[1]https://lwn.net/Articles/571379/
Posted Feb 2, 2014 0:31 UTC (Sun)
by cmccabe (guest, #60281)
[Link] (3 responses)
To be honest, I am not that familiar with either nginx or the Apache web server. I haven't worked on either. People knowledgeable in the industry have told me that you go with nginx if you want to serve simple web pages efficiently, and the Apache web server if you want features and extensibility. There is room for more than one web server in the open source world (in fact, there's room for more than two, even :)
nginx and varnish are not Apache projects, and are free to do whatever they want. If people feel they can do better than what the upstream maintainers are doing, they're free to fork, the same as any other open source project. I imagine that people quickly will, if upstream ever decides to remove features from the permissively licensed version.
Even if we agree that open core models are a bad thing (and I haven't seen any evidence that they are or are not here), the GPL doesn't protect against them. Oracle uses dual-licensing (GPL and proprietary) to offer MySQL Enterprise as a paid product. It can do this because it owns the copyright to the code, because the project has always used copyright assignment. Of course, this has produced forks, and now MySQL's popularity seems to be waning (although who can say what the future holds?)
To summarize: the market interprets bad licensing or bad project management as damage, and routes around it.
Posted Feb 2, 2014 1:07 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
Posted Feb 2, 2014 10:52 UTC (Sun)
by Del- (guest, #72641)
[Link] (1 responses)
I do, it saddens me if you got any other impression. Just as I respect Theo De Radt and OpenBSD's work. I believe they have the best intentions when it comes to software development. However, they have chosen a model that caters to the vendors of proprietary software at the expense of the free software community. It is not a model that is well suited for building communities.
> To be honest, I am not that familiar with either nginx or the Apache web server.
If open development is important to you, I suggest you do.
> nginx and varnish are not Apache projects
No, but they share the same licensing model. Moreover, Varnish would probably be GPL and an integrated part of the Apache web-server if only Apache used the GPL license. (yes, the same company that gave birth to Varnish chose to contribute directly to copy-left projects) So you see, Apache being clear about their ideology doesn't necessarily solve the issues related to permissive licensing. As I said though, I do see the Apache web-server and OpenBSD as prime examples of successful permissively licensed projects, just pointing out that even there we see the problems surface. Move over to a plethora of other BSD projects and it really gets depressing.
> the GPL doesn't protect against them. Oracle uses dual-licensing (GPL and proprietary) to offer MySQL
I already mentioned that case a couple of posts up. To repeat, GPL projects with CLA (i.e., copyright transfer agreements to software companies) face the same dangers as permissively licensed projects. There is plenty of empirical evidence supporting that too. Canonical is about to learn a hard lesson on that, seems few free developers are taking the bait.
> To summarize: the market interprets bad licensing or bad project management as damage, and routes around it.
The management part is important regardless of license. However, GPL enables more democratic models than other licenses. Looking beyond linux, democratic/consensus oriented models have actually proven quite effective in the long run.
The market wants the developers of free software, but they do not want the commitments. That is why various software houses are attempting to move things over to permissive licensing. They want you to believe that it doesn't matter. Just to repeat, there is nothing wrong with that, it is business as usual. My problem is when those same software houses try to muddy the waters by brain-washing developers into believing that copy-left or permissive doesn't matter. It does matter. We have three decades of overwhelming empirical evidence to show it. It really saddens me to see that history is so quickly forgotten.
Posted Feb 2, 2014 16:30 UTC (Sun)
by raven667 (subscriber, #5198)
[Link]
Every generation is born without history, you can try to teach them but there can be no visceral appreciation of the factors which caused things to be the way that they are until the new generation experiences failure of those systems first-hand, then learning can happen.
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
> elimination of global state, and support for use of GCC in a JIT library,
> led by Andrew MacLeod and David Malcolm.
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Wol
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
GCC plugins, derived work, mere aggregation
> that doesn't mean that it's derived from the GCC codebase.
> the plugin together with GCC
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Wol
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Here is a challenge for you: design a (fictitious) license which lets
proprietary software use LLVM in pretty much any way they want, yet prevents GPL software from doing the same.
Simple: insist that a particular political message (the equivalent of a GFDL Cover Text or Invariant Text) is kept in any source code files as a comment. This is clearly an extra restriction as far as the GPL is concerned, but has no practical implications.
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
code. Free software released under a pushover license is available
for us to use, but available to our adversaries just as well."
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Rob, you mentioned Apple going away from GPL over version 3. From what I have seen this not correct.
Just what are your talking about? Apple was not happy with GPLv2 but accepted it and compiled with it. Kicking and screaming but complied. GPLv3, on the other hand was banned outright (that's why Apple used GCC 4.2 for years till LLVM was more-or-less ready, that's why it still uses bash 3.x, etc).
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
> I don't think Apple ever accepted GPLv2, or any other copy-left license.
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
http://gcc.gnu.org/ml/gcc/2005-11/msg00888.html
http://gcc.gnu.org/ml/gcc/2005-11/msg01112.html
To me it seemed the sentiment was rather positive in all camps. However, the copyright transfer seems to never happen, and this is the latest I found on that issue:
http://gcc.gnu.org/ml/gcc/2006-03/msg00706.html
This was now four months later. It may of course be that the early work on GPLv3 had something to do with it, but if so, I saw no hint of it. It seems to me that the process never came past the copyright transfer agreements.
it does give support to those who see GPLv3 anti-Tivo clause as a problematic point for embedded vendors. Note for instance that Cisco seems to be OK with GPLv3 as long as it is not in the more critical parts of the OS (with critical I assume boot-loader, init-system and kernel counts). You will find a number of the sponsors of linux foundation on the concerned parties, so I assume linux was under as least as much pressure to not go with GPLv3.
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
The gap is still huge. See this post : http://gcc.gnu.org/ml/gcc/2014-01/msg00230.html
Indeed! The clang "vectorizer" chokes on anything that's slightly harder to digest: http://llvm.org/bugs/show_bug.cgi?id=16358. Reported against clang 3.3, but clang 3.4 is no better.
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Architecture support ?
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
http://nvidianews.nvidia.com/Releases/NVIDIA-Contributes-...
https://developer.nvidia.com/cuda-llvm-compiler
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
http://gcc.gnu.org/ml/gcc/2013-11/msg00410.html
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00842.html
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
> Exactly - not usable without nonfree software.
I'm not sure that there is really a difference..
s/some/nearly all/
Wol
This whole discussion started because ESR had some information that was at least five years out of date: he thought that GCC was deliberately nonmodular and unfriendly to extension to block use by proprietary code. But the legal barriers to GCC plugins were removed long ago, and this was negotiated in a way that was satisfactory to both RMS and to gcc developers way back in 2007.
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
> both compilers. It's a good thing
Stallman on GCC, LLVM, and copyleft
If GCC wins, then nobody wins, as it will stagnate.
Wol
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
> that RMS didn't want it to be more modular
would not cause this problem. It just needs someone to write the code."
https://lists.gnu.org/archive/html/emacs-devel/2014-01/ms...
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
http://gcc.gnu.org/ml/gcc/2013-11/msg00410.html
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00842.html
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Well, there's some good news.
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Wol
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
but I want free software compilers to always be in the lead.
Wol
but I want free software compilers to always be in the lead.
but I want free software compilers to always be in the lead.
Wol
but I want free software compilers to always be in the lead.
Wol
but I want free software compilers to always be in the lead.
but I want free software compilers to always be in the lead.
but I want free software compilers to always be in the lead.
but I want free software compilers to always be in the lead.
but I want free software compilers to always be in the lead.
> find loopholes and developers to implement workarounds.
Stallman on GCC, LLVM, and copyleft
The facts are that for two years, out of GCC's 28 years of development, a bunch of developers developed the GCC codebase in a parallel repository. Both projects were GPL'd, and both development teams strongly supported free software and the FSF. The EGCS fork lead to a bunch of technical improvements, and they are now part of GCC.
And I think that this may have been the largest single long-term benefit of the XEmacs/Emacs fork: the Egcs developers painstakingly avoided taking any steps that would have prevented a remerge of the fork in spite of not being in synch with the FSF's and/or Richard Stallman's objectives.
I doubt that this would have worked in the way it did without the lessons from the big Emacs schism.
And I very much commend the temporarily forked community for the discipline they exercised in order not to complicate a future merge.
Stallman on GCC, LLVM, and copyleft
And I think that this may have been the largest single long-term benefit of the XEmacs/Emacs fork: the Egcs developers painstakingly avoided taking any steps that would have prevented a remerge of the fork
That wouldn't have been a problem, since the fork was not remerged: almost no work was done on 'the real' GCC during the egcs period, so egcs was just redesignated 'GCC' at the end of it. No merge was needed.
Stallman on GCC, LLVM, and copyleft
The facts are that for two years, out of GCC's 28 years of development, a bunch of developers developed the GCC codebase in a parallel repository. Both projects were GPL'd, and both development teams strongly supported free software and the FSF. The EGCS fork lead to a bunch of technical improvements, and they are now part of GCC.
This is, I think, an inaccurate portrayal of history. The facts are that for two years, out of GCC's 28 years of development, all the GCC developers (including the then official maintainer of the (stagnating) GCC, Richard Kenner) experimented with a new governance methodology under a new temporary project name. When this was a wild success, it supplanted the original.
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
but I always jump in when someone claims [...] the two-year EGCS story from fifteen years ago is somehow proof that RMS has poor project management skills.
That's like talking about the housing skills of a building. It somehow still misses the point.
Stallman on GCC, LLVM, and copyleft
Outdated information, extending GCC in Python
http://blog.cuviper.com/2014/01/23/add-new-warnings-to-gc...
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
> single one of us who likes maintaining private branches, and if we had
> our way with things we would do everything in the public tree.
> dimension. For example, you'll never see an Apple compiler with better
> C++1y support than the public Clang.
Why wouldn't you want your licensing term to reflect this practice then?
Wol
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
> better C++1y support than the public Clang.
Stallman on GCC, LLVM, and copyleft
Wol
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
> opportunity to gain a business advantage.
> with broad societal ramifications
But you're not helping those causes
Wol
But you're not helping those causes
But you're not helping those causes
Wol
If they want to own it, they can keep it.
But you're not helping those causes
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
(2) 90% of the developer's work will be make-work, trying to keep up with the Free version, for which the employer will be reluctant to pay.
Wol
Stallman on GCC, LLVM, and copyleft
Note that copyleft has nothing to do with freedom. If you download the LLVM source code from the public repository and build it yourself, you can verify that the resultant program satisfies the Four Freedoms <https://www.gnu.org/philosophy/free-sw.html> and is therefore free software.
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Copyleft just ensures that derived work is free as well.
but this in itself is a restriction so you cannot really argue that copyleft is free while non copyleft open source isn't (which actually allows the user to do more).
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
http://savannah.gnu.org/bugs/?41061
as long as you have rich uncles with an invested interest in sabotaging community influence, I guess you can get away with it, but breaking API may chase away open projects that want to contribute to an ecosystem around LLVM/Clang.
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
In my experience, Stallman's view is extremely myopic because the real impediments to free software are larger societal issues[*].
[*] The GPLv3 "anti-Tivo-ization" wording is a perfect example that shows that confining your view just to software is myopic. Why shouldn't we want the entire device and all its chips to be free also? Why shouldn't the company's internal discussions be done in public? The answer to these questions is the same as the answer to "why does non-free software exist?".
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
> That fits with the GPLv3.
Stallman on GCC, LLVM, and copyleft
“Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.
Note the requirement that modified code is not interfered. This is not the case with the Chromebook as after activating that mode I cannot deactivate it and keep my changes. And if the mode is activated, then booting is clearly affected with a rather annoying message precisely "because modification has been made".
Stallman on GCC, LLVM, and copyleft
In any case, hardware changes to get a custom boot loader are outside “Installation Information” as otherwise anybody can claim that one can always disable a verified boot using a probing station or something to change a value in the register at the runtime.
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Hence we are down to the Tivo story as the only problematic point. What exactly does it do for Google?
Nothing, they make all their devices hacker friendly, even to the point where they are now the most prominent backer of coreboot, and open source bios.
Does anybody really believe that iphones sell better because they are locked down?
I am pretty sure Google would have gone with linux even with GPLv3, and I do believe it would make the world somewhat better for all of us.
It is also very clear from the Android example that we do need to use the license to make these things happen (i.e., open devices).
Stallman on GCC, LLVM, and copyleft
http://www.blackducksoftware.com/resources/data/top-20-op...
Unfortunately, they do not distinguish between GPLv2 and GPLv2+, but as you see, the GPLv3+ projects are just as popular as Apache 2.0 (which is by far the most popular permissive license). Counting in GPLv2+ projects (which is also available under GPLv3), I believe you are looking at GPLv3 being the most used open license in the world. Chew on that one for a while.
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Sure, and the industry said that it's unacceptable.
Not really. GCC, gdb, glibc, busybox and others used to be indispensable. So indispensable that RMS used to call Linux as GNU/Linux.
Be that as it may, it's not the point of the argument. Large organizations figured out that collaborating on non-essential software is better than reinventing the wheel all the time. They are also absolutely allergic to GPLv3 which denies them ability to keep ESSENTIAL software controlled.
Sure. Apple ripped out Samba from Mac OS X - it's replaced by their own SMB implementation. They've also replaced gcc with clang - the last available officially supported gcc on Mac OS X is the last non-GPLv3 version. And Google avoided GPLv3 completely.
Basically, I think that copy-left is a nice idea in small quantities.
Stallman on GCC, LLVM, and copyleft
http://www.infoworld.com/t/mobile-development/open-source...
Personally I am finding myself using more and more open apps on android, and yes, with a GPL license.
Stallman on GCC, LLVM, and copyleft
Wrong. Stop deluding yourself.
So?
LGPL with static link exception is fine. GPL for end-user software is also OK-ish.
Nope. Even FreeBSD was built using gcc, there literally was no free alternative. Remember?
Can you understand what people write to you? It's perfectly OK for large companies to use GPL or even GPLv3 for infrastructure or non-essential services. It can't harm anyone that way. They might even throw a patch or two to tweak something.
There's no GIMP on iOS. Or Android, for that matter.
LOL.
Stallman on GCC, LLVM, and copyleft
You really need to get your history straight, copy-left ran the pants of anything BSD had to offer. It is your very good friend Apple and its fat wallet you can thank for BSD having another go at compilers. Seems they have a lot of money to spend on astroturfing these days too, I have never seen so many lies about GCC spreading before. Those unfamiliar with history is bound to repeat the mistakes, and it saddens me that so few care about the history.
Stallman on GCC, LLVM, and copyleft
Actually, there is not. Smartphones this year outnumbered all other computers, except for microcontrollers.
:facepalm:
Nope. Android was designed this way to allow carriers to lock down phones, and total avoidance of GPL was a pre-emptive step to avoid being forced to support GPLv2 forks indefinitely.
Google uses Coreboot which is GPLv2 on Chromebooks. JFYI. Lots of Android devices use U-Boot which is, you guessed it, GPLv2.
So there's no phone with GPLv3 software out there. Even the new Jolla phone does NOT have GPLv3 anywhere, though they have quite a lot of GPL and LGPL software on it.
Again, it's either isolated or used in non-core parts. Or in situation where GPLv3 has no bite at all.
Stallman on GCC, LLVM, and copyleft
https://wiki.merproject.org/wiki/Architecture#GNU_utilities
Nokia on the other hand was big enough to make a difference, and Microsoft made sure that never happened. I would say Microsoft did a bargain when they got Nokia on board with an exclusive deal, worth every billion. However, GPLv3 software is easily available in abundance on Sailfish, Meego and Android. On a related note, Jolla does ship glibc, did you know that?
Stallman on GCC, LLVM, and copyleft
There is _no_ GPL (of any version) in Android images and even no LGPL anymore. Android tools certainly use it.
Sure. They don't limit third-party software, so they can't care less.
Which is LGPLv2.1
Nope.
It IS a big deal on devices. So big that big vendors essentially forked the entire FSF stack to avoid it.
Again, another understatement like "the waves were higher than normal during the tsunami in Japan".
LGPL is most certainly there: KHTML^H^H^H^HWebkit^H^H^H^HBlink^H^H^H^Hwhat-the-name-if-this-thing-today still includes few LGPL-licensed files. But all the new development there uses BSD (not Apache, BTW, but BSD) thus it's pretty limited and constrained.
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Links?
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
> Again, it's either isolated or used in non-core parts. Or in situation where GPLv3 has no bite at all.
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
> that's why Android comes with no libstdc++.so.*
Care to enlighten me, exactly what legal issues are there related to using libstdc++? AFAIK it is linked in just about any proprietary application out there.With Google opting for Apache, I am pretty sure any switch to LLVM will be despite its license, not because of it.
Please provide documentation that HTC lost carriers over offering tools to root their phones.
Make up your mind, do you believe that copy-left makes sense?
Counting in GPLv2+ projects (which is also available under GPLv3), I believe you are looking at GPLv3 being the most used open license in the world.
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
-no carriers lost
-tool reverted for one phone in August 2013 (a weak and struggling HTC caving in)
-tool provided two years earlier (ref. http://www.htcdev.com/bootloader ), with no carriers lost for the entire two years
I call that pretty sound proof that the unlocking thing is a no-brainer. It did not shut anybody out of the market, and it will not shut anybody out of the market as long as somebody stands up. Right now you seem to be part of the problem, not part of the solution.
Stallman on GCC, LLVM, and copyleft
You see, libstdc++ uses straight GPLv3 (not LGPL!)
This is factually incorrect. If libstdc++ used either license it would be nearly impossible to compile non-GPL C++ programs, because a lot of libstdc++ is implemented in header files.
Stallman on GCC, LLVM, and copyleft
carrier "subsidy"
This is all well and good if you can actually find a plan which is $15-20 per month. Then you discussing is valid. In countries like US or Japan your choice is service without “free” or “cheap subsidized” phone or the same service for the same price without it (and in both cases it's not $15-20 per month, that's for sure). In such a case phone without “subsidy” is DOA. You may explain that “it's not really a subsidy” till you are blue in face, but phone is still DOA. Just ask Nokia (well, by now you'll need someone from “old Nokia”) which was extremely strong in US at the end of last century yet went to single-digits when it angered carriers (it refused to cripple their phones by disabling tethering: huge crime in their books).
carrier "subsidy"
carrier "subsidy"
carrier "subsidy"
carrier "subsidy"
carrier "subsidy"
carrier "subsidy"
carrier "subsidy"
carrier "subsidy"
carrier "subsidy"
carrier "subsidy"
carrier "subsidy"
carrier "subsidy"
carrier "subsidy"
carrier "subsidy"
carrier "subsidy"
Not really. A couple of years ago AT&T was not offering any discount for bring-your-own devices. Has the situation changed?
carrier "subsidy"
carrier "subsidy"
carrier "subsidy"
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
> The reason is that LLVM's development practices create a strong disincentive for keeping any code private because LLVM's C++ API's (which is where 99.999% of development happens) has no backwards compatibility and changes very rapidly,
Uh, GCC has wildly unstable internal APIs as well, y'know.
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
By now I should have checked of course, but maybe you can share with me, is this the API you are struggling with? I haven't worked with that API myself, but I have seen GCC developers being sorry for not having it more stable. Whether they are just being modest, or whether they really have broken the API numerous times I don't know, and to be frank, I do not find you line of posting very helpful in conveying it either.
Stallman on GCC, LLVM, and copyleft
When it comes to linux drivers, we are not talking about an API, but about an ABI. It is somewhat different, but as I said, there is not supposed to be an API for external use there.
Do you even know what these words mean? We are talking about an API. The Linux kernel internal API, which is what is relevant with regard to drivers and anything else running in kernel space, is unstable and will be changed whenever an improvement comes along that needs it.
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
> Not sure how this confusion came about, but I guess I had one post where I was unclear.
Stallman on GCC, LLVM, and copyleft
> Whether they are just being modest, or whether they really have broken the API
> numerous times I don't know, and to be frank, I do not find you line of posting
> very helpful in conveying it either.
> and then whether the API is stable or not is a rather important issue, at least for me.
Stallman on GCC, LLVM, and copyleft
ref. http://en.wikipedia.org/wiki/Linux_kernel_API#Kernel_user...
I find the ABI story of C++ in GCC more fascinating, that's all.
A part from that I can only think of the plugin API I already gave you. Does even GCC define an internal API? AFAIK, internal APIs are typically not stable, so not sure how relevant they are for this discussion at all. The starting point for this discussion was usage of LLVM by external projects. So no, I have no clue as to what GCC API you go on about.
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
and i did point you at said API, you can read the code or references to the code in that header
Oh, if only that was all plugins had to conform to. Keeping them working would be simple! :)
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
which means they can be broken for *particular ports*, which you probably can't build
Or, rather, which you probably won't think to build, and can't test even if you built them.
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
I do very well know what an API is,
Actually, from your comments it seemed very much like you didn't. APIs for random programs differ radically from the interfaces exposed to something like a plugin for a compiler: I was trying to describe how and why that was true. If you saw it as patronising 'mud bathing', I'm sorry.
When it comes to GCC it seems fairly well accepted that it is not a particularly modular code base, and this seems to be one of the key areas being prioritized for the next releases
Yes, but that will not help much. What's changing is e.g. that a bunch of code is moving out of macros into function pointers ('langhooks'). This will not change the fact that plugins are inspecting and possibly even changing a giant data structure manipulated by large numbers of other passes, and it will not greatly reduce the enormous number of implicit and explicit dependencies that plugins are thus exposed to. It'll make plugins more pleasant to write, definitely, but it won't mean they won't still get unavoidably broken at unpredictable intervals by changes in GCC. This is not a stable API in any real sense, nor do I see how it can ever become one. (The API by which plugins register themselves can be and is fairly stable, but that is, again, not the API plugins are really concerned with.)
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Sounds like the api does little more than expose the internals of GCC.
That's pretty much what it does. That's also pretty much what LLVM's does, and I have explained in other comments how I suspect this is unavoidable for anything remotely like a compiler. Most of its 'internals' are, after all, either exposed in or implied by the very IR whose exposure is the whole point of a plugin interface in the first place.
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Why do you think GCC license does not affect the willingness of developers to work on it?
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Do not forget, for gcc all contributions copyright must be transfered to FSF ! Is it good ?
Do not forget, for gcc all contributions copyright must be transfered to FSF ! Is it good ?
Do not forget, for gcc all contributions copyright must be transfered to FSF ! Is it good ?
Do not forget, for gcc all contributions copyright must be transfered to FSF ! Is it good ?
Wol
Do not forget, for gcc all contributions copyright must be transfered to FSF ! Is it good ?
Do not forget, for gcc all contributions copyright must be transfered to FSF ! Is it good ?
Wol
Do not forget, for gcc all contributions copyright must be transfered to FSF ! Is it good ?
Do not forget, for gcc all contributions copyright must be transfered to FSF ! Is it good ?
Wol
Do not forget, for gcc all contributions copyright must be transfered to FSF ! Is it good ?
Do not forget, for gcc all contributions copyright must be transfered to FSF ! Is it good ?
There have been some interesting things said in this thread. This thread inspired to write this blog post about GCC, LLVM, Copyleft, Companies and Non-Profits. I hope it's a useful addition to the discussion.
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
http://nginx.com/products/
Again, nothing wrong with that. Only business as usual. These are two very recent examples at the heart of Apaches success. Doesn't matter what your company says, doesn't matter what your management says, doesn't matter what your colleagues say, doesn't matter what you think. If the right incentives are there, it will be forked to open core, simply because it can. There will be companies providing add-ons, plugins, whatever, as proprietary software. We already had one core developer from LLVM telling about it happening for LLVM. I really am sorry for being this blunt, but this is how it is. Five years from now there is a substantial probability of HDFS and Hadoop being proprietary software for all practical purposes.
http://wiki.openwrt.org/toh/start
I believe the litigation was an important part of the picture. The network router I am writing this through even came with DD-Wrt pre-installed from Buffalo with fully open Atheros drivers, very competitive specs and pricing. Heck, we are not even come that far on PCs yet.
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
> Kroah-Hartman said that people who show any ability to get patches into the kernel immediately get job offers.
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft
Stallman on GCC, LLVM, and copyleft