It did not take long for the IT pundits to declare that
having the source code available for .NET is either "a trap
for Mono", "the end of Mono" or some similarly
low accuracy per bit arguments.
It is amazing though, as some of these pundits are supposed
to be covering "free software" and "open source" and yet, they
know very little about history and how open source software is
actually developed. More worrying is the fact that they could
have researched this instead of sticking their foot in their
mouth.
I was not going to blog about this, hoping that this would
just go away, but I keep getting emails asking about these
articles (which am not going to link to, you can google them
up):
Lets look at Pundit #1:
Thanks to Mono, we now have the popular Linux programs such
as the Banshee music player, Beagle search tool and F-spot
photography program. With Mono, you can also now run Visual
Basic programs on Linux. Mono is also working on porting
Microsoft's Silverlight 1.0, a cross-browser, cross-platform
plug-in for delivering richer Web user experiences in a
project called Moonlight.
All of these programs are now in danger from Microsoft.
I know, I know, if you just look at the headline, the executive
summary, "Microsoft opens up .NET," it sounds great for Mono
open-source developers. It's actually a death trap for Mono.
No, it is not a death trap for Mono.
It seems that Pundit #1 needs a history lesson on free
software.
When GNU was launched in
1983 there were concerns similar to this one. In particular,
a concern was what would happen to people that contributed
code, but the code came from the wildly available proprietary
source code?
To put things in perspective, at the time, Universities
were getting source code licenses to ATT's Unix and it was
wildly available (by the 1980's standards of availability).
It was important that contributions to GNU were not
tainted by proprietary code that belonged to someone else.
I quote section 2.1 of the GNU
Standards document on this matter:
2.1 Referring to Proprietary Programs
Don't in any circumstances refer to Unix source code for or
during your work on GNU! (Or to any other proprietary
programs.)
If you have a vague recollection of the internals of a Unix
program, this does not absolutely mean you can't write an
imitation of it, but do try to organize the imitation
internally along different lines, because this is likely to
make the details of the Unix version irrelevant and dissimilar
to your results.
For example, Unix utilities were generally optimized to
minimize memory use; if you go for speed instead, your program
will be very different. You could keep the entire input file
in memory and scan it there instead of using stdio. Use a
smarter algorithm discovered more recently than the Unix
program. Eliminate use of temporary files. Do it in one pass
instead of two (we did this in the assembler).
Or, on the contrary, emphasize simplicity instead of
speed. For some applications, the speed of today's computers
makes simpler algorithms adequate.
Or go for generality. For example, Unix programs often have
static tables or fixed-size strings, which make for arbitrary
limits; use dynamic allocation instead. Make sure your program
handles NULs and other funny characters in the input
files. Add a programming language for extensibility and write
part of the program in that language.
Or turn some parts of the program into independently usable
libraries. Or use a simple garbage collector instead of
tracking precisely when to free memory, or use a new GNU
facility such as obstacks.
(Emphasis added).
Now, Mono is an open source project and follows those rules
(and I have followed those rules myself since 1992 when I
first started writing free software).
If only reporters had a way to find out this information,
some kind of wizard that they could use to fact check their
pieces...
[Ziing!] Hi! Am the Great Gazoogle!
Oh hi, Great Gazoogle. Say, what’s this?
Mono Project -- Contributing -- Important Rules
- If you have looked at Microsoft's implementation
of .NET or their shared source code, you will not be
able to contribute to Mono.
- In general, be careful when you are implementing
free software and you have access to proprietary
code. We need to make sure that we are not using
someone else's copyrighted code accidentally.
- Do not use the ildasm, reflector or other
equivalent tools program to disassemble proprietary
code when you are planning to reimplement a class for
Mono. If you have done this, we will not be able to
use your code.
- Please stick to published documentation for
implementing any classes; when in doubt, post to the
mailing list and discuss the possible approaches with
others.
This text was originally added before
the launch of the project, as indicated by the Great
Gazoogle:
[Zeerp!] "I looked it up, this horse was beat to death
on the mailing lists!" says the Great Gazoogle.
The Great Gazoogle can be used to identify other times when
we the issue of Rotor, SSCLI and Mono has come up in the past.
We go even further than that. We do not even
accept LGPL contributions to our own class libraries, we use
the MIT X11 license for that, and as such we are unable to
incorporate changes that were developed as LGPL or GPL with
exceptions (which is why we could not work together or accept
patches from pnet folks unless they relicensed their code).
So we do not take proprietary code, and we do not take open
source code that is not suitably licensed to be included in
Mono itself.
A similar situation existed forever for Java. Java was
only open sourced less than a year ago, but before it became
open source, the source code for Java was wildly available for
anyone that wanted to look at it under a non-open source
license.
Obviously open source efforts --GNU Classpath, the older
class library project and the various open source Java VMs--
could not accept contributions from people that had looked at
Sun's code.
And of course, there was Rotor. Rotor was Microsoft's
first attempt at giving developers some access to the source
code of .NET. Rotor used a Shared Source license instead of
MS-RL that prevented people from using its source for
commercial purposes (so just like this new release, it is a
non-stater for Mono).
Rotor differs also from the upcoming release in that Rotor
contained the source to the C# compiler and the virtual
machine and this release does not. But Rotor did not include
the "major" class libraries like ASP, ADO and Winforms that
are included in the upcoming release.
So the doomsday scenario has existed for as long as 24
years for free software, but Pundit #1 just thought of this
scenario all by himself:
If you ever, and I mean ever, want to write open-source code,
I recommend you not come within a mile of Microsoft's .NET
Framework code or any other similar projects that the boys
from Redmond "open" up.
To be fair though, it is an important warning, and it is
good that this is kept in mind by anyone contributing to open
source software.
Now lets look at Pundit with an Axe to Grind
(referred to from now on as Pundit
#2). Pundit #2 likes to setup a strawman, but he does so
in a careful way, with plausible deniability, look at this
carefully crafted piece:
If you believe some of the headlines, Microsoft just open
sourced a bunch of software related to its .Net
libraries. Don't be fooled. The definition of open source is
very clear. This is not open source. Not even a little bit. In
fact, this may actually be an insidious trap (more on that
below).
Microsoft never claimed they were open sourcing anything in
.NET. They do not even use that language. Am not sure where
the rumor that it was open source started, but clearly people
did not even bother reading the actual announcements from
Microsoft, because such text is nowhere to be found. You would
think that in this day an age they could have done a quick
check. But alas, when you got an Axe
to Grind
the axe comes first. Facts and research come last.
Some creative uses of the Axe (I had to use the great
Gazoogle to get the "joke"):
Far-fetched? Well, not if you look at Microsoft's
history. Microsoft is playing to win, and it seems to believe
the only way to win is if open source loses. This is myopic,
but the company refuses to get LASIK.
Do you get it? LASIK: so you can fix the myopic view!
So this is a pundit that repeats and quotes the claims from
Pundit #1 (the guy that did not know history) and invokes
history. To be fair, he is a pundit, his depth of knowledge
is razor thin.
In my opinion, Pundit #2 is failing at both punditry and
humor.
Credits: Great Gazoogle artwork and concept originally from
Gavin M. at Sadly, No!.