I guess it all goes back to using what’s best for the job, and if you can’t use what’s best for the job, copy what’s best for the job. While it may be nice to innovate everywhere, and create something amazing and new, it’s not always the right action. For mine, take what’s already there, pick the good bits, copy them and make them better. If there is something which could be done better, do it. There should be no room for idealogical bullshit.

For mine too much of the free software world has its head too far up its own ass. Too much complaining and angst, not enough thinking and action. Then again, I’d be tempted to say the same about most of the world.

Everything is a compromise, anybody who suggests otherwise is a fool.

On a side note, the good old shell vs GUI argument seems to have popped up somehow, and I’d like to say, who cares. Use what you want, they’re both there. For mine they should be both feature complete so to speak. Where it applies both should be accessible, once again with the nature of free software, if people stop using it, it will stop being developed. There’s no reason to rant one way or the other, it’s just a personal choice.

What does this have to do with “patent api traps”?

These include whenever you have a standard or interop requirement. In particular, the worry is over the API (eg, standard) and patent being designed alongside each other.

I don’t pretend to believe I proved anything (eg, like a mathematical proof). Also, the patent trap link mentioned earlier has a comment underneath with a link to a similar argument made in 2003 on a mono discussion thread. Individuals and their corporate patrons have likely been attempting this sort of thing since software patents were attempted. In fact, just this sort of weakness/loophole/flaw is why many probably felt software patents would not fly. The US courts still need a little help realizing just how unconstitutional software patents are.

Thanks for the patent link, btw. I’m not sure if I would look at it. Obviously, mono is horrible, wrt this discussion, being based so closely on so many Monopolysoft-created specs; however, I will keep looking for the opportunity to contribute to alternative browsers and office suites (I like competition, and I also have some complaints over these giants).

Java is known to infringe on Kodak patents, and large sums of money changed hands to settle.

As for COM+, start with 6460058 and go from there

*If* correct, this would be a case of a patent trap.. that might be pretty nasty.

Seeing how nasty that might be, I would suggest we not create other applications that would be good candidates to end up the same. Two is enough.

I would love to see alternatives to these apps (there are for many scenarios, but more work is needed).

>> And Mono is much less of a problem (due to its limited use compared to other technologies infringing on MS patents) than big block busters like Firefox and OpenOffice.

I completely disagree about mono when contrasted to alternatives (C? Java? ..?), but I’m willing to hear about more patents or whatever.

As for these two apps, the key is to have substitutes for what they are (eg, subs for the useful plugins, etc). The totality of their features, in relation to other apps, and their replaceability with other apps helps define the potential risk (wrt patents).

Microsoft has more patents for recent technologies. The missed the opportunities to cash in (as they are trying to do now) back then. For a while now, much prior art has exists for these older technologies.

>> Also, there is no such thing as an “Antitrust safeguard”

Antitrust authorities can step in as necessary. While Microsoft can in the future attempt to acquire more patents (eg, to try to have opengl related patent holdings catch up to the directx related ones), antitrust authorities may step in then or maybe should Microsoft get too pushy afterwards.

Anyway, Microsoft’s major investments are with dotnet (ooxml, etc). That’s where they have the ability (inside info) to rack up the patents that would be thorns to others.

(a) if the standard specifies you need to have it implemented and it must behave as such.. then you do it or you don’t follow the standard. There is no way around that. Does mono follow X or Y standard?

(b) if you care about interop, about meeting some specific interface exposed by some other software, then you have no choice in the matter either. If you don’t implement, then you don’t interface properly and hope of interop drops near zero pretty quickly.

Of course, each of these is manageable at the beginning. It’s when you have propagated the API extensively and then find out about inconvenient patent traps that things become really ugly.

>> You missed then, as you do now, the reason people suggest your analysis is flawed.

Point to the particular comment you have in mind because I don’t remember any challenge that wasn’t rebuttled fairly successfully (at least to my understanding).

>> If an API has a HelloWorld() method, then you can do what you want with it, even if the API says “Draw a message using GDI+” nobody is stopping YOUR implementation of HelloWorld() from using Qt. Or somesuch. That’s how this stuff works.

Perhaps you don’t understand then. This example you gave doesn’t touch on why this would or would not be a trap. In fact, as you lightly describe it, I don’t see a trap.

>> instead of returning the (patented) stored data, provides autogenerated data instead

It would help me analyze this example if you gave more info. I can’t tell if this is a good or a bad example.

All I see is that (a) apparently the file content provides redundant information, (b) patent infringement could be avoided if you avoid one of redundant components, so (c) the FOSS devs did just that and derived the part they left out.

The gif patent problem is a better example. It’s closer to what I have in mind, except that it is very specific and won’t affect large portions of many apps.

The gif standard says do X. To interoperate you need to do X. There is no X’ that is suitable, according to the standard. Anything but X means you fail at that task. You cannot avoid the patent and interoperate with .gif. [I haven't looked at the details of the gif patents or gif spec, but I think this is the general idea.. at least if it was unavoidable.]

That is the basic issue I am talking about. It’s not that you can’t achieve some of the results you want through other API/designs (eg, avoiding the trap api from the start; eg, spread .png rather than .gif). The problem is that as you grow out software using that particular trap API, you create the equivalent of interlocking components. You create the equivalent of many .gif files, ie, of numerous jigsaw puzzles that are only useful when completed; however, to avoid a patent, you must take out certain pieces of each puzzle. To replace these holes, you can add redesigned pieces of a different behavior/shape (to avoid the patent problems). This means, however, that you have to keep changing adjacent components, at least some amount, at least initially, because the initial surrounding environment (defining the outline of the missing puzzle pieces) expects specific behavior (specific shapes), which we eventually found out we have to avoid (to avoid the patents). How much redesign will be needed for any particular scenario? How frequently will you learn about patent problems and have to redesign?

Note that the environment around the holes can be composed of more mono code (that is not infringing as is, with the holes set up). However, it can also be composed of dotnet code or closed mono code where these third party components are not going to be changed by their owners (eg, because they can’t manage that but don’t want to reveal source; because they won’t; because it’s MSdotnet and they have a license; etc). It can also be composed of non dotnet code or even dotnet-ish code but which must abide by rigid interfaces (eg, an IMAP server or plugin, see example scenario below).

So, full resolution of each missing puzzle piece for each violating puzzle will depend on how much change will ultimately be needed from the regions adjacent to the holes. Externally, there are limits imposed by already defined interfaces (some of which can’t be changed). Internally, you would like to avoid making too many changes. For each chain reaction of changes that might be a candidate fit, you must make sure to avoid further patent infringements (on any patent).

For perspective, all FOSS is subject to this, but all FOSS does not gratuitously walk into patent traps. We ask, *who is Microsoft* and how much to they have invested in “patent traps” around dotnet? We compare that answer (in theory) to the same question but about every other API/vendor combination (eg, dotnet/Sun, Java/Microsoft, Java/Sun.. etc). And don’t forget we are talking about api traps, not about general patents. It’s about designing api and patents together to track each other. And to avoid prior art, you have to anticipate the api, else others would be using it already, providing such prior art and foiling the patent-that-tracks-the-api trap.

>> If one specific method is at risk, then avoid it – and given this is Free Software we’re talking about

It likely would be more much than “a method” call. For some patent claims, it might be “any” method call within some API (because all method calls might rely on certain assumptions that would have to be changed to avoid violating patent claims). Plus, some methods or framework pieces are very important in that they help guide application design decisions.

>> Unless you live in fear

Things can definitely get uglier than you pretend is the likely scenario.

Perhaps some people don’t mind, when things get ugly, accepting deals with Microsoft as necessary (eg, patent protection). For example, Novell seems to have taken this approach. They probably prefer to take the Microsoft money and protection (in exchange for their contract work) and thus avoid having to recode and redesign their way out of any future messes across their product lines.

Let’s remember that mono supporters (like many devs) seek to create as much integration as possible and as many apps as possible with their preferred technology.

Let’s remember we aren’t talking about one method call. Microsoft’s patent writing machine is nonstop. Microsoft engineers are talented. Microsoft has lots of money. Microsoft has given the marching orders (they made patents a key strategy in the late 1990s in fighting off the threat to their money line from FOSS). Microsoft learns from its past mistakes as well as the mistakes others make (eg, they learn from ineffective or bypassable patents). Each single patent can affect numerous API components. Etc, etc.

Let’s remember that not everyone using mono will have community backing.

Let’s remember what we just covered above. The trap API will be used to create large interlocking system, some parts of which will not be changed for various reasons. In any case, more than just the immediately affected pieces will have to be redesigned and recoded.

An example of a trap would be if a patent applies when the app (a) makes use of some basic security feature that happens to be embedded in many API calls and framework assumptions, (b) relies on an error-logging framework, and (c) does IMAP or POP or even TCP. To avoid infringement with an app that already does all these three things, you undo any one of (a) (b) or (c). But we can’t really avoid (c) as that is defined by the context of where the application works. Eg, to change any part of TCP, you would have to change established, standards based software to handle special exceptions for these apps (and do so everywhere this app might be deployed, and across all vendors that implement this standard and which may interact with the deployed app). Avoiding (b) might be the way to go, especially if (a) would imply way too many changes or almost a full blown change of API, but (b) might be just as ugly or worse. It all depends on each app.

Now, working on these fixes means other apps stand to push ahead, but this will still mean Linux will take steps back, proportionally to its dependence on the affected software.

My point is that Linux+FOSS should avoid these dependencies. Ie, mono (as a high risk candidate technology) should be avoided to avoid pain later. There are many (imperfect) substitutes to mono.

..and of course, this is the patent angle only. I already mentioned there are other very important reasons why I would not want to help Monopolysoft or put the ball in their court even if patents were not an issue.

Just do a google patent search for “QueryInterface” or “IUnknown” and Microsoft. The patent covers the very foundation of COM, and all of the listed products infringe on it.

There is no difference in how they obtained the patents. The fact of the matter is that they own them.

And Mono is much less of a problem (due to its limited use compared to other technologies infringing on MS patents) than big block busters like Firefox and OpenOffice.

Also, there is no such thing as an “Antitrust safeguard”, you just made that out of thin air.

So what about a little consistency here?

You missed then, as you do now, the reason people suggest your analysis is flawed.

An API is just a set of rules. How you implement those rules (if at all) is entirely up to you. If an API has a HelloWorld() method, then you can do what you want with it, even if the API says “Draw a message using GDI+” nobody is stopping YOUR implementation of HelloWorld() from using Qt. Or somesuch. That’s how this stuff works.

Let’s take an active example of Freetype. Freetype implemented a method of font hinting (i.e. using font hints stored in a .ttf file) patented by Apple. Apple’s legal department started rattling sabers, and Freetype was modified so the API call for “give me the font info”, instead of returning the (patented) stored data, provides autogenerated data instead.

If one specific method is at risk, then avoid it – and given this is Free Software we’re talking about, even if a change causes app breakage, those apps can be fixed trivially.

There is far greater danger from patented algorithms (i.e. codecs) than from your spurious “API trap”. Unless you live in fear of the concept of HelloWorld(), rather than a “bad” implementation thereof.

Patents is only one of two main issues I mentioned. Arguably it is the lesser problem. Certainly, to date, Microsoft’s main weapon has not been patents. However, it’s worth noting that the Comes exhibit revealed Microsoft does look towards patents as a very crucial weapon to manage the open source challenge. This strategic change happened just before the turn of the century. Personally, I continue to think the more subtle “monopoly leveraging of interop they control” is a more potent weapon, but it certainly helps them to get patents on their side, if only for the FUD (deception) and extortion factors.

When there are so many similar platforms (including platforms that could be forked if necessary and adjusted or which are less under the control of a dominating entity), why pick platform Y over X? My experience on forums (and it is limited) is that those that back mono tend not to be bothered or even do like Microsoft’s monopolies. They also tend to speak as Microsoft is unstoppable.

>> For instance, both Mozilla and OpenOffice implement Microsoft COM

Is that true, or are you pulling my leg? I haven’t studied those 3, but I always believed there were real differences among them (maybe they are more similar than I thought). Some of the core concepts are pretty simple and might be shared. These might not be patentable, but if you aggregate enough of these simple concepts it becomes readily patentable in the US.

Novell (cl)aims for “interop” with MSdotnet. That is very different than saying you have a framework that shares basic items and concepts.

So from the patent (read the api trap link) as well as the traditionally more important EEE perspective, you should not IMO contribute to the generic dotnet platform.

FWIW, I would like to see alternatives to Firefox and Openoffice gain ground on these two (wherever they lag behind).

Also, keep in mind that mono is developed and sold as a tool for building new FOSS apps. Firefox and Openoffice, while platforms themselves, have more limited capabilities as application generators (at least in practice).

Finally, those two alternative platforms don’t belong to Monopolysoft, but rather to organizations (one being nonprofit) that have a high interest in bringing competition to markets controlled by Monopolysoft. Each of these competes aggressively with Monopolysoft. These platforms gain from the growth of Linux and FOSS.

>> it seems like they are both juicier targets to go after than Mono.

Their core are not clones.

Did you notice that the FAT patents were very specific. The more specific the patents, the less likely a judge would sympathize with you.

>> Microsoft purchased the graphics and OpenGL patents from SGI

I am aware of that but not of the details.

From the EEE perspective, Microsoft gains much more from use of DirectX interfaces. I also expect they have many more patents (especially tricky ones) on DirectX.

>> Why are you not boycotting the use of OpenGL in that case?

A few more differences I see are that they bought those patents after the fact, rather than having the ability and desire (see Comes exhibit) to create interfaces and protect them with patents.

It was also a small number of patents, iirc, not the many Microsoft has been taking out and likely has on dotnet related interfaces.

BTW, if antitrust safeguards kick in, DirectX is Microsoft’s playground. OpenGL is not.

>> And instead of fighting open source projects, you could *fight* software patents and work for patent reform.

Too late, I’m already on it.

You focused only on the patent question. I think the risks are highest for FOSS devs when you clone Monopolysoft. Also, the other “half” of the battle, which has nothing to do with patents, means that you basically vote for the viability of a platform/standard/etc (and of its patrons) when you use/clone it and build for it. There are many better alternatives than to be voting for Monopolysoft (again, IMO). There is a very good reason I call this company Monopolysoft.

Even “mere” users can vote for the team they think best helps them by contributing.

I think more users will be better off by breaking monopolies, especially when the monopolist has multiple monopolies and levers and uses them to move into new markets. Microsoft uses every ounce they can get away with legally (or illegally if they think justice will lag sufficiently or they outsmart the authorities).

Yes, I really have a problem with Monopolysoft specifically. They are very competent at dominating markets one way or other. They find angles and creative weapons where others don’t even (dare) look or exploit. They know what counts and what doesn’t. They know what wins. They embrace customers only as much as necessary to win and dominate. With control, customers and “partners” have less leverage against them. They also have no qualms about deceiving.

Monopolysoft doesn’t need my help. Monopolies stagnate and suffocate, more so, the more power they gain. I don’t want to see FOSS be embraced, extended, and extinguished (marginalized). Monopolysoft embraces good ideas, then extends them to keep others out of the party (except under Monopolysoft supervision and limitations) We are open. Microsoft is not. I don’t want people to “learn the Microsoft lessons (again)” ten years from now. Enough is enough. I don’t feed parasites if I can help it.

..If I have to pick between similar options and one helps them while the other less so, I will not pick what helps them more.