Attachmate Acquisition: What does it mean for SUSE, openSUSE & open source?

—A Q&A with Jeff Hawn, chairman and CEO of Attachmate by Jos Poortvliet, openSUSE Community Manager at Novell

I had a chance to speak with Jeff Hawn, chairman and CEO of Attachmate Corporation about his views and intentions around SUSE and openSUSE. Jeff has commented that SUSE is an important brand and business that he wants to strengthen. What are his thoughts about the community and what does he see for SUSE and openSUSE? Here below are the questions I put forward and Jeff’s current thoughts. —Jos

Open Source

What is Attachmate’s history with open source projects?

Attachmate does not have a corporate track record in the open source business. However, we recognize the importance of open source technology, particularly Linux, and the growing value it brings to enterprises globally. We also recognize and value the openSUSE project, the contribution that the community makes to the SUSE business and most importantly, the many ways in which the community benefits SUSE customers.

At the end of the day, we are a technology company that is customer-driven, made up of engineers and technology enthusiasts. We have a lot of individuals that are long-time users of open source and participants in the open source movement. We recognize and understand what the community has developed, particularly over the last decade, and we are excited to be part of its future.

What is Attachmate’s view of open source software?

Attachmate recognizes that enterprises all over the world are utilizing more open source technology in their infrastructures, data centers and desktops every year. We believe this is a trend that will continue and that’s why we are excited about the Open Platform Solutions business and in particular, the SUSE Linux community.

It is easy for people to assume that because we are not currently in the open source business, we don’t value or understand it. This is far from the case. We are in the business of meeting customer needs and they see great value in utilizing open source technology solutions. Because of its open nature, open source is being adopted by enterprises in all industries around the world. Our intent is to keep it that way and continue to foster what has made it so successful for the Open Platforms Solutions business.

SUSE

Ok, then what is the plan for SUSE?

We cannot speak to specifics until after close, but what we can communicate now is our intention to establish a SUSE business unit on par with the existing Attachmate and NetIQ business units. We believe that establishing SUSE as its own business unit will give greater focus and flexibility to grow within a competitive market. We view SUSE as a well regarded and proven technology in the open source and enterprise Linux community and we want to further build upon that. We intend for SUSE to continue to provide the same high quality open source technology solutions, such as SUSE Linux Enterprise Server, needed to meet users’ demands for scalability, interoperability and cost effectiveness.

What will the SUSE business unit be – what do you mean by “business unit”?

A business unit brings together all the resources, IP, people and infrastructure needed to operate – to build product, deliver solutions and support customers. So, what is known today as Open Platform Solutions will now be centralized within the SUSE business unit. In most respects SUSE will continue to operate as it did as OPS, but will benefit from being a dedicated and more visible brand with a focused business unit behind it.

Does Attachmate intend to immediately sell the SUSE business?

I want to be clear here: all of our efforts will be focused on doing the things necessary to make SUSE the highest performing business with the strongest openSUSE community that we can. This is a healthy, growing dynamic business. We want to continue to nurture this business and grow it. This is why we want to elevate the SUSE brand and operate that part of the business as a distinct unit where it will receive greater visibility and focus.

How do you plan to compete in the Linux market?

We’re excited about SUSE because of the great competitive advantages it already has. With thousands of certified ISV applications, the best interoperability and unsurpassed scalability, it provides the best value and the lowest cost of ownership on the market. Attachmate intends to continue that commitment to high quality and cost-effective solutions.

What are your intentions for open source initiatives sponsored by Novell today?

No decisions have been made regarding any specific projects or sponsorships. Much more integration work needs to happen before discussions of changing the status of individual projects can occur. But we can say that the new SUSE business unit will stay committed to participating in the projects and initiatives that are most important to the SUSE business and its customers.

Will Attachmate continue to support Linux kernel development by employees as Novell has done?

Yes, we will. Key contributions to the Linux kernel are a benefit to everyone in the community. This sort of contribution is a key element of what makes the synergy between business and open source so successful and we intend to continue support it.

openSUSE

Will Attachmate increase or decrease the investments in development and marketing for openSUSE?

There is a lot of integration work to do before those decisions are made and some of that work cannot be done until after the transaction has closed. Our intent is to continue to sponsor and participate in the openSUSE project.

Will this impact the initiative to create an independent foundation for openSUSE?

No decisions on this initiative have been made. This is a complex topic that has been actively debated in the community for some time. We look forward to continuing that discussion with the community after the close of the transaction.

Will Attachmate continue to support the openSUSE conference?

No decisions have been made about the ongoing sponsorship of openSUSE conference. It is simply too early to reach conclusions on specific areas such as this – more integration work and collaboration with the SUSE team is needed. Our overall intent is to maintain the continuity of success we see within the SUSE business and that includes continuing to work closely with the openSUSE community.

Will the acquisition have any other effects on the openSUSE project or community?

We look forward to learning more about the project and working together with the community to figure out what’s working well, what could be done differently or improved. This will be a highly collaborative relationship.

Does Attachmate intend to shut down the openSUSE community project?

No, we don’t. Attachmate intends to continue the sponsorship and collaboration with the openSUSE project. We view the openSUSE project and its extended community as an important part of the overall SUSE business and we value its contributions to the technology that forms the heart of the SUSE offerings (see related statement on the Attachmate website here).

Intellectual Property

What IP assets are being purchased by CPTN Holdings LLC?

Attachmate cannot provide details on the IP assets being purchased, but we can clarify that CPTN is NOT purchasing products. They are purchasing 882 patents and patent applications as described in the initial 8-K filed by Novell.

The purchase does not include the Novell UNIX copyrights (see related statement on the Novell website here). It does not include the product source code or product implementations.

Attachmate would not buy a company and not preserve what is working nor hamper our ability to operate this business. So, SUSE will retain all the technology, rights and IP needed to continue and grow.

Does the purchase by CPTN Holdings impact the openSUSE project or the SUSE enterprise business?

After the merger is complete, the SUSE business unit will retain all the IP and technology rights needed to operate, continue its sponsorship of the openSUSE project and supporting SUSE customers.

What happens to the Novell UNIX copyrights after the sale of IP assets to CPTN Holdings?

No change. The purchase of IP assets by CPTN Holdings does not include the UNIX copyrights and the copyrights will continue to be owned by Novell (see related statement on the Novell website here).

Take it for what it’s worth, I guess. I’d say it doesn’t look good for the Open Source projects, especially those with no direct profitable application, but I take a cynical view of such press releases.

Consider the retardation of the question “Does Attachmate intend to shut down the OpenSUSE community project” – it’s not like Attachmate could do such a thing, even if the wanted to. What they could do (and what I suspect they eventually will do) is adopt the same sort of “relationship” with external communities that Oracle does: basically, do exactly what we want, how we want it, and we still won’t support you in any way whatsoever of import.

I’m dying to find a copy of the “Exhibit A” that lists the 882 patents – it is referred to in several SEC filings, but the exhibit itself is not available as far as I can tell.

My favorite bit: the “intention to establish a SUSE business unit on par with the existing Attachmate and NetIQ business units”. And since we all know how the existing Attachmate and NetIQ business units have lit the Linux world on fire with innovation and contribution, this can only be a fantastic development.

Oh Twitter User, It’s So Cute When You Try

So, as I parsed my enormous referrer logs, populated only with visits by Distinguished Guests of the Highest Caliber, I noticed some incoming Twitter traffic. Imagine my shock when I found someone defending Mono on Twitter! Then imagine my utter disbelief when I found that same someone – brace yourself – had their facts wrong! Why I nearly succumbed to the Vapors that Very Moment!

A shock I know, but steel yourself, Gentle Reader, as we journey forth again…(and to seven hells with Twitter for not having an easy-to-use threaded conversation view. I’ve often said this is because no one is interested in having a real conversation or discussion there. Twitter: Proof that a terrible UI is no bar to massive success.)

plaimbock: #ubuntu 11.04 switches to #banshee http://is.gd/i7avD but what about the #MCP/patent issues? pixie dust made them vanish? http://is.gd/i7aUx

trampstr: @plaimbock Their are no patient issues, Banshee is covered a legally binding “community promise” not to sue

trampstr: @plaimbock maybe you missed it but the work to cut back the size of the banshee install for 11.04 removed all non EMCA components. Its safe.

trampstr: @plaimbock http://bit.ly/e81pnr <- commit that removed all non emca components.

Of course, those who are paying attention in class already know the problem, but I’ll point it out here for anyone just joining us:

• Banshee is not covered, in any sense.
• All of the non-ECMA components were not removed.
• That commit doesn’t remove all the non-ECMA components.

3 tweets, every one of which is totally, 100% wrong presented as casually as you like without disclaimer, explainer or retainer.

Let me also note there is also an important distinction to be made between “Banshee is covered” and “Mono is covered”. If applications were directly being covered, then we wouldn’t care if Mono or Logo or Any Other Language were being used. But the Community Promise is applied to the C#/CLI implementation, which means it is Mono that the application developer is relying on to be safe within the confines of the Microsoft Community Promise.

In effect, the Mono project and its promoters are making a promise to application developers and users: “Use Mono to develop your applications, it’s useful and safe. Microsoft has made a promise.” The implication is that developers and users need not be concerned with verifying they are remaining withing the boundaries of Microsoft’s promise. But, this sort of Mono Apologist violates that trust by not only implementing things they know are not covered by the promise, but also by obfuscating which bits are “safe” and “unsafe” and then lying about it.

That’s a whole different thing than being honest and saying something like “Mono may be risky, but we think it’s useful and not too risky.” Nothing wrong with this premise, because I believe rational people can evaluate the level of acceptable risk differently. (Team Apologista has a problem here in how they argue it, but the premise is a decent enough starting point.)

So, the original questioner has been misled. Perhaps not maliciously – but misled nonetheless. Of course, there’s more:

plaimbock: @trampstr: what about this report that #banshee, tomboy, f-spot and #mono use non-ECMA namespaces? http://is.gd/iEe7Z

trampstr: @plaimbock thats old info, also it lists System.Xml as non EMCA but it is in ECMA335.

Um, no – it is not “old info”. Unless you consider the last 2 days “old”. The source code repository is ~2 days old, and the ECMA standard is the released-this-month 5th Edition. Any more up-to-date and it would be realtime. Furthermore, while parts of System.Xml are now in the standard, the commonly used methods by the Mono apps do not appear to be - as I explitictly mentioned in the “Cautionary note” in my post. The System.Xml thing is legit.

How do you combat this? One tries to be careful in researching and fact-checking – no-one is forthcoming with easy, available or comprehensive references in this area, after all – and yet any random jackass on Twitter will authoritatively deny something even when looking right at it! Is this person a liar? Incompetent? Lazy? Just repeating shit he read on some Mono Cabal Talking Points Memo? All or none of the above?

And of course, the final delight, an amazingly un-self-aware twit tweet :

trampstr: @plaimbock there are very strong opinions on both sides. and lots of miss information going around (from both sides).

FUUUUUUUUUU! YOU! YOU! You are the one spreading misinformation! Gah!

Aaaanywaaay

The good news is: now that it is clearly documented that:

• All of the most popular Mono applications in Linux use non-ECMA .NET namespaces extensively
• Mono is not split into ECMA/non-ECMA packages in Debian/Ubuntu, and probably not in any other distro either

I am supremely confident that we will never again hear another argument from a Mono Apologist suggesting otherwise. I also fully expect those very vocal Mono Apologists who manage to appear in every thread to defend Mono and may have stated or implied different, to go back and correct themselves so they don’t continue to mislead others. After all, I know factual accuracy is of the highest concern.

I am also expecting Swedish Triplets and a Lamborghini Spyder Performante for Xmas.

Which do think is more likely?

The Claim

One of the common claims of the Mono proponent is that distribution packagers are splitting Mono into ECMA and non-ECMA packages. Debian and/or Ubuntu are commonly held up as examples in this area.

This always seemed a questionable claim to me: for one thing, it’s not easy to determine exactly what bits go where, and to be frank who has the time to screw with that? Also, there are a host of technical considerations – what if they conflict somehow? Furthermore, how will users know which packages are “safe” or “unsafe”? And, as we have seen, all the Mono apps need “unsafe” stuff anyway – so why bother splitting things up?

Also, without being crass about things – I don’t think that most Mono proponents’ top priority is the safe/unsafe distinction. Generally, it seems to me, if you are supporting Mono, you are in for a penny in for a pound and not too concerned over nuance unless forced to discuss it by raging freetard zealots such as myself. We all have our special roles to play.

Enough setup — I thought I might check out a package and see if we can accept or reject the claim that some distribution packagers are splitting Mono into ECMA and non-ECMA pacakages.

The Exam

Now we do have some Debian packages like libmono-system-data2.0-cil and libmono-winforms2.0-cil, so a casual glance might suggest that there is some ECMA/non-ECMA division going on.

On that note, I took mscorlib.dll from the Debian package libmono-corlib2.0-cil (2.6.7-3). This is the “Core Library of Mono for CLI 2.0″, and as far as I can determine absolutely required for any Mono whatsoever on your system.

[jason@apollo 2.0]$ egrep -I -a -o 'S.y.s.t.e.m.............................' mscorlib.dll | sort | uniq
SystemSystem.Data1S
System Operators/BUI
System, Version=2.0.
System.Attribute.}e
System.Byte.!Value t
System.Char
           utf32QTh
System.Core, Version
System.Data, Version
System.Data.OleDb.Ol
System.Data.SqlClien
System.DateTimefile
System.DecimalCInval
System.Decimal.Parse
System.Design, Versi
System.Diagnostics.E
System.Diagnostics.P
System.DirectoryServ
System.DoubleUDouble
System.Drawing!Syste
System.Drawing, Vers
System.Drawing.Desig
System.Drawing.Print
System.Guid.CompareT
System.Int16ArraySu
System.Int16;Value i
System.Int32s%Value
System.Int64qInput s
System.Messaging, Ve
System.Messaging.Mes
System.Net.DnsPermis
System.Net.SocketPer
System.Net.WebPermis
System.NonSerialized
System.Reflection.As
System.Resources.Res
System.Resources.Run
System.Runtime.Compi
System.Runtime.Inter
System.RuntimeType)S
System.SByte.7Value
System.Security, Ver
System.Security.Cryp
System.Security.Perm
System.Security.Poli
System.Security.Supp
System.SerializableA
System.ServiceProces
System.Single.9Value
System.Text.CP5CodeP
System.Text.ENCCEnco
System.Type are not
System.UInt16.5Value
System.UInt32.Negat
System.UInt64.7Value
System.Web, Version=
System.Windows.Forms

What’s this!? System.Data? System.Drawing? System.Windows.Forms!?!

The Verification

So, it appears that there are non-ECMA bits even in the “most basic” Mono library. At this point, I was pretty sure we could reject the claim.

However, even in my freetarded factfinding frenzy I wanted to be sure, so I did something absolutely insane: I asked Jo Shields about it. (In case you don’t know, Mr. Shields packages Mono for Debian and Ubuntu.)

Mr. Shields was kind enough to respond, and here’s the summarized deal:

1. ECMA/non-ECMA is not a consideration in packaging Mono.
2. No distribution ships Mono with ECMA-only components.
3. It is not possible to do so without “deep surgery”.
4. Splitting along ECMA/non-ECMA lines is not a priority.

So, we can reject the claim that distribution packagers are splitting Mono into ECMA/non-ECMA components.

The Thank You

My sincere thanks to Jo for taking the time and effort to reply.

The Unredacted Email

At Mr. Shield’s suggestion, here is the unredacted email (which contains my original email), so everyone can get context and judge for themselves. I suggest reading it if you are interested in more about the packaging details behind Mono.

On Mon, 2010-12-13 at 14:43 +0900, Jason Melton wrote:
> Jo,
>
> Your favorite zealot here. I'd like to ask some questions on a Mono
> Packaging issue before I write a post about it. I want to do this so I
> have "asked someone in the know" as well as offer you an opportunity
> to respond if you desire in the post itself.
>
> If you want me to F off and not bother you again, I'll respect that, of course.

For actually asking me the question, I'm happy to answer fully. It's
more than Roy's ever done.

> Anyway, on to the questions:
>
> 1. Is the Debian Mono packaging split into ECMA / non-ECMA components?

It's split into a hundred odd packages, but no, ECMA/non-ECMA isn't a
consideration - the only consideration is minimizing dependency chains
whilst retaining usefulness (and reducing circular dependencies), and
grouping related items. As an example, a minimal install (mono-runtime
plus its dependencies) pulls in four library packages, containing the
following assemblies:

libmono-corlib2.0-cil:
mscorlib.dll

libmono-posix2.0-cil:
Mono.Posix.dll

libmono-security2.0-cil:
Mono.Security.dll

libmono-system2.0-cil:
System.Configuration.dll
CustomMarshalers.dll
System.Management.dll
System.Transactions.dll
System.Drawing.dll
System.Xml.Linq.dll
System.Xml.dll
System.Core.dll
System.Security.dll
System.dll
System.ServiceProcess.dll
System.Configuration.Install.dll

So these assemblies are the unavoidable minimums installed on a current
system (Ubuntu Maverick). But they cover most situations outside
compilation, where we pull in the kitchen sink in order to provide
simpler Build-Depends lines. And if you aren't aware, note that assembly
names do not necessarily match the namespaces provided therein. Whilst
it would be possible to chop things out of libmono-system2.0-cil to make
a pure-er (although likely not completely pure) minimal system, I think
the benefits to our users would be minimal, and the cost in terms of
awkwardness on upgrades high.

> 2. If there is a split is it an official policy?

See above

> 3. If there is a split is it comprehensive/complete or in
> progress/trying-our-best-but-not-100%-just-yet-for-whatever-reason?

See above-er

> 4. How could a non-packager determine which bits should go where and
> verify that the packaging is correct?

As I said, the concern is really just over minimizing chains of
dependencies, so what makes us sit up and make changes is cases where
pulling in an extra library leads to pulling in several more - that's a
scenario we want to avoid. As an example, when attempting to attack
Banshee with a scalpel (the changes noted in the current Natty package),
we found two instances where depending on a single library would pull in
buckets more random stuff. Using System.Data pulled in the
libmono-system-data2.0-cil package - but one of the rarely-used
assemblies in that package pulled in libmono-wcf3.0-cil and all ITS
dependencies, bloating things up. Our solution was to split the "bad"
assembly into a new package (will be in Mono 2.6.7-4), Banshee
upstream's solution was to drop System.Data entirely (already in the git
snapshot in Natty).

The other example is the Youtube extension using the google-gdata
packages (which contain about 14 assemblies for managing various Google
web services), one of which uses System.Web. Banshee upstream provided
us with a minimal patch to remove that dependency, by copying a little
of Mono's source code (GData upstream already did this to provide
missing namespaces on the Microsoft.NET Compact Framework, so we just
added one or two missing methods and removed the ifdef).
libmono-system-web2.0-cil suffers from a similar, but sadly unavoidable,
chain of dependencies which we sought to cut off. Due to obtuse Windows
line-ending issues, showing you the patch wouldn't be meaningful or
interesting.

So now Banshee's dependency list isn't much different from Tomboy or
gBrainy. See http://people.ubuntu.com/~hyperair/banshee-dep.png for the
visual version of the above.

> 5. When I examine mscorlib.dll I see references to non-ECMA components
> such as System.Data and System.Drawing. [1] Does this mean that
> mscorlib.dll (from the Debian package
> libmono-corlib2.0-cil_2.6.7-3_all.deb) contains non-ECMA components?

Congratulations for being the first Mono critic (AFAIK) to notice this.
I was going to blog on this topic at some point, once finishing my
current secret Project Marmoset.

You're correct. ECMA 335 defines HOLY SHIT. They updated it to .NET 4.0!
That's news to me that is! You'd have thought Miguel would have blogged
about it. Damn, now I need to restart Project Marmoset.

Sorry. Anyway, the currently MCP'd version of ECMA 335 (4th edition,
2006) defines 331 different classes, with 617 properties and 2097
methods, split across System.dll, mscorlib.dll, System.Xml.dll, and
System.Threading.Parallel.dll. Not every namespace in those assemblies
is defined in the ECMA spec - the spec covers individual methods and
properties on individual objects, each one needing vetting one by one by
the standards committee.

So the current (okay, not current, I'm on 2.6.7 here) Mono
implementations of the named libraries contain:

mscorlib.dll: 1085 classes, 13438 methods, 3213 properties.
System.dll: 822 classes, 8644 methods, 3109 properties.
System.Xml.dll: 240 classes, 5384 methods, 2158 proprties.

I should stress that I'm relying on grep for numbers here, so I don't
know how much autogenerated noise is included in the monodis output.
Probably plenty, but even with that it's clear that the implemented
methods & properties exceed the ECMA methods and properties. And no, I
don't know where System.Threading.Parallel.dll is either. And yes, I
know that the Community Promise needs everything in the spec to be
implemented. Go figure.

FYI, ECMA 335 5th edition increases the number of ratified classes from
331 to 374, properties from 617 to 651, and methods from 2097 to 2319.

> Obviously, I think that the package contains non-ECMA bits and want to
> point this out as a counter argument to those who say that Mono is
> split into "safe"/"unsafe" bits by distro packagers and often use
> Debian/Ubuntu as an example.

As far as I can tell, most people consider some technologies
more dubious than others - System.Windows.Forms or System.Data is
hairy, whereas a non-spec method on the String class doesn't make
everybody leap in fear. Whether that's naive is the topic for a
different flame war, I suspect.

So it's true that we have distinct packages for the "scary" bits like
System.Data versus "less scary" stuff like mscorlib.dll, but it is
absolutely true to say that no distribution ships a Mono framework with
ECMA-only components, and it's not possible to do so without deep
surgery on the class library, requiring a lot of man hours. Which is
time Miguel would rather get his guys to invest in MonoDroid or
MonoTouch. Completely hypothetically, I think using the monolinker tool
from MonoTouch (which creates custom minimized versions of the class
libraries on a per-app basis) to turn a "full" Mono into an ECMA-only
Mono would be a faster route to the stated goal, but I have no idea
what would run, and no idea whether monolinker would be prepared to
chop off that much stuff. Would sure be interesting though, wouldn't it?

> I'm trying to get your input so I can be sure of my facts and to
> present "the other side". It's the first time I've tried such a thing,
> so your response is much appreciated. If it helps I can send you a
> copy before I post it so you know I don't quote you out of context or
> anything shady like that.

Whilst I think we disagree pretty strongly about comparative risk, your
dedication towards accuracy in this matter is appreciated. I don't
think anything I've written here is incorrect, so I don't want you to
feel you need to provide me with your intended blog post in advance. If
I'm wrong, I'm sure corrections will appear in comments. And wrong or
right, people like gnufreex will call me Satan, so there's not much
advantage to advance copy.

I think the question of context would be best served by providing
readers access to all emails unredacted, so they (pro or anti Mono) can
form their own opinions on context.

> [1] Basically: egrep -I -a -o 'S.y.s.t.e.m....[lots of dots]...' mscorlib.dll

Try using "monodis", which decompiles .NET code to MSIL (or whatever
they're calling it today). A cursory examination suggests there are
mentions, but not dependencies. Stuff like InternalsVisibleTo, at a
guess, which gives those assemblies access to non-public content inside
mscorlib. I can't read MSIL, so I'm largely guessing. If there were a
true dependency, the packaging would pick up on it.

Answering Questions

First, you may want to read my stunningly well-written post “What Patents is Novell Selling?” Make sure you have a pencil in both hands.

The main conclusion I draw patent-wise is that we can easily find Novell has a little over 800 patents, and we know 882 are for sell, so I believe Novell is selling all (or at the very least, an overwhelming majority of) its patents.

Let me respond to some of the feedback I have received.

Matt Asay Says Novell Has 2000+ Patents

My thanks to Roy Bixler for mentioning this from Matt Asay:

While this IP doesn’t include the Unix copyrights, it does include 882 of Novell’s roughly 2,000 patents which almost certainly involve IP surrounding WordPerfect and other technologies that give Microsoft more cause for sabre-rattling against open-source projects like OpenOffice.

On one hand, you might think Mr. Asay is in the position to know, having once been a Novell employee. On the other hand, it would be neither surprising nor rare for Mr. Asay to get a fact or 17 incorrect in an article.

Here’s the problem with the 2,000 number:

1. We can’t find anywhere near that from searching.
2. Novell never claimed to have anywhere near that number (that I can find).

For example, check out the most recent Internet Archive copy of the page where Novell used to list all its patents. Novell used to constantly refer to this page in almost all of its documentation as where to find a list of Novell patents.

The archived copy is from Oct. 27, 2007 and lists 325 patents. Figure ~150 patents granted and ~280 applied for in the next 3 years, and those numbers seems to work well with the ~800 figure.

Where did the other 1200 patents come from?

You Didn’t Count International Patents

Fair enough, but not only is there no good way to do so comprehensively, but even so, I don’t think it will matter.  Still, let’s give it a go:

There is the WIPO PatentScope search, which gives us 30 additional Novell Patents:

• Novell, Inc: 28 Patents
• Novell Inc: 2 Patents

This search covers ARIPO (17 or so African countries), Cuba, Argentina, Korea, Mexico, Singapore, Viet Nam, South Africa, Israel, Morocco, Spain, Brazil and Columbia.

So, let’s throw those into the count as well. Total now: 841 Patents.

The difficult to use Japan search gives 3 patents. It’s easier to just list the patents than the search:

• 2002-288139
• 2002-033998
• 2002-033771

Let’s add those in as well. Total now: 844 Patents.

The European Patent Office search results are quite interesting. There a Worldwide search for  “NOVELL INC [US]” gives us 886 results.

So, no matter how you cut it you are still around 882 patents.

Novell is selling what its got, and what its got is for sale

Again, the only rational conclusion is whatever Novell has is up for sale. In fact, if you read the terms of the deal, Microsoft can buy Novell’s patents even if the deal with Attachmate falls through:

In addition, CPTN may also elect to continue the Patent Purchase Agreement in the event that the Merger Agreement is terminated for any other reason than Novell’s receipt of an acquisition proposal for the entire company that it deems to be a superior proposal to the Merger, in which case the Patent Purchase Agreement will remain in full force and effect and references in the Patent Purchase Agreement to the Merger Agreement shall automatically be deemed to be of no force or effect.

This basically means that unless someone comes in outbidding Attachmate by over $60 Million dollars (the termination fee Novell would have to pay Attachmate for going to another bidder), those patents are going to Microsoft.

Remember, the only way this deal can happen is because Microsoft is throwing in the $450 million for the patents. Without that, the deal is a non-starter. Is someone out there prepared to argue, then, that Microsoft is going to leave 1200 some-odd patents on the table?

The (Lack of a) Future for Novell

Novell is done for – it is in effect being bought by Attachmate by proxy (for Microsoft and Elliot Associates) for about $700M. ($2.2B, less $1B Cash-on-hand, less $450M from Microsoft)
Consider the players:

Elliot Associates has no interest in Novell as a software and/or Linux company – its interest is in the  $1 Billion in cash and short-term securities Novell has. No help to Novell’s future there.
Microsoft has no interest in Novell beyond the patents it will acquire, and perhaps some minor lip service/PR use. No help to Novell’s future there, and certainly no help to SUSE/OpenSUSE.
Attachmate has never expressed interest in Open Source (and only mild interest in Linux in general). They initially state they will be splitting Novell into 2 separate divisions.
That’s the most important point: if Novell can’t make Novell work, what exactly makes anyone think Novel-Under-Attachmate is going to work?

Attachmate, as a company, brings no new technology, management or rainmakers to Novell. Novell as a Linux/Open Source entity gains absolutely nothing from the Attachmate-Novell deal. In fact, Novell loses a lot:

• Novell loses nearly all its patents.
• Novell loses nearly all its image of being a stable choice.
• Novell loses what little SUSE/old-school Novell synergy it had.
• Novell loses even more of what little Open Source/Linux credibility it had left.
• Novell loses the ability to independently decide to operate in an Open Source-friendly manner.
• Novell loses the ability to pretend like its flavor of “interoperability” is a desirable business model.

In return, Novell gains nothing. There is not one single aspect of Novell’s positioning in the Linux or Open Source worlds that is improved by Attachmate’s ownership.

The only possible upside is the inevitable changes in management that will come, and that is only because it is not possible for any living thing to manage Novell more ineptly than its current management.

Nothing Will Change?

Furthermore, despite wishful thinking that “nothing will change”, a moment’s thought reveals how idiotic such rose-tinted non-thought is: if nothing changes, than all Novell will do is decrease in value. Why would Attachmate bother to buy out a failing business, and then not change anything?

Even if Attachmate intends to hold on to Novell for the long-term – a highly questionable proposition in itself – the only way to do so and become profitable is to radically change the way Novell operates. If “changing nothing” worked, Novell never would have found itself on the auction block.

If you want to take the view that Novell will continue on (and this means for SUSE and OpenSUSE as well), you have to present some things that Attachmate brings to Novell, some ways that Attachmate will change how Novell did business, that make that approach viable.

I think it is telling that among the host of articles I have read on this deal, not as a single peep has peeped on this front.

What Will Happen?

They don’t call me the Novellstradamus for nothing, so here’s what I see happening:

Attachmate has to try to get some real value out of Novell. The clearest and easiest way to do that is from two sources:

• Products that integrate well with existing Attachmate products.
• Smart people that come to work for Attachmate.

Anything that meets this criteria will be quickly moved to the Attachmate side of the house. Once this is apparent to staff, people began leaving Novell as fast as possible for more attractive employers.

Attachmate is not a “go-getter” company. Take a look at their product line. Basically a bunch of  SSH and FTP clients. Exciting stuff. This is not a company that is going to be breaking new ground, even if that broke ground is half-assed clones of Microsoft’s latest half-baked offerings.

So, any of those fancy products are out. OpenSUSE and SUSE are done with, in terms of corporate backing. Take a look at the Attachmate Management Team, not a single mention of Linux and/or Open Source.  Attachmate will try to hold this a steady as possible while trying to sell it off. Major cuts in funding within 6 months. OpenSUSE community will not even be able to get an Attachmate janitor on the phone after 3 months.

Any Open Source contributions unreleated to Mono halve every year. In 2012, someone from Canonical gives a slideshow chastising Novell for their lack of “upstream contributions”.

Mono/Moonlight. There will be an initial half-hearted attempt to maintain this product line. Due to uncertainty about the future, combined with Microsoft killing off Moonlight as a desktop development envirionment, adoption of Mono will continue to slow, decreasing its value even further.

Not out of the question for a Mono-based start-up funded in part by Microsoft to appear, with less-than-equal focus on Open Source and Linux.

Any Novell bits that aren’t moved over to the main Attachmate side of the house will all be sold or spun off within 2 years. The earlier the better for all concerned, but the sale will be tricky now that Novell has gutted itself through the patent sale to Microsoft. It’s worth even less to any future buyer than it was for this deal.

Microsoft may continue to be involved, and might funnel some cash to Attachmate (via coupons or patent cross-licensing, or some other pretense) in either compensation for making the initial deal or to offset loses from the Novell division in return for just sitting back and letting it flounder.

Microsoft steps up patent FUD against Linux. Novell bootlickers continue to promote “IP peace of mind” in Novell ads and talking points, while never once taking responsibility for aiding Microsoft in its FUD campaigns.

I continue to be right about everything, as well as dashingly handsome and terribly witty at social engagements.

According to my (on-going and slip-shod) research, here’s some speculation on exactly what patents Novell is selling to Microsoft.

What patents are for sell?

Only a number (882) is given in the SEC filing, so we don’t know for sure. But, we can look at patents assigned to (and applied for by) Novell, and those companies Novell has acquired to get a picture of what patents Novell owns.

Novell proper

• Novell: 462 patents
• Novell: 287 applications

Companies Novell has acquired (and so probably owns the patents):

• 1986 – Santa Clara Systems: 0
• 1986 – Cache Data Products: 0
• 1987 – Softcraft: 0
• 1988 – CXI: 1 Patent
• 1989 – Excelan: 0
• 1991 – Digital Research: 0
• 1992 – International Business Software: 0
• 1993 – Unix System Laboratories: 0
• 1993 – Serius
• 1994 – WordPerfect: 3 Patents
• 1999 – Netoria: 0
• 1999 – Ukiah Software: 5 patents
• 2000 – JustOn: 0
• 2000 – PGSoft: 0
• 2001 – Callisto Software: 0
• 2001 – Novetrix: 0
• 2001 – Cambridge Technology: 5 patents
• 2002 – SilverStream: 6 patents
• 2003 – Ximian: 0
• 2004 – SUSE Linux: 0
• 2004 – Salmon LTD: 0
• 2004 – Commerce One: 6 Patents
• 2005 – Tally Systems : 2 Patents
• 2005 – Immunix: 0
• 2006 – e-Security: 0
• 2006 – Red Mojo: 0
• 2007 – Senforce: 1 Patent
• 2008 – SiteScape: 0
• 2008 – PlateSpin: 0
• 2008 – Managed Objects: 0
• 2009 – Fortefi: 0

Novell Subsidiaries

• JGR Acquisitions: 2 Patents assigned to them, and known to have bought 39 Commerce One patents.

Assuming (in order of safe-assumption-ness) all those applications are approved, none overlap with the “patent” list, and all those acquisition patents are correct and owned by Novell that gives us 811 patents. (Counting only 39 Commerce One patents in total.)

Still a bit short from the 882 number given in the SEC filing, but of course not only could I have missed something, but Novell (or a company it acquired) may have bought patents somewhere along the line.

The basic point to make here I think is that Novell will be selling every patent it owns. I don’t think it’s a case of “which Novell patents are up for sale”, they all are. The question is “which Novell patents might be used by Microsoft against Linux (and other competitors, for that matter)”.

A further note of interest, the word “patent” in this deal is a bit broader than simply a patent at the USPTO. As defined in the SEC documentation:

“Patents” means domestic and foreign patents and patent applications, industrial and utility models, industrial designs, petty patents, patents of importation, patents of addition, certificates of invention, and any other indicia of invention ownership issued or granted by any Governmental Entity, together with all reissuances, divisionals, continuations, continuations-in-part, revisions, renewals, extensions, and reexaminations thereof, and any identified invention disclosures, and moral and economic rights of inventors in any of the foregoing.

So, there may be some instruments there a bit outside of a simple patent number. Even so, this doesn’t change the fundamental analysis here: Novell’s selling what its got, and what its got is for sale.

OIN Patents

It seems to me that patents are either “sold” or “donated” to the OIN, making OIN the new owner, which in turn licenses them out. If this is the case then those patents given to the OIN by Novell are not going to Microsoft, because OIN owns them now, not Novell.

Here is a Google Spreadsheet I made with all the patents OIN claims to own, along with the patent assignee. And here are the patents that OIN claims to own that I believe came from Novell:

3 patents that OIN owns that were assigned to Commerce One:

• 6751600
• 6542912
• 6591260

These are 2 from JGR Acquistions, Inc., a subsidiary of Novell:

• 6993506
• 7036072

It’s morbidly amusing, then, that the end score for Novell if counted in patents is something like: Linux – 5, Microsoft – 882 .

(Novell helped buy some of those Microsoft patents as well, so I guess if you are feeling generous, give them another 6 or so points, though Linux – 11, Microsoft -882 isn’t much better).

(Also, some additional patents may well have came from Novell, and it’s not obvious from the limited information I have, but you get my point. I’m just so damned blinded by zealotry that I feel the need to ruin a great bit by adding in disclaimers and clarifications to make sure an honest opinion is presented. That’s just the sort of rage without regard to the facts we engage in here.)

UNIX Copyrights

Novell has since released a statement that the UNIX copyrights will remain with Attachmate-Novell after the sale. In my opinion, this doesn’t matter, because a big outcome  of the SCO case was not just proving that Novell owned the copyrights, but that Linux didn’t violate them anyway.

The Baystar-SCO gambit (and related chicanery like the disgraceful book of lies Samizdat, from the shill-center Alexis de Tocqueville Institution funded by Microsoft) was all an ultimately failed attempt to show Linux violated UNIX copyrights somehow.

Microsoft has already tried to attack Linux via this route, and it yields nothing. In summary, Novell is being allowed to keep the UNIX copyrights because they have no worth to Microsoft.

Technical Business

The always excellent and informative The Standards Blog has a detailed analysis of what we know so far from a legal/business perspective. I’d also note that they are in agreement with my assessment of the UNIX copyright value:

Does this new disclosure have any implications to Linux? The answer should be no, since copyrights cover the actual code, and not any underlying “inventions” that might be infringed by Linux (which is what patents cover). Despite strenuous efforts, SCO was never able to prove that Linux included any UNIX code, and therefore ownership of the UNIX copyright would not provide any rights against Linux developers, distro vendors or users.

I suggest reading the blog, because it goes into the business structure that will be in place after the deal, including some thoughts on how that might impact operations.

More to come

Novell recently filed an Agreement and Plan of Merger with the SEC, and more detailed bits are sure to come.

You can get an RSS feed of Novell’s filings with the SEC here.

Novell also announced it has entered into a definitive agreement for the concurrent sale of certain intellectual property assets to CPTN Holdings LLC, a consortium of technology companies organized by Microsoft Corporation, for $450 million in cash, which cash payment is reflected in the merger consideration to be paid by Attachmate Corporation.

… almost precisely as Your Humble Host predicted back in May, Microsoft has organized a thin front organization to pick up whatever pieces they think will be useful against Linux. Novell, as has been standard practice for them since at least 2006, has once again chosen to do whatever is best for Microsoft.

In this case, it is selling some 882 patents for $450 million in cash, according to the SEC filing:

Also on November 21, 2010, Novell entered into a Patent Purchase Agreement (the “Patent Purchase Agreement”) with CPTN Holdings LLC, a Delaware limited liability company and consortium of technology companies organized by Microsoft Corporation (“CPTN”). The Patent Purchase Agreement provides that, upon the terms and subject to the conditions set forth in the Patent Purchase Agreement, Novell will sell to CPTN all of Novell’s right, title and interest in 882 patents (the “Assigned Patents”) for $450 million in cash (the “Patent Sale”).

The Patent Purchase Agreement contains representations and warranties of the parties, including with respect to Novell’s title to the Assigned Patents, existing licenses and rights with respect to the Assigned Patents, restrictions on rights to the Assigned Patents, the validity and enforceability of the Assigned Patents and the equity commitments of the members of CPTN to fund CPTN in an aggregate amount equal to or exceeding $450 million.

Business Insider has already captured the deal’s essence in a piece entitled “Today’s Novell Deal Helps Microsoft Continue Linux Fight“:

The deal helps Microsoft in its decade-long fight against open-source operating system Linux in two ways.

First, it keeps a Microsoft competitor from buying Novell’s SUSE Linux implementation. VMWare was looking at buying SUSE so it could sell a top-to-bottom software stack that would compete directly against Microsoft’s Windows Server and its built-in virtualization technology. This was a major fear in Microsoft’s server group, according to my sources there.

Second, although the companies didn’t say exactly what patents were included, it seems likely that some of them are related to SUSE Linux. If so, these patents will give Microsoft further ammunition to sign cross-licensing deals with companies that sell other products based on Linux. And those licensing deals will continue to raise questions in the mind of potential Linux customers.

Please note Business Insider is not some “freetard” blog. This is rational, business-oriented analysis. Remember that as Team Apologista winds up the spin and attempts to downplay the traitorous nature of this odious deal: the Patent Purchase Agreement portion of this deal is 100% beneficial to Microsoft in its fight against Linux. It strengthens Microsoft’s claims that it owns so-called “Intellectual Property” that entitles Microsoft  to demand licensing fees or other tribute in order for someone to run Linux.

Also note there are almost certainly other technologies and/or markets that Microsoft hopes to gain leverage in with these patents – but the essence is how much it bolsters Microsoft’s war chest against Linux. Don’t be distracted by claims that Microsoft has its eye on some other technology (ala Platespin). True as a side benefit, perhaps, but the real importance to Microsoft is – and has always been: to kill Linux, and, failing that, to hinder adoption of Linux, and, failing that, to require payment for the privilege of running Linux.

Questions that need answering

Which 882 Patents, exactly? Knowing which patents are in play here would go part of the way to predicting (and therefore defending) against future Microsoft claims against Linux.

What happens to any OIN patents? My impression is that the OIN “owns” the patents, so I don’t expect any change in those patents, but it would be re-assuring to confirm that.

What are the other companies in CPTN Holdings, LLC? I don’t doubt for a moment that this is 99.9999% Microsoft and .00001% Microsoft cronies assembled solely for this deal, but I’d still like to know more about the organization’s composition, history and activity.

Are there any anti-trust or other legal obstacles to the patent sale? In a logical world, Microsoft would not be able to both hold Linux up as a competitor (so as to deflect anti-trust criticism) and simultaneously attempt to extract licensing fees from use of their “competition”. However, what is legal and what is logical rarely meet, so let’s see if the regulators give this a once over and what they say. I don’t expect anything to come from this front.

What happens to Microsoft’s “Covenants”? Microsoft and Novell had some exclusive arrangements (which Novell loved to talk out of both sides of its mouth about). The Covenant to Downstream Recipients of Moonlight, for example, is specifically tied to Novell in a dozen places. The “special relationship” Novell enjoyed with Microsoft is mentioned in the SEC document, but nothing about it extending or continuing (or ending for that matter):

Information Regarding Certain Relationships

Novell and Microsoft are parties to a Business Collaboration Agreement, a Technical Collaboration Agreement and a Patent Cooperation Agreement that collectively were designed to build, market and support a series of new solutions to enhance the interoperability of Novell’s products with Microsoft’s products.

What happens to Mono? Miguel de Icaza is already trying to calm the waters, claiming “Mono continues as-is, but our paychecks will come from Attachmate instead of Novell“. I’d argue that changes are inevitable – that’s what happens when you get bought out; the new owners like to change stuff up – but I’m also interested in seeing if Microsoft will strike a no-sue secretive deal with Attachmate, so Team Mono can go on operating with the same cavalier attitude they did when with Novell.

I wouldn’t be surprised, because the Novell-Microsoft deal could not have been more beneficial to Microsoft: after years of dividing the FLOSS community and spawning a herd of “Open Source Advocates That Defend Microsoft” – Novell comes out the other end dead, Microsoft comes away with 880+ patents and a host of people promoting its technology and standards (both real and de facto) in the Open Source community. Why not see if they can continue that winning streak with Attachmate?

I guarantee you Miguel de Icaza and the rest of Team Apologista is up for it.

How will Team Apologista spin this? Mostly for the lulz factor, but I’m interested in seeing the spin. I suspect there will be two major lines of defense:

• Mono/OpenSUSE are Open Source, so they are “bigger” than who owns what. (Like Oracle buying Sun didn’t affect OpenOffice.org and Canonical has only minor influence on Ubuntu, I’m sure.)
• Microsoft is buying patents for defensive purposes. (Like the same patent can’t be used both offensively and defensively).

For additional lulz, one could note the jackholes that expressed such delightful schadenfreude when Oracle bought out Sun, aren’t crowing about Novell dying and selling nearly 900 patents to Microsoft on the way down.

Who is Attachmate? By this I mean we need to know more about Attachmate’s business strategy and philosophy. They say they will continue to support SUSE (and I assume, at this point, OpenSUSE) – so we will see. After checking out their site and searching Google, I don’t see anything that suggests Attachmate is pro-Open Source (or even interested in Open Source), so that is a bit troublesome. Still, I’ll reserve speculation on this point, because I need to know more about the company.

More to come on this, I’m sure…

But a lot of time has past since the original discussions and in that time, some things became very clear.

• Microsoft does hold patents on the .NET technology that mono is based on
• They made a community promise not to sue FOSS projects implementing the ECMA submitted parts of .NET
• The community promise is not a binding patent grant
• Mono implements a lot more than the ECMA parts, De Icaza’s promise to seperate mono into safe and non-safe parts was never fulfilled
• There is no promise on the non-ECMA parts
• Software like F-Spot and Tomboy are therefor using parts based on non-free bits of .NET

So, why is including MP3 support and DeCSS problematic but do we digg a hole by using patented technologies from one of the biggest patent trolls on the planet???

I don’t think any of this is malicious, but it does feel naive and misguided to me…

This is fairly reserved criticism of Mono – and outside of arguing over what a “binding patent grant” means to the Microsoft Community Promise - each point is factual. (I guess you can argue over the definition of “patent troll” as well, but that’s in the conclusion and not in the points.)

Here’s how the criticism is portrayed by one member of Team Apologista in the comments:

You are currently aiding in spreading uninformed hatred against a valuable group of Open Source contributors.

“Uninformed hatred“. Hatred. Think on that characterization carefully, and the implications that the wielder is trying to make.

Let’s look at the points and see if those implications hold up: is criticism of mono – specifically the points that Mr. Van Sanden makes – “uniformed hatred”?

Microsoft does hold patents on .NET technology

There is at least one patent unambiguously on .NET (the “Jim Miller” e-mail patent), and it is clear that Microsoft themselves think they have .NET patented just fine:

It seems pretty clear and simple to me, but maybe I’m missing something. Microsoft has a commercial product, the CLR, and we treat it as we do any commercial product. It is covered by patents, copyrights, trade secrets, trade marks, whatever the lawyers dream up next.

- Jim Miller

If someone implemented a product that conforms to the [CLI] specification, we believe we have a patent or one pending that’s essential to implementing the specification.

- Michele Herman, Microsoft Director of Intellectual Property

Q: Are there any patents that apply or that will apply to implementers of .NET or Hailstorm?

A: I expect there certainly will be. I mean, the patent process takes a long time.

- Craig Mundie, Microsoft Chief Research and Strategy Officer

[SLIDE TITLE]Maintaining Gap vs. Linux

1. Keep network effect with Applications
   • Migrate applications to .NET framework
     • BUT keep framework proprietary to Windows
     • Patents required to implement clone

—Dan Nault, 2005 “Highly Confidential” Presentation

So, we see here that Microsoft at multiple levels certainly thinks they have patented .NET – and, in that last case, intends to use patents as a way to differentiate “Genuine .NET Advantage” and .NET clones.

Not to even bring in the nearly 300 Microsoft patents that reference the “NET Framework”. Of course, some of they may not apply to .NET and/or Mono, but I’m willing to wager one or two (hundred?) of them do!

In light of:

• the statements by Microsoft people (they are in the position to know)
• internal documents that specifically mention patenting .NET (again, they are doing the planning)
• the content of the ECMA promise (why cover patents if there aren’t any?),
• the content of the “Community Promise” (again, why idemnify something irrelevant?),
• the history of Microsoft (they are not shy about patenting things), and
• the appearance of multiple patents that appear to apply to .NET

I submit to you: the informed and rational position is that Microsoft does hold patents on .NET. Microsoft says they do and the evidence supports that.

If you are arguing otherwise, the burden of proof is upon you. You are the one making an extraordinary claim. And extraordinary claims require extraordinary proof.

Consider the alternative: when .NET first came out, it was largely seen as a technology that Microsoft was “betting the company on.” Is someone seriously prepared to argue that Microsoft, one of the most prolific patent holders in the world, was planning on developing and betting the company on a technology they intentionally would not patent?

Facts and Rational Points: 1. Uninformed Hatred: 0.

Microsoft did make a Community Promise

This is not in dispute. What is in dispute is how comprehensive and “safe” the promise is. That is outside the scope of this particular point, though.

Facts and Rational Points: 2. Uninformed Hatred: 0.

The Community Promise is not a binding patent grant

This is the questionable one I guess, depending on what one means by “a binding patent grant”.

If you take it to mean something along the lines of “Microsoft can’t revoke its Community Promise”, then I’ll agree to that.

However, if you take it mean something along the lines that the Community Promise has enough “wiggle room” that it might not be “safe enough”, then I’ll agree to that as well.

The FSF has given its issues with the Microsoft Community Promise, along with a suggested fix. I’ve mentioned my own issues with the MCP before, which basically revolve around 2 points:

• The promise only applies to compliant full implementations at the time of the Promise. No partial implementations, and no future-proofing.
• Microsoft could sell patents to a 3rd party which is not bound by the MCP.

The Software Freedom Law Center has similar concerns over the “better” Microsoft Open Specification Promise as well.

So, while I suppose you might quibble over the word choice, it’s certainly fair to say that the Microsoft Community Promise is not without potential problems.

Facts and Rational Points: 3. Uninformed Hatred: 0.

Mono implements more than the ECMA parts, and de Icaza never fulfilled his promise to seperate them into safe and “unsafe” parts

True, and acknowledged by Mr. de Icaza back in July 2009:

In the next few months we will be working towards splitting the jumbo Mono source code that includes ECMA + A lot more into two separate source code distributions. One will be ECMA, the other will contain our implementation of ASP.NET, ADO.NET, Winforms and others.

To my knowledge this has not happened. In fact, I heard the idea to split the packages was abandoned because “people would just complain anyway”.

Facts and Rational Points: 4. Uninformed Hatred: 0.

There is no promise on the non-ECMA parts

Is anyone disputing this? The Community Promise explicitly addresses only the various ECMA portions of .NET (334 and 335).

I suppose you could run into other Covered Specifications that are incorporated in .NET, and then say there is a Promise covering some non-ECMA parts, but that seems a pedantic and misleading argument.

Facts and Rational Points: 5. Uninformed Hatred: 0.

Tomboy and F-Spot use unsafe bits of .NET

This is true for Banshee as well, a fact also acknowledged by Mr. de Icaza.

I suppose this could change, but it seems telling to me that Mono applications using non-ECMA portions are still doing so despite the public attention and acknowledgment.

In any cast, another factual point made, and here at the end I have the score as:

Facts and Rational Points: 6, Uninformed Hatred: 0.

So, why the charge of “uninformed hatred”?

If a simple listing of facts and rational points becomes accused of uninformed hatred, what must the reasoning be?

Well, for one thing, the facts must be against you! Remember, “If neither the facts nor the law are on your side, pound the table!”

There lies the root of every logical fallacy and personal attack that Team Apologista so often reaches for: unable to dispute the facts, they must instead turn to attempts to discredit the person. You see this effect in ludicrous overdrive in the attempts to discredit the FSF (and/or RMS) in particular.

Mr. Van Sanden’s post is a wonderful example because it is so very mild and tempered - if such civil posts are deemed hatred, imagine how analysis and speculation is characterized!

Pot demands apology from Kettle after calling Kettle black

Also, I’d like to note the supreme audacity in demanding “a full retraction of your post along with an apology and promise to research before posting in the future”, considering the hatchet job Team Apologista tried to do on GNote and the lies spread about Rhythmbox.

I challenge anyone to read the shameful flurry of slander against GNote and argue there is no “uninformed hatred” there.

Mono Apologists must rely on uninformed acceptance of their points, because one can not simultaneously be informed and make the arguments that Team Apologista does. The best honest argument Team Apologista can make is something along the lines of: “Mono may have issues, but so do a lot of projects, and we don’t think ours rise to a level of serious concern.”

That argument is fair, truthful, and – unfortunately – not very convincing. That is why Team Apologista must resort to misrepresenting the FSF, or trying to silence critics, or trotting out one logical fallacy after another, or resorting to personal attacks.