While the BSD licensing model allows various hijinks to go around without the requirement of disclosure.
Complaining about the GPL is like complaining that you can't play dirty pool with code licensing(see Tivoization). Then again, you probably would rather throw some ad hominem at me regarding a certain GPL advocate.
Complaining about the GPL is like complaining that you can't play dirty pool with code licensing(see Tivoization).
I haven't heard Apple complaining about the GPL or trying to circumvent it - they're just switching to alternative projects.
Of course, its a pity, because even if if you Tivoized GPLv2 code you still had to share your source so people could learn from it, or use and modify it on other (or jailbroken) hardware, whereas now people are moving to BSD-style licenses with no such benefits... but if the FSF want to let the perfect be the enemy of the good, declare jihad on Tivoization and have a tilt at the patent windmill, that is their right.
whereas now people are moving to BSD-style licenses with no such benefits.
This is symptomatic of PHB/MBA thinking: short term gains/benefits that mortgage long term growth.
In a couple of years time, there will be a proliferation of different, incompatible versions of CLang/LLVM that will be increasingly expensive to maintain. Furthermore, I can foresee vendors making incompatible changes to the code produced by CLang, subtle ABI breakage and the like. The upper levels will suffer too : vendor A's version
In a couple of years time, there will be a proliferation of different, incompatible versions of CLang/LLVM that will be increasingly expensive to maintain. Furthermore, I can foresee vendors making incompatible changes to the code produced by CLang, subtle ABI breakage and the like. The upper levels will suffer too : vendor A's version will not be able to compile source code with vendor B's extensions and vice versa.
Hindsight is invariably more accurate than foresight. And in this case, hindsight tells us that there are plenty of non-GPL free packages that you use every day that haven't succumbed to either of your fears. In fact you use at least a couple of them when you read this.
This sounds like the 1980s/ealy 1990s all over again
That wouldn't be bad. The productivity per user has never been higher, and most of what we use now was invented then. I'd rather see that again that these modern days where ideas are scarce and productivity per user base at an all time low.
And in this case, hindsight tells us that there are plenty of non-GPL free packages that you use every day that haven't succumbed to either of your fears
Yes but compilers are one area where this sort of thing has happened before and appears to be happening now. Where this fragmentation hasn't happened with BSD projects is when only one entity is heavily invested and cooperation isn't happening or his happening within the one entity.
I'd rather see that again that these modern days where ideas are scarc
When are these modern days with scarce ideas? I'd say we are having a pretty wonderful world of software diversity and experimentation. Just look at the incredible number of web frameworks, for designing interactive websites.
I think you just proved my point. These days, we have umpteen web frameworks. Back then, we had people inventing things like the web. We've reached a point where rehashing is considered innovation.
Compilers in their hayday never had diversity like this.
But how groundbreaking is that diversity? People quibble about which back-end to use for the compiler. Thus this thread.
With half the OSS code out there not even compiling without a gcc front-end, I don't think you have much of a case for diversity. I remember being able to use MipsPRO, Aztec, gcc, Manx or Sun
Back then, we had people inventing things like the web
Which took decades, GML started around in 1960. ISIL was in the 1980s. That's not a fair comparison you have no idea what technologies being invented today are important for the computing world of 2030. How would you know?
I can tell you as someone who was around when the web starting being used in the early 1990s I didn't think of it as all that big a deal. I actually thought Gopher with built in indexing was going to be better than the HTML with
In a couple of years time, there will be a proliferation of different, incompatible versions of CLang/LLVM that will be increasingly expensive to maintain.
It's already happened. This is why so many companies are now actively involved in the LLVM community: it's cheaper. I'm currently on my way back from BSDCan (where I was talking a bit about the progress in switching to clang) and I was at EuroLLVM a couple of weeks earlier. Both conferences were full of corporate contributors to LLVM and FreeBSD (two projects that I work on). They like the fact that the license means that they don't need to run everything that they possibly want to do past their legal team and, over the past decade, they've all discovered (at different speeds) that it's much cheaper to engage the community and push work upstream than it is to maintain a private fork.
You get much better support from companies that join your community because they regard it as being good for them than if they dump code on you because they are legally obliged to. We don't want drive-by code dumps, we want long-term commitments to maintenance.
I agree with you and good point regarding the X analogy. GCC has benefited time and time again from corporations contributing code that benefit other corporations in uses they never considered. LLVM has some substantial technical advantages over GCC. So we might end up with a situation like we had for a long time where GCC is standard based, feature rich but technically inferior to the commercial compilers many of which are LLVM based.
In a couple of years time, there will be a proliferation of different, incompatible versions of CLang/LLVM that will be increasingly expensive to maintain.
Or they'll be a mainline version that is maintained by an active community of both independent and paid corporate developers contributing code, and corporations that want to maintain proprietary extensions will do so in a modular way, contributing any necessary core support back to the mainline project.
There's plenty of widely-used non-GPLv3 (public doma
Many companies for instance strip all comments from GPL'd source before releasing for legal reason
That's specifically illegal under the GPL. Source code is defined as what is used internally. If a company uses a commented version internally they can be forced to hand that over by the people whose code they are comingling with.
Making things up doesn't constitute a valid argument.
You don't have to disclose anything under the GPL unless you "convey" the work to others. There is nothing to force someone to hand over internally used code.
"To 'convey' a work means any kind of propagation that enables other parties to make or receive copies... You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force." -GPLv
You even quoted the correct line, "The 'source code' for a work means the preferred form of the work for making modifications to it" The version used by developers for making modifications is the one with the comments.
As for the GPL what prevents someone from stripping comments is that the recipient can request source.
I prefer the form of the work which has a binding contract paying me $1M for viewing the source. I demand you provide source code.
Are you really that obtuse? The GPL is clearly making a distinction between high level "source code" and other forms of the code, so someone can't offer up, say, an intermediate assembly language output.
As I correctly pointed out, if the "conveyed" binary was compiled from a source with no comments in it, then source with no comments is all one has to provide.
The GPL is clearly making a distinction between high level "source code" and other forms of the code, so someone can't offer up, say, an intermediate assembly language output.... As I correctly pointed out, if the "conveyed" binary was compiled from a source with no comments in it, then source with no comments is all one has to provide
No that's not true, that is not what the GPL is doing. Source code is not defined as what you compile from but what you modify from. Source code the way you are using it,
I think one of the heads of Red Hat nailed it when he was asked about RMS: "Richard treats his friends as his enemies". Whether the community wants to accept it or not when RMS specifically targeted a single company with GPL V3 he gave a pretty damned good reason for businesses to stay away from the GPL, fear of being the target of GPL V4.
That's a lot of meat without bones. Fear of being the target of parasite lawyers who sue over GPL is more of the reality, whether it's GPL2, 3, LGPL or other.
BTW I personally bet that if there is a GPL V4 the new buzzword will be "Androidization" since RMS hates Android even though it has put more Linux devices into users hands than anyone else in history.
I'm glad you have insight into Richard's brain and can tell us what he hates. As for bringing more devices into the hand of people, that's not the purpose of the open source movement. At best it's a side effect. The purpose is to do what governments and their constitutions fail to do - support progress, by ensuring that new code becomes available to
I'm glad you have insight into Richard's brain and can tell us what he hates.
Actually, that's the exact problem, isn't it? Nobody knows what RMS might do next week.
The purpose is to do what governments and their constitutions fail to do - support progress, by ensuring that new code becomes available to anyone who can improve on or learn from it.
That's clearly not the goal of the GPL3, because if it were, there would be no need of an anti-TiVoization clause, but the Affero clause would be standard.
A quick Google search for "gpl lawsuit" returned: About 1,810,000 results (0.21 seconds)
The publicity is enough to make managers worry, and their reaction isn't to investigate to get the real deal and make sure they dot their i's and cross their t's to avoid a potential GPL lawsuit, but to avoid GPL whenever they can.
I haven't seen that at all. People who are getting sued are generally getting sued for violating the GPL and on purpose. That's not lawyer parasites but the kinds of lawsuits that happen with commercial software all the time.
This is precisely what I predict as well, and in fact have in previous threads touching on this subject - if there is a GPLv4, it will target 'Androidization'. But on the main story, it's interesting how GPLv3 has become so toxic that the crown jewel of the GNU - namely GCC - is now being abandoned in droves by the BSDs. And mark my words - if Debian can do a FreeBSD edition called kFreeBSD which gets decorated w/ Debian userland, then similarly, they can also first make a Clang/LLVM, and then make a Linu
Them, and then, there are also the OpenBSD and NetBSD communities. OpenBSD is trying out PCC, and it's probably a matter of time before they too abandon GCC
I know there are reports that C is even with Java again. But what you say made me wonder about this. Despite what Java advocates say, the idea of the app server and enterprise Java was not new to Java. There were and still are brokers around that do much of what a Java app server does, but using C/C++. Tuxedo is one. The thing I am thinking about however, is that Java started a heyday when groups like Apache came around and there was a huge resource of Java utilities and helpers and libraries that were fre
I'm theorizing that Java took off because despite being further behind in enterprise architecture than C at the time (remember Tuxedo et al), it had a support community that didn't encumber the companies, so they backed this stream.
Java took off because C/C++ are a bear to work with, the time was right, and Sun was good at marketing, not because of some Apache libraries that were developed behind the popularity of Java.
C which also has a ton of libraries, but was hamstrung by GNU
At the point where Java took off GCC was not a very good compiler and was not a major player. The Linux kernel guys had had to fork it to try and get anything less than terrible performance. Intel's, Watcom, Microsoft, and a 4th I'm forgetting were the big players. In the early 2000s the technical disadvantages of GCC were still rather well known. We are in a rather unusual window for GCC where it seen as not just an open compiler but one
This modifies what I said a little, but not much. The change would be: C had either a very restrictive open source license or very restrictive closed source licenses. Java had an open license that at the same time didn't require companies to give away code they spent a ton of money to develop. Then Apache came along and made it even sweater by expanding the code base with even more open license will still not forcing companies to give away their code. And remember that a lot of the early app servers used at
company X writes code for Y that Y sells it as part of a suite to Z. If Y wants to GPL his stuff then X's community can use it. If Y wants to keep his stuff then he had to buy a commercial license from X. This way X got money from people with money, got contributions from people who were willing to contribute and could sue people who did neither.
But company X writes code for Y that Y sells as part of a SaaS suite to Z. doesn't constitute dist
Oh, Hurd is pretty much abandonware as far as the FSF is concerned. The only people working on producing a working version of it are Arch and Debian, Otherwise, RMS himself says that Linux is the kernel of the GNU.
I'm out of mod points, sorry. I agree on all points. I'm frankly astonished at this view that the GPL or Stallman are evil or hateful or built with malicious intent.
Most big companies prefer a BSD or MIT license to GPL because it lets them take what they want and allows them to give back as much or as little as they want, including nothing. If your primary interest is promoting your own business, this makes sense. The GPL was not designed with facilitating profit as a goal, and as a result it doesn
Of course, its a pity, because even if if you Tivoized GPLv2 code you still had to share your source so people could learn from it, or use and modify it on other (or jailbroken) hardware, whereas now people are moving to BSD-style licenses with no such benefits... but if the FSF want to let the perfect be the enemy of the good, declare jihad on Tivoization and have a tilt at the patent windmill, that is their right.
This is absolutely the case! When TiVo was complying w/ GPLv2, the FSF suddenly discovered a major objection to their practice - namely, that they were putting the code in read-only devices, and declared a jihad on the company. However, even GPLv3 doesn't explicitly say that GPL software cannot be put on a Read-only memory (which would again violate the GNU's Freedom #3) or copy-protect memory (which could prevent the device that contains the software from getting copied) or anything else about the devices that the software can reside on.
As you very well put it, it's one more of those cases of the perfect being the enemy of the good, and in the process, the FSF waging a war on its own licensees, namely TiVo. Given that track record, which company in its right mind, even if they endorsed the liberation of software, would want to get into bed w/ the FSF?
Why guess about this, when it is so easy to google "Tivo GPL" or "Tivoization". From Wikipedia [wikipedia.org]:
Tivoization (pronounced "Teevo-ization") is a term coined to describe the creation of a system that incorporates software under the terms of a copyleft software license (like the GPL), but uses hardware restrictions to prevent users from running modified versions of the software on that hardware.
If the problem was simply that they were in violation of GPL v2 by not releaing the code, then there would not have been a reason to create a whole new license to address this.
They didn't declare a jihad. They indicated that TIVO had exposed a problem with the license and sought to fix it. Particularly since at the time what TIVO was doing was likely to become more mainstream with things like the Palladium initiative.
Given that track record, which company in its right mind, even if they endorsed the liberation of software, would want to get into bed w/ the FSF?
Companies that want to help a competitor get sued. Or companies that provide so
Labelling the problem as 'Tivoization' was pretty much an act of bad faith, even if they didn't actually have Tivo in mind as a violator but rather, a shortcoming of GPLv2. It's a reflection of their anti-corporate profile.
GPLv3 is great if a software project wants to release it in such a way that its competitors can use it, but not improvise on it and then release the improvized software. From that angle, it's good, and even GPLv2 satisfied that. However, granting all users patents that may otherwise
However, granting all users patents that may otherwise accidentally get violated is nothing but an act of bad faith,
What it is an act of is an attempt to use copyright law to address a problem in black letter patent law. A patent creates a way to violate the spirit of GPLv2 without violating the letter. The purpose of the GPLv3 is to close these kinds of loopholes.
and the termination clauses, which would allow any author to revoke their license in the event of a violation, is what makes it a double ed
Apple has mostly dumped GCC in Lion and replaced with Clang. They still include a GCC but it's very incompatible as it has LLVM back end and breaks stuff with inline assembler. I can understand them wanting to make a change but I don't understand why they include an incompatible GCC.
I can understand them wanting to make a change but I don't understand why they include an incompatible GCC.
Probably just a stop-gap until everybody fixes their makefiles to use Clang rather than GCC. GCC is still the default command-line compiler. There's still a heap of open-source stuff in OS X (Apache, PHP, Perl, Python, Postgresql,...) and also projects like MacPorts that enable you to compile most of the usual open-source suspects. Since these are mostly cross-platform, I'd assume that inline assembler is fairly rare, but build scripts that depend on GCC are fairly common.
Just for reference – they don't include gcc any more: Greyjoy:~ tatd2$ which gcc/usr/bin/gcc Greyjoy:~ tatd2$ ls -la/usr/bin/gcc lrwxr-xr-x 1 root wheel 12 22 Mar 15:43/usr/bin/gcc -> llvm-gcc-4.2
No, llvm-gcc is GCC. More precisely, it's the GCC front end with the LLVM back end. That's the one the GP was talking about; although it is GCC, it has some hairy edges where it doesn't behave quite like the standalone GCC.
The actual Clang compilers are called clang and clang++.
One reason for that is because the GCC team won't accept Apple's patches for new versions of Objective-C. Apple want to move Objective-C forward, GCC has become a barrier to that, so they support CLANG/LLVM development. The version of GCC included is simply for legacy support and will be removed in due course once CLANG support for C++ is good enough.
Clang/LLVM also gives you nifty stuff for interfacing with the IDE, far better compilation errors/warnings, faster compile times, etc.
But the "legacy" version of GCC isn't compatible with the older GCC. Include both and let the user decide. I need gcc for various reasons, I'm not using xcode and never will, I'm not writing mac or phone apps, so all Apple is doing is making Linux more attractive.
Yup, and am having troubles getting it to build as well. Even the mac ports version (universal so I can get 32/64 bit) has some problems with one application.
Maybe your time is better spent on #DEFINEs or similar to get your code to work on other compilers? Tying yourself to GCC irrespective of what apple does is not really a wise move.
Maybe. But we do have a lot of inline asm (ie, emulating RTOS task switching, third party code with optimized functions, etc). Ie, there is code that properly checks for __GNUC__ around some inline assembler but this fails because LLVM-GCC claims to be GCC but doesn't handle the syntax correctly (possibly an xcode 4.3 bug?). Probably with time we could get things working but I.T. is insistent that people upgrade now and be disrupted rather than put it off until code is ported and makefiles rewritten.
As far as I understand it this is the approach that LLVM recommends. Using the LLVM GCC front end for your code while you slowly migrate. If you want real GCC you can use the MacPorts version.
He wasn't complaining about the GPL, he was stating (correctly) that it is one of the key reasons some groups choose not to use GCC, particularly GPL version 3 (note that FreeBSD has not used and of the recent GCC release specifically for that reason - they were fine using GPLv2).
It is a case of choosing the right tool for the job. Until recently their choice was to redefine the job (change the parts of their projects and licensing policy that GPLv3 conflicted with), keep the old tool (using older, GPLv2 licensed, releases of GCC only), or use something less stable/proven/compatible. They chose the middle option. Now option three is replaced by "use something else that is now stable/proven/compatible enough to be an alternative" they have taken that choice. Again this isn't complaining about GPLv3, it is simply refusing to use it because it is incompatible with some of their chosen goals.
I'm told there are technical reasons why Clang and the related tool chain are preferable to GCC in some circumstances too, though I'm out of the loop on that one so I don't know what they are or if they are significant to FreeBSD.
While his answer was rather terse and it would have helped to be less so (it made him appear to some, to you at least, like an anti-GPL troll), what you appear to have done in your response is set up a strawman to attack. This is the sort of thing that anti-GPL people (both within the open-source arena and external to it) will jump on as "proof" that GPL advocates are rabid loonies, so by defending the GPL in such a manner you may be harming the cause rather then helping it. You might want to be more careful not to come across that way (it may not have been you intention on this occasion, but it does seem that way by my reading).
TiVo and that Xerox printer @ MIT are apples and pineapples. In the case of the latter, RMS and his group wanted to get the source code of the drivers so that they could compile it for the platform they were using. It didn't involve altering anything in the printer itself that could risk making it unworkable. TiVo was about locking that box itself - but if someone wanted to write a driver whereby a Linuxstation could get inputs from a TiVo box and display it, instead of connecting it to a TV, then the Ti
TiVo and that Xerox printer @ MIT are apples and pineapples.
The principle is exactly the same. There was software that came with the device and they wanted the ability to modify it. Just because you could treat the TiVo as a black box doesn't mean there couldn't be value in being able to alter the source code on the TiVo itself.
Here is what I personally don't get, maybe someone can explain it to me, but WTF was it with RMS and the TiVo? It was ONE device that had NO choice but to be made the way it was.
If it had not been TiVo it would have been something else. His problem was the use of GPLed software in that manner. While it wasn't found to break the letter of the license it broke the clearly stated spirit of the license, so that wording was updated in v3 to patch the hole.
Would he have been more happy if it had used WinCE?
Yes, basically. Or some form of BSD (the licenses used there would allow this sort of use IIRC). Or anything else not GPL licensed. They had those choices available to them.
RMS is an absolutist on this and similar matters (some would say extremist, but I feel that label to be rather too strong here): if you want to use Free, keep it Free with your use, otherwise use something else (paying for it if need be).
it just seems stupid to attack one specific corp
He wasn't going after one specific corp, just the first one that did it (visibly) first and shoring up the hole before others tried. Remember that TiVo could keep using GPLv2 software as they had already done, they'd just have to start maintaining by other means once later versions switched to GPLv3, so the switch to GPLv3 did not explicitly stop them distributing their product.
and make other businesses afraid of being next on RMS' shit list and all over a device that frankly could have been made no other way without only being sold at China Mart and other "pro piracy" hardware sites.
That is where it falls down of course, but so does every other license commercial or otherwise - if you can't enforce the license in a territory people wanting to do something against the (letter of the) licence in that territory are at an advantage to those elsewhere. "Pro piracy" regimes are not a GPL specific problem and not really relevant here - you could just as easily state that VMWare's recent licensing model changes are an attack on compliant companies.
There are many people who think RMS is wrong on the matter, of course. Linus for instance still explicitly uses GPLv2 as evidenced by it being the license git is released under (the kernel is a different matter: that could not be switched even if he wanted because of how many contributions there have been where rights were not explicitly handed over to the project).
In the real world, TiVo would have been forced to support such modified platforms - especially if the modification broke them. At any rate, TiVo's choices were to produce something that was GPLv3 compliant, but breakable as a result, or stop @ GPLv2 compliant, but solid. Picking the latter was a no-brainer.
He wasn't complaining about the GPL. GNU just has different goals than BSD, and different licensing. Building a complete OS requires a matching compiler, so one that's under the BSD license is a desirable effort for the BSD licensed variants. That's not the same thing as saying "GPL bad". It's just making your system feature complete and organically portable - as BSD was always intended to be.
Building a complete OS requires a matching compiler
Why? There are many operating systems without a matching compiler (and a few without a compiler at all), and I would think that unless you beg the question, this is patently false.
I think he probably should have said "Building a complete Unix like OS". Unix has always had system compilers and an assumption that even end users would need to compile code.
We are losing each other I think, or at least I'm losing you. I read up the thread I'm not seeing anything about data. So can you clarify what at this point I'm responding to.
From my perspective the GP was just giving an argument for LLVM (it is BSD licensed and thus a better fit for the BSD culture) but phrased this more generally, you questioned him and I said he was over generalizing you then agreed. Which is all good, except there is something about data here...?
I was agreeing with you. The bit about data is from some papers I read in the early days about the motivations for portable compilers and operating systems. But since the data is the reason for everything, I guess it's been implied for so long we don't talk about that any more.
There is another excellent reason why the Linux Kernel is staying on GPLv2: a very large proportion of Linux's market share these days is on ARM SoC in mobile devices. There is truckloads of IP in these devices, and right now the chipset vendors are able to keep this closed and compartmentalised.
It's not a case of these chipset vendors wanting to keep their own IP private - often it's not theirs to start with, having been licensed - probably several times already - from other parties.
Had the GPLv2 really been an improvement on GPLv2, all those devs would have been banging on Linus door to get the license updated, and Linus too would have had no problems w/ it.
What this clause really does is say that the FSF can at any time change the details of the license you are giving to your users.
It absolutely does not. The license you give to your user is whatever words you put in the license you give to your user. You can make this up yourself, or you can use a license someone else has written for you. All the FSF does is provide legally tested templates to you to use, and they put a new version number in whenever they release a new one. If they said one day "we've decided to change the GPL v2 to be [something madly different]" it would have no effect on any software, except those that chose to ad
Do you really believe that Linus would use GPLv3 for the kernel ? You most be kidding. Linus is very clear about why he does not want GPLv3. He is happy with GPLv2.
Many people wants _real_ freedom for their software
No, they don't. If they did, they'd use GNU GPL v3.
But I think you mean the opposite of what you said: people want to be free to do whatever they want with the software, including taking away the software's freedom.
That's the thing. Free software is not about your freedom, it's about the software's freedom. It is not for the benefit of anyone in particular, it is for the benefit of the whole humanity. When you think about where rms came from, and when you read his writings, you realize that his ideal is not an indifferent "here's some code, use as you wish". It is an ideologically grounded "here's some code, it's for everyone to use, and if you build upon it, the result is also for everyone to use".
That's the thing. Free software is not about your freedom, it's about the software's freedom. It is not for the benefit of anyone in particular, it is for the benefit of the whole humanity.
The problem with that argument is that what is best for the software and humanity is not clear cut. Most of the better software out there has significant corporate backing. Far too often, open source software falls into the trap of writing code that "works for me", where "me" is defined as the person who wrote it, yet tends not to "work for me", where "me" is defined as anyone else. Corporate backing tends to fix a lot of that because you have lots of "mes" working on the code, each of whom has a significant interest in making it work correctly and reliably (because they're getting paid to spend their time doing so). Any licensing requirements that are sufficiently onerous to scare away that corporate backing, therefore, tend to result in software of lesser quality.
IMO, the ideal situation is a BSD or similar license with the code owned by a non-profit organization. In this way, you have a reasonable assurance that the code won't suddenly get closed by its primary maintainer, and other companies are unlikely to want to close the code themselves because of the maintenance headaches of keeping a proprietary branch in sync with something that is regularly getting updated by others. However, companies are willing to work on the software and improve it because they don't have to worry about crossing some fuzzy line and getting sued.
We don't have to guess which model works best, at this point we have historical data. Your model failed with respect to X. MIT created and maintained an X that they released via. the MIT license. All the UNIX vendors then took this MIT code and intermixed it with their custom code creating value add X's that were specific to their platform, and closed source. The effect was that the X that existed in the public domain was worthless for end users, and the X's that were worthwhile were closed. X itself couldn't progress because it fragmented so all the interesting stuff existed in other layers. Years later when there was a desire for a workable open X, the XFree86 project had to start, essentially from scratch and this took years. We still haven't gotten all the features that existed in those proprietary Xs 2 decades ago.
That is the classic example of why BSD style licensing doesn't work. The primary maintainer is not unchanging.
Conversely the GPL has a long history of successful multi corporate contributions over time. The historical data simply refutes your theory of what should work.
Far too often, open source software falls into the trap of writing code that "works for me", where "me" is defined as the person who wrote it, yet tends not to "work for me", where "me" is defined as anyone else. Corporate backing tends to fix a lot of that because you have lots of "mes" working on the code, each of whom has a significant interest in making it work correctly and reliably (because they're getting paid to spend their time doing so).
I don't see this working in the real world, e.g. with Android. Corporate backing tends to push code of low quality (cf. the plethora of bugs that were fixed when the Android specific code was put in the upstream Linux kernel) because it was written quickly due to the corporation feeling the pressure from its competitors, and because its developers are paid for the time they spend coding; their interest is focused on solving the corporation's own problems (a corporation is a very big and selfish "me") with no regards to the effect that their solution will have on others' problems (cf. what happened with Apple and CUPS). And when a corporation has moved to the next product, they have no interest whatsoever for either the old code itself or its users (cf. what happens every time a new release of Android is revealed and users would like to upgrade, but they can't because of the binary blobs or forked code).
Any licensing requirements that are sufficiently onerous to scare away that corporate backing, therefore, tend to result in software of lesser quality.
This is not what I'm seeing with GPL projects such as Linux and the GCC. I think that the code quality of an open source project depends more on the community that it's able to gather than its license. But even if it we assume it's so, then the problem lies with the FUD about the license rather than in the license itself. FUD that I find in your comment, too:
they don't have to worry about crossing some fuzzy line and getting sued.
No company has ever been sued because of "crossing some fuzzy line". A couple of companies were sued because they absolutely refused to put a tarball on an FTP site despite the fact that the authors of that code had tried to convince them to do so for years. In comparison, Google is getting sued to hell because of BSD-licensed code. The truth is that no license will make you safe from copyright/patent trolls.
No company has ever been sued because of "crossing some fuzzy line".
Just about no company of any size (other than the Linux distro vendors themselves) has touched anything licensed under GPLv3, either. Most companies are not comfortable with that license. Whether you feel that their fear is rational or not isn't really relevant; that fear still exists, and still drives their behavior.
Partitioning the Linux vendors away from other companies seems arbitrary to me; RedHat makes millions by selling GPLv3 software. Nokia also has GPLv3 software in its repositories for the N9 (which is an end user-oriented, DRM-restricted product).
I really don't know why companies should be afraid of the GPLv3, since it's compatible with more licenses than the GPLv2, including permissive ones such as the Apache license, and is actually more business-friendly than the GPLv2, with its automatic license reinst
Linux vendors are unusual in that they've already thoroughly cast their lot with the GPL, for better or worse. They don't have any alternative short of not being a Linux vendor. Same goes for other companies that make their living by providing support for GPLed software.
So if you imply that I should license my software under a permissive license only to give in to the companies' unjustified fears, in the hope that their involvement will make my software better, then I disagree.
If your proprietary program breaks or has a security flaw and the company is out of business or charges a fee you cannot or will not pay, you cannot fix it. If you fix it yourself, you can't share the fix. I work at a small company, we had some proprietary software that cost $650 per server in 2003 and cost $15,000 per server in 2010, and that's when we switched to a free software alternative.
With free software, if it breaks for you, you can fix it. If you can't fix it, you can pay someone else to fi
You can fix bugs in either one. But other people and companies can also fix bugs in either one. With BSD the people and companies can choose whether to share the changes when they distribute new binaries based on the changes. With GPL they have to share the changes when they distribute new binaries based on the change.
Yes, there are cases like FreeBSD and WebKit where most of the useful changes are passed upstream to the parent project. But it's overly optimistic to assume that this model will alwa
The situations where companies have created closed-source forks of BSD-licensed projects have almost invariably been cases where there was no set of benevolent core maintainers, e.g. the Apache Foundation. If the open source content is not changing significantly, there is minimal benefit of keeping up with public changes, and thus no real penalty for creating a closed branch. That's why I specifically stipulated that the ideal situation was a BSD license in which the core development was done by a benevo
I realize that Apple releases some of the changes they make as open source, and taken as a whole it's a lot of code. But the monetary value of the source code Apple releases is insignificant when views as a percentage of their annual income. They could fund an industry-changing amount of free software, and they choose not to because their entire business model is built around steering customers towards their proprietary software. I'm grateful for the code they have released back to the community, but
I'm well aware of that. Not sure what part of my post made you think I wasn't. Perhaps my comment about the primary maintainer taking something closed. That's a concern with software (regardless of license, including the GPL) because whenever an organization or company that owns a project's copyright (or enough of the copyright that they can easily rewrite the rest) decides to create a closed-source fork of that project, it generally results in the death of the open source fork of the project, for all i
Perhaps my comment about the primary maintainer taking something closed. That's a concern with software (regardless of license, including the GPL) because whenever an organization or company that owns a project's copyright (or enough of the copyright that they can easily rewrite the rest) decides to create a closed-source fork of that project, it generally results in the death of the open source fork of the project, for all intents and purposes.
This will always be the case where a project has significant corporate backers. If you have a large corporate backer, you are always at risk of them pulling the plug, forking, or in other ways derailing the project. If you don't have significant corporate backers this is not a problem- but you're also far less likely to have a seriously competitive piece of software.
The same problem applies similarly to GPL works, seeing as corporate backers can still pull the plug. For example, if Canonical were to drop Ub
This will always be the case where a project has significant corporate backers.
True, but it is a far bigger concern when you have exactly one major corporate backer. When you have five or six companies contributing lots of code, the disadvantages caused by keeping private repositories in sync with the public ones usually outweigh any advantages any single company might get from keeping significant bits proprietary.
GPL just closes off the one possible line of attack, in that the company can't have their cak
GPL is about the USERS freedom. The software is inanimate and doesn't give a crap. It's the users of the software that the GPL is intended to protect. I understand that many developers like to make a buck. I also understand that some developers want to use other peoples work for free but don't want their users to benefit in the same way. For them it's BSD.
What baffles me though is this use of a technically inferior compiler. I could see in a few years if LLVM can produce comparable code in more cases. But
I always thought about it this way: the GPL is about user freedom, and BSD is about developer freedom. If you're using GPL'd software, you are explicitly given the right to know what it's doing and the right to change it. If you're developing with BSD software, you're given the right to control how it's integrated into your project and how it's distributed. Unfortunately it's impossible to guarantee both rights at the same time; the correct choice for each project depends a lot on how that project is meant
Nonsense. BSD also gives the user the same freedom. In either case, the user can look at the sources.
In the case of the GPL, the user can look at the sources. With BSD the user may or may not have access to the source, but if he does then he has plenty of freedom.
BSD does not guarantee access to the source; it defers this choice to whoever is distributing it.
BSD lets distributors decide whether the user has access to the source, while the GPL guarantees it. You can't do both: it's impossible to let the distributor decide whether to give the source to users and also guarantee users have access. Often, authors of BSD-licensed code choose to distribute the source for free, and it's quite possible to create a much freer environment than you can with the GPL. But the GPL
Except, GPLv3 over-steps software into platform and then governance... and sadly, some platforms cannot be allowed to do whatever they COULD do.
Take for example your wifi card... is it a wifi card or a 2.4ghz radio made to be wifi? you probably could turn many wifi cards into bluetooth sniffers or cordless phone sniffers had you the FPGA code and know how... but then, that hardware manufacturer would be barred from the type approvals needed to sell the device in certain countries. What about 3G modem? Cell
What about your TiVo? Would make a great copyright infringement device with the right code.
As an aside the TiVo as it ships now includes everything you need for copyright infringement. The DMCA prevents people from selling an "all-in-one" solution for the software side, TIVO itself is not doing anything secret here.
If you have control over the hardware (as Apple does), you can make hardware changes that renders the original code unusable, locking you up in the derivative closed code.
(I'm not implying that Apple is evil - all companies are: if any of them finds a breach to restrict a freedom in order to maximize a profit, they will do it!)
Again, think of Stallman's roots, and you will see that his definition makes perfect sense. Consider that he came from MIT's AI Lab, from a hacker culture where you built upon others' code, and others built upon yours. That's what Free software means: the code is always available for everyone, and to hinder the code is to hinder everyone's freedom.
One can search the brain with a microscope and not find the
mind, and can search the stars with a telescope and not find God.
-- J. Gustav White
What's wrong with GCC? (Score:5, Interesting)
Re: (Score:5, Informative)
The GPL.
Dropping the GPL ~= worse. (Score:1, Flamebait)
While the BSD licensing model allows various hijinks to go around without the requirement of disclosure.
Complaining about the GPL is like complaining that you can't play dirty pool with code licensing(see Tivoization). Then again, you probably would rather throw some ad hominem at me regarding a certain GPL advocate.
Re:Dropping the GPL ~= worse. (Score:5, Insightful)
Complaining about the GPL is like complaining that you can't play dirty pool with code licensing(see Tivoization).
I haven't heard Apple complaining about the GPL or trying to circumvent it - they're just switching to alternative projects.
Of course, its a pity, because even if if you Tivoized GPLv2 code you still had to share your source so people could learn from it, or use and modify it on other (or jailbroken) hardware, whereas now people are moving to BSD-style licenses with no such benefits... but if the FSF want to let the perfect be the enemy of the good, declare jihad on Tivoization and have a tilt at the patent windmill, that is their right.
Re: (Score:2, Interesting)
whereas now people are moving to BSD-style licenses with no such benefits.
This is symptomatic of PHB/MBA thinking: short term gains/benefits that mortgage long term growth.
In a couple of years time, there will be a proliferation of different, incompatible versions of CLang/LLVM that will be increasingly expensive to maintain. Furthermore, I can foresee vendors making incompatible changes to the code produced by CLang, subtle ABI breakage and the like. The upper levels will suffer too : vendor A's version
Re:Dropping the GPL ~= worse. (Score:5, Interesting)
In a couple of years time, there will be a proliferation of different, incompatible versions of CLang/LLVM that will be increasingly expensive to maintain. Furthermore, I can foresee vendors making incompatible changes to the code produced by CLang, subtle ABI breakage and the like. The upper levels will suffer too : vendor A's version will not be able to compile source code with vendor B's extensions and vice versa.
Hindsight is invariably more accurate than foresight. And in this case, hindsight tells us that there are plenty of non-GPL free packages that you use every day that haven't succumbed to either of your fears. In fact you use at least a couple of them when you read this.
This sounds like the 1980s/ealy 1990s all over again
That wouldn't be bad. The productivity per user has never been higher, and most of what we use now was invented then. I'd rather see that again that these modern days where ideas are scarce and productivity per user base at an all time low.
Re: (Score:3)
> The productivity per user has never been higher
There were no software patents, so the point is very debatable.
Re: (Score:2)
And in this case, hindsight tells us that there are plenty of non-GPL free packages that you use every day that haven't succumbed to either of your fears
Yes but compilers are one area where this sort of thing has happened before and appears to be happening now. Where this fragmentation hasn't happened with BSD projects is when only one entity is heavily invested and cooperation isn't happening or his happening within the one entity.
I'd rather see that again that these modern days where ideas are scarc
Re: (Score:2)
When are these modern days with scarce ideas? I'd say we are having a pretty wonderful world of software diversity and experimentation. Just look at the incredible number of web frameworks, for designing interactive websites.
I think you just proved my point. These days, we have umpteen web frameworks. Back then, we had people inventing things like the web. We've reached a point where rehashing is considered innovation.
Compilers in their hayday never had diversity like this.
But how groundbreaking is that diversity?
People quibble about which back-end to use for the compiler. Thus this thread.
With half the OSS code out there not even compiling without a gcc front-end, I don't think you have much of a case for diversity. I remember being able to use MipsPRO, Aztec, gcc, Manx or Sun
Re: (Score:3)
Back then, we had people inventing things like the web
Which took decades, GML started around in 1960. ISIL was in the 1980s. That's not a fair comparison you have no idea what technologies being invented today are important for the computing world of 2030. How would you know?
I can tell you as someone who was around when the web starting being used in the early 1990s I didn't think of it as all that big a deal. I actually thought Gopher with built in indexing was going to be better than the HTML with
Re:Dropping the GPL ~= worse. (Score:5, Insightful)
In a couple of years time, there will be a proliferation of different, incompatible versions of CLang/LLVM that will be increasingly expensive to maintain.
It's already happened. This is why so many companies are now actively involved in the LLVM community: it's cheaper. I'm currently on my way back from BSDCan (where I was talking a bit about the progress in switching to clang) and I was at EuroLLVM a couple of weeks earlier. Both conferences were full of corporate contributors to LLVM and FreeBSD (two projects that I work on). They like the fact that the license means that they don't need to run everything that they possibly want to do past their legal team and, over the past decade, they've all discovered (at different speeds) that it's much cheaper to engage the community and push work upstream than it is to maintain a private fork.
You get much better support from companies that join your community because they regard it as being good for them than if they dump code on you because they are legally obliged to. We don't want drive-by code dumps, we want long-term commitments to maintenance.
Re: (Score:2)
I agree with you and good point regarding the X analogy. GCC has benefited time and time again from corporations contributing code that benefit other corporations in uses they never considered. LLVM has some substantial technical advantages over GCC. So we might end up with a situation like we had for a long time where GCC is standard based, feature rich but technically inferior to the commercial compilers many of which are LLVM based.
Re: (Score:2)
Or they'll be a mainline version that is maintained by an active community of both independent and paid corporate developers contributing code, and corporations that want to maintain proprietary extensions will do so in a modular way, contributing any necessary core support back to the mainline project.
There's plenty of widely-used non-GPLv3 (public doma
Re: (Score:2)
Many companies for instance strip all comments from GPL'd source before releasing for legal reason
That's specifically illegal under the GPL. Source code is defined as what is used internally. If a company uses a commented version internally they can be forced to hand that over by the people whose code they are comingling with.
Re: (Score:2)
Making things up doesn't constitute a valid argument.
You don't have to disclose anything under the GPL unless you "convey" the work to others. There is nothing to force someone to hand over internally used code.
Re: (Score:2)
You even quoted the correct line, "The 'source code' for a work means the preferred form of the work for making modifications to it" The version used by developers for making modifications is the one with the comments.
As for the GPL what prevents someone from stripping comments is that the recipient can request source.
Re: (Score:2)
Are you really that obtuse? The GPL is clearly making a distinction between high level "source code" and other forms of the code, so someone can't offer up, say, an intermediate assembly language output.
As I correctly pointed out, if the "conveyed" binary was compiled from a source with no comments in it, then source with no comments is all one has to provide.
Re: (Score:2)
The GPL is clearly making a distinction between high level "source code" and other forms of the code, so someone can't offer up, say, an intermediate assembly language output.... As I correctly pointed out, if the "conveyed" binary was compiled from a source with no comments in it, then source with no comments is all one has to provide
No that's not true, that is not what the GPL is doing. Source code is not defined as what you compile from but what you modify from. Source code the way you are using it,
Re: (Score:2)
Is it also your position that since you can't remove comments, you can't remove lines of code from the original as part of your modification?
Re: (Score:3, Insightful)
Re: (Score:3)
I think one of the heads of Red Hat nailed it when he was asked about RMS: "Richard treats his friends as his enemies". Whether the community wants to accept it or not when RMS specifically targeted a single company with GPL V3 he gave a pretty damned good reason for businesses to stay away from the GPL, fear of being the target of GPL V4.
That's a lot of meat without bones. Fear of being the target of parasite lawyers who sue over GPL is more of the reality, whether it's GPL2, 3, LGPL or other.
BTW I personally bet that if there is a GPL V4 the new buzzword will be "Androidization" since RMS hates Android even though it has put more Linux devices into users hands than anyone else in history.
I'm glad you have insight into Richard's brain and can tell us what he hates.
As for bringing more devices into the hand of people, that's not the purpose of the open source movement. At best it's a side effect. The purpose is to do what governments and their constitutions fail to do - support progress, by ensuring that new code becomes available to
Re: (Score:2, Insightful)
Re: (Score:3)
I'm glad you have insight into Richard's brain and can tell us what he hates.
Actually, that's the exact problem, isn't it? Nobody knows what RMS might do next week.
The purpose is to do what governments and their constitutions fail to do - support progress, by ensuring that new code becomes available to anyone who can improve on or learn from it.
That's clearly not the goal of the GPL3, because if it were, there would be no need of an anti-TiVoization clause, but the Affero clause would be standard.
Re: (Score:2)
As for bringing more devices into the hand of people, that's not the purpose of the Free Software movement. At best it's a side effect. .
FTFY. Making more software open source is precisely the goal of the open source movement. But not that of the FSF.
Re: (Score:2)
What lawyers have sued over GPL beyond a few special cases?
Re: (Score:2)
A quick Google search for "gpl lawsuit" returned:
About 1,810,000 results (0.21 seconds)
The publicity is enough to make managers worry, and their reaction isn't to investigate to get the real deal and make sure they dot their i's and cross their t's to avoid a potential GPL lawsuit, but to avoid GPL whenever they can.
Re: (Score:2)
I haven't seen that at all. People who are getting sued are generally getting sued for violating the GPL and on purpose. That's not lawyer parasites but the kinds of lawsuits that happen with commercial software all the time.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Use of Java/Apache vs C/C++/Gnu (Score:3)
I know there are reports that C is even with Java again. But what you say made me wonder about this. Despite what Java advocates say, the idea of the app server and enterprise Java was not new to Java. There were and still are brokers around that do much of what a Java app server does, but using C/C++. Tuxedo is one. The thing I am thinking about however, is that Java started a heyday when groups like Apache came around and there was a huge resource of Java utilities and helpers and libraries that were fre
Re: (Score:2)
I'm theorizing that Java took off because despite being further behind in enterprise architecture than C at the time (remember Tuxedo et al), it had a support community that didn't encumber the companies, so they backed this stream.
Java took off because C/C++ are a bear to work with, the time was right, and Sun was good at marketing, not because of some Apache libraries that were developed behind the popularity of Java.
Re: (Score:2)
C which also has a ton of libraries, but was hamstrung by GNU
At the point where Java took off GCC was not a very good compiler and was not a major player. The Linux kernel guys had had to fork it to try and get anything less than terrible performance. Intel's, Watcom, Microsoft, and a 4th I'm forgetting were the big players. In the early 2000s the technical disadvantages of GCC were still rather well known. We are in a rather unusual window for GCC where it seen as not just an open compiler but one
Re: (Score:2)
This modifies what I said a little, but not much. The change would be: C had either a very restrictive open source license or very restrictive closed source licenses. Java had an open license that at the same time didn't require companies to give away code they spent a ton of money to develop. Then Apache came along and made it even sweater by expanding the code base with even more open license will still not forcing companies to give away their code. And remember that a lot of the early app servers used at
Re: (Score:2)
Re: (Score:2)
It is not really an RMS issue.
The model that worked well for GPLv2 was:
company X writes code for Y that Y sells it as part of a suite to Z.
If Y wants to GPL his stuff then X's community can use it.
If Y wants to keep his stuff then he had to buy a commercial license from X.
This way X got money from people with money, got contributions from people who were willing to contribute and could sue people who did neither.
But
company X writes code for Y that Y sells as part of a SaaS suite to Z.
doesn't constitute dist
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Most big companies prefer a BSD or MIT license to GPL because it lets them take what they want and allows them to give back as much or as little as they want, including nothing. If your primary interest is promoting your own business, this makes sense. The GPL was not designed with facilitating profit as a goal, and as a result it doesn
'Tivoization' a problem? (Score:4, Informative)
Of course, its a pity, because even if if you Tivoized GPLv2 code you still had to share your source so people could learn from it, or use and modify it on other (or jailbroken) hardware, whereas now people are moving to BSD-style licenses with no such benefits... but if the FSF want to let the perfect be the enemy of the good, declare jihad on Tivoization and have a tilt at the patent windmill, that is their right.
This is absolutely the case! When TiVo was complying w/ GPLv2, the FSF suddenly discovered a major objection to their practice - namely, that they were putting the code in read-only devices, and declared a jihad on the company. However, even GPLv3 doesn't explicitly say that GPL software cannot be put on a Read-only memory (which would again violate the GNU's Freedom #3) or copy-protect memory (which could prevent the device that contains the software from getting copied) or anything else about the devices that the software can reside on.
As you very well put it, it's one more of those cases of the perfect being the enemy of the good, and in the process, the FSF waging a war on its own licensees, namely TiVo. Given that track record, which company in its right mind, even if they endorsed the liberation of software, would want to get into bed w/ the FSF?
Re: (Score:2)
> namely, that they were putting the code in read-only devices
without making the source available under the terms of the gpl, I guess?
Re: (Score:2)
Why guess about this, when it is so easy to google "Tivo GPL" or "Tivoization". From Wikipedia [wikipedia.org]:
Tivoization (pronounced "Teevo-ization") is a term coined to describe the creation of a system that incorporates software under the terms of a copyleft software license (like the GPL), but uses hardware restrictions to prevent users from running modified versions of the software on that hardware.
If the problem was simply that they were in violation of GPL v2 by not releaing the code, then there would not have been a reason to create a whole new license to address this.
Re: (Score:2)
and declared a jihad on the company
They didn't declare a jihad. They indicated that TIVO had exposed a problem with the license and sought to fix it. Particularly since at the time what TIVO was doing was likely to become more mainstream with things like the Palladium initiative.
Given that track record, which company in its right mind, even if they endorsed the liberation of software, would want to get into bed w/ the FSF?
Companies that want to help a competitor get sued. Or companies that provide so
Re: (Score:2)
Labelling the problem as 'Tivoization' was pretty much an act of bad faith, even if they didn't actually have Tivo in mind as a violator but rather, a shortcoming of GPLv2. It's a reflection of their anti-corporate profile.
GPLv3 is great if a software project wants to release it in such a way that its competitors can use it, but not improvise on it and then release the improvized software. From that angle, it's good, and even GPLv2 satisfied that. However, granting all users patents that may otherwise
Re: (Score:2)
However, granting all users patents that may otherwise accidentally get violated is nothing but an act of bad faith,
What it is an act of is an attempt to use copyright law to address a problem in black letter patent law. A patent creates a way to violate the spirit of GPLv2 without violating the letter. The purpose of the GPLv3 is to close these kinds of loopholes.
and the termination clauses, which would allow any author to revoke their license in the event of a violation, is what makes it a double ed
Re: (Score:2)
Apple has mostly dumped GCC in Lion and replaced with Clang. They still include a GCC but it's very incompatible as it has LLVM back end and breaks stuff with inline assembler. I can understand them wanting to make a change but I don't understand why they include an incompatible GCC.
Re: (Score:2)
I can understand them wanting to make a change but I don't understand why they include an incompatible GCC.
Probably just a stop-gap until everybody fixes their makefiles to use Clang rather than GCC. GCC is still the default command-line compiler. There's still a heap of open-source stuff in OS X (Apache, PHP, Perl, Python, Postgresql,...) and also projects like MacPorts that enable you to compile most of the usual open-source suspects. Since these are mostly cross-platform, I'd assume that inline assembler is fairly rare, but build scripts that depend on GCC are fairly common.
I'd guess the LLVM backend is for
Re: (Score:2)
Just for reference – they don't include gcc any more: /usr/bin/gcc /usr/bin/gcc /usr/bin/gcc -> llvm-gcc-4.2
Greyjoy:~ tatd2$ which gcc
Greyjoy:~ tatd2$ ls -la
lrwxr-xr-x 1 root wheel 12 22 Mar 15:43
Re: (Score:2)
No, llvm-gcc is GCC. More precisely, it's the GCC front end with the LLVM back end. That's the one the GP was talking about; although it is GCC, it has some hairy edges where it doesn't behave quite like the standalone GCC.
The actual Clang compilers are called clang and clang++.
clang, clang++,... (Score:2)
Re:Dropping the GPL ~= worse. (Score:4, Informative)
One reason for that is because the GCC team won't accept Apple's patches for new versions of Objective-C. Apple want to move Objective-C forward, GCC has become a barrier to that, so they support CLANG/LLVM development. The version of GCC included is simply for legacy support and will be removed in due course once CLANG support for C++ is good enough.
Clang/LLVM also gives you nifty stuff for interfacing with the IDE, far better compilation errors/warnings, faster compile times, etc.
Re: (Score:2)
But the "legacy" version of GCC isn't compatible with the older GCC. Include both and let the user decide. I need gcc for various reasons, I'm not using xcode and never will, I'm not writing mac or phone apps, so all Apple is doing is making Linux more attractive.
Re: (Score:2)
Re: (Score:2)
Yup, and am having troubles getting it to build as well. Even the mac ports version (universal so I can get 32/64 bit) has some problems with one application.
Re: (Score:2)
Re: (Score:2)
Maybe. But we do have a lot of inline asm (ie, emulating RTOS task switching, third party code with optimized functions, etc). Ie, there is code that properly checks for __GNUC__ around some inline assembler but this fails because LLVM-GCC claims to be GCC but doesn't handle the syntax correctly (possibly an xcode 4.3 bug?). Probably with time we could get things working but I.T. is insistent that people upgrade now and be disrupted rather than put it off until code is ported and makefiles rewritten.
Is
Re: (Score:2)
Due to licensing changes, apple are unable/unwilling to bundle newer versions. So maybe it is too much?
Re: (Score:2)
As far as I understand it this is the approach that LLVM recommends. Using the LLVM GCC front end for your code while you slowly migrate. If you want real GCC you can use the MacPorts version.
Re:Dropping the GPL ~= worse. (Score:5, Insightful)
Complaining about the GPL
He wasn't complaining about the GPL, he was stating (correctly) that it is one of the key reasons some groups choose not to use GCC, particularly GPL version 3 (note that FreeBSD has not used and of the recent GCC release specifically for that reason - they were fine using GPLv2).
It is a case of choosing the right tool for the job. Until recently their choice was to redefine the job (change the parts of their projects and licensing policy that GPLv3 conflicted with), keep the old tool (using older, GPLv2 licensed, releases of GCC only), or use something less stable/proven/compatible. They chose the middle option. Now option three is replaced by "use something else that is now stable/proven/compatible enough to be an alternative" they have taken that choice. Again this isn't complaining about GPLv3, it is simply refusing to use it because it is incompatible with some of their chosen goals.
I'm told there are technical reasons why Clang and the related tool chain are preferable to GCC in some circumstances too, though I'm out of the loop on that one so I don't know what they are or if they are significant to FreeBSD.
While his answer was rather terse and it would have helped to be less so (it made him appear to some, to you at least, like an anti-GPL troll), what you appear to have done in your response is set up a strawman to attack. This is the sort of thing that anti-GPL people (both within the open-source arena and external to it) will jump on as "proof" that GPL advocates are rabid loonies, so by defending the GPL in such a manner you may be harming the cause rather then helping it. You might want to be more careful not to come across that way (it may not have been you intention on this occasion, but it does seem that way by my reading).
Comment removed (Score:5, Insightful)
Re:Dropping the GPL ~= worse. (Score:5, Informative)
Tivo did exactly what RMS started the Free Software Foundation to prevent (The Printer Story [gnu.org]). What did you expect would happen?
'Problem' of TiVoization (Score:2)
TiVo and that Xerox printer @ MIT are apples and pineapples. In the case of the latter, RMS and his group wanted to get the source code of the drivers so that they could compile it for the platform they were using. It didn't involve altering anything in the printer itself that could risk making it unworkable. TiVo was about locking that box itself - but if someone wanted to write a driver whereby a Linuxstation could get inputs from a TiVo box and display it, instead of connecting it to a TV, then the Ti
Re: (Score:2)
TiVo and that Xerox printer @ MIT are apples and pineapples.
The principle is exactly the same. There was software that came with the device and they wanted the ability to modify it. Just because you could treat the TiVo as a black box doesn't mean there couldn't be value in being able to alter the source code on the TiVo itself.
Re:Dropping the GPL ~= worse. (Score:5, Insightful)
Here is what I personally don't get, maybe someone can explain it to me, but WTF was it with RMS and the TiVo? It was ONE device that had NO choice but to be made the way it was.
If it had not been TiVo it would have been something else. His problem was the use of GPLed software in that manner. While it wasn't found to break the letter of the license it broke the clearly stated spirit of the license, so that wording was updated in v3 to patch the hole.
Would he have been more happy if it had used WinCE?
Yes, basically. Or some form of BSD (the licenses used there would allow this sort of use IIRC). Or anything else not GPL licensed. They had those choices available to them.
RMS is an absolutist on this and similar matters (some would say extremist, but I feel that label to be rather too strong here): if you want to use Free, keep it Free with your use, otherwise use something else (paying for it if need be).
it just seems stupid to attack one specific corp
He wasn't going after one specific corp, just the first one that did it (visibly) first and shoring up the hole before others tried. Remember that TiVo could keep using GPLv2 software as they had already done, they'd just have to start maintaining by other means once later versions switched to GPLv3, so the switch to GPLv3 did not explicitly stop them distributing their product.
and make other businesses afraid of being next on RMS' shit list and all over a device that frankly could have been made no other way without only being sold at China Mart and other "pro piracy" hardware sites.
That is where it falls down of course, but so does every other license commercial or otherwise - if you can't enforce the license in a territory people wanting to do something against the (letter of the) licence in that territory are at an advantage to those elsewhere. "Pro piracy" regimes are not a GPL specific problem and not really relevant here - you could just as easily state that VMWare's recent licensing model changes are an attack on compliant companies.
There are many people who think RMS is wrong on the matter, of course. Linus for instance still explicitly uses GPLv2 as evidenced by it being the license git is released under (the kernel is a different matter: that could not be switched even if he wanted because of how many contributions there have been where rights were not explicitly handed over to the project).
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Building a complete OS requires a matching compiler
Why?
There are many operating systems without a matching compiler (and a few without a compiler at all), and I would think that unless you beg the question, this is patently false.
Re: (Score:2)
I think he probably should have said "Building a complete Unix like OS". Unix has always had system compilers and an assumption that even end users would need to compile code.
Re: (Score:2)
Re: (Score:2)
We are losing each other I think, or at least I'm losing you. I read up the thread I'm not seeing anything about data. So can you clarify what at this point I'm responding to.
From my perspective the GP was just giving an argument for LLVM (it is BSD licensed and thus a better fit for the BSD culture) but phrased this more generally, you questioned him and I said he was over generalizing you then agreed. Which is all good, except there is something about data here...?
Re: (Score:2)
Re: (Score:2)
Oh the reasons for portable compilers and operating systems show up a lot.
1) Most end user programs don't require low level access to hardware.
2) "Best hardware" changes rapidly, much more rapidly than software life-cycles.
Thus the intermediate levels should abstract hardware.
Both GCC and LLVM are very portable as compilers go. Both of them support operating systems that are widely cross platform.
Re:Dropping the GPL ~= worse. (Score:5, Informative)
There's a reason even the shining monument of GPL (Linux) uses GPLv2...
Even if Linus did want to move the kernel to GPLv3 (he doesn't), he would have to get every kernel contributor to agree to the license change, AFAIK.
Re: (Score:2)
There is another excellent reason why the Linux Kernel is staying on GPLv2: a very large proportion of Linux's market share these days is on ARM SoC in mobile devices. There is truckloads of IP in these devices, and right now the chipset vendors are able to keep this closed and compartmentalised.
It's not a case of these chipset vendors wanting to keep their own IP private - often it's not theirs to start with, having been licensed - probably several times already - from other parties.
You can bet that a GP
Re: (Score:2)
Re: (Score:2)
What this clause really does is say that the FSF can at any time change the details of the license you are giving to your users.
It absolutely does not. The license you give to your user is whatever words you put in the license you give to your user. You can make this up yourself, or you can use a license someone else has written for you. All the FSF does is provide legally tested templates to you to use, and they put a new version number in whenever they release a new one. If they said one day "we've decided to change the GPL v2 to be [something madly different]" it would have no effect on any software, except those that chose to ad
Re: (Score:2)
Do you really believe that Linus would use GPLv3 for the kernel ? You most be kidding. Linus is very clear about why he does not want GPLv3. He is happy with GPLv2.
Re:Dropping the GPL ~= worse. (Score:5, Insightful)
Many people wants _real_ freedom for their software
No, they don't. If they did, they'd use GNU GPL v3.
But I think you mean the opposite of what you said: people want to be free to do whatever they want with the software, including taking away the software's freedom.
That's the thing. Free software is not about your freedom, it's about the software's freedom. It is not for the benefit of anyone in particular, it is for the benefit of the whole humanity. When you think about where rms came from, and when you read his writings, you realize that his ideal is not an indifferent "here's some code, use as you wish". It is an ideologically grounded "here's some code, it's for everyone to use, and if you build upon it, the result is also for everyone to use".
Re:Dropping the GPL ~= worse. (Score:4, Insightful)
The problem with that argument is that what is best for the software and humanity is not clear cut. Most of the better software out there has significant corporate backing. Far too often, open source software falls into the trap of writing code that "works for me", where "me" is defined as the person who wrote it, yet tends not to "work for me", where "me" is defined as anyone else. Corporate backing tends to fix a lot of that because you have lots of "mes" working on the code, each of whom has a significant interest in making it work correctly and reliably (because they're getting paid to spend their time doing so). Any licensing requirements that are sufficiently onerous to scare away that corporate backing, therefore, tend to result in software of lesser quality.
IMO, the ideal situation is a BSD or similar license with the code owned by a non-profit organization. In this way, you have a reasonable assurance that the code won't suddenly get closed by its primary maintainer, and other companies are unlikely to want to close the code themselves because of the maintenance headaches of keeping a proprietary branch in sync with something that is regularly getting updated by others. However, companies are willing to work on the software and improve it because they don't have to worry about crossing some fuzzy line and getting sued.
Re:Dropping the GPL ~= worse. (Score:5, Informative)
We don't have to guess which model works best, at this point we have historical data. Your model failed with respect to X. MIT created and maintained an X that they released via. the MIT license. All the UNIX vendors then took this MIT code and intermixed it with their custom code creating value add X's that were specific to their platform, and closed source. The effect was that the X that existed in the public domain was worthless for end users, and the X's that were worthwhile were closed. X itself couldn't progress because it fragmented so all the interesting stuff existed in other layers. Years later when there was a desire for a workable open X, the XFree86 project had to start, essentially from scratch and this took years. We still haven't gotten all the features that existed in those proprietary Xs 2 decades ago.
That is the classic example of why BSD style licensing doesn't work. The primary maintainer is not unchanging.
Conversely the GPL has a long history of successful multi corporate contributions over time. The historical data simply refutes your theory of what should work.
Re:Dropping the GPL ~= worse. (Score:4, Insightful)
Far too often, open source software falls into the trap of writing code that "works for me", where "me" is defined as the person who wrote it, yet tends not to "work for me", where "me" is defined as anyone else. Corporate backing tends to fix a lot of that because you have lots of "mes" working on the code, each of whom has a significant interest in making it work correctly and reliably (because they're getting paid to spend their time doing so).
I don't see this working in the real world, e.g. with Android. Corporate backing tends to push code of low quality (cf. the plethora of bugs that were fixed when the Android specific code was put in the upstream Linux kernel) because it was written quickly due to the corporation feeling the pressure from its competitors, and because its developers are paid for the time they spend coding; their interest is focused on solving the corporation's own problems (a corporation is a very big and selfish "me") with no regards to the effect that their solution will have on others' problems (cf. what happened with Apple and CUPS). And when a corporation has moved to the next product, they have no interest whatsoever for either the old code itself or its users (cf. what happens every time a new release of Android is revealed and users would like to upgrade, but they can't because of the binary blobs or forked code).
Any licensing requirements that are sufficiently onerous to scare away that corporate backing, therefore, tend to result in software of lesser quality.
This is not what I'm seeing with GPL projects such as Linux and the GCC. I think that the code quality of an open source project depends more on the community that it's able to gather than its license. But even if it we assume it's so, then the problem lies with the FUD about the license rather than in the license itself. FUD that I find in your comment, too:
they don't have to worry about crossing some fuzzy line and getting sued.
No company has ever been sued because of "crossing some fuzzy line". A couple of companies were sued because they absolutely refused to put a tarball on an FTP site despite the fact that the authors of that code had tried to convince them to do so for years. In comparison, Google is getting sued to hell because of BSD-licensed code. The truth is that no license will make you safe from copyright/patent trolls.
Re: (Score:2)
Just about no company of any size (other than the Linux distro vendors themselves) has touched anything licensed under GPLv3, either. Most companies are not comfortable with that license. Whether you feel that their fear is rational or not isn't really relevant; that fear still exists, and still drives their behavior.
Re: (Score:2)
I really don't know why companies should be afraid of the GPLv3, since it's compatible with more licenses than the GPLv2, including permissive ones such as the Apache license, and is actually more business-friendly than the GPLv2, with its automatic license reinst
Re: (Score:2)
Linux vendors are unusual in that they've already thoroughly cast their lot with the GPL, for better or worse. They don't have any alternative short of not being a Linux vendor. Same goes for other companies that make their living by providing support for GPLed software.
No, I'm just saying that if
Re: (Score:2)
With free software, if it breaks for you, you can fix it. If you can't fix it, you can pay someone else to fi
Re: (Score:2)
What does that have to do with GPL versus BSD? They're both open source. You can fix bugs in either one.
Re: (Score:2)
Yes, there are cases like FreeBSD and WebKit where most of the useful changes are passed upstream to the parent project. But it's overly optimistic to assume that this model will alwa
Re: (Score:2)
The situations where companies have created closed-source forks of BSD-licensed projects have almost invariably been cases where there was no set of benevolent core maintainers, e.g. the Apache Foundation. If the open source content is not changing significantly, there is minimal benefit of keeping up with public changes, and thus no real penalty for creating a closed branch. That's why I specifically stipulated that the ideal situation was a BSD license in which the core development was done by a benevo
Re: (Score:2)
Re: (Score:2)
I'm well aware of that. Not sure what part of my post made you think I wasn't. Perhaps my comment about the primary maintainer taking something closed. That's a concern with software (regardless of license, including the GPL) because whenever an organization or company that owns a project's copyright (or enough of the copyright that they can easily rewrite the rest) decides to create a closed-source fork of that project, it generally results in the death of the open source fork of the project, for all i
Re: (Score:2)
Perhaps my comment about the primary maintainer taking something closed. That's a concern with software (regardless of license, including the GPL) because whenever an organization or company that owns a project's copyright (or enough of the copyright that they can easily rewrite the rest) decides to create a closed-source fork of that project, it generally results in the death of the open source fork of the project, for all intents and purposes.
This will always be the case where a project has significant corporate backers. If you have a large corporate backer, you are always at risk of them pulling the plug, forking, or in other ways derailing the project. If you don't have significant corporate backers this is not a problem- but you're also far less likely to have a seriously competitive piece of software.
The same problem applies similarly to GPL works, seeing as corporate backers can still pull the plug. For example, if Canonical were to drop Ub
Re: (Score:2)
True, but it is a far bigger concern when you have exactly one major corporate backer. When you have five or six companies contributing lots of code, the disadvantages caused by keeping private repositories in sync with the public ones usually outweigh any advantages any single company might get from keeping significant bits proprietary.
It's not "the softwre's freedom". (Score:2)
What baffles me though is this use of a technically inferior compiler. I could see in a few years if LLVM can produce comparable code in more cases. But
Re: (Score:3)
I always thought about it this way: the GPL is about user freedom, and BSD is about developer freedom. If you're using GPL'd software, you are explicitly given the right to know what it's doing and the right to change it. If you're developing with BSD software, you're given the right to control how it's integrated into your project and how it's distributed. Unfortunately it's impossible to guarantee both rights at the same time; the correct choice for each project depends a lot on how that project is meant
Re: (Score:2)
Nonsense. BSD also gives the user the same freedom. In either case, the user can look at the sources.
GPL is about giving rights to the giver of the code, and BSD is about giving freedom to the recipients of the code.
Re: (Score:2)
Nonsense. BSD also gives the user the same freedom. In either case, the user can look at the sources.
In the case of the GPL, the user can look at the sources. With BSD the user may or may not have access to the source, but if he does then he has plenty of freedom.
Re: (Score:2)
BSD does not guarantee access to the source; it defers this choice to whoever is distributing it.
BSD lets distributors decide whether the user has access to the source, while the GPL guarantees it. You can't do both: it's impossible to let the distributor decide whether to give the source to users and also guarantee users have access. Often, authors of BSD-licensed code choose to distribute the source for free, and it's quite possible to create a much freer environment than you can with the GPL. But the GPL
Re: (Score:2)
Except, GPLv3 over-steps software into platform and then governance... and sadly, some platforms cannot be allowed to do whatever they COULD do.
Take for example your wifi card... is it a wifi card or a 2.4ghz radio made to be wifi? you probably could turn many wifi cards into bluetooth sniffers or cordless phone sniffers had you the FPGA code and know how... but then, that hardware manufacturer would be barred from the type approvals needed to sell the device in certain countries. What about 3G modem? Cell
Re: (Score:2)
Funny that you use the TiVo as an example, as it is the very reason for GPLv3. [wikipedia.org]
Re: (Score:2)
What about your TiVo? Would make a great copyright infringement device with the right code.
As an aside the TiVo as it ships now includes everything you need for copyright infringement. The DMCA prevents people from selling an "all-in-one" solution for the software side, TIVO itself is not doing anything secret here.
Re: (Score:3)
And how does that "take away" anything from anyone? Am I no longer free to alter or use the original work?
Re: (Score:3)
Not necessarily.
If you have control over the hardware (as Apple does), you can make hardware changes that renders the original code unusable, locking you up in the derivative closed code.
(I'm not implying that Apple is evil - all companies are: if any of them finds a breach to restrict a freedom in order to maximize a profit, they will do it!)
Re: (Score:2)
Again, think of Stallman's roots, and you will see that his definition makes perfect sense. Consider that he came from MIT's AI Lab, from a hacker culture where you built upon others' code, and others built upon yours. That's what Free software means: the code is always available for everyone, and to hinder the code is to hinder everyone's freedom.