Slashdot Mirror

* Apple sued developers of the KDE and Gnome themes that were "confusingly similar" to their Aqua theme?

* Made the decision to keep their window manager closed, in order to keep the community from benefiting?

An exercise for the AC...

Here are my points:

---
OSS doesn't make sense in the reseller market (the one Microsoft is in)

As said previously, why spend millions making software when it's out there for free. If Microsoft makes the best product in the world and sells it for $300 with the source under an open source license, someone will just take the code, maybe modify it a bit, and derive their own product, presumably selling it for less.

---
but it makes sense in the support market.

Read.

---
Example is Red Hat. No, they're just under being profitable

From Red Hat's website:
"In an increasingly difficult IT environment, Red Hat delivered a profit and generated positive cash flows for the first time," commented Matthew Szulik, President and CEO of Red Hat.

I conceed, I was a touch out of date.

---
but they aren't catering to the large market

From Entrepreneur.com:
"Linux was the primary OS for 27 percent of the server operating market at the end of last year"

Again, I'm a little out of date, but 27% is not the kind of market share that Microsoft has (41% from the same website). I phrased "catering to the large market" incorrectly, but I think you get the point.

---

I should also add that it's estimated that over 70% of development occurs in-house and not for resale.

From opensource.org:
---
Programming will collapse if software has no market value

Very unlikely. Code written for resale is only the tip of the programming iceberg. It used to be said that 85% of all the code in the world was written in-house at banks and insurance companies. This is probably no longer the case ... but most estimates put the proportion of all code written in-house at companies other than software vendors at over 75%.
----

I know, I know, don't feed the trolls, but I figured that someone asked for links, I might as well offer them for those who show a real interest (and don't have their heads up their asses).

An exercise for the AC...

Here are my points:

---
OSS doesn't make sense in the reseller market (the one Microsoft is in)

As said previously, why spend millions making software when it's out there for free. If Microsoft makes the best product in the world and sells it for $300 with the source under an open source license, someone will just take the code, maybe modify it a bit, and derive their own product, presumably selling it for less.

---
but it makes sense in the support market.

Read.

---
Example is Red Hat. No, they're just under being profitable

From Red Hat's website:
"In an increasingly difficult IT environment, Red Hat delivered a profit and generated positive cash flows for the first time," commented Matthew Szulik, President and CEO of Red Hat.

I conceed, I was a touch out of date.

---
but they aren't catering to the large market

From Entrepreneur.com:
"Linux was the primary OS for 27 percent of the server operating market at the end of last year"

Again, I'm a little out of date, but 27% is not the kind of market share that Microsoft has (41% from the same website). I phrased "catering to the large market" incorrectly, but I think you get the point.

---

I should also add that it's estimated that over 70% of development occurs in-house and not for resale.

From opensource.org:
---
Programming will collapse if software has no market value

Very unlikely. Code written for resale is only the tip of the programming iceberg. It used to be said that 85% of all the code in the world was written in-house at banks and insurance companies. This is probably no longer the case ... but most estimates put the proportion of all code written in-house at companies other than software vendors at over 75%.
----

I know, I know, don't feed the trolls, but I figured that someone asked for links, I might as well offer them for those who show a real interest (and don't have their heads up their asses).

An exercise for the AC...

Here are my points:

---
OSS doesn't make sense in the reseller market (the one Microsoft is in)

As said previously, why spend millions making software when it's out there for free. If Microsoft makes the best product in the world and sells it for $300 with the source under an open source license, someone will just take the code, maybe modify it a bit, and derive their own product, presumably selling it for less.

---
but it makes sense in the support market.

Read.

---
Example is Red Hat. No, they're just under being profitable

From Red Hat's website:
"In an increasingly difficult IT environment, Red Hat delivered a profit and generated positive cash flows for the first time," commented Matthew Szulik, President and CEO of Red Hat.

I conceed, I was a touch out of date.

---
but they aren't catering to the large market

From Entrepreneur.com:
"Linux was the primary OS for 27 percent of the server operating market at the end of last year"

Again, I'm a little out of date, but 27% is not the kind of market share that Microsoft has (41% from the same website). I phrased "catering to the large market" incorrectly, but I think you get the point.

---

I should also add that it's estimated that over 70% of development occurs in-house and not for resale.

From opensource.org:
---
Programming will collapse if software has no market value

Very unlikely. Code written for resale is only the tip of the programming iceberg. It used to be said that 85% of all the code in the world was written in-house at banks and insurance companies. This is probably no longer the case ... but most estimates put the proportion of all code written in-house at companies other than software vendors at over 75%.
----

I know, I know, don't feed the trolls, but I figured that someone asked for links, I might as well offer them for those who show a real interest (and don't have their heads up their asses).

The main thrust of my argument was moral rights - you should make a decision based upon the entire work, and either view it as it was meant to be seen, or respect the director's vision and not see it at all (if that's the director's wish.)

But would people stand for their mail to be subtly modified, even if they were notified of it?

Personally, I have serious issues about taking this kind of activity to court, but after Clean-Flicks, in anticipation of being sued by the directors, sued first [bizjournals.com] to declare their activity explicity legal, the DGA didn't have any choice but to go ahead and sue to protect artists' rights.

I think what it will boil down to is that clean-flicks will have to stop pre-cleaning films directly, since they are serving in a distributory capacity (in my opinion.) Instructions on how to do it yourself, closing your eyes, having a friend take care of it, that's fine by me - but editing someone else's work for profit? Not cool. [emphasis is mine]

You, the end user, can do whatever you want with the media. You can burn it, cut it up, remaster it, mix it, splice it, or throw it away. The instant you redistribute or start to share the results of your modifications, is where the creator becomes concerned - because it is then no longer their work, although it may be represented or assumed by the viewing public as such.

The instant where you redistribute for profit is where you cross the line - and that's what I assume the DGA is finding legal grounds to sue on.

BTW, I do believe that control over distribution is covered under the rights granted by the legislature.

If end users bought a copy of an "Austin Powers" videotape, delivered it to CF to sanitize, and then watched it, I don't think there would be an issue.

However, they're offering edited films for rent, and are essentially acting as a distributor of altered content.

The real problem with this lawsuit is over gizmos allowing the user to implement blocking, as you come dangerously close to censoring just pure information (they sell a kind of "safe movie" software that tells your DVD player to censor your DVD at appropriate places.)

...the nice folks at the Open Source Initiative sell such accounts?

Oh, it isn't *that* OSI? Never mind, then.

> You seem to expect O'Reilly to act as a shill for open source.

Knowing that he helped validate the term by organising the Freeware Summit Conference, I do not see why would he be excused of supporting it.

By the way, I am not speaking about open source, but free software. By this I imply that all software should be free as in freedom, not beer.

> Why does O'Reilly's position as a book publisher mandate that he is not allowed an opinion?

He is entitled to an opinion, sure enough. But he has an obligation to give well-reasoned criticism a place. Anyone has, but publishers specially, because they control the mass media. And his choice of email messages he quoted seems to imply that all is well with Mac OS X, but the free software community disagrees, and he ignores it. Picturing himself as an open source advocate, and open source as another name for free software -- which it is not -- he should give the real free software community a say.

> if you'd read the piece, you'd see that it contains criticism of Apple as well as praise.

Which criticism, that is too expensive or incompatible with new gadgetry? This are not the real points, but that it is proprietary. I could have missed such a criticism, because the whole piece is so self-congratulatory I nearly dozed before finishing.

Actually the base OS, darwin is . So it isnt "completely closed source".

The best bug finding mechanism around is to release the software as open source software. Many, many eyes will then be looking at the code and using it.. Other coders will email you improvements, patches, and all kinds of good helpful stuff..

It's the darn'dest thing ever, open source software, you should try it!

by which definition?

Atleast not real-world definition, open source can be used as a tool for promoting or causing harm to a specific vendor(s). From Open Source Definition : "The license must not discriminate against any person or group of persons"

So is it this? The license may not dicriminate anyone but you can choose to use an open source license when you know that selecting it instead of something else as licensing method discriminates someone. For example, if someone has cumulated capital in some form (wisdom, money, whatever) and then you half this someones capital (even if it was gathered by discrimination) by opensourcing you surely discriminate this someone. That does not mean open source is bad, it's still good atleast in my opinion, but it is not a magic hippiee miracle.

1.4 "Deploy" means to use, sublicense or distribute Covered Code other than for Your internal research and development (R&D) and/or Personal Use, and includes without limitation, any and all internal use or distribution of Covered Code within Your business or organization except for R&D use and/or Personal Use, as well as direct or indirect sublicensing or distribution of Covered Code by You to any third party in any form or manner

I wonder why they wanted to limit it just to GPL? That's what the article clearly says anyway. Considering they are planning to for example make commercial closed source and open source systems co-exist, I see some practical reasons why something the original BSD license or atleast LGPL would be much more suitable in some cases. So, WHY did they name only GPL and not for example the whole OSI suite - - - or does the article contain rotten details :)

While the DFSG and the OSD are equivalent, that doesn't mean that Debian and the OSI always interpret them similarly.

Debian generally errs on the side of caution, whereas the OSI seems mostly interested in looking good in the press, so lets dubious stuff like the APSL through.

The last word on the APSL on debian-legal concludes that the APSL probably doesn't even qualify for non-free, because of the insistence on a 12 month minimum source publication period, whereas Debian only keeps source for versions of binaries we are currently publishing.

Apple have adopted open standards in just about everything they've done without trying to damage them a la M$ & Kerberos. I've seen plenty of Embrace but absolutely no Extend nor Extinguish. Please point some out ...

They've based their entire OS core on BSD/Mach and then went on to release the sources, including those of the usual services. I just downloaded bootpd a minute ago, BTW.

Indeed - in fact the APSL is OSI Approved. So it is just fine.

If Apple uses the APSL [apple.com], then the source code could not be used in Linux [kernel.org].

The APSL is not compatible with the GPL. This means that you could not link the APSL code directly into GPLed code such as the linux kernel. However, i do not see why the rendezvous code would need to actually be in the kernel. It seems preferable to me that a linux implementation of rendezvous would be just a daemon or something, like inetd or any other number of things are, in which case it would just be a normal program and could be under any license at all.

If for some reason i can't forsee it is somehow necessary for the rendezvous implementation to be in the kernel, it could just be done as a kernel module; there is some dispute as to whether it is okay for linux kernel modules to be non-GPL, but a lot of people, including Linus Tourvalds, interpret the GPL such that OS kernel modules do not have to be GPLed.

I'm uncertain if Debian [debian.org] would accept any APSL submissions.

The GNU foundation doesn't like the APSL. However, debian is more aligned with OSI than they are with the GNU foundation. (Correct me if this is incorrect.) Anyway, in order for Debian to include software in its core distribution, that software must fit the Debian Free Software Guidelines. The APSL is on the OSI approved license list meaning it fits the DFSG and APSL code could be included in Debian's main codebase, no problem.

Incidentally, Debian does maintain a non-free portion to their distribution, it is just that this portion is not considered "part of the main distribution", and it is not always included with the install discs (it depends on how you obtain your copy of debian, as far as i can tell). But that's irrelivant here because the APSL is OSI certified!

The only reason Apple's decision not to use the GPL would be a problem, as far as i can tell, is that some people don't like to release code under non-GPL licenses, and those people may decide not to contribute to a rendezvous implementation. But other than a few offended people, that's about the extent of the problems the APSL presents.

But it makes the GPL so much easier to understand, doesn't it? If the FSF doesn't like it, why doesn't the writer submit it to the OSI as a new license? I'd use it.

Does this mean that open source free ware is still...well...free??

No, it means it isn't. Its not Open Source if it doesn't meet the Open Source Definition and this violates sections 1 and 6.

It isn't open source unless it can be freely distributed and modified. Something is only open source when it complies to the Open Source Definition

Yes the issues were fixed, no RMS is way not cool with the QPL. The solution was for Trolltech to license Qt under a dual GPL/QPL license. I can't think of anyone out there who actually uses the QPL side of it, but people are certainly happy with the GPL part.

It ain't GPL-compatible, but it is Open.

Why is this modded as informative? You cant take someone elses work and re-release it under a different license. What you can do is include its code in GPL'd projects. But that code is not GPL'd, it is still subject to the terms of the BSDL. Read the damn license before you feel the need to comment on it.

"Preferred" doesn't have to be slippery at all, though.

For any software, the government must create a list of requirements and specs for what the software should do. If you can fulfill those requirements and specifications, and be Open Source, the contract should go to you, or one of your Open Source competitors. If there's no Open Source solution that completely fulfills those requirements, then the choice will be among proprietary vendors.

This way, there's pressure for proprietary vendors to Open Source their software, but it's not necessary for everyone to use Open Source software in every case.

(You know, I just realized that I probably should be using the phrase "open source" instead of "Open Source". I think it's important that the government be able to alter its own software, but mandating public access to the source of all government software is another argument altogether. Force of habit.)

Simmer down, now... -SNL skit reference, no attempt to simulate the accents used...

Really, though, I thought the comment you are reacting to was an attempt to point out exactly what you are saying. At least that's the way I saw it.

Although there is a thread of bias against large corporations here, I think the real negativity towards AOL tends to be from those who don't like the infusion of the clueless into internet society. It used to be the realm of the geek. Now everyone participates, and the noise to signal ratio has gone way up.

I don't harbor negativity towards AOL for this. Rather, I feel that developers have done their job well when an interface disguises underlying complexities. AOL's interface allows my parents to get online without extensive training

Microsoft, on the other hand, is a different matter for most of us. For me, I dislike Microsoft, not for their monopoly, but for their methods of acheiving it and maintaining it. If you haven't already, read The Halloween Documents. They expose the kind of things that Microsoft does to hurt the Internet, hurt healthy competition and ultimately hurt the consumer.

For me, my enjoyment of Linux has nothing to do with Microsoft. I am a computer hobbyist, and the learning I can to with Linux makes it fun for me. I would have no problem with Microsoft having a monopoly over the commercial market as long as they were doing it ethically. The market should be won by having a better product, not by destroying competition through underhanded and arguably illegal means.

The OSI doesn't agree with you.

Now, please begin your RMS-style ranting about how open source software is not the same as free software.

Damn, I love these ACs. Please, if anyone wants to have a debate here, grow some genitals and post under your user name.

"A major study" ...by some guy who my sister's friend's aunt met at the circle-K...

From OSI jobs page
Programming will collapse if software has no market value

"Very unlikely. Code written for resale is only the tip of the programming iceberg. It used to be said that 85% of all the code in the world was written in-house at banks and insurance companies. This is probably no longer the case (and a good thing; who in their right mind wants to wear a tie and grind out huge volumes of COBOL?) but most estimates put the proportion of all code written in-house at companies other than software vendors at over 75%."

Forgive me for not putting that right or looking it up. I'll forgive you for being a mocking jack-ass.

"And the leftover 25% would most likely be fine as well" ..most likely, we guess, although nobody really knows because it hasn't been tried. And if they would prefer to remain programmers, fuck 'em - everybody should follow the Church of Stallman!

Although I resent your sarcasm, I'll agree with you here on both points. Stallman has gone over the top quite a few times. That doesn't make him wrong, however.


"Microsoft is slowly realizing the benefits of the OSS development model"

Here's the really humorous part. Yeah, they were so tired of making money they decided to just go Open Source!

Damn, you're dense. I didn't say they're doing open source, I said they're realizing the benefits. Read: Shared source. I didn't say how far they were taking it, just that they realize the benefits. This is just a beginning.


"you only make yourself look like one"

whereas by quoting statistics without also quoting sources you make yourself a paragon of truth and reliable source of undisputable facts, I suppose.

Being sarcastic doesn't add to your point, either.

I think that these legal issues should not be underestimated. Microsoft will use the DMCA, patents, trade secrets etc. as a weapon against real competition, no matter how the current anti-trust lawsuit ends. Just look at the Halloween documents. In these documents, patents are described as a method to fight competing operating systems. And I believe that MS will enter the legal arena if the OS war becomes really close.

Why don't you read rule three and four of the official definition.

And if you still don't see it, then skip ahead and read the last rule, rule nine "The License Must Not Restrict Other Software".

> it seems like you are quoting history you yourself didn't live through.

Wrong. I started developing on the IBM System 370 in 1976. I installed Windows 1.0 on a single-1.44-floppy Kaypro 2000 laptop (they claimed it was impossible -- it took six hours of switching floppy disks). I modified the HP Laserjet driver for Borland's Sprint text editor to work with my HP Deskjet 500. I used Software Carousel to run Gem Draw, Turbo Pascal, FFM (a shareware file manager), and a DOS prompt, in swappable sessions, all loaded into 1 MB of memory on a PC. I could go on, but suffice it to say that I was there, and I was paying attention.

> Microsoft has never billed itself as an innovator until very recently.

Microsoft still isn't an innovator. .Net is a combination of Java (the C# language), and cross-language capabilities that already exist on other platforms (e.g. IBM's Logical Environment for C, PL/1, and Cobol). Microsoft hired the main developer of Borland's Delphi to provide them with C#, and IIRC they bought a company that was already working on the cross-language capabilities.

> Microsoft's strategy was based on low price and high volume.

Microsoft's strategy has always been to sabotage the competition. They made a change in DOS 5 (IIRC) that broke Geoworks. They put a fake error message in Windows to make people afraid to use DR-DOS, then added secret API calls to Windows 95 to prevent it from running on DR-DOS. Microsoft lied to WordPerfect about supporting OS/2, then provided broken Windows API calls to WordPerfect while using secret calls in MS Word. Microsoft changed the function-key API to break AMI Pro, which, at the time, was the fastest growing word processor. Microsoft's efforts to sabotage Java ("grow the polluted Java market"), Netscape ("make the use of any other browser a jolting experience"), and Linux ("decommoditize protocols") are well documented.

> > Do you remember, in the early nineties, when we had hardware-based Virtual Machine capabilities on the > PC? Remember when, because of virtual memory and multitasking innovations from companies like Qualcomm, we were able to run multiple copies of DOS, DR-DOS, and other OSes, in parallel?

> The company was Quarterdeck. You didn't have virtual machines prior to the 386 since the 8088 and 286 didn't offer protected memory. Quarterdeck's 286 task sharing system (Desqview) was able to allow for genuine multi-tasking when the 386 came out. This was about the same time that Microsoft offered multi-tasking in windows.

It would appear that you are the one who wasn't there at the time.

Quarterdeck did indeed provide the software, Desqview, that allowed multitasking on the PC.

However, Desqview provided multitasking capabilities even before the 386 arrived.

Before the 386, Desqview provided multitasking by making use of hardware memory-management capabilities built into certain memory cards, which, if I recall correctly, were built by Qualcomm.

At the time, there were two competing standards for taking PC memory beyond 1 MB, called extended and expanded memory (don't ask me which was which). The simpler, and less expensive option came from memory cards supplied by AST. Those cards did not have any multitasking capabilities. The more expensive memory cards came from Qualcomm (IIRC), and those were the cards that had the necessary hardware and protocols to allow Desqview to provide full multitasking on a PC.

At that time, both companies, and everyone else, knew that having two different standards was holding everyone back. Thus, an industry consortium formed, that included both memory card manufacturers, and dozens of other major players. That consortium came up with a single memory, standard, which not only provided for multitasking and hardware-based virtual memory, but was also backward compatible with the two earlier standards -- all the old software would still run. I remember cheering out loud when I read about it.

As soon as the consortium had announced its memory standard, however, Microsoft immediately announced that Windows would be using a different standard, one that tied memory management into Windows, and one that provided none of the memory protection and multitasking abilities of the consortium standard.

Multitasking on the PC was already working before the 386 was even introduced. It was going to work even better. Microsoft destroyed it.

And you are right that the 386 also makes virtual-machines possible. That's one of the reasons why Microsoft has worked so hard to tie hardware peripherals directly into Windows. Now, the only way to get VM capabilities on a PC is through a software layer, like VMware, that sits on top of an OS, or emulates the complex interaction between Windows and the PC hardware.

> [Microsoft] didn't offer [386 memory protection] in Windows for the reason we were just discussing above such protection would have caused large numbers of the Dos applications to not function.

That's BS. We have 386 memory protection today, and I can still run old DOS programs. I have it on Windows NT, I have it on Linux, and it's on OS/2. You can talk about what OS/2 may or may not have been doing years ago, but OS/2 today makes full use of the CPU and memory capabilities, and still has better DOS emulation than even Windows 3.1 did.

> > Remember when, in 1990, everyone had a capable GUI, that is, eveyone but Microsoft? By the end of the > eighties, we had the Macintosh, the Amiga, the Atari ST, and OS/2 and Geoworks for the PC.

> For a very long time the business community rejected GUIs in favor of menu system which Microsoft did support via. ansi.sys quite well.

Nonesense. The industry chose the PC because it was cheaper. Just because Microsoft hadn't yet provided a GUI doesn't mean the industry didn't want one.

> Notice that Geoworks was not scalable but rather was a niche product that filled a particular hardware gap in Microsoft's strategy existed for a short period of time and died.

You are kidding, aren't you? Geoworks was intended to be, and in fact was, a full GUI layer running on top of the OS. Geoworks was one of the top selling pieces of PC software at the time, and came pre-loaded with a good percentage of PCs. And Microsoft sabotaged Geoworks by introducing an incompatibility into DOS. Geoworks soon provided a patch to get around the problem, which I ordered, but by then it was too late -- Geoworks had been killed.

In order to prevent new competitors like DR-DOS and Geoworks, Microsoft tied the GUI layer into the OS. Note that Microsoft lied, and said that Windows was combined with DOS in Windows 95, but the DR-DOS lawsuit eventually proved that all Microsoft had done was add some secret API calls to make Windows incompatible with DR-DOS.

> > It wasn't until five years later that Microsoft came out with something even remotely similar, in Windows 95.

> Did the start menu rather than application groups make that much of a difference?

That is a truly deceptive response. What happened to all of your PC knowledge all of a sudden?

Geoworks and OS/2 (and the Amiga) were pre-emptive multitasking. Windows 3.1, on the other hand, used co-operative multitasking, which meant any badly-written application could prevent other applications from running. Windows 95 was more-or-less pre-emptive, though, because the GUI is tied into the OS, there are still far too many cases where Windows 95 will not let me switch tasks.

> > Remember when there were simple standards for LANs (SMP),

> Baloney. There were no used standards for LANs at all when NetBUI came out.

That's true early on. But IBM introduced SMB, clean and simple, then Microsoft "embraced and extended" it. Now it's an undocumented mess.

> > security (Kerberos),

> Again a Unix standard.

Which Microsoft has again adopted, and extended in proprietary, undocumented ways.

The value of a standard like Kerberos is in its being open and shared. It is that value that Microsoft seeks to destroy. Cross-platform compatibility does not fit well with Microsoft's lock-in strategy.

> > printers (PCL),
> > and video (VGA)?
> > Microsoft didn't want open standards,

> Microsoft has never had any problems with PCL.
> Again what did Microsoft ever do to hinder VGA?

The point is that common interface standards were developing on their own, until Microsoft trumped the standards process. Microsoft began taking an active role in defining hardware standards for the PC.

Microsoft has studiously resisted defining or improving standards at the points where they are simple, and can be shared. Instead, Microsoft set the "standard" at a complex interface between to driver and the OS, a point where, due to its complexity, hardware manufactures are unable to share. Thus, we now have a situation where there are no standards, and every printer manufacturer, and every video manufacturer, has their own unique driver.

Thus, today, it is not enough for an OS like Linux to support a common set of video and printer interface standards. Now, Linux can't communicate with a hardware peripheral without having a complex driver to deal with that hardware's unique interface. Companies like NVidia are so married to this lock-in process, that their hardware interface is undocumented and secret.

> Microsoft has been the champion of open hardware which makes standards difficult to say the least. No one benefit more from easy unified interfaces than Microsoft, but what they have refused to do is tie into particular vendors.

Hahahahaha...please stop...I can't breath.

The reason why Linux and OS/2 have so much trouble communicating with the various printers, and video hardware, is because there are no standards. That's the way Microsoft intended it to be.

What Microsoft wanted, and achieved, was for each peripheral to have its own unique interface, with its own unique driver -- a driver that ties it to only Windows.

Of course, Microsoft's strategy backfires somewhat. The same thing that makes it hard for Linux to interface with PC peripherals, also makes it hard for Windows NT and 2000. That's why the hardware support has been so poor in Windows NT, because, like Linux, there is no clear set of standards for Windows NT to support -- each peripheral needs its own unique driver, rewritten just for NT.

> > Remember when Microsoft tried to sabotage the standards for Java and OpenGL? Remember the Halloween document where Microsoft stated their plans to "decommoditize" (i.e. destroy the openness of Internet protocols? Have you noticed that Microsoft has been carrying through on that threat?

> You are switching from crushing innovation to not being standards compliant. This is a different issue.

You don't consider it an innovation to be able to automatically download and run software in your browser, in complete safety and security?

You don't consider it an innovation for the entire world be able to communicate, publish, and read information, using any platform?

You don't consider it to be "crushing" innovation when Microsoft pollutes those common standards, thus sabotaging and destroying the capabilities they provide?

> And how many 64 bit CPUs do Microsoft's customer's use? Again Microsoft supports customer demand.

Haha, please, I asked you to stop with the jokes.

Industry has been running 64-bit servers for a long time. If they could do so more cheaply, and just as well, with Windows, then they would. Microsoft tried to compete in that field, prompting articles that appointed Windows NT as the Unix killer. Microsoft failed because they weren't up to the challenge. Microsoft's rate of development -- their innovation if you will -- is too slow, and of too poor quality.

> Above you go on for standards. If there is one area that Microsoft has innovated in more than any other company its creating a standard base for applications and the creation of standard applications.

As I have said, the truth is the opposite of your claim.

What standards exist have occurred despite Microsoft. Microsoft's "Embrace, Extend, Extinguish" strategy has destroyed simple standards, and replaced them with hoops that everyone has to jump through in order to run on a PC. Microsoft's "standards" are intentionally-complex interfaces, intended to tie hardware manufacturers to Windows, by making it too expensive to consider supporting more than one platform.

But don't take my word for it. Microsoft described this process themselves, in the Halloween Document:

> "OSS projects have been able to gain a foothold in many server applications because of the wide utility of highly commoditized, simple protocols. By extending these protocols and developing new protocols, we can deny OSS projects entry into the market."

But Microsoft has been digging their own grave. There are few left who trust Microsoft and, with the growth of Linux, I expect things to change. Once the hardware manufacturers discover how much easier it is to interface with Linux, they are going to start to innovate again. Actually, as I pointed out in my earlier post, that process has already started.

Actually... if you really want to get pedantic...

You've missed the difference between having the source code available (sometimes referred to as "open source") and Open Source.

In short, having source code available does not make a project Open Source - its all about the licensing. And not all Open Source projects match the Free Software definition (witness FSF vs BSD jihads).

> Are they an actual evil company?

Of course they are. But don't take my word for it. You can see it in Microsoft's own words...

Microsoft sabotages new technologies:

> The "strategic objective" is to "kill cross-platform Java by grow[ing] the polluted Java market." http://java.sun.com/lawsuit/051498.unfair.html

Microsoft commits fraud against their customers:

> "At this point its [sic] not good to create MORE noise around our win32 java classes. Instead we should just quietly grow j++ share and assume that people will take advantage of our classes without ever realizing they are building win32-only java apps." (same link)

Microsoft uses extortion:

> "Apple let us down on the browser by making Netscape the standard install." Gates then reported that he had already called Apple's CEO [Gil Amelio] to ask "how we should announce the cancellation of Mac Office...."

> "Though the language of the agreement uses the word "encourage," I think that the spirit is that Apple should be using [IE] everywhere and if they don't do it, then we can use Office as a club." http://www.usdoj.gov/atr/cases/f3800/msjudgex.htm

In order to get what they want, Microsoft is even willing to destroy things that are of great value to the whole world, such as the openness and compatibility of the Internet:

> "OSS projects have been able to gain a foothold in many server applications because of the wide utility of highly commoditized, simple protocols. By extending these protocols and developing new protocols, we can deny OSS projects entry into the market." http://www.opensource.org/halloween/halloween1.htm l

But those are only a few examples. Microsoft's entire history has been one of sabotage and fraud. Plus, Microsoft has never produced a new idea, preferring to copy others.

As a result of Microsoft's acts of destruction, PC technology is ten years behind where it should be.

Huh? How is Troll Tech evil? People wanted QT under the GPL, and lo and behold, they released it under the GPL. Seems like a nice bunch of folks to me.

Not quite. People really wanted it under the LGPL or BSD licenses, just like GTK+, FLTK, FOX, wxWindows, etc.

One of the problems (unless you follow Stallman's manifesto) is that although the Free version is free for open-source, their commercial licenses are structured so that if at any point in time your software project is touched by a free (free, non-commercial, acedemic, etc) version of Qt, you may never at any later time buy a commercial license and release your software commercially.

Huh? How is Troll Tech evil? People wanted QT under the GPL, and lo and behold, they released it under the GPL. Seems like a nice bunch of folks to me.

Not quite. People really wanted it under the LGPL or BSD licenses, just like GTK+, FLTK, FOX, wxWindows, etc.

One of the problems (unless you follow Stallman's manifesto) is that although the Free version is free for open-source, their commercial licenses are structured so that if at any point in time your software project is touched by a free (free, non-commercial, acedemic, etc) version of Qt, you may never at any later time buy a commercial license and release your software commercially.

Apple's license is OSI Certified, and is quite close to being "Free Software" as defined by the FSF with the only "flaw" according to the FSF being "any modified version "deployed" in an organization must be published". I don't really understand why so many seem to be bothered by the APSL.

False. "Open Source" is not a trademark; it has been ruled too generic to use. I think you're talking about "OSI Certified", which is a trademark of the Open Source Initiative.

You can call anything you want Open Source without legal trouble, because Open Source as yet has no legal definition.

February 1998
Eric Raymond and friends come up with the term "open source". They apply for trademark status and put up the opensource.org web site.

In December 1990, folks were discussing "open source" software, particularly BSD. Thad Florian quoted Kent Paul Dolan using the term, then used it himself.

Check it here. Basicaly, the BSD License allows you to do whatever you want with the toaster and the clock. Even sell it. En masse, if you want to. You just can't complain that the free toaster you got doesn't work with your bread size. And you can't say your clock-toaster isn't based on anything, you have to give credit to the authors.

there are many more open source licences.

And things get more complicated if some software is dual licenced or use an license that is incompatible wit other licences.

And this kind of thing might me important if you do support on some product.

If it was this simple why do people start flame fests here all the time over GPL and other licences.

I submitted this earlier today, but it was rejected, it has some more interesting links, some of them in Spanish, feel free to post translations(I don't have the time to do it myself)

2002-07-16 12:59:06 Microsoft buys Peru (articles,news) (rejected)
---
The firts news, in Spanish, from Barrapunto, Advogato have another article about it in English, and another news item from Register, and more coverage in Spanish in a Peruvian news site.

Basically MS is "giving" 550$ million in software and consulting, including setting up an intranet for the congress, a "secure" web site for the government and giving away software for a few thousand schools.

I wonder how much is this really costing to MS? and how much will they get back from it? How much will Peru have to pay in the next "upgrade cycle"?

The proposed bill to mandate Free/Open software in the government have been put on hold, and will probably be dismissed, but some people(including Dr. Villanueva) will continue working on getting it accepted.

Well, we all knew that it was just matter of time until MS bought their own country...

At least we all have gained from this a great anti-FUD
---

How much buys you 550M $$? This days it seems yo buy you a full country... with president and all...

The POVray license contains:

These archives must not be re-archived using a different method
without the explicit permission of the POV-Team. You may rename
the archives only to

which collides with 3 of the OSD:

3. Derived Works

The license must allow modifications and derived works, and
must allow them to be distributed under the same terms as the
license of the original software.

Further on, the POVray license also contains

You must distribute a FULL PACKAGE of files as described in the
next section.

[..]

[Definition Full Package:]

1) End user executable archives containing an executable
program,
documentation, and sample scenes but no source.

- or -

2) Programmer archives containing full source code but no
executable.
Also you must include an archive containing documentation,
and
sample scenes. On some platforms, the documentation and
sample
scenes are archived separately from the source. Source alone
is not sufficient. You must have docs and scenes.

This collides with 1 of the OSD:

1. Free Redistribution

The license shall not restrict any party from selling or giving
away the software as a component of an aggregate software
distribution containing programs from several different
sources. The license shall not require a royalty or other fee
for such sale.

After our new logo was featured on Slashdot, we have received a ton of email asking where to obtain a LOGO Interpreter for Linux. This is the LOGO interpreter we used to create our new, um, logo:

ftp://ftp.anarres.cs.berkeley.edu/pub/ucblogo

-OSI Certification Program

After our new logo was featured on Slashdot, we have received a ton of email asking where to obtain a LOGO Interpreter for Linux. This is the LOGO interpreter we used to create our new, um, logo:

ftp://ftp.anarres.cs.berkeley.edu/pub/ucblogo

-OSI Certification Program

Well, the certification is useful because it helps us tell real open source licenses from fake ones.

The logo, on the other hand, is pretty much for PHB's.

Here is a complete list of various sized images for your web pages.

http://opensource.org/trademarks/osi-certified/w eb /

This paper analyzes the amount of source code in GNU/Linux, using Red Hat Linux 7.1 as a representative GNU/Linux distribution, and presents what I believe are interesting results.

In particular, it would cost over $1 billion ($1,000 million - a Gigabuck) to develop this GNU/Linux distribution by conventional proprietary means in the U.S. (in year 2000 U.S. dollars). Compare this to the $600 million estimate for Red Hat Linux version 6.2 (which had been released about one year earlier). Also, Red Hat Linux 7.1 includes over 30 million physical source lines of code (SLOC), compared to well over 17 million SLOC in version 6.2. Using the COCOMO cost model, this system is estimated to have required about 8,000 person-years of development time (as compared to 4,500 person-years to develop version 6.2). Thus, Red Hat Linux 7.1 represents over a 60% increase in size, effort, and traditional development costs over Red Hat Linux 6.2. This is due to an increased number of mature and maturing open source / free software programs available worldwide.

Many other interesting statistics emerge. The largest components (in order) were the Linux kernel (including device drivers), Mozilla (Netscape's open source web system including a web browser, email client, and HTML editor), the X Window system (the infrastructure for the graphical user interface), gcc (a compilation system), gdb (for debugging), basic binary tools, emacs (a text editor and far more), LAPACK (a large Fortran library for numerical linear algebra), the Gimp (a bitmapped graphics editor), and MySQL (a relational database system). The languages used, sorted by the most lines of code, were C (71% - was 81%), C++ (15% - was 8%), shell (including ksh), Lisp, assembly, Perl, Fortran, Python, tcl, Java, yacc/bison, expect, lex/flex, awk, Objective-C, Ada, C shell, Pascal, and sed.

The predominant software license is the GNU GPL. Slightly over half of the software is simply licensed using the GPL, and the software packages using the copylefting licenses (the GPL and LGPL), at least in part or as an alternative, accounted for 63% of the code. In all ways, the copylefting licenses (GPL and LGPL) are the dominant licenses in this GNU/Linux distribution. In contrast, only 0.2% of the software is public domain.

This paper is an update of my previous paper on estimating GNU/Linux's size, which measured Red Hat Linux 6.2 [Wheeler 2001]. Since Red Hat Linux 6.2 was released in March 2000, and Red Hat Linux 7.1 was released in April 2001, this paper shows what's changed over approximately one year. More information is available at http://www.dwheeler.com/sloc. 1. Introduction The GNU/Linux operating system has gone from an unknown to a powerful market force. Netcraft found that, of the systems running web servers on June 2001, GNU/Linux was now the second most popular operating system (with 29.6%, versus Windows' 49.6%) [Netcraft 2001]. Another survey, of primarily European and educational sites, found that GNU/Linux was used more than any other operating system (of the sites it surveyed) [Zoebelein 1999]. IDC found that 25% of all server operating systems purchased in 1999 were GNU/Linux, making it second only to Windows NT's 38% [Shankland 2000a].

There appear to be many reasons for this, and not simply because GNU/Linux can be obtained at no or low cost. For example, experiments suggest that GNU/Linux is highly reliable. A 1995 study of a set of individual components found that the GNU and GNU/Linux components had a significantly higher reliability than their proprietary Unix competitors (6% to 9% failure rate with GNU and Linux, versus an average 23% failure rate with the proprietary software using their measurement technique) [Miller 1995]. A ten-month experiment in 1999 by ZDnet found that, while Microsoft's Windows NT crashed every six weeks under a ``typical'' intranet load, using the same load and request set the GNU/Linux systems (from two different distributors) never crashed [Vaughan-Nichols 1999].

However, possibly the most important reason for GNU/Linux's popularity among many developers and users is that its source code is generally ``open source software'' and/or ``free software''. A program that is ``open source software'' or ``free software'' is essentially a program whose source code can be obtained, viewed, changed, and redistributed without royalties or other limitations of these actions. A more formal definition of ``open source software'' is available from the Open Source Initiative [OSI 1999], a more formal definition of ``free software'' (as the term is used in this paper) is available from the Free Software Foundation [FSF 2000], and other general information about these topics is available at Wheeler [2000a]. Quantitative rationales for using open source / free software is given in Wheeler [2000b]. The GNU/Linux operating system is actually a suite of components, including the Linux kernel on which it is based, and it is packaged, sold, and supported by a variety of distributors. The Linux kernel is ``open source software''/``free software'', and this is also true for all (or nearly all) other components of a typical GNU/Linux distribution. Open source software/free software frees users from being captives of a particular vendor, since it permits users to fix any problems immediately, tailor their system, and analyze their software in arbitrary ways.

Surprisingly, although anyone can analyze GNU/Linux for arbitrary properties, I have found little published analysis of the amount of source lines of code (SLOC) contained in a GNU/Linux distribution. Microsoft unintentionally published some analysis data in the documents usually called ``Halloween I'' and ``Halloween II'' [Halloween I] [Halloween II]. Another study focused on the Linux kernel and its growth over time is by Godfrey [2000]; this is an interesting study but it focuses solely on the Linux kernel (not the entire operating system). Paul G. Allen posted some results from running Scientific Toolworks, Inc.'s tools on the Linux kernel, but this analysis only considered C code (including headers) - ignoring the many other languages used in constructing the Linux kernel (e.g., assembly language), and only concentrating on the kernel. The Free Code Graphing Project at http://fcgp.sourceforge.net generates a graphical representation of a program (currently, the Linux kernel), but only of the C code. In a previous paper, I examined Red Hat Linux 6.2 and the numbers from the Halloween papers [Wheeler 2001].

This paper updates my previous paper, showing estimates of the size of one of today's GNU/Linux distributions, and it estimates how much it would cost to rebuild this typical GNU/Linux distribution using traditional software development techniques. Various definitions and assumptions are included, so that others can understand exactly what these numbers mean. I have intentionally written this paper so that you do not need to read the previous version of this paper first.

For my purposes, I have selected as my ``representative'' GNU/Linux distribution Red Hat Linux version 7.1. I believe this distribution is reasonably representative for several reasons:

1. Red Hat Linux is the most popular Linux distribution sold in 1999 according to IDC [Shankland 2000b]. Red Hat sold 48% of all copies in 1999; the next largest distribution in market share sales was SuSE (a German distributor) at 15%. Not all GNU/Linux copies are ``sold'' in a way that this study would count, but the study at least shows that Red Hat's distribution is a popular one.
2. Many distributions (such as Mandrake) are based on, or were originally developed from, a version of Red Hat Linux. This doesn't mean the other distributions are less capable, but it suggests that these other distributions are likely to have a similar set of components.
3. All major general-purpose distributions support (at least) the kind of functionality supported by Red Hat Linux, if for no other reason than to compete with Red Hat.
4. All distributors start with the same set of open source software projects from which to choose components to integrate. Therefore, other distributions are likely to choose the same components or similar kinds of components with often similar size for the same kind of functionality.

Different distributions and versions would produce different size figures, but I hope that this paper will be enlightening even though it doesn't try to evaluate ``all'' distributions. Note that some distributions (such as SuSE) may decide to add many more applications, but also note this would only create larger (not smaller) sizes and estimated levels of effort. At the time that I began this project, version 7.1 was the latest version of Red Hat Linux available, so I selected that version for analysis.

Note that Red Hat Linux 6.2 was released on March 2000, Red Hat Linux 7 was released on September 2000 (I have not counted its code), and Red Hat Linux 7.1 was released on April 2001. Thus, the differences between Red Hat Linux 7.1 and 6.2 show differences accrued over 13 months (approximately one year).

Clearly there is far more open source / free software available worldwide than is counted in this paper. However, the job of a distributor is to examine these various options and select software that they believe is both sufficiently mature and useful to their target market. Thus, examining a particular distribution results in a selective analysis of such software.

Section 2 briefly describes the approach used to estimate the ``size'' of this distribution (more details are in Appendix A). Section 3 discusses some of the results. Section 4 presents conclusions, followed by an appendix. GNU/Linux is often called simply ``Linux'', but technically Linux is only the name of the operating system kernel; to eliminate ambiguity this paper uses the term ``GNU/Linux'' as the general name for the whole system and ``Linux kernel'' for just this inner kernel. 2. Approach My basic approach was to:

1. install the source code files in uncompressed format; this requires carefully selecting the source code to be analyzed.
2. count the number of source lines of code (SLOC); this requires a careful definition of SLOC.
3. use an estimation model to estimate the effort and cost of developing the same system in a proprietary manner; this requires an estimation model.
4. determine the software licenses of each component and develop statistics based on these categories.

More detail on this approach is described in Appendix A. A few summary points are worth mentioning here, however. 2.1 Selecting Source Code

I included all software provided in the Red Hat distribution, but note that Red Hat no longer includes software packages that only apply to other CPU architectures (and thus packages not applying to the x86 family were excluded). I did not include ``old'' versions of software, or ``beta'' software where non-beta was available. I did include ``beta'' software where there was no alternative, because some developers don't remove the ``beta'' label even when it's widely used and perceived to be reliable.

I used md5 checksums to identify and ignore duplicate files, so if the same file contents appeared in more than one file, it was only counted once (as a tie-breaker, such files are assigned to the first build package it applies to in alphabetic order).

The code in makefiles and Red Hat Package Manager (RPM) specifications was not included. Various heuristics were used to detect automatically generated code, and any such code was also excluded from the count. A number of other heuristics were used to determine if a language was a source program file, and if so, what its language was.

Since different languages have different syntaxes, I could only measure the SLOC for the languages that my tool (sloccount) could detect and handle. The languages sloccount could detect and handle are Ada, Assembly, awk, Bourne shell and variants, C, C++, C shell, Expect, Fortran, Java, lex/flex, LISP/Scheme, Makefile, Objective-C, Pascal, Perl, Python, sed, SQL, TCL, and Yacc/bison. Other languages are not counted; these include XUL (used in Mozilla), Javascript (also in Mozilla), PHP, and Objective Caml (an OO dialect of ML). Also code embedded in data is not counted (e.g., code embedded in HTML files). Some systems use their own built-in languages; in general code in these languages is not counted.

This paper analyzes the amount of source code in GNU/Linux, using Red Hat Linux 7.1 as a representative GNU/Linux distribution, and presents what I believe are interesting results.

In particular, it would cost over $1 billion ($1,000 million - a Gigabuck) to develop this GNU/Linux distribution by conventional proprietary means in the U.S. (in year 2000 U.S. dollars). Compare this to the $600 million estimate for Red Hat Linux version 6.2 (which had been released about one year earlier). Also, Red Hat Linux 7.1 includes over 30 million physical source lines of code (SLOC), compared to well over 17 million SLOC in version 6.2. Using the COCOMO cost model, this system is estimated to have required about 8,000 person-years of development time (as compared to 4,500 person-years to develop version 6.2). Thus, Red Hat Linux 7.1 represents over a 60% increase in size, effort, and traditional development costs over Red Hat Linux 6.2. This is due to an increased number of mature and maturing open source / free software programs available worldwide.

Many other interesting statistics emerge. The largest components (in order) were the Linux kernel (including device drivers), Mozilla (Netscape's open source web system including a web browser, email client, and HTML editor), the X Window system (the infrastructure for the graphical user interface), gcc (a compilation system), gdb (for debugging), basic binary tools, emacs (a text editor and far more), LAPACK (a large Fortran library for numerical linear algebra), the Gimp (a bitmapped graphics editor), and MySQL (a relational database system). The languages used, sorted by the most lines of code, were C (71% - was 81%), C++ (15% - was 8%), shell (including ksh), Lisp, assembly, Perl, Fortran, Python, tcl, Java, yacc/bison, expect, lex/flex, awk, Objective-C, Ada, C shell, Pascal, and sed.

The predominant software license is the GNU GPL. Slightly over half of the software is simply licensed using the GPL, and the software packages using the copylefting licenses (the GPL and LGPL), at least in part or as an alternative, accounted for 63% of the code. In all ways, the copylefting licenses (GPL and LGPL) are the dominant licenses in this GNU/Linux distribution. In contrast, only 0.2% of the software is public domain.

This paper is an update of my previous paper on estimating GNU/Linux's size, which measured Red Hat Linux 6.2 [Wheeler 2001]. Since Red Hat Linux 6.2 was released in March 2000, and Red Hat Linux 7.1 was released in April 2001, this paper shows what's changed over approximately one year. More information is available at http://www.dwheeler.com/sloc. 1. Introduction The GNU/Linux operating system has gone from an unknown to a powerful market force. Netcraft found that, of the systems running web servers on June 2001, GNU/Linux was now the second most popular operating system (with 29.6%, versus Windows' 49.6%) [Netcraft 2001]. Another survey, of primarily European and educational sites, found that GNU/Linux was used more than any other operating system (of the sites it surveyed) [Zoebelein 1999]. IDC found that 25% of all server operating systems purchased in 1999 were GNU/Linux, making it second only to Windows NT's 38% [Shankland 2000a].

There appear to be many reasons for this, and not simply because GNU/Linux can be obtained at no or low cost. For example, experiments suggest that GNU/Linux is highly reliable. A 1995 study of a set of individual components found that the GNU and GNU/Linux components had a significantly higher reliability than their proprietary Unix competitors (6% to 9% failure rate with GNU and Linux, versus an average 23% failure rate with the proprietary software using their measurement technique) [Miller 1995]. A ten-month experiment in 1999 by ZDnet found that, while Microsoft's Windows NT crashed every six weeks under a ``typical'' intranet load, using the same load and request set the GNU/Linux systems (from two different distributors) never crashed [Vaughan-Nichols 1999].

However, possibly the most important reason for GNU/Linux's popularity among many developers and users is that its source code is generally ``open source software'' and/or ``free software''. A program that is ``open source software'' or ``free software'' is essentially a program whose source code can be obtained, viewed, changed, and redistributed without royalties or other limitations of these actions. A more formal definition of ``open source software'' is available from the Open Source Initiative [OSI 1999], a more formal definition of ``free software'' (as the term is used in this paper) is available from the Free Software Foundation [FSF 2000], and other general information about these topics is available at Wheeler [2000a]. Quantitative rationales for using open source / free software is given in Wheeler [2000b]. The GNU/Linux operating system is actually a suite of components, including the Linux kernel on which it is based, and it is packaged, sold, and supported by a variety of distributors. The Linux kernel is ``open source software''/``free software'', and this is also true for all (or nearly all) other components of a typical GNU/Linux distribution. Open source software/free software frees users from being captives of a particular vendor, since it permits users to fix any problems immediately, tailor their system, and analyze their software in arbitrary ways.

Surprisingly, although anyone can analyze GNU/Linux for arbitrary properties, I have found little published analysis of the amount of source lines of code (SLOC) contained in a GNU/Linux distribution. Microsoft unintentionally published some analysis data in the documents usually called ``Halloween I'' and ``Halloween II'' [Halloween I] [Halloween II]. Another study focused on the Linux kernel and its growth over time is by Godfrey [2000]; this is an interesting study but it focuses solely on the Linux kernel (not the entire operating system). Paul G. Allen posted some results from running Scientific Toolworks, Inc.'s tools on the Linux kernel, but this analysis only considered C code (including headers) - ignoring the many other languages used in constructing the Linux kernel (e.g., assembly language), and only concentrating on the kernel. The Free Code Graphing Project at http://fcgp.sourceforge.net generates a graphical representation of a program (currently, the Linux kernel), but only of the C code. In a previous paper, I examined Red Hat Linux 6.2 and the numbers from the Halloween papers [Wheeler 2001].

This paper updates my previous paper, showing estimates of the size of one of today's GNU/Linux distributions, and it estimates how much it would cost to rebuild this typical GNU/Linux distribution using traditional software development techniques. Various definitions and assumptions are included, so that others can understand exactly what these numbers mean. I have intentionally written this paper so that you do not need to read the previous version of this paper first.

For my purposes, I have selected as my ``representative'' GNU/Linux distribution Red Hat Linux version 7.1. I believe this distribution is reasonably representative for several reasons:

1. Red Hat Linux is the most popular Linux distribution sold in 1999 according to IDC [Shankland 2000b]. Red Hat sold 48% of all copies in 1999; the next largest distribution in market share sales was SuSE (a German distributor) at 15%. Not all GNU/Linux copies are ``sold'' in a way that this study would count, but the study at least shows that Red Hat's distribution is a popular one.
2. Many distributions (such as Mandrake) are based on, or were originally developed from, a version of Red Hat Linux. This doesn't mean the other distributions are less capable, but it suggests that these other distributions are likely to have a similar set of components.
3. All major general-purpose distributions support (at least) the kind of functionality supported by Red Hat Linux, if for no other reason than to compete with Red Hat.
4. All distributors start with the same set of open source software projects from which to choose components to integrate. Therefore, other distributions are likely to choose the same components or similar kinds of components with often similar size for the same kind of functionality.

Different distributions and versions would produce different size figures, but I hope that this paper will be enlightening even though it doesn't try to evaluate ``all'' distributions. Note that some distributions (such as SuSE) may decide to add many more applications, but also note this would only create larger (not smaller) sizes and estimated levels of effort. At the time that I began this project, version 7.1 was the latest version of Red Hat Linux available, so I selected that version for analysis.

Note that Red Hat Linux 6.2 was released on March 2000, Red Hat Linux 7 was released on September 2000 (I have not counted its code), and Red Hat Linux 7.1 was released on April 2001. Thus, the differences between Red Hat Linux 7.1 and 6.2 show differences accrued over 13 months (approximately one year).

Clearly there is far more open source / free software available worldwide than is counted in this paper. However, the job of a distributor is to examine these various options and select software that they believe is both sufficiently mature and useful to their target market. Thus, examining a particular distribution results in a selective analysis of such software.

Section 2 briefly describes the approach used to estimate the ``size'' of this distribution (more details are in Appendix A). Section 3 discusses some of the results. Section 4 presents conclusions, followed by an appendix. GNU/Linux is often called simply ``Linux'', but technically Linux is only the name of the operating system kernel; to eliminate ambiguity this paper uses the term ``GNU/Linux'' as the general name for the whole system and ``Linux kernel'' for just this inner kernel. 2. Approach My basic approach was to:

1. install the source code files in uncompressed format; this requires carefully selecting the source code to be analyzed.
2. count the number of source lines of code (SLOC); this requires a careful definition of SLOC.
3. use an estimation model to estimate the effort and cost of developing the same system in a proprietary manner; this requires an estimation model.
4. determine the software licenses of each component and develop statistics based on these categories.

More detail on this approach is described in Appendix A. A few summary points are worth mentioning here, however. 2.1 Selecting Source Code

I included all software provided in the Red Hat distribution, but note that Red Hat no longer includes software packages that only apply to other CPU architectures (and thus packages not applying to the x86 family were excluded). I did not include ``old'' versions of software, or ``beta'' software where non-beta was available. I did include ``beta'' software where there was no alternative, because some developers don't remove the ``beta'' label even when it's widely used and perceived to be reliable.

I used md5 checksums to identify and ignore duplicate files, so if the same file contents appeared in more than one file, it was only counted once (as a tie-breaker, such files are assigned to the first build package it applies to in alphabetic order).

The code in makefiles and Red Hat Package Manager (RPM) specifications was not included. Various heuristics were used to detect automatically generated code, and any such code was also excluded from the count. A number of other heuristics were used to determine if a language was a source program file, and if so, what its language was.

Since different languages have different syntaxes, I could only measure the SLOC for the languages that my tool (sloccount) could detect and handle. The languages sloccount could detect and handle are Ada, Assembly, awk, Bourne shell and variants, C, C++, C shell, Expect, Fortran, Java, lex/flex, LISP/Scheme, Makefile, Objective-C, Pascal, Perl, Python, sed, SQL, TCL, and Yacc/bison. Other languages are not counted; these include XUL (used in Mozilla), Javascript (also in Mozilla), PHP, and Objective Caml (an OO dialect of ML). Also code embedded in data is not counted (e.g., code embedded in HTML files). Some systems use their own built-in languages; in general code in these languages is not counted.

This paper analyzes the amount of source code in GNU/Linux, using Red Hat Linux 7.1 as a representative GNU/Linux distribution, and presents what I believe are interesting results.

In particular, it would cost over $1 billion ($1,000 million - a Gigabuck) to develop this GNU/Linux distribution by conventional proprietary means in the U.S. (in year 2000 U.S. dollars). Compare this to the $600 million estimate for Red Hat Linux version 6.2 (which had been released about one year earlier). Also, Red Hat Linux 7.1 includes over 30 million physical source lines of code (SLOC), compared to well over 17 million SLOC in version 6.2. Using the COCOMO cost model, this system is estimated to have required about 8,000 person-years of development time (as compared to 4,500 person-years to develop version 6.2). Thus, Red Hat Linux 7.1 represents over a 60% increase in size, effort, and traditional development costs over Red Hat Linux 6.2. This is due to an increased number of mature and maturing open source / free software programs available worldwide.

Many other interesting statistics emerge. The largest components (in order) were the Linux kernel (including device drivers), Mozilla (Netscape's open source web system including a web browser, email client, and HTML editor), the X Window system (the infrastructure for the graphical user interface), gcc (a compilation system), gdb (for debugging), basic binary tools, emacs (a text editor and far more), LAPACK (a large Fortran library for numerical linear algebra), the Gimp (a bitmapped graphics editor), and MySQL (a relational database system). The languages used, sorted by the most lines of code, were C (71% - was 81%), C++ (15% - was 8%), shell (including ksh), Lisp, assembly, Perl, Fortran, Python, tcl, Java, yacc/bison, expect, lex/flex, awk, Objective-C, Ada, C shell, Pascal, and sed.

The predominant software license is the GNU GPL. Slightly over half of the software is simply licensed using the GPL, and the software packages using the copylefting licenses (the GPL and LGPL), at least in part or as an alternative, accounted for 63% of the code. In all ways, the copylefting licenses (GPL and LGPL) are the dominant licenses in this GNU/Linux distribution. In contrast, only 0.2% of the software is public domain.

This paper is an update of my previous paper on estimating GNU/Linux's size, which measured Red Hat Linux 6.2 [Wheeler 2001]. Since Red Hat Linux 6.2 was released in March 2000, and Red Hat Linux 7.1 was released in April 2001, this paper shows what's changed over approximately one year. More information is available at http://www.dwheeler.com/sloc. 1. Introduction The GNU/Linux operating system has gone from an unknown to a powerful market force. Netcraft found that, of the systems running web servers on June 2001, GNU/Linux was now the second most popular operating system (with 29.6%, versus Windows' 49.6%) [Netcraft 2001]. Another survey, of primarily European and educational sites, found that GNU/Linux was used more than any other operating system (of the sites it surveyed) [Zoebelein 1999]. IDC found that 25% of all server operating systems purchased in 1999 were GNU/Linux, making it second only to Windows NT's 38% [Shankland 2000a].

There appear to be many reasons for this, and not simply because GNU/Linux can be obtained at no or low cost. For example, experiments suggest that GNU/Linux is highly reliable. A 1995 study of a set of individual components found that the GNU and GNU/Linux components had a significantly higher reliability than their proprietary Unix competitors (6% to 9% failure rate with GNU and Linux, versus an average 23% failure rate with the proprietary software using their measurement technique) [Miller 1995]. A ten-month experiment in 1999 by ZDnet found that, while Microsoft's Windows NT crashed every six weeks under a ``typical'' intranet load, using the same load and request set the GNU/Linux systems (from two different distributors) never crashed [Vaughan-Nichols 1999].

However, possibly the most important reason for GNU/Linux's popularity among many developers and users is that its source code is generally ``open source software'' and/or ``free software''. A program that is ``open source software'' or ``free software'' is essentially a program whose source code can be obtained, viewed, changed, and redistributed without royalties or other limitations of these actions. A more formal definition of ``open source software'' is available from the Open Source Initiative [OSI 1999], a more formal definition of ``free software'' (as the term is used in this paper) is available from the Free Software Foundation [FSF 2000], and other general information about these topics is available at Wheeler [2000a]. Quantitative rationales for using open source / free software is given in Wheeler [2000b]. The GNU/Linux operating system is actually a suite of components, including the Linux kernel on which it is based, and it is packaged, sold, and supported by a variety of distributors. The Linux kernel is ``open source software''/``free software'', and this is also true for all (or nearly all) other components of a typical GNU/Linux distribution. Open source software/free software frees users from being captives of a particular vendor, since it permits users to fix any problems immediately, tailor their system, and analyze their software in arbitrary ways.

Surprisingly, although anyone can analyze GNU/Linux for arbitrary properties, I have found little published analysis of the amount of source lines of code (SLOC) contained in a GNU/Linux distribution. Microsoft unintentionally published some analysis data in the documents usually called ``Halloween I'' and ``Halloween II'' [Halloween I] [Halloween II]. Another study focused on the Linux kernel and its growth over time is by Godfrey [2000]; this is an interesting study but it focuses solely on the Linux kernel (not the entire operating system). Paul G. Allen posted some results from running Scientific Toolworks, Inc.'s tools on the Linux kernel, but this analysis only considered C code (including headers) - ignoring the many other languages used in constructing the Linux kernel (e.g., assembly language), and only concentrating on the kernel. The Free Code Graphing Project at http://fcgp.sourceforge.net generates a graphical representation of a program (currently, the Linux kernel), but only of the C code. In a previous paper, I examined Red Hat Linux 6.2 and the numbers from the Halloween papers [Wheeler 2001].

This paper updates my previous paper, showing estimates of the size of one of today's GNU/Linux distributions, and it estimates how much it would cost to rebuild this typical GNU/Linux distribution using traditional software development techniques. Various definitions and assumptions are included, so that others can understand exactly what these numbers mean. I have intentionally written this paper so that you do not need to read the previous version of this paper first.

For my purposes, I have selected as my ``representative'' GNU/Linux distribution Red Hat Linux version 7.1. I believe this distribution is reasonably representative for several reasons:

1. Red Hat Linux is the most popular Linux distribution sold in 1999 according to IDC [Shankland 2000b]. Red Hat sold 48% of all copies in 1999; the next largest distribution in market share sales was SuSE (a German distributor) at 15%. Not all GNU/Linux copies are ``sold'' in a way that this study would count, but the study at least shows that Red Hat's distribution is a popular one.
2. Many distributions (such as Mandrake) are based on, or were originally developed from, a version of Red Hat Linux. This doesn't mean the other distributions are less capable, but it suggests that these other distributions are likely to have a similar set of components.
3. All major general-purpose distributions support (at least) the kind of functionality supported by Red Hat Linux, if for no other reason than to compete with Red Hat.
4. All distributors start with the same set of open source software projects from which to choose components to integrate. Therefore, other distributions are likely to choose the same components or similar kinds of components with often similar size for the same kind of functionality.

Different distributions and versions would produce different size figures, but I hope that this paper will be enlightening even though it doesn't try to evaluate ``all'' distributions. Note that some distributions (such as SuSE) may decide to add many more applications, but also note this would only create larger (not smaller) sizes and estimated levels of effort. At the time that I began this project, version 7.1 was the latest version of Red Hat Linux available, so I selected that version for analysis.

Note that Red Hat Linux 6.2 was released on March 2000, Red Hat Linux 7 was released on September 2000 (I have not counted its code), and Red Hat Linux 7.1 was released on April 2001. Thus, the differences between Red Hat Linux 7.1 and 6.2 show differences accrued over 13 months (approximately one year).

Clearly there is far more open source / free software available worldwide than is counted in this paper. However, the job of a distributor is to examine these various options and select software that they believe is both sufficiently mature and useful to their target market. Thus, examining a particular distribution results in a selective analysis of such software.

Section 2 briefly describes the approach used to estimate the ``size'' of this distribution (more details are in Appendix A). Section 3 discusses some of the results. Section 4 presents conclusions, followed by an appendix. GNU/Linux is often called simply ``Linux'', but technically Linux is only the name of the operating system kernel; to eliminate ambiguity this paper uses the term ``GNU/Linux'' as the general name for the whole system and ``Linux kernel'' for just this inner kernel. 2. Approach My basic approach was to:

1. install the source code files in uncompressed format; this requires carefully selecting the source code to be analyzed.
2. count the number of source lines of code (SLOC); this requires a careful definition of SLOC.
3. use an estimation model to estimate the effort and cost of developing the same system in a proprietary manner; this requires an estimation model.
4. determine the software licenses of each component and develop statistics based on these categories.

More detail on this approach is described in Appendix A. A few summary points are worth mentioning here, however. 2.1 Selecting Source Code

I included all software provided in the Red Hat distribution, but note that Red Hat no longer includes software packages that only apply to other CPU architectures (and thus packages not applying to the x86 family were excluded). I did not include ``old'' versions of software, or ``beta'' software where non-beta was available. I did include ``beta'' software where there was no alternative, because some developers don't remove the ``beta'' label even when it's widely used and perceived to be reliable.

I used md5 checksums to identify and ignore duplicate files, so if the same file contents appeared in more than one file, it was only counted once (as a tie-breaker, such files are assigned to the first build package it applies to in alphabetic order).

The code in makefiles and Red Hat Package Manager (RPM) specifications was not included. Various heuristics were used to detect automatically generated code, and any such code was also excluded from the count. A number of other heuristics were used to determine if a language was a source program file, and if so, what its language was.

Since different languages have different syntaxes, I could only measure the SLOC for the languages that my tool (sloccount) could detect and handle. The languages sloccount could detect and handle are Ada, Assembly, awk, Bourne shell and variants, C, C++, C shell, Expect, Fortran, Java, lex/flex, LISP/Scheme, Makefile, Objective-C, Pascal, Perl, Python, sed, SQL, TCL, and Yacc/bison. Other languages are not counted; these include XUL (used in Mozilla), Javascript (also in Mozilla), PHP, and Objective Caml (an OO dialect of ML). Also code embedded in data is not counted (e.g., code embedded in HTML files). Some systems use their own built-in languages; in general code in these languages is not counted.

The mere ability to read source isn't enough to support independent peer review and rapid evolutionary selection. For rapid evolution to happen, people need to be able to experiment with and redistribute modifications.

Legally anyway. I haven't looked at the EULA for Gamespy (haven't downloaded it, actually), but I'm betting some large odds it'll have some clause in it saying they're not responsible even if it destroys your computer, sets fire to your home, and heralds the End of the World.

You mean like this one and this one, and this one, and every other EULA I've ever read?

The infamous Halloween Documents (granted, they're from 1998, but the MO hasn't changed a bit - it's just being approached from a different angle) out-and-out prove that MS perceives Linux as a threat - MS honestly sees Linux as a true threat to its stranglehold on market share, and with shifts in corporate IT departments to Linux and other UNIX-based systems in favour of XP or 2k-based systems, MS clearly thinks that Linux is an obstacle to be steamrolled in the process of gaining back lost market share.

With the Macintosh crowd turning firmly toward UNIX-based systems with the release of MacOS X, it's all the more clear that UNIX is beginning to win back all the space it lost through the 90s.

What's more, the application suites in Linux are quickly beginning to rival those developed by MS for its own OS - I've tried OpenOffice 1, and it's just as good as its Microsoft-produced counterpart.

There's just one more hurdle to clear - getting independent software developers to see things the same way. Games make the system, and this is one area where Linux is lacking. Smash-hit store-bought games is one major reason why Windows took off. Linux still doesn't have the wealth of games that Windows has, unfortunately.

Here's my suggestion. Make inroads into the home market - get the average Joe User to see how well Linux performs - and word will spread like wildfire. As long as the only people who proselytise Linux are IT directors, it won't achieve the one thing we all want - the downfall of the Big Redmond Machine.

Linux has made considerable gains in recent years - and this is largely attributable to its consistently top-notch development system and the initiative to develop applications that compete head-on with similar Windows products. But it's not over yet.

As the columnist said, Tuxers, it's time for the gloves to come off.

The acid test of any license is whether it's DFSG [debian.org] free and can thus be included in Debian, Mandrake and other Free Software distributions.

Er, no. The Open Source Definition and the Free Software List of Freedoms are used a lot more commonly than the DFSG, which the OSD to a certain extend replaced. I think you just saw this as an excuse to advocate Debian ignoring well known yardstick of the Open Source / Free Software community. Mandrake use the OSD themselves to define what should and shouldn't be in their distro, as do Red Hat (both of which do include proprietary apps, eg Netscape 4, when there are no stable OSS alternatives).

Groups like Apple and the DivX team have been known to release purportedly "open source" software under look-but-don't-touch style licenses.

They are lying. As there's as little to stop them saying a proprietary application is Open Source under the DFSG as there is the Open Source Definition.