Comments

• Shane Coyle

  2009-01-11 15:53:52

  Oy. Great find, and potentially a real nugget re: Mono (emphasis mine)
  
  

  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 - Solve application/OS deployment problem even for Win32 - Projecting Windows API experience into new form factors and usage modes around home

• Dan O'Brian

  2009-01-11 15:57:35

  Shane: depends on which parts. Also keep in mind that the Mono developers have stated that their main purpose for developing Mono is not to port Windows apps to Linux; but rather their main goal is to develop a nicer programming environment for Linux.

• Dan O'Brian

  2009-01-11 15:59:13

  FWIW, I suspect they are talking about WPF there.

• Roy Schestowitz

  2009-01-11 15:59:53

  So which parts, Dan? What about Winforms for example?

• Roy Schestowitz

  2009-01-11 16:03:38

  ".NET framework" != WPF.

• Dan O'Brian

  2009-01-11 16:03:58

  Yes, Windows.Forms could be a potential problem area. I haven't ever disagreed on that.
  
  Note, however, that Wine would also infringe on any Windows.Forms patents (Windows.Forms is just a managed binding to the native WinForms, which is what Wine implements).
  
  I know you like to claim that if Microsoft should sue Wine(users) over those patents, that you could just drop Wine - but by that logic, the same holds true for Mono: users could just drop the Windows apps running under Mono and uninstall Mono's winforms libraries ;-)

• Dan O'Brian

  2009-01-11 16:05:38

  Roy: the text Shane refers to never says ".NET framework", it just says "framework" which could be anything. There are a lot of frameworks built on top of .NET. WPF is one example.

• Shane Coyle

  2009-01-11 16:08:45

  Right, I'm not saying that I now know what (if any) patents are involved, but it is at least instructive and disconcerting that Microsoft 1) believes there are patents required and 2) has based their strategy partly upon that fact.
  
  Then, it's more concerning to me that Novell - the Mono people so to speak - went and made a patent licensing deal with Microsoft, because maybe Novell believes it too, deep down.
  
  Now, this also means, strategically, that if we can invalidate software patents, a lynchpin of their strategy is pulled...
  
  Also, whatever came of Office.net? Or the "this sucks" button? So much innovation that never materialized...

• Dan O'Brian

  2009-01-11 16:10:12

  Actually, it doesn't even refer to the framework that it'd patent:
  
  1. Keep network effect with Applications   - Migrate applications to .NET framework     -BUT keep framework proprietary to Windows     -Patents required to implement clone
  
  "clone" could just as easily refer to the application, and not any .NET framework at all.
  
  It's also unclear if this was just a brainstorming idea that was never followed through or if it is something that was done.

• Dan O'Brian

  2009-01-11 16:13:14

  Shane: I see no evidence that this document is talking about patents in .NET after having located the original source with the contextual indentation.

• Shane Coyle

  2009-01-11 16:14:47

  Further about just how much of .NET should go into standards bodies, and I presume how much should conversely be 'held back' from letting the 'horses out'...
  
  

  The NET framework contains the latest developer platform innovation for the future, and it must be licensed like Windows. Subsets have gone about as far as they should go in the standards bodies, but we need a compact subset for phones and TVs. It was noted that we have to be careful because once the horses are out, they are out forever. At the right royalty, we can have the discussions around technology beyond this.

  
  
  It really looks like MS really intended this to be the baited field to hunt over that I've jokingly referred to it as.

• Roy Schestowitz

  2009-01-11 16:14:56

  Dan, you therefore acknowledge that "Windows.Forms could be a potential problem area."
  
  Noted.

• AlexH

  2009-01-11 16:16:00

  It does seem to be talking about patenting parts, but later says that the stuff that has been standardised is potentially lost for this purpose.
  
  Either way, I don't see why continuing to push Microsoft's software patent propaganda is in many people's interests.

• Roy Schestowitz

  2009-01-11 16:18:20

  Let's also ignore the tigers that escaped the zoo. Talking abut them might scare people.

• AlexH

  2009-01-11 16:19:22

  @Roy: the correct analogy is "let's tell people tigers escaped to scare them off!"

• Dan O'Brian

  2009-01-11 16:20:54

  Roy: You realize that Windows.Forms in Mono is a removable component, right?

• Roy Schestowitz

  2009-01-11 16:21:21

  AlexH,
  
  But as Dan said, "Windows.Forms could be a potential problem area. I haven’t ever disagreed on that."

• Roy Schestowitz

  2009-01-11 16:22:17

  Dan, yes and at what expense? You could also remove "while" statements from C++.

• Dan O'Brian

  2009-01-11 16:23:51

  It's pointless to attack Mono over WinForms when it can be so easily dropped from Mono. In fact, most distributions ship the winforms libraries as a different rpm/deb from the rest of Mono.
  
  If WinForms becomes a problem, just `apt-get remove mono-winforms` or `rpm -e mono-winforms`

• AlexH

  2009-01-11 16:24:53

  @Roy: arguing with you on this topic is hopeless because you're unwilling to examine facts.
  
  Suffice to say you're repeating Microsoft's rhetoric to scare people using free software.
  
  If Microsoft ever decide to start suing free software distributors, it's not going to matter whether they use Mono or not. That's not how patents work.

• Shane Coyle

  2009-01-11 16:25:37

  Remember, this is a strategy session circa 2001 - some of these things were implemented, some not, some we will likely never know.
  
  But, again, it shows that Microsoft considered these possible strategies - and, we must consider - what if they pursued them? Usually these conspiracy theories about Microsoft hunting over a baited field lack original sources.
  
  It's like that discussion the other day re: ACPI - just because you say you'd like to do something doesn't prove you did...

• Dan O'Brian

  2009-01-11 16:26:38

  Dan, yes and at what expense? You could also remove “while” statements from C++.

  
  
  Uh, are you seriously that ignorant about programming? Removing Mono's Windows.Forms is nothing like removing a while-statement from C or C++. It's more akin to removing winelib ;-)
  
  Mono's Windows.Forms library, just like the wine library, are ... you guessed it! Libraries! They are not syntax elements in the programming languages. Nor are they core components that every program needs in order to run.

• AlexH

  2009-01-11 16:30:26

  @Dan: what it also ignores is that there have been at least three separate implementations of S.W.F, one of which was just a layer over Gtk+. To say that each would fall under MS's patents scheme is to be ignorant of patent problems.
  
  @Shane: it also ignores the far more profitable strategy of patenting other people's products, not just your own, so you can shut down competitors rather than piss off the people on "your" platform.

• Roy Schestowitz

  2009-01-11 16:33:23

  Dan,
  
  My point was that you inconvenience developers.

• Dan O'Brian

  2009-01-11 16:52:06

  Roy: except that you're wrong. Linux apps that are built on Mono don't use Windows.Forms, they use Gtk# as you know very very well (you just like to pretend that Windows.Forms is a core technology because you think it helps your argument to do so).

• Shane Coyle

  2009-01-11 16:59:20

  I guess my stance is, essentially, that I believe Mono is definitely Free Software - I can't believe it's anything other than 100% Free code.
  
  I believe in standards, and therefore believe that all of the parts of Mono which implement standardized aspects of .net are as safe as anything else - for what that's worth, as we all know nothing is completely safe, but anyway.
  
  My concern is when the project extends beyond those bounds, and I'm less comfortable if/when it is Novell in particular venturing out onto the frozen lake - since they seem to own a unique MS life vest and wet suit.

• Roy Schestowitz

  2009-01-11 17:01:35

  Novell also began advertising patent protection ("IP peace of mind") some months ago.

• Dan O'Brian

  2009-01-11 17:05:23

  Shane: I think that's reasonable, just remember that all of the Mono components that go beyond the standards are easily removed from Mono - and most (all?) of them have alternatives that the Mono guys push instead.

• ushimitsudoki

  2009-01-11 17:22:09

  @Dan: "Roy: the text Shane refers to never says “.NET framework”, it just says “framework” which could be anything. There are a lot of frameworks built on top of .NET."
  
  This is tortuous to the point of dishonesty. The text says:
  
  - Migrate applications to .NET framework --BUT keep framework proprietary to Windows --Patents required to implement clone
  
  Are you really going to argue the first bullet point refers to the ".NET framework", but the sub-bullet directly underneath that --- which even starts with a conjunction --- is some other un-identified framework?
  
  I hope I have misunderstood your assertion, because otherwise I must say you have taken a ridiculous position on that point.

• Roy Bixler

  2009-01-11 17:30:18

  Novell also began advertising patent protection (”IP peace of mind”) some months ago

  I wonder what was the trigger for that. I recall that, when Novell first signed their pact with Microsoft and there was an outcry in the open source community, they claimed that it was only included at Microsoft's insistence and denied that they believed that any patent licence with Microsoft was necessary. If that were true, why would they now be advertising "IP peace of mind" as a feature?

• Dan O'Brian

  2009-01-11 17:44:22

  ushimitsudoki: if you look at the original article (with the intact indentation) it seems to me that they refer to the applications being ported rather than to "the .NET framework" because all of the other bullet points do. The .NET framework is obviously not platform specific (they implemented Rotor on FreeBSD, remember?). Their purpose seems to be to tie the ported application to Windows by making it use Windows-specific APIs (e.g. WPF or Windows.Forms, P/Invoking native libs, etc).

• Roy Schestowitz

  2009-01-11 17:52:04

  What do the bullets/indentation have to do with it?

• Dan O'Brian

  2009-01-11 17:56:12

  The indentation is significant because it shows how the data points relate to each other.

• Shane Coyle

  2009-01-11 18:20:00

  Here is a faithful recreation of the original indentation (I hope...it is the source from the posting), it is also on p.16 of the pdf [pdf] if you want to see the original exhibit.
  
  HIGHLY CONFIDENTIAL
  
  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     - Solve application/OS deployment problem even for Win32     - Projecting Windows API experience into new form factors and usage modes around home
  
  2. Keep network effect with Hardware     - Keep growing range of peripherals supported (better together with other devices)     - Drive key hardware initiatives (Trusted Windows, fast boot, etc.) with OEMs
  
  3, Innovate
  
      - Storage         - Light-weight db, consistent programming model across file system and database         - Focus on defining key metadata schemas and using them in the shell         - Drive applications to use the new rich store     - Shall         - Visual presentation driven by presentation platform advances         - Beyond files and documents - promote users and groups to fist class objects         - Honing focus on scenarios - photos, music, video, gaming, communications     - Presentation reform         - Tighter Further using the error reporting loop to rapidly solve customer issues         - Automatic updates, even fewer reboots
  
      - Natural language         - Natural language for local (aided by the rich store) and Internet content     - Communication         - P2P platform for ad-hoc applications         - Focus on community and group access all of the key scenarios
  
  MS-CC-RN 000001036800 HIGHLY CONFIDENTIAL

• ushimitsudoki

  2009-01-11 18:30:07

  Dan,
  
  You asserted that "framework" in the sub-bullet does not refer to the ".NET framework" in the parent bullet.
  
  That is absurd semantically, grammatically, and contextually.
  
  The sub-bullet says "keep framework proprietary", so it must be *some* framework; and -- unless the author is intentionally playing linguistic games -- it is a certainty that framework is the ".NET framework" already being mentioned.
  
  Platform specificity is irrelevant to this point.
  
  The truth (or falseness) of attempting to tie applications to the Windows platform through APIs is irrelevant to this point.
  
  What other bullet points address or do not address is irrelevant to this point.
  
  My point is that your assertion that "framework" != ".NET framework" in that slide is absurd. Since you continue to defend that assertion, I see no point in continuing to engage with you.

• saulgoode

  2009-01-11 19:49:24

  I guess my stance is, essentially, that I believe Mono is definitely Free Software - I can’t believe it’s anything other than 100% Free code.
  
  I believe in standards, and therefore believe that all of the parts of Mono which implement standardized aspects of .net are as safe as anything else - for what that’s worth, as we all know nothing is completely safe, but anyway.

  
  
  MPEG codec technology is standardized as well; yet some of the largest software patent lawsuit penalties to date have been awarded over MPEG codecs. Does Mono's being standardized make it any less safe than MPEG implementations?
  
  I believe Mono is Free Software as well; HOWEVER, it is encumbered by patents. The Mono Project tells us the patents exist, and that they apply to the technology of the ECMA 335 standard. What they don't tell us -- unlike the FFMPEG and MPLAYER projects -- is that there may be a certain degree of legal risk associated with using their software.
  
  Instead, they tell us that everything is copacetic because Microsoft has granted everybody a worldwide license to use that patented technology however they want, no strings attached. Of course this license isn't written anywhere. There's no evidence of it anywhere on the Web. But since ECMA 335 is "standard", there must be one, huh? Just like there is a free patent license for everyone to implement MPEG codecs (oh wait...).
  
  Personally, I have no compunction when using patent-encumbered Free Software, but I severely question the integrity of a project that misrepresents the risks associated with their software to such a great extent.

• Dan O'Brian

  2009-01-11 19:56:20

  ushimitsudoki: Uh, that's not what I'm arguing.
  
  I'm arguing that "clone" may or may not refer to ".NET framework", because it could just as easily refer to the application itself.
  
  whether "framework" that they want to keep Windows-specific from the bullet above that refers to the .NET framework or not is irrelevant because we already know that .NET is not specific to Windows (see Rotor on FreeBSD, which Microsoft implemented).
  
  But even if I'm wrong, and "clone" does refer to the .NET framework, it still doesn't prove that it refers to the ECMA/ISO standardized portions (there are a lot of .NET frameworks which are not part of the ECMA/ISO specification).

• Dan O'Brian

  2009-01-11 19:58:10

  Also, Microsoft has given up their ability to sue over the ECMA/ISO portions anyway. Those portions are available under RAND-Z (which means anyone and everyone can get a RAND-Z patent grant to those portions, making it impossible for Microsoft to attack anyone for using said patents in a re-implementation of those standardized portions).

• Dan O'Brian

  2009-01-11 20:00:10

  MPEG codec technology is standardized as well; yet some of the largest software patent lawsuit penalties to date have been awarded over MPEG codecs. Does Mono’s being standardized make it any less safe than MPEG implementations?

  
  
  Wow, there is either some blatant ignorance, or blatant dishonesty - I'm not sure which one.
  
  MPEG is a standard, yes, but it is not an ECMA nor ISO standard and they do not offer RAND-Z terms on patent licenses.

• Roy Schestowitz

  2009-01-11 20:05:22

  Does Winforms?

• Dan O'Brian

  2009-01-11 20:05:41

  I believe Mono is Free Software as well; HOWEVER, it is encumbered by patents.

  
  
  Encumbered means that it illegaly infringes upon patents. This is not the case, they have patent rights to implement the ECMA/ISO portions (which are licensed under RAND-Z terms).
  
  

  The Mono Project tells us the patents exist, and that they apply to the technology of the ECMA 335 standard.

  
  
  Which are under RAND-Z terms... thus, not an infringement.
  
  

  What they don’t tell us — unlike the FFMPEG and MPLAYER projects — is that there may be a certain degree of legal risk associated with using their software.

  
  
  FFMpeg and MPlayer illegaly implement (aka infringe) upon patents that they do not license. That's the difference.
  
  Now, it's only illegal in some counties, like the US and EU(?) and not in Hungary, which is where FFmpeg and MPlayer are implemented, so those developers are legally safe. As are users that live in countries that do not respect patents.

• Dan O'Brian

  2009-01-11 20:06:51

  Does Winforms what? Fall under RAND-Z?

• Shane Coyle

  2009-01-11 20:11:20

  And, it even appears that Microsoft had understood that the portions which had already been submitted for standardization were out of the stable in terms of being a royalty target (my emphasis, like usual)

  
  
  The NET framework contains the latest developer platform innovation for the future, and it must be licensed like Windows. Subsets have gone about as far as they should go in the standards bodies, but we need a compact subset for phones and TVs. It was noted that we have to be careful because once the horses are out, they are out forever. At the right royalty, we can have the discussions around technology beyond this.

• Roy Schestowitz

  2009-01-11 20:12:27

  Dan,
  
  Yes, is it?
  
  Someone has just passed me this:
  
  

  ---

  
  
  ----- Forwarded message from Andre Klapper -----
  
  Date: Sun, 11 Jan 2009 00:10:29 +0100 From: Andre Klapper To: desktop-devel-list X-Mailer: Evolution 2.24.2 (2.24.2-2.fc10) Subject: GNOME 2.26 module inclusion discussion heats up
  
  Ahoj,
  
  a reminder that module inclusion discussion must heat up now. At January 19th, Module Freeze takes place: New modules and functionality for GNOME 2.26 will be chosen[1]. Next weekend, the GNOME Release Team will meet and decide about the proposed modules.
  
  Readers: We have already seen community input on this mailing list on the proposed modules. If you feel that something important hasn't been mentioned yet about a module, speak now by replying to the existing proposal thread / starting a seperate thread for the module. (Please do not reply to this generic email.)  Maintainers: If you're a maintainer of a proposed module and some important things have changed, e.g. you have improved the "Gnome-ness" of your module[2] or reacted to feedback/criticism that had been given after you first proposed this: DO tell us about it now! It will improve your chances.
  
  According to the subpages of [1], the following modules have been proposed:
  
  Proposed Desktop Modules: * brasero * gnome-user-share * evolution-mapi
  
  Proposed External Deps: * libproxy * unique * Mono.Addins * libgda * libnotify * notification-daemon * libmapi * samba4
  
  If you already have proposed a module on this mailing list and it is missing in this list, please add it to the wiki pages NOW.
  
  Please do not propose *new* modules now, it's too late. You can do this again in October for GNOME 2.28.
  
  andre
  
  [1] http://live.gnome.org/TwoPointTwentyfive [2] http://live.gnome.org/ReleasePlanning/ModuleProposing#judgement-criteria
  
  

  ---

  
  
  Mono.Addins... is it adding a dependency on Mono to GNOME?

• Shane Coyle

  2009-01-11 20:24:12

  I don't know if this is the end all and be all of patent pledges, but on the ECMA C#/CLI page there is a pdf of a letter from Microsoft in which they promise Reasonable And Non Discriminatory terms to anyone who asks, although not necessarily royalty free, either.

• Dan O'Brian

  2009-01-11 20:26:53

  What does Mono.Addins or Windows.Forms have to do with this random GNOME message to desktop-devel-list?

• AlexH

  2009-01-11 20:27:36

  @Dan: because Mono.AddIns was a proposed external dependency (SWF obviously isn't).
  
  @Roy: good grief. Seriously.

• Dan O'Brian

  2009-01-11 20:28:24

  Shane: if you poke Microsoft, they will give you a royalty-free patent pledge for ECMA 334 and 335.

• Dan O'Brian

  2009-01-11 20:32:34

  AlexH: ah, I missed that line somehow.
  
  Mono.Addins is not a clone of any Microsoft software afaik, in fact it competes with Microsoft's MEF .NET framework. Miguel is pushing .NET developers to use Mono.Addins instead of MEF.
  
  Mono.Addins as an external dependency to GNOME is hardly making the core of GNOME dependent upon Mono.

• Shane Coyle

  2009-01-11 20:37:49

  Shane: if you poke Microsoft, they will give you a royalty-free patent pledge for ECMA 334 and 335.
  
  Okay. I will try that, for a project, and report back.
  
  What, specifically should I ask for - I want to ensure it's Free Software compatible, so I'd need redistribution rights - what else? I want to do this right.

• Roy Schestowitz

  2009-01-11 20:39:46

  Shane, have you seen this yet?

• Dan O'Brian

  2009-01-11 20:43:35

  Shane: I think redistribution rights would cover it.

• Shane Coyle

  2009-01-11 20:44:48

  Well, specifically I want to word it as if I were to implement my own Mono - call it ecma-mono, of just the ecma standardized portions - how do I request a Free Software- compatible set of terms from Microsoft?
  
  How did Mono project go about this, if they did?

• saulgoode

  2009-01-11 20:46:19

  Wow, there is either some blatant ignorance, or blatant dishonesty - I’m not sure which one.

  I don't suspect you of dishonesty.
  
  

  MPEG is a standard, yes, but it is not an ECMA nor ISO standard and they do not offer RAND-Z terms on patent licenses.

  Erm... MPEG is a working group of ISO/IEC. I would daresay ALL MPEG standards are ISO standards (completed ones, anyway), though I am not 100% sure of this. Nonetheless, as MPEG is a part of ISO, most of the standards they produce are indeed ISO standards -- that is the raison d'etre for MPEG to exist and I doubt that an ISO group is permitted a whole lot of leeway in working on non-ISO activities.
  
  And you are correct that MPEG doesn't require royalty-free (Z) terms; however, offering RAND licensing for patented standards is indeed a requirement of MPEG -- should we be surprised that a part ISO uses the same guidelines as the rest of ISO? Here is what they say about it:

  http://www.mpegif.org/patents/ MPEG does not (cannot, under ISO rules) deal with patents and licensing. It asks of companies that propose technologies that get adopted into the standard to sign a statement that they will license their patents on Reasonable and Non-Discriminatory Terms (also called RAND terms).

• Dan O'Brian

  2009-01-11 20:50:44

  Shane: I'd probably just ask if ECMA 334/335 are available under a zero-cost license or, if not, what it would cost to license the patents needed to implement those specifications.

• Dan O'Brian

  2009-01-11 20:53:49

  soulgoode: Er, yes, you are correct - MPEG is an ISO standard. I meant to type just ECMA but I got carried away. Apologies.

• Roy Schestowitz

  2009-01-11 20:54:01

  Let's drop the assumption that standards and patents are contradictory because they are not. It's a fallacy.
  
  Given the corruption that occurs inside ISO, I doubt it means much either way.

• Dan O'Brian

  2009-01-11 20:57:21

  soulegood: the important part, however, is that unlike MPEG (which is under RAND), ECMA 334 and 335 are under RAND-Z. And that makes all the difference in the world.

• Dan O'Brian

  2009-01-11 20:58:25

  Roy: whether ISO is corrupt or not, if something is offered under RAND-Z, it is legally binding.

• Roy Schestowitz

  2009-01-11 21:00:14

  Are extensions of ECMA 334 under RAND-Z? ;-)

• Dan O'Brian

  2009-01-11 21:06:04

  What patent licensing terms does an extension to HelloWorld.c fall under, Roy?

• Roy Schestowitz

  2009-01-11 21:09:33

  Irrelevant. Please address the question.

• Dan O'Brian

  2009-01-11 21:13:43

  No, it's not irrelevant. Any extensions to HelloWorld.c could potentially implement patents that require a patent license.
  
  It's the same for any piece of nontrivial software.

• saulgoode

  2009-01-11 21:19:49

  soulegood: the important part, however, is that unlike MPEG (which is under RAND), ECMA 334 and 335 are under RAND-Z. And that makes all the difference in the world. What if the terms of that RAND-Z license state that you must download the software from Novell (such as is the case for Moonlight)? Wouldn't that mean that everyone who gets their software from Debian (or Canonical, or Mandriva, et al) is now violating the terms of the license?
  
  Would you then be just as adamant about patents being infringed as you were for the "illegal implementations" of FFMPEG and MPlayer?
  
  I will admit ignorance of what the precise terms of this RAND-Z license are; I haven't seen it. Nor have you.

• Roy Schestowitz

  2009-01-11 21:26:29

  Miguel has.
  
  

  MIX - Novell's de Icaza criticizes Microsoft patent deal

  
  
  Open-source pioneer and Novell Vice President Miguel de Icaza Thursday for the first time publicly slammed his company's cross-patent licensing agreement with Microsoft as he defended himself against lack of patent protection for third parties that distribute his company's Moonlight project, which ports Microsoft's Silverlight technology to Linux.
  
  Speaking on a panel at the MIX 08 conference in Las Vegas, de Icaza said that Novell has done the best it could to balance open-source interests with patent indemnification. However, if he had his way, the company would have remained strictly open source and not gotten into bed with Microsoft. Novell entered into a controversial multimillion dollar cross-patent licensing and interoperability deal with Microsoft in November 2006.
  
  "I'm not happy about the fact that such an agreement was made, but [the decision] was above my pay grade; I think we should have stayed with the open-source community," de Icaza said. He was speaking on a panel that also included representatives from Microsoft and open-source companies Mozilla and Zend.
  
  [...]
  
  De Icaza shot back that it was "unfair" of Schroepfer to paint Novell as the only company protected by patent covenants, as many companies have signed licensing agreements not only with Microsoft, but also with other companies such as IBM that have a large patent portfolio.
  
  [...]
  
  The choice has drawn ire from open-source diehards who were displeased with Novell's decision to sign a cross-licensing agreement with Microsoft in the first place. A Web site called "Boycott Novell" decried Moonlight as a Microsoft "pet project" and criticized the company's decision not to port Silverlight to Linux itself.

• Dan O'Brian

  2009-01-11 21:32:40

  Roy: uh, he's not talking about RAND-Z there, he's talking about the Microsoft/Novell deal. Did you really think they were the same thing?
  
  soulgoode: That's not how patent licensing works, so you'd be wrong.

• saulgoode

  2009-01-11 21:42:39

  soulgoode: That’s not how patent licensing works, so you’d be wrong.

  What do you mean? A patent license (or a copyright license, or a trademark license) always has terms associated with it. Just because one of the terms doesn't happen to be "the party of the second part will give the party of the first part $XXX" doesn't mean the other terms don't matter. You violate the terms, you violate the license. You violate the license, you are liable for infringement.
  
  How exactly do you think patent licensing works?

• Dan O'Brian

  2009-01-11 21:45:31

  My point is that's not what the terms are for ECMA 334 or 335. That would fail the "Reasonable" portion of RAND-Z.
  
  Remember that DotGNU also implements ECMA 334 and 335, using the same RAND-Z license.

• Roy Schestowitz

  2009-01-11 21:57:57

  What about the extensions?

• Dan O'Brian

  2009-01-11 22:00:52

  What extensions?

• Roy Schestowitz

  2009-01-11 22:03:35

  Mono extensions. You're avoiding my query to you.

• Dan O'Brian

  2009-01-11 22:08:10

  I'm not avoiding anything. You just expected me to be telepathic and somehow figure out what extensions you were talking about.
  
  You're still being unclear as to which extensions you mean, so I can't answer your question other than to say that if an extension implements a patent, it may need to be licensed from the patent holder. It really makes no difference if we are talking about extensions to Mono or extensions to KDE, GNOME, Linux, Firefox, or anything else.

• Roy Schestowitz

  2009-01-11 22:14:15

  It matters when Microsoft not only applies for specific software patents but also says it intends to use them.
  
  Microsoft seems to be entrapping using Mono while at the same time getting developers 'addicted' to .NET (and users too, being consumer of the programs).

• twitter

  2009-01-11 22:50:08

  Hey Shane, I've collected the ACPI story here. When M$ says they want to make life difficult for others, they usually do. In other cases, you might give a company the benefit of the doubt. M$ is a repeatedly convicted felon and guilt should be presumed.

• Roy Schestowitz

  2009-01-11 22:55:11

  We don't lack examples of technical sabotage, but I lack time that's required to process and post them here. I have about 30 Comes vs Microsoft posts in the pipeline.

• Rui Seabra

  2009-01-11 22:55:32

  Dan O'Brian said, Shane: if you poke Microsoft, they will give you a royalty-free patent pledge for ECMA 334 and 335.

  
  
  Well, people have been repeatedly asking for their royalty-free licenses for ages and still none has been received, so I call dibs on your statement unless you can actually post the Royalty-Free license link at microsoft.com
  
  I've been a faithfull GNOME user since the start, but if I can no longer rid mono from my systems and keep GNOME at the same time, then I will no longer have GNOME.
  
  It'll be a breeze of free memory, anyway...

• saulgoode

  2009-01-11 22:55:50

  My point is that’s not what the terms are for ECMA 334 or 335. That would fail the “Reasonable” portion of RAND-Z.

  
  
  My point is "what are the terms?".
  
  According to the Mono Project, there are no terms; no conditions; no strings attached ("basically a grant is given to anyone who want to implement those components for free and for any purpose"). According to Microsoft, they... well, "will be available" is about the closest we have to any tangible statement about licensing terms.
  
  Also, the word "reasonable" is absolutely free in interpretation. The idea of prohibiting sublicensing certainly didn't seem unreasonable to MS Director of Intellectual Property, Michele Herman. And to be honest, it doesn't seem that unreasonable to me (taking their perspective). Nonetheless, such a prohibition is unacceptable to the idea of software being Free.
  
  

  Remember that DotGNU also implements ECMA 334 and 335, using the same RAND-Z license.

  The DotGNU project doesn't proclaim any indemnity from Microsoft owing to any license. Their only mention of patents is to say that Microsoft's Rotor license does NOT offer patent protection.

• Roy Schestowitz

  2009-01-11 22:58:49

  Rui Seabra,
  
  Obligatory dependency may be less than likely, but pragmatically, it is already hard to find Mono-free 'implementations' (binaries) of GNOME. Ubuntu is a good example.

• Shane Coyle

  2009-01-11 23:07:25

  In that same linked article, it does indeed indicate Microsoft's intent to issue a royalty-free RAND license (RAND-Z or RAND-RF, I believe are the appropriate acronyms)

  According to Herman, third parties will have to enter into a reasonable and non-discriminatory (RAND) license agreement with Microsoft. "But," says Herman, "while RAND sometimes means there could be a financial obligation, [Microsoft] …will be offering a conventional non-royalty non-fee RAND license. We've always made that clear to anyone who has asked." In other words, there will be no financial obligation.

• Dan O'Brian

  2009-01-11 23:40:02

  Thanks Shane ;-)

• saulgoode

  2009-01-11 23:58:32

  Shane,
  
  I eagerly await the results of your quest to enter into such an agreement and to learn of the actual terms you are granted -- particularly whether you will be able to pass those terms onto others (and they onto others).

• Shane Coyle

  2009-01-12 00:02:25

  learn of the actual terms you are granted — particularly whether you will be able to pass those terms onto others (and they onto others).
  
  That's pretty much the part I am most interested to learn, as well.

• Roy Schestowitz

  2009-01-12 00:27:16

  Was it ever stated why this can't be publicly disclosed?

• Dan O'Brian

  2009-01-12 01:35:38

  Btw, do you guys really think Novell's Mono team is breaking the law? Because that's what you are accusing them of.

• Roy Schestowitz

  2009-01-12 01:45:25

  How so?

• ushimitsudoki

  2009-01-12 05:49:38

  Dan,
  
  I think I owe you an apology. I did not see your post starting with "Actually, it doesn’t even refer to the framework that it’d patent:", which I now take to mean you modified your position initially from focusing on "framework" to "clone".
  
  If this is correct, it would be unfair of me to criticize you for saying "framework" != ".NET framework", when that was something you later modified to "clone" != ".NET framework".
  
  This was an oversight on my part in a fast moving thread of comments and I should have read more carefully before attacking a position that you did not actually hold.

• Jose_X

  2009-01-12 08:05:27

  [I've only just started this long thread, so I may be duplicating. Also, what I am quoting come from different authors.]
  
  ***
  
  >> Also keep in mind that the Mono developers have stated that their main purpose for developing Mono is not to port Windows apps to Linux; but rather their main goal is to develop a nicer programming environment for Linux.
  
  They can get a "nicer" programming environment without following dotnet or any other specific platform in most details.
  
  Numerous mono devs and Novell have as a major focal point to "clone" MSdotnet.
  
  ***
  
  >> Note, however, that Wine would also infringe on any Windows.Forms patents (Windows.Forms is just a managed binding to the native WinForms, which is what Wine implements).
  
  The implication is incorrect. You *can* patent new aspects of something old. Obviously Windows.Forms is not WinForms (whatever these things are) or else they wouldn't be marked off as separate technologies (at least on this thread there is a distinction being made by some). Being different, then, the implications you suggest don't follow.
  
  This is not to say there aren't patent problems with WinForms. Perhaps those patents do carry over to the new stuff, but not vice-versa.. not necessarily anyway as you suggest.
  
  However, I'd avoid coding to *any* MS API of any time period, even if it can be expected that, the newer the tech, the greater the risks. Microsoft has really ramped up patent applications over time.
  
  ***
  
  >> I know you like to claim that if Microsoft should sue Wine(users) over those patents, that you could just drop Wine - but by that logic, the same holds true for Mono: users could just drop the Windows apps running under Mono and uninstall Mono’s winforms libraries
  
  I'll answer for myself. I am not encouraging people to code to MS API, but obviously you and some others have.
  
  mono supporters, in particular, seem to be encouraging the spread of their product's API. I don't think wine supporters are that gung-ho in their respective case. (?)
  
  Of course, I always prefer to avoid the newer MS API/platforms even more than the older ones since the value to Microsoft's monopolies today (eg, lock-in of desired apps) is greatest with the newer MS technologies (with these being used by the newest products generally). ..and, as mentioned, their software patent production has really gone up over time.
  
  ***
  
  >> It’s pointless to attack Mono over WinForms when it can be so easily dropped from Mono. In fact, most distributions ship the winforms libraries as a different rpm/deb from the rest of Mono.
  
  ..and lose your favorite app?
  
  Well, that is why I don't support any apps that I know I will not want to ever make my favorite apps because of risks like these. I don't support mono apps.
  
  Read your own (DanO'B) earlier comment about how you did specify to drop the apps. That can be a very inconvenient piece of advice. Better advice is to avoid becoming dependent on risky apps. [Perhaps you advised it because you aren't seeing the risks as I am. I'm hoping you will pay attention to my arguments.]
  
  ***
  
  >> Roy: arguing with you on this topic is hopeless because you’re unwilling to examine facts.
  
  I disagree, though feel free to stop arguing with Roy on this topic so much if you think its hopeless.
  
  ***
  
  >> If Microsoft ever decide to start suing free software distributors, it’s not going to matter whether they use Mono or not. That’s not how patents work.
  
  Alex, are you still confused about patenting functionality that was designed with dotnet in mind (but before prior art existed.. as only MS/proxies can be expected to do)?
  
  The API semantics and patent claims can parallel each other. What are you going to do, dig into mono and change the API semantics? ..and essentially break every single app using those API?
  
  ***
  
  >> It’s like that discussion the other day re: ACPI - just because you say you’d like to do something doesn’t prove you did...
  
  But it's almost unavoidable for Microsoft to avoid the extensions. They didn't have to state in an email they would make it a point to try to create obstacles for Linux; however, for those that care, those emails suggest (criminal) intention and perhaps also suggest an effort to go heavy on the incompatibilities.
  
  They write closed source. They debug/design/test with their partners. "Bugs" do form part of the de facto interface specs, for better or for worse.
  
  And do you know of a single instance where Microsoft has not had a bug or otherwise added a reasonable extension to anything (or done both)? If you do, please name the product as well as the documentation that describes it perfectly. We can start building a list for the eventual defense of Microsoft.
  
  The burden of proof is on Microsoft amid all the evidence of such tactics in their history (EEE) and considering the natural course of human-based software development (bugs).
  
  And let's not forget all the business reasons Monopolysoft has for relying on extensions and closed source "innovations". They are very open about their closed source "innovations".
  
  Would Microsoft really let their stockholders down by attempting a superhuman effort to meet published specs exclusively and to do so while producing bug-free code? (..assuming the specs were even super quality full specs to begin with, which I have heard ACPI is not)
  
  The fallout for competitors happens quite naturally, aided more so the worse the specs are [but the email does suggest to me extra effort to create even more issues].
  
  The solution to lock-in, so that there is competition for your buck (or lack of buck) and so you have freedom, is open source. This is particularly important for customers to keep in mind when the context is Monopolysoft. Open standards enhance open source. Closed source implementations of open standards are at best iffy.
  
  Bottom line: Microsoft writes closed source, so they can attempt anything behind your back with modest effort; thus, you should look at their EULAs to see -- of all the things Microsoft can do and that you can't verify -- from which of these are you protected. I don't think you'll find very much protection, actually.
  
  ***
  
  >> what it also ignores is that there have been at least three separate implementations of S.W.F, one of which was just a layer over Gtk+. To say that each would fall under MS’s patents scheme is to be ignorant of patent problems.
  
  Can you (AlexH) elaborate because I don't keep up with "S.W.F"?
  
  Here is my view.
  
  If functionality X is patented, you can't do it freely (according to sw patent enforcement). You can try to achieve the effects some other way, but not following the patented process.
  
  For those that know dotnet better, is the following analogy correct or incorrect (and why ..if you think it's incorrect)?
  
  Eg, if using water through a set of pipes and oil through another set of pipes in some prescribed way in order to run some engine is patented, you can't do it freely.
  
  The software equivalent to this is that you might be safe implementing drawing to screen and event handling if you do it like GTK+ (let's assume), but that doesn't mean you would then be safe if you use GTK+ in the background to implement a patented process. For example, running water and running oil through pipes is not patented, but when combined within a larger system to achieve some effect it might be. GTK+/while-loops/water-and-oil/pipes may not be patented, but GTK# (composed of some of these unpatented components) might be.
  
  Alex, I know you know that unpatented processes can be combined into a patented process, so is the problem that I did not understand your quote? If so, can you reword it or explain "S.W.F" a little? Can you analyze wrt the analogy just presented?
  
  Microsoft knew the details of dotnet before prior art existed. Let's not forget this.
  
  Microsoft would not be doing anything too different than what Rambus and probably IBM and many other companies have done (except the threat of enforcement against Linux are different for various reasons). That is, they would patent a recipe that others would then implement (for compatibility reasons), perhaps naively thinking patent risks didn't exist.
  
  If there are serious risks for using various MS created API, as I have suggested there likely might be, what FOSS dev would want users and other devs to ignore or be naive wrt to the patent risks from the creators of dotnet?
  
  [I mentioned some specific patents from Microsoft in an earlier comment elsewhere (based on a post by ushimitsudoki?). I may bring that link back to look at it closer.]
  
  ***
  
  >> except that you’re wrong. Linux apps that are built on Mono don’t use Windows.Forms, they use Gtk# as you know very very well (you just like to pretend that Windows.Forms is a core technology because you think it helps your argument to do so).
  
  It would help if you guys gave a quick overview of what Windows.Form is.
  
  Are you suggesting though that interface functions in Windows.Form are not being used in any mono apps because they are not implemented in mono? [I don't know, so please help me with the details here.]
  
  You did state earlier in this thread that Windows.Form can be removed from mono and you compared it to removing winelib (comment 58083); thus, I am a little confused in trying to reverse engineer from your comments what Windows.Form actually is (I'd think I would know what winelib is).
  
  In any case, the risks from Microsoft, in general, are very clear. If we use their API, we put our apps and time invested and potential businesses in their hands, and we know how friendly those hands are to competitors that don't pay tolls. These are potentially very significant investments, individually and collectively, that we could be talking about wasting by spreading their dotnet and other API over the FOSS world.
  
  ..and never mind issues like this: http://boycottnovell.com/2009/01/11/microsoft-patents-and-mono-vs-linux/#comment-58186 which are further described here http://boycottnovell.com/2008/11/25/jose-on-mono/ as well as on this very blog posting at the top and elsewhere.

• AlexH

  2009-01-12 08:23:18

  @Jose: if an "API" is patented, it doesn't matter how much you change the API, or what language it's written in: it's still patented. That's how patents work.

• Jose_X

  2009-01-12 08:32:48

  >> Btw, do you guys really think Novell’s Mono team is breaking the law? Because that’s what you are accusing them of.
  
  Dan O'B, the mono team you mentioned might have a different set of terms than you or I might get.
  
  People are looking for a guarantee of terms compatible with the GPL and other FOSS licenses.
  
  Why the hush hush? How long before we get licenses from Microsoft whose terms can be passed to anyone we please? This might imply an end to the hush hush since we would then be allowed to post on a website (not sure about this -- I'd have to (re)read the various FOSS licenses I care about in order to form a stronger nonprofessional opinion).
  
  Also, I hope you take a look at my longer prior post since much of it is a reply to something or other you said. [I hope Alex also takes a look, especially at the recurring issues on the patent risks of mono to which I keep returning.]

• Jose_X

  2009-01-12 08:42:59

  Alex, to take it a few steps further, would you now say that usage of an MS API may pose significantly greater risks in comparison to usage of an API created by someone or some group who disclaimed patent requirements? [assumption being that MS has not offered unrestricted patent licensing for the API in question, should their patents apply]
  
  Also, reader should keep in mind that Microsoft has close ties to a number of serious patent companies/trolls whom Microsoft (or it's ownership) likely can or will use as proxies as necessary to help Microsoft.

• AlexH

  2009-01-12 08:47:21

  @Jose: no, not at all.
  
  The source of the actual API doesn't matter because it's not the API which is patented. So, unless you're proposing to avoid any software which has an MS equivalent which MS could have patented, then it's meaningless.

• Jose_X

  2009-01-12 08:53:44

  >> Also, reader should keep in mind that Microsoft has close ties to a number of serious patent companies/trolls whom Microsoft (or it’s ownership) likely can or will use as proxies as necessary to help Microsoft.
  
  By this I mean that as long as I don't trust Microsoft's relationship to Linux+FOSS (surely not as long as they have their strong monopoly levers), I would wipe by nose on the paper of their patent covenants/licenses (if/when/as they produce these licenses) because they could easily sell patents to trolls or facilitate the creation of patents by others based on their created technologies. Attack by proxy is not something I want to facilitate. I avoid Monopolysoft technologies.
  
  When will I post: "I'm getting itchy... I need to sneeze... Someone please hand me an MS license because I didn't pick one up on the way out of the restroom..."
  
  [Now, will be gone at least for some hours, but longer if I fall asleep when I get back.]

• Jose_X

  2009-01-12 08:57:17

  >> So, unless you’re proposing to avoid any software which has an MS equivalent which MS could have patented, then it’s meaningless.
  
  Of course I'd rather avoid such software. MS created API have a much higher risk of being patented than any other use you might randomly come across in writing code.
  
  Patents are only a part of why I avoid sw that I think helps Monopolysoft retain their position of strength. [I've stated this numerous times but once again doesn't hurt so that it's clear I am not only defensive against patents when I shun mono.]

• Jose_X

  2009-01-12 08:57:50

  I need to run out the door but will return eventually.

• AlexH

  2009-01-12 09:19:15

  @Jose: you keep repeating that the API is more likely to be patented, but it doesn't stand to reason.
  
  First, the actual API itself cannot be patented: it's an implementation detail, and the interface itself is entirely standard.
  
  So, there are two options: either there is a way of implementing the API that doesn't run afoul of patents, or there isn't.
  
  An example of the latter might be an API to encode audio data in MP3 format. The API itself is entirely non-patented, but there is no way to implement it without running afoul of the MP3 patents.
  
  What I keep pointing out to you, and that you don't seem to be getting, is that it doesn't matter if you API is .net, C, Java, or Cobol - it's patented, and it cannot be avoided.

• Roy Schestowitz

  2009-01-12 09:28:15

  First, the actual API itself cannot be patented: it’s an implementation detail, and the interface itself is entirely standard.

  
  
  What about extensions?

• AlexH

  2009-01-12 09:33:38

  @Roy: what about them? There's nothing special about them from the point of view of patents. An extension's actual API cannot be patented, simply because it's a descriptive thing: it's potentially subject to copyright (hence how the GPL works), but that's it.
  
  Patents could only affect the code that's "behind" the API, and it doesn't matter what the API is or how the code is written: the patent covers an idea.

• Roy Schestowitz

  2009-01-12 09:50:36

  Microsoft limits access to protocols, too.
  
  http://boycottnovell.com/2007/05/24/is-novell-a-wspp-or-mcpp-licensee/

• AlexH

  2009-01-12 10:13:44

  Attempt to shift topic away noted.

• Roy Schestowitz

  2009-01-12 11:16:07

  It wasn't a diversion, it's a practical example.

• AlexH

  2009-01-12 13:03:28

  Not really, because Microsoft have patents which cover the SMB protocol and Samba don't have an agreement/license with them, yet Samba still manage to avoid the patents.

• Jose_X

  2009-01-12 13:04:21

  >> What I keep pointing out to you, and that you don’t seem to be getting,
  
  If I am to believe you, I'd have to believe there was an ewe nearby, but I don't think there is.. yet we keep ramming heads?
  
  >> is that it doesn’t matter if you API is .net, C, Java, or Cobol - it’s patented, and it cannot be avoided.
  
  As to the problem that a Microsoft patent may apply to some API/interface developed elsewhere, if the API was done independently of Microsoft, (a) the odds of the violated patent claims being not that inventive would be more demonstrable than if Microsoft API are adopted blindly. (b) The odds of finding such a violation outside of API developed by Microsoft are significantly lower than if you adopt the very API Microsoft wants to protect. [see the next reply part of this comment]
  
  I do agree sw patents are a pos.
  
  If you are attached to dotnet.. if your livelihood depends on dotnet.. you are not a good candidate for dropping it, but a great many people are not in that position. To this last group I say that they'd do FOSS a positive service by avoiding dotnet, which might imply contributing enough to the competition of any dotnet pieces floating around the FOSS world.
  
  >> Patents could only affect the code that’s “behind” the API, and it doesn’t matter what the API is or how the code is written: the patent covers an idea.
  
  I hope you know I haven't contradicted that. I use the term "patent an API" loosely at times because I have qualified it in the past.
  
  The literal expression of an API is not patentable (copyrights), but usage of an API can simultaneously result in you implementing some particular functionality in that software just as per the claim(s) of some patent.
  
  If a patent says Y is performed by carrying out steps x,y, and z. And some software system (think mono, the software product) accessible through some API in some language L has components that achieve that same effect/functionality Y through steps x, y, and z, then you can run afoul of the patent potentially just by making the most basic uses of that API within your application ..or perhaps just by linking to the runtime and having the runtime carry out those functions for you transparently (eg, as some sort of initialization sequence, through some sort of background monitoring/management system, etc).
  
  The number of scenarios that can fall under this API/patent relationship is very large. Probably most API can have patents built to capture violations through simple usages of the API, except for the fact that there would already be prior art if you attempted to write such a patent to parallel an existing API (or except that the patent examiner might decide the patent was not very useful or inventive or whatever was required by law).
  
  Under the current system (at least in the US), many ideas might be allowed to be patented. The writer of the patent/API could go to a bit of care to avoid prior art principally by making the component pieces of the claims unusual in structure/organization/functionality, but arguably nevertheless useful and non-obvious so as to be granted the patent. In this case, it might be trivial to get the basic effects (the Y) into your application in some way that is non-violating UNLESS you already committed to using the precise recipe afforded through the use of such an API/patent duo.
  
  And once that code is written and in use, it can be a pain to find, analyze, redesign, recode, rebuild, redeploy, etc, per each such violation instance across all your applications+customers. And you may have alternative recourse, AND be forced to stop usage immediately (after a court ruling). If there is an alternative, it might, eg, also be expensive and perhaps even line Monopolysoft's pockets, or it might put you out of business depending on your niche and on the license terms you may be able to acquire.
  
  Using something like GTK+ is likely to be safe (vs. say asp dot net usages); however, that wouldn't completely safeguard GTK# since there is some amount of software within the implementation of the GTK# access that is not within "typical" GTK+ bindings. This extra software may involve some book-keeping, some particular initialization, or something else characteristic/specific of a dotnet system, done by the software system runtime (eg, by "mono") in order to effect the call to the GTK+ binary code.
  
  Through the patenting of odd and unique signature recipes only found in, eg, dotnet, these patents/API can avoid prior art YET not even be all that inventive (just unusual enough and inventive enough to convince/fool a patent examiner). Microsoft might be able to crank out these patents and possibly only have them apply to systems following very very closely along the same dotnet API path. [Again, the API is but the vehicle that allows the app dev to incorporate into the app (poison) software functionality implemented as per some particular patented process.]
  
  This is why I say there is an especially high chance of violating patent claims when you follow the exact API created by someone laying such traps as opposed to when you follow an API not created by someone laying those traps. Sure the latter "safe" API may be used within some application so as to violate patent claims out there somewhere, but those risks would be normal patent violation risks ...
  
  ...In other words, in contrast to Microsoft patent scenarios, there would be better defenses in court if the code or API design was done by a normal developer in the course of solving a typical problem; there would be significantly lower odds of such patent claims even existing within your code; there would be typical/lower odds of the patent claim violations being recognized by the patent owner; there would be typical/lower odds of damaging enforcement being desired by the patent owner noticing such violations; etc. Cumulatively, the overall threat would depend on the multiplication of all of these small probabilities (leading to a very very small number for each of the very large number of possible cases). All the cases summed would still be manageable perhaps. In contrast, if *each* of these probabilities would be **much** higher, the overall threat would be *several* times **much** higher. [..This is a rough analysis outline of the risks.]

• Jose_X

  2009-01-12 13:15:32

  Novell could give Microsoft a run for their money if they developed dotnet-ng. They'd have expertise in migrations from dotnet. They still likely have talent on board (and would take more devs in as they grew) and no a priori reason to think they couldn't become a much larger company than they are today while Monopolysoft is being cut down in size. They could organize/collaborate better with other technologies not too unlike dotnet They'd have many more FOSS supporters. ETC. ETC. [The community support would be priceless! ;-) ]

• Roy Schestowitz

  2009-01-12 13:18:47

  It's not so simple.
  
  If they anger Microsoft, they'll get no voucher bribe ("patent royalties").

• Jose_X

  2009-01-12 13:31:01

  >> then you can run afoul of the patent potentially just by making the most basic uses of that API within your application ..or perhaps just by linking to the runtime and having the runtime carry out those functions for you transparently (eg, as some sort of initialization sequence, through some sort of background monitoring/management system, etc).
  
  The initialization, background processing, etc, might be requirements of the overall dotnet system (eg, to maintain consistency among various standardized objects).
  
  To avoid these behind-the-scenes actions (should a valid patent claim be presented), you would very possibly have to break compatibility with "dotnet" as you had implemented up to that point in time, but, regardless, any or all past violations you are called on would become major headaches to fix at such time as you are called on them (hence why Microsoft is not likely to sue, but only to threaten, for some years).
  
  >> And you may have alternative recourse, AND be forced to stop usage immediately (after a court ruling).
  
  Should be corrected to:
  
  "And you may not have alternative...." [Note the "not".]

• AlexH

  2009-01-12 13:32:59

  @Jose: you keep up this "patents and API" thing when the two are totally and utterly separate. You can implement APIs in ways which do or do not infringe patents; it's nothing to do with the API itself. Similarly, you can infringe those exact same patents using different APIs.
  
  Patents don't restrict themselves to technical boundaries. You don't have ".net patents" and "C++ patents", they're all just "patents". The implementation just does not matter.

• Jose_X

  2009-01-12 13:38:56

  >> It’s not so simple. >> If they anger Microsoft, they’ll get no voucher bribe (”patent royalties”).
  
  I'm just stating some components of a particular theory. I hope I didn't imply it would be simple or that Novell (Microvell.. whatever) would find it attractive.
  
  The main point is that Novell has (or had) an ability to adjust its future and improve its image in the eyes of many FOSS supporters simply by competing *against* Microsoft (go for the really big slice of pie) instead of working on Microsoft's side (and getting paid a much smaller and monopoly supporting traitorous blood fee).

• Roy Schestowitz

  2009-01-12 13:46:28

  I’m just stating some components of a particular theory. I hope I didn’t imply it would be simple or that Novell (Microvell.. whatever) would find it attractive.

  
  
  There is a real company called Microvell... ;-) we can't use that term anymore.

• Shane Coyle

  2009-01-12 14:31:24

  I don't feel I'm accusing Mono or DotGNU of anything, but rather conducting some research by contacting the original sources - something that many have pined for in the past here. A new era at BN.
  
  Even then, I am only asking a specific subset of the myriad questions regarding all of this - permission to implement and redistribute an implementation of ecma334&335 under a Free license.
  
  Mono goes beyond that, so even if I am granted permission, it is not necessarily analagous to Mono. Also, even if I am granted 334&335 - is that even enough to make a working c#/CLI implementation? (a technical question well beyond me)
  
  I'll spin up the letter after work, post it for review and suggestions, then we'll send it certified snail mail. In any event, I plan to prominently post the response here on the site as a reference - hopefully we can eliminate at least some FUD with some FACTS...

• Dan O'Brian

  2009-01-12 14:40:56

  I don’t feel I’m accusing Mono or DotGNU of anything, but rather conducting some research by contacting the original sources - something that many have pined for in the past here. A new era at BN.

  
  
  I didn't mean you.
  
  

  Mono goes beyond that, so even if I am granted permission, it is not necessarily analagous to Mono.

  
  
  Yes it is. While Mono does implement more than just ECMA 334 and 335, those pieces are easily split from Mono and are even packaged separately.
  
  Windows.Forms, for example, is in a "mono-winforms" package.
  
  

  Also, even if I am granted 334&335 - is that even enough to make a working c#/CLI implementation? (a technical question well beyond me)

  
  
  Yes, it is all that you need. Banshee, Tomboy, etc are all written using the ECMA 334 & 335 bits + Gtk#
  
  It should be noted that the ECMA 334 & 335 bits are more extensive than libc, yet people can obviously write very useful C applications.
  
  Microsoft's extensions to their own .NET framework are not required to exist under Linux for Mono to be useful. Just like Linux C/C++ applications don't use MSVC, Mono apps on Linux don't need to use Windows.Forms or MEF or any other extensions that Microsoft comes up with.

• Roy Bixler

  2009-01-12 15:01:45

  Not really, because Microsoft have patents which cover the SMB protocol and Samba don’t have an agreement/license with them, yet Samba still manage to avoid the patents.

  It helps to have a list of the patents which Microsoft is asserting so that the Samba project could avoid them.

• Roy Schestowitz

  2009-01-12 15:07:38

  Samba is also a Special Case because of the European Commission.

• Ian

  2009-01-12 15:10:52

  The main point is that Novell has (or had) an ability to adjust its future and improve its image in the eyes of many FOSS supporters simply by competing *against* Microsoft (go for the really big slice of pie) instead of working on Microsoft’s side (and getting paid a much smaller and monopoly supporting traitorous blood fee).
  
  Jose,
  
  As Roy loves to point out, and for better or worse, Novell is a mixed source company. Some of what they produce is open source, while many of the products they charge money for are proprietary and closed source products. Much of what Novell provides is in direct competition with many Microsoft offerings. Unfortunately for Novell, they have gotten ass beat by Microsoft for the better part of a decade in many of their previously lucrative market segments such as the groupware and workgroup segments for a variety of reasons. They still compete in these segments though.

• Jose_X

  2009-01-12 15:16:01

  >> You can implement APIs in ways which do or do not infringe patents; it’s nothing to do with the API itself.
  
  No, you can't avoid this in all cases. The API can by definition/standard/design/etc semantically implement steps of a patented process. It may take a single object creation and method X call sequence to implement the full claim within your app or it may take a few more coded sequences.
  
  Eg, ...claim 2: ...check if an object can be instantiated by testing if the foo bit is set.
  
  The foo bit is well-defined and is used in other scenarios. The system implements the above.
  
  Now, you find that the above patent claim is violated because the runtime linked to your app works as above.
  
  How do you get out of this? [Note, I just constructed this example. It's not clear to me this quickly that the example demonstrates what I am trying to explain.]
  
  -- First, assume that this claim leverages other pre-existing conditions (from, eg, claim 1), such that no prior art exists. Ie, assume the patent is valid.
  
  -- We can expect that this patent will not be violated in non dotregret apps. In particular, claim 1 describes several attributes of a dotregret based app not likely to all be met by non dotnet apps. Nevertheless... [for the sake of the upcoming principle argument, we can forget about this point if you don't believe it, since I am not giving the details of claim 1]
  
  -- It's otherwise very easy to instantiate an object without testing the foo bit (ie, if you didn't have a dotregret environment); however...
  
  -- The full dotregret system has numerous other features that are intricately tied to this foo bit assumption. In particular, the spec asks you to set the foo bit of a blob prior to using that blob as raw material to instantiate an object. Since this is how the API was designed, many people set that foo bit. They also do other things with that foo bit later on. It is passed explicitly as a parameter to numerous basic API calls. In particular, the spec designates that bit for the developer to use frequently as storage of particular type of boolean state, whose meaning will vary based on the type of object and even during the lifetime of the object. Some other value elsewhere, bar, defines the meaning of foo at any given point in time, for a given object.
  
  Let's add,
  
  "claim 3: ...the value of bar defines the meaning of the state of foo according to this matrix...."
  
  The matrix depends on the type of object (various general categories/classes are defined) and some other things.
  
  The API similarly defines bar, except that the spec gives precise meaning to more details that otherwise might be general within the patent. Eg, the patent describes category 1 as objects that are created after system initialization by the memory manager (sys init and mem mgr are defined more precisely elsewhere in the patent). The dotregret defines an actual memory manager object with more tangible characteristics. Dotregret defines exactly what system initialization is, so that this definition is a subset of the patent definition, and so that the precise boundary in time of the end of sys init is well-defined. ETC.
  
  "claim 4: ..." covers more of the ways foo is used.
  
  "claim 5..." etc.
  
  OK, so try and answer this next question as best you can (fill in missing details yourself if it will help your response.. I may have to add the details in myself later on if this is too vague):
  
  Question: how do we not break existing apps without violating the patents? (ie, avoid having to analyze, redesign, recode, recompile, etc, any application)
  
  Generally, so as not to violate the patent, we may have to change any of the reqs to a claim, for all claims.
  
  (Assuming claim 1 stays for now), can we avoid claim 2? 3? ....?
  
  Can we not violate having a bit type object that is used as foo is used, yet not have to change a single API signature yet change the API semantics but without affecting the intended behavior of any part of the application that has been coded to rely on the intended meaning of foo?
  
  Mathematically, it may be possible to prove that certain scenarios (if not this foo/bar case) cannot have alternative isomorphisms, but I am not in the mood to attept such a proof right this minute.
  
  I'll think about this some more.

• AlexH

  2009-01-12 15:48:50

  @RoyS: the EC case doesn't make Samba special; they have no special rights, indeed, they had to pay for their access to documentation like other licensees. Roy B. is precisely right.
  
  @Jose: I gave you a better example already; an API to play back mp3s. You can't implement it without butting up against patents.
  
  The problem is, you can't implement it in any language. Unless you're proposing that there are some features which are only relevant to .net, I don't see what statement that's making other than "some countries have software patents".

• Jose_X

  2009-01-12 16:05:32

  OK, Alex, I was working on a new post that took your mp3 assumption. Let me try and address your "patents are language/platform agnostic (or not)" question and any other loose ends as best I can.
  
  I'll be back.

• Jose_X

  2009-01-12 16:25:07

  I would be interested in the patent number of any SMB (or other protocol related) patent that Samba safely avoids.
  
  Given Samba works around such a patent, I would guess that absent some sort of mistake on Microsoft's part, that they tried to patent their implementation and not the precise functionality in the protocol itself.
  
  If you cover the protocol interactions, eg, a specific way to communicate file size over the network, by doing x, y, and z (to match the actual spec), then Samba would/should not be able to bypass that when they speak with Windows machines (absent MS carelessness or lack of aggressiveness). How else could Samba pass along that info or ask for it except to use the precise language expected by Windows clients (ie, if Samba doesn't use and limit itself to the precise protocol capabilities and language)? How could it avoid the patents if the protocol functionality (send file size over network) was patented exactly as implemented through the protocol conversation rules?
  
  Assuming such a simple example is patentable of course.
  
  Perhaps Microsoft didn't realize then how to patent something easy to invent and that would also avoid prior art [hint: this point is related to the language agnostic question]

• AlexH

  2009-01-12 16:30:29

  @Jose: as noted, the PFIF documentation contains an up-to-date list of all such patents. Here's one for free, and notice Samba implements equivalent functionality.
  
  I think you overestimate how easy it is to gain a patent on something which prevents anyone implementing a useful alternative.

• Jose_X

  2009-01-12 16:54:09

  >> I think you overestimate how easy it is to gain a patent on something which prevents anyone implementing a useful alternative.
  
  I'm having second thoughts about the mp3 example I was planning; however, perhaps the foo/bar *quandary* I did give not long ago is also very difficult to bypass.
  
  Have you tried it yet?
  
  The trick isn't to find a non-violating way to instantiate an object. Nor is it to find a way to have one object's value be used to define the semantics of another object. Ie, we aren't looking at a problem that is difficult like the mp3 patent claim. We can in fact find ways to do these things generally.
  
  The trick is to solve a very practical problem.
  
  How do we fix past violating applications that make certain calls in a way that violate a patent?
  
  This issue also has nothing to do with being language agnostic as I momentarily imagined it did after reading your other reply.
  
  The problem is with implementing functionality into your program in some patented way and then having to fix that violation without having to analyze, redesign, recode, etc.
  
  That is the trick.
  
  The language is irrelevant.
  
  The dotnet platform is relevant to the extent that the functionality patented matches the way the dotnet spec is defined.
  
  The foo/bar example outlined also would suggest that it might be relatively easy to come up with these API-patents.
  
  Do you now see or no? If no, then please find the problem in the alleged enigma presented. [Ie, answer the question near the end of this comment http://boycottnovell.com/2009/01/11/ms-maintaining-gap-vs-linux/#comment-58243 ]

• Jose_X

  2009-01-12 17:14:38

  >> The trick isn’t to find a non-violating way to instantiate an object. Nor is it to find a way to have one object’s value be used to define the semantics of another object. Ie, we aren’t looking at a problem that is difficult like the mp3 patent claim. We can in fact find ways to do these things generally.
  
  This paragraph came out badly. Just ignore it completely as well as the next line (since it otherwise sounds odd): "The trick is to solve a very practical problem."

• AlexH

  2009-01-12 17:18:07

  @Jose: I don't get what question you're asking, but you cannot patent the mechanics of calling conventions like that.

• Jose_X

  2009-01-12 18:09:09

  The impression I get from the intro to http://www.freepatentsonline.com/5261051.html is that Microsoft is describing a very precise series of non-required server requests that they possibly believe are necessary in order to do efficient file caching.
  
  To create an unavoidable patent scenario, they should have simply stuck to the required steps of the protocol. [Note this patent is quite old, so the less aggressive patenting approach demonstrated likely accurately reflects their older approach to patenting.]
  
  One guess why they weren't more aggressive in mimicking the protocol (assuming the steps they mentioned aren't required, as I suspect) is that the protocol would have already been designed with required handshakes and such that did not appear to be novel in any way. Another reason could be that they were not going for the jugular in the patent domain at that point in time (aware perhaps that it was an area where they were outmatched and possibly which would be useless anyway (software patents) and most likely not really valuable to their business).
  
  Note, this patent does cover numerous steps. It truly almost sounds like a protocol, but these precise steps don't sound like if they would be required exactly that way during any specific required interchange; thus, Samba found a different series of steps (not something that is always possible to discover or practical to implement) and also could avoid this patent because these steps were not necessary for any functionality of the protocol to be achievable. [That's my best guess.]

• AlexH

  2009-01-12 19:03:37

  @Jose: I think you're trying hard to make the facts fit your world view, but ultimately not succeeding.
  
  Speculating that there would be some way of ensuring a patent covers all possible methods of achieving a behaviour isn't based on actual evidence.

• Jose_X

  2009-01-12 21:27:11

  Woke up from a nap but will go back to sleep. I think I'll post a cleaner example some time after I get up.
  
  >> but you cannot patent the mechanics of calling conventions like that.
  
  Could you be more specific?
  
  >> I think you’re trying hard to make the facts fit your world view, but ultimately not succeeding.
  
  Can't tell what you mean here either.
  
  >> Speculating that there would be some way of ensuring a patent covers all possible methods of achieving a behaviour isn’t based on actual evidence.
  
  Also, can't here, either.
  
  You are extremely vague. I presented a lot of discussion you haven't addressed.
  
  Do you even know how Samba got around that patent? Do you want to address the discussion I provided (I haven't seen the code and just looked at the patent for the first time, yet I had a lot more to day on it than you did, who brought up the Samba case).
  
  Do you know why you can't work around the mp3 patents or were you just repeating what someone else said?
  
  I'm just asking because you don't seem willing to address what I ask using any sort of specificity.
  
  I clearly marked off the questions I wanted you to address, but I'll take some blame that the example I threw together could have been better.
  
  Well, I do have to get some zzzzs now.

• AlexH

  2009-01-12 21:52:14

  @Jose: you can't get around the MP3 patents because (as an example of one of them) it covers the encoding of audio by quantizing it in reference to the natural frequency response of the human ear. You can't avoid that physical process and still be MP3 compatible unless you forgo actual compression.
  
  Your other questions can't be addressed with specificity because they have none. You propose hypothetical scenarios to fit the answer you're looking for because you can't propose an actual one. It's impossible to argue against that because you can keep changing the hypotheticals in order to try to avoid any response; that's basically a goose chase.

• Shane Coyle

  2009-01-13 00:00:37

  I am thinking something real simple and to the point, like the below as a start - I will have to send to Microsoft as well as HP since both companies had submitted these patent grant letters...
  
  

  
  
  Dear Sir or Madam:
  
  I am in the process of planning a software project, and am requesting assistance with any potential licensing issues prior to commencement.
  
  Pursuant to the “Patents Statement” letter available on the ECMA web site (http://www.ecma-international.org/publications/files/ECMA-ST/Ecma PATENT/ECMA-334 & 335/2001ga-123 & 2002ga-003.pdf), I would like to request information regarding the process for obtaining any and all required licenses for creating an implementation of ECMA 334 (C# Language Specification) and ECMA 335 (Common Language Infrastructure) for the GNU/Linux Operating System, to be distributed under the GNU General Public License v2 or v3.
  
  

  
  
  Suggestions? Ideas?

• Roy Schestowitz

  2009-01-13 00:02:24

  That looks good to me.

• Jose_X

  2009-01-13 06:25:29

  Alex (and anyone else)..
  
  It was a frustrating day.
  
  Your description of why you can't avoid mp3 is very vague (not even a complete wave of the hand).
  
  The reason I barked (not to mention it was a frustrating day and I was quite sleepy at that point) is that I wanted to see what kind of rigor you would use to show various mp3 claims (in aggregate) would somehow cover all the implementation possibilities.
  
  You obvious have only waved a hand (if that). To show something like an allegation that patent claims x through y cover all ways something can be done (if even possible to show) would require at a minimum going over the actual text of all such claims, which itself at a minimum requires referencing all the patent claims you want to cover. [You obviously did none of this.]
  
  So you weren't rigorous by a few wide miles. So what is my point? That I was hoping for some slack in trying to analyze the sorts of things to which I was referring.
  
  I know I am asking for a lot. I understand that since I am offering hypotheticals, that absolutely means we could ultimately be dealing in an exercise in futility and have wasted much time and energy in the process.
  
  I am willing to do it to a point because it most definitely looks to me like there is a serious issue here.
  
  I surely have an obligation to do a more convincing job explaining if I expect any kind of more in depth response from anyone (except from the super-motivated).
  
  Anyway, I didn't intend to get unnecessarily critical.
  
  >> It’s impossible to argue against that because you can keep changing the hypotheticals in order to try to avoid any response;
  
  Right. I was basically asking for help in constructing a proof or a convincing argument. Obviously, whether ultimately correct or not, we'd have to shuffle things around if holes appear, at least until we prove it can or prove it can't be done.
  
  A lot of homework I was proposing, that's for sure.
  
  Despite that, I am surprised a bit you aren't a bit more responsive to what I am suggesting (well you have been responsive, but not in the positive way I'd hope).
  
  ..Well, no. If I were working on something (as I believe you are with mono), I too would not want to waste time showing how it might fail. Rather, I would put the burden of high proof to show that onto others.. at least if I believed in what I was doing.
  
  ..However, obviously, I would prefer not to work on something if I believed there was a dead end up ahead.
  
  ***
  
  I'm going to give this another shot.
  
  The next BN comment from me will present the major elements of a hypothetical (similar to the prior foo/bar example but more specific and to the point). We start with 2 patent claims that I hope will appear legit. Then we look at some API. Then I give some sample code for an app. Finally, I propose a question.
  
  The first patent claim attempts to narrow the scope of the further claims in order to avoid prior art [this would correspond to defining a dotregret system]. I don't actually claim anything ("..") but I could find something trivial to claim if that bothers anyone. The goal is to lay context for claim 2.
  
  The second patent claim is just a simple portion of this dotregret system that I want to patent (foo and bar).
  
  The API example is intended to show that claim 2 is violated (I go a bit overboard here with some details that aren't that important). I define a bunch of aux methods in the key class and then define foo and bar. Mostly, we just want to show that the foo-bar relationship falls under the second patent claim.
  
  The App 1 pseudocode should make sense. It just shows that we can build an app that really tries to exercise the capabilities of the API (within this limited context of course).
  
  I then ask essentially if we can fix the libraries (monolibo) so as to avoid having even to recompile dynamically linked apps.
  
  There are pseudo code descriptions. Hopefully, I wasn't too unclear with them. I wanted to flesh things out a little in a quasi-realistic way. I am not trying to create any tricks, so hopefully what something sounds like is just what it is. Skimming might be the best approach to take on a first pass.

• Jose_X

  2009-01-13 06:32:10

  The foo bar violations of Dotregret:
  
  :Patent Claim 1:
  
  -- A system has at least 34 values associated with it. -- The first represents how many processes were started by the system within the last hour. -- The second represents how many responsive hardware components have replied to a query from the system within the last hour. -- The third represents how many hardware components responded to the system within the initialization period. -- The fourth ... .. -- The thirty-fourth ....
  
  :Patent Claim 2:
  
  For the system described by claim 1... Every "ordinary" object in our system has a value associated with it (bar) that defines the meaning of a second value also associated with it (foo). The second value can possibly define the value of some particular state of the system. The second value can also possibly be set to set some particular state of the system. In all cases, the first value controls which state is associated with the second value.
  
  :API: System State Variables Description:
  
  class SystemMeasure X1; //This represents the total number of instantiations of Process objects within the last hour. class SystemMeasure X2; //This represents how many SuccessfulQuery objects were returned by all getHardwareQuery() calls within the last hour. class SystemMeasure X3; //This represents how many SuccessfulQuery objects were returned by all getHardwareQuery() calls within the initialization period. class SystemMeasure X4; //... .. class SystemMeasure X34; //...
  
  :API: foo and bar Descriptions:
  
  class CommonObject.. TrueOrFalseType isValidAddress(StateSelector b); //..if b is bar, then returns true at all times. TrueOrFalseType isValidStateValue(StateValue f); //..if f is foo, then returns true at all times. TrueOrFalseType isStateValueSettable(StateSelector b); //..if b is bar, then returns true only if the corresponding foo can be safely set. VoidReturn setFoo(); //..should always be used to set foo and can always be called safely. TrueOrFalseType wasFooChanged(); //..is true if and only if foo was changed the last time setFoo as called. TypeOfStateValue getStateValueType(StateSelector b, StateValue f); //..if f is foo and b is bar, then the return object is uniquely defined by b. StateSelector bar; //..determines which subclass of State foo describes. StateValue foo; //..is the value of the State subclass that corresponds to bar. ..
  
  :Sample legal (AdvancedPseudo) code in App 1:
  
  Begin: get all common objects in system; { for each of them, for each bar value, set foo to the corresponding value in our AA table if foo is settable; print the value of foo } End.
  
  :Question:
  
  Once we find out about the above patent and its alleged infringement by our App 1 that was coded with the above API, can we remove this patent violation without touching App 1?
  
  [An acceptable solution might be: "Refresh our system (libs) and restart the system (and App 1) once the system (libs) are good. Make the system good by ...."]
  
  If you (Alex/anyone else) have any trouble understanding or have any questions just ask.
  
  I did not try to be tricky. I included some API info but not necessarily because I thought it was needed. Hope you understand the AdvancedPseudo language.

• Jose_X

  2009-01-13 06:36:51

  Shane, I didn't attempt to verify the details of your letter, but the substance sounds fine.
  
  :-)

• AlexH

  2009-01-13 08:12:34

  @Jose: I've said before, it's not possible to reply essay-to-essay in these boxes.
  
  MP3: actually, I was extremely precise. One patent covers the quantisation of audio in different frequency bands, and it applies greater quantisation in those frequencies which humans cannot hear as well, reducing the psychological impact of the compression.
  
  That single patent is sufficient for this conversation, because you cannot recover the audio signal in any other (known) process.
  
  The US patent is 5579430, claim 1 is sufficient. Knock yourself out.
  
  The reason I'm not interested in working on your hypotheticals is because you're trying to find a question which gives the answer you're looking for. I've already pointed out two absolute attributes that such a question would need to have:
  
  a. it must be a system or feature which is only of relevance to .net, and no other system; b. it must be possible to patent in an unavoidable fashion.
  
  All your points about linkers, libraries and calling conventions are entirely irrelevant, because the calling convention is set out in the standard. If there is such a patent, it's nothing to do with API, and that's a red herring.

• Jose_X

  2009-01-13 08:43:56

  Putting aside the issues of patentability of software...
  
  Some useful key points:
  
  -- Portions or all of dotnet could be captured across patent claims. This is true for Java or for any other invention.
  
  -- Such patent claims would not differentiate across languages (unless, and except to the extent, some concept of "language" was a key part of such an invention).
  
  -- A set of patent claims around a dotnet invention would not affect java. The dotnet invention is significantly different from java. Any such patent claims would have to be specific enough to identify dotnet uniquely. BUT..
  
  -- You can try to patent concepts (inventions) that could be used in dotnet AND in java and.... That is not what we have here, however (eg, above foo bar examples). Here we are patenting around the something like a dotregret invention. Again, languages has nothing to do with this. The invention is a binary product running on some computer. How you got that binary product is not part of this particular invention. Repeat, languages has nothing to do with this...
  
  -- In fact, an API can be abstracted to apply to many platforms/languages. In our case of foo bar, we are looking at an API for dotregret, expressed in PseudoJava, and which has an equivalent version (not shown) in the AdvancedPseudo language that was used to build App 1.
  
  -- mp3 patent claims, for example, may appear to be comprehensive and cover all ways to interact with mp3s, but this concept has nothing to do with dotregret. Among the many patent claims around dotregret we could write, we only showed the foo bar claim. [Update, I'll take a look at the link Alex provided recently]
  
  -- Rather, what is at stake is something very simply: if we use the API in question, wrt foo bar, we will be violating a patent claim. That's it!
  
  -- So once we write applications that violate that patent claim, how do we clean up?
  
  -- The trick we fell for was that we accepted the short-cut of using the dotregret foo bar solution to write our app because we didn't know dotregret foo bar usage within our application was captured in a patent claim.
  
  -- Specifically, our application came out to be a "dotregret managed application" (this definition was not shown). When our application runs, the "system" that is our application maintains 34 key variables as described in patent claim #1. This is done by the runtime linked to our application. Additionally, we instantiated (ie, created) CommonObject in our app (implicitly done by the AdvancedPseudo language compiler). These objects all have foo and bar set to follow certain restrictions (done implicitly by our AdvancedPseudo language compiler and maintained by the system routines). We could code all of this by hand (eg, assembler) but the point is that our app relied upon and leveraged the foo bar relationship. No matter what build system we would use, we'd ultimately produce the foo bar effect (language is not issue because the final binary invention, however produced, behaves as described with patent claim 2). We, thus, violated patent claim 2 because objects in our system with a particular attribute had this relationship maintained.

• AlexH

  2009-01-13 08:48:46

  @Jose: here's your main mistake:
  
  

  You can try to patent concepts (inventions) that could be used in dotnet AND in java and…. That is not what we have here, however (eg, above foo bar examples). Here we are patenting around the something like a dotregret invention. Again, languages has nothing to do with this. The invention is a binary product running on some computer. How you got that binary product is not part of this particular invention. Repeat, languages has nothing to do with this…

  
  
  You're trying to claim - simultaneously - that the language and implementation isn't anything to do with the invention, but that also it is somehow limited to a particular implementation.
  
  You can't have it both ways.

• Jose_X

  2009-01-13 08:57:36

  >> MP3: actually, I was extremely precise.
  
  Alex, I hope you don't confuse precision with rigor. There is a reason the patent you only now specified is as long as it is. Cut it down to your few sentence summary and you don't have a patent that allegedly can't be bypassed. Plus, an analysis/proof of this allegation would mean making the explanation longer than the patent itself.
  
  So don't confuse a proof and rigor with being "precise".
  
  In short, I have no reason to believe you allegation based on anything you provided except to the extent I am willing to read that patent and conduct a thorough analysis for myself (but thanks for the link!!). And I (or anyone else) may not ever be able to prove what you alleged.
  
  In any case, this mp3 is a red herring. The only way you appear to know how to talk is with actual patent numbers, so I may start looking at Microsoft patents such at that other one mentioned on BN not long ago.
  
  I'll point to that and make a claim similar to what you just claimed about the mp3 patents and call it a morning.
  
  >> One patent covers the quantisation of audio in different frequency bands, and it applies greater quantisation in those frequencies which humans cannot hear as well, reducing the psychological impact of the compression. >> That single patent is sufficient for this conversation, because you cannot recover the audio signal in any other (known) process.
  
  You don't even mention what this has to do with mp3.
  
  Based on what you just explained, you don't cover the case where sound is recorded as a different set of measurements (obviously, possibly losing some information in comparison to any other capture method), followed by a translation (including an approximate and partly inaccurate translation), followed by an encoding unto something else besides mp3 format (I don't know the details of mp3, but that likely doesn't make this last sentence incorrect).
  
  I'll finish replying later since I have to run.

• Jose_X

  2009-01-13 08:59:06

  >> You’re trying to claim - simultaneously - that the language and implementation isn’t anything to do with the invention, but that also it is somehow limited to a particular implementation.
  
  I don't have time to reply now/finish up, but I didn't understand this. Can you clarify?

• AlexH

  2009-01-13 09:34:45

  @Jose: if you want to start arguing that the MP3 patent I pointed to can be bypassed, I'd love to see your analysis. Perhaps you could forward it on to Fedora and Debian so that we could include some of the MP3 free software which is thus far excluded.
  
  That you don't understand my comments in relation to MP3 make me think you don't understand the issue at hand:
  
  - the patent describes a process of encoded audio according to physical (frequency domain) rules; - it doesn't matter how you do that encoding: it doesn't even need to be in software; - MP3 data is effectively quantized, huffman-encoded frequency-domain audio data; - that type of data is the subject of the patent; - you cannot recreate the source audio wave without reversing the method.
  
  The reason this is relevant is because this is the type of patent that you propose is hidden, somehow, in .net. Further, you claim that there is such a patent which is also of no interest to any other language/platform and thus is effectively restricted to .net.
  
  Both those claims are bold and unbelievable, frankly.

• Jose_X

  2009-01-13 13:04:32

  >> if you want to start arguing that the MP3 patent I pointed to can be bypassed
  
  Was this a rhetorical question?
  
  No, clearly I am not alleging mp3 can or can't be bypassed (read what I said). I won't attempt to find a counter-example or construct any sort of proof one way or the other.
  
  If you think I said something suggesting otherwise, please point it out so I can clarify or fix the mistake.
  
  >> That you don’t understand my comments in relation to MP3 make me think you don’t understand the issue at hand:
  
  Well, your list describing the patent seems like that is what the patent will attempt to describe (I gather this mostly from the Abstract). [The last item, about impossibility of reversing the method, is the only one that I'm not sure about from the Abstract. I'm not even sure what you mean with "reversing," but, anyway, these details are not important for this conversation.]
  
  >> The reason this is relevant is because this is the type of patent that you propose is hidden, somehow, in .net.
  
  I have no idea what led you to this conclusion.
  
  OK, let me make something clear. I suspect it's somewhat straightforward (not to imply it's easy .. at least not until you have practice) to patent around an API so that to use the API would imply a violation of the patent. In an effort to make this clearer, and I'm not sure why you don't agree with that prior statement, I wanted to demonstrate the effect using a small contrived scenario: the foo bar biz.
  
  So what do you mean by this "hidden" business? I'm in no way suggesting anything is hidden, nor do I think I'm implying such a thing. Feel free to elaborate. Quote me liberally if you need to.
  
  [**I'm going to post another reply after this one since I have some new ideas (based on this latest exchange between us) of where there might be some misunderstanding.]
  
  >> Further, you claim that there is such a patent which is also of no interest to any other language/platform and thus is effectively restricted to .net.
  
  Well, the same sort of patent can be done so as to apply to any other limited set of platforms. I'm not implying dotnet is special in any way. [It's "special" only to Microsoft because of their relationship to it.] What I am saying is that a specific set of claims can definitely be narrowed down so as to apply only to platforms with a specific set of attributes (eg, the patent writer might want to narrow down to dotnet systems).
  
  Now, why would someone "pick" on dotnet.. or why would anyone want to limit areas where their patent might apply?
  
  I wasn't suggesting that anyone wants to build patents that are limited in scope. I have said repeatedly that by limiting the scope, you help avoid prior art. And if you avoid prior art in this way, you also have more flexibility over what you can get away with "inventing".
  
  OK, let me get on to a new reply to hit this from another angle. [I think] I'll compare to the mp3 thing you keep bringing up.

• AlexH

  2009-01-13 14:01:14

  @Jose: limiting scope to avoid prior art doesn't work on product boundaries. You can't say "Someone else did this in Java, but I patent the .net version" - it simply doesn't work that way.
  
  The only way you can narrow a patent is to narrow the claims. Which leaves you still in the position of claiming that there is some way of narrowing claims such that they still apply to .net but not to some other system.

• Jose_X

  2009-01-13 14:54:59

  I want to discuss limited scope. I'll look at the patent (#5579430) during the discussion. At the end, I draw a parallel to the foo bar fake patent ( http://boycottnovell.com/2009/01/11/ms-maintaining-gap-vs-linux/#comment-58310 ). Hopefully, from this parallel and the primary discussion, we can see what I mean by "limited scope" and make some sense of the "dotregret limited scope" I am talking about.
  
  [From #5579430] >> 2. A coding process according to claim 1, wherein a Huffman code is utilized as said encoder.
  
  Claim 1 creates context. It limits the scope of claim 2.
  
  Claim 1 could definitely be more specific. The patent writer could have added a restriction to "software implementations" or added a restriction that "the steps of claim 1 must be done in a given order." Neither of these two hypothetical additional restrictions would be desirable if keeping it general would get the job done. [ref claim 1http://www.freepatentsonline.com/5579430.html since I didn't quote it]
  
  Are there cases where we want to add restrictions? Sure.
  
  Claim 1 is a set of restrictions on Claim 2. What if Claim 1 didn't exist? What if the writer of #5579430 had decided to patent something much more general?
  
  Many people have done things where Huffman coding was used for encoding (that's what claim 2 says roughly if we ignore claim 1). Thus Claim 2 would have prior art and fail.
  
  Huffman himself could have taken out a patent on something along the lines of vanilla Claim 2 (of #5579430). Maybe that invention would have claimed little more than "sound is recorded and stored using Huffman coding."
  
  While that patent lasted, #5579430 could not have been taken out nor any such invention implemented.
  
  Once the Huffman patent expired, no one could take out another simple Huffman patent, but you could take out #5579430 which is a subset of the Huffman invention: it has much more limited scope (eg, Claim 1 of #5579430 limits the scope of Claim 2 of #5579430).
  
  So an approximate version of #5579430 Claim 2 (without the claim 1 clause but limited to recording sound) could not have been a patented at any time after Huffman developed the coding (except way back then and by Huffman.. using approx US patent law). But a patent (#5579430) was possible in 1996 when Claim 2 was combined with Claim 1.
  
  OK, now a parallel to the foo bar patent ( http://boycottnovell.com/2009/01/11/ms-maintaining-gap-vs-linux/#comment-58310 ).
  
  Claim 2 of foo bar, minus the claim 1 context, is something where prior art exists. Today, you likely can't avoid prior art on just that. There likely have already been various such systems built using Java or plain C or any of various other tools.
  
  .. however, we might be able to get a patent if we restrict the context of that claim 2 by claim 1. Why? Because likely no one has implemented claim 2 AND claim1 in any invention.
  
  In this way, we can reuse old inventions (a) if any patents on them have run out and (b) if we narrow the scope further than existing prior art.
  
  This suggests a strategy. We can patent something that is not that amazing by adding sufficient restrictions. All we have to assure is that the restrictions really do limit the invention so that prior art is unlikely (foo bar claim 1 mentions 34 system variables that are maintained at all times), and make sure that the ordinary invention (claim 2) falls under no outstanding patents (easy to fulfill if the invention is quite ordinary and was likely invented decades ago).

• AlexH

  2009-01-13 15:08:44

  @Jose: unfortunately, that's not how patents work at all.
  
  It's not a process of narrowing to a specific claim which makes something patentable; it's the presence of innovation. You're right that the entirety of a patent does not need to "advance the state of the art" - you can re-use prior art - but that's only relevant to the actual key innovation.
  
  In the case of Huffman coding, the MP3 patent makes mention of it because it is the ideal way of encoding the quantized data. And you're right in that Claim 2 is a dependent claim. But Claim 1 doesn't "restrict" Claim 2; rather, Claim 2 extends / builds on Claim 1.
  
  Because it's a dependent claim, you can't just analyse it separately and say "oh, it's prior art". Go look at the case law; e.g. Diamond v. Diehr, where all components were prior art.

• Roy Schestowitz

  2009-01-13 15:16:05

  Read this new post from Asay and this from Slated. All 'inventions' are assemblage of prior art. This is why intellectual monopolies are so dangerous to permit.

• AlexH

  2009-01-13 15:29:34

  @Roy: while I agree with the theory, I think it's too simplistic a point of view.
  
  Certainly, there are some things which are emphatically not prior art, unless you define that to mean things outside the realm of human knowledge.
  
  Also, I'm not sure there's anything fundamentally wrong with assembling prior art: we all knew about air vortexes and centripetal force; but no-one seemed to have think about putting such concepts inside a vacuum cleaner before Dyson came along.
  
  So it's not quite as cut-and-dried as saying all inventions are basically prior art.

• Roy Schestowitz

  2009-01-13 15:33:35

  They are combinations of it. The same goes for copyrighted work, be it music or poetry. But people are indoctrinated so as to take credit for all joinings of knowledge that they use (and most of that knowledge is free of restrictions, inc. cost, etc).

• Jose_X

  2009-01-13 16:19:47

  I have a long post coming up when I proof read it, but let me address your new comment.
  
  >> It’s not a process of narrowing to a specific claim which makes something patentable; it’s the presence of innovation.
  
  Innovation is something new. Any new combination is new. It may not be marketable, make you much money, or leave the drawing board, but it will likely get a patent in the US of A.
  
  Do I think it's fair? Nope, not generally. Certainly not for software IMO, but it's how the system works best I can tell.
  
  I do think there are contradictions in motivations for allowing such laws. I posted such on groklaw. Roy just pointed to a link as well. "Countless" others have expressed these views before no doubt. However...
  
  Into the forseeable future, "it's not fair" won't solve your problems or spare you hassles and money when the trolls come a-knock'n.
  
  >> but that’s only relevant to the actual key innovation.
  
  Wave the hand and chant "innovation" but you're not going to slow down many people.
  
  Remember any new way of doing something is innovation. A new combination is a new way.
  
  Microsoft won't have problems getting a lot of patents.
  
  Plus, what is complex to the vast majority of lay people and even to some or many that practice, will still be obvious to a great many.. likely those that are working on FOSS seriously.
  
  Nope. You have nothing here. The bar is too low, especially in the US.
  
  >> But Claim 1 doesn’t “restrict” Claim 2; rather, Claim 2 extends / builds on Claim 1.
  
  You are incorrect to say Claim 1 doesn't restrict Claim 2.
  
  Claim 1 definitely restricts Claim 2 when you adjust the wording (to make it a complete sentence in a natural way). It's also true that Claim 2 extends Claim 1. I argue that use of the language either.
  
  Again, Claim 2 of #5579430 (without claim 1) fails because of prior art. It succeeds when the scope is restricted to Claim 1.
  
  As a test, replace Claim 1 with a nice big void. What do you have left? Exactly.
  
  Look, I'll do it for you:
  
  "A coding process [blah blah void void], wherein a Huffman code is utilized as said encoder. "
  
  >> Because it’s a dependent claim, you can’t just analyse it separately and say “oh, it’s prior art”.
  
  Again, we'd have to fix the English wording.
  
  I completely understand that #5579430 was not written with Claim 2 intended to be read in a simple way without Claim 1.
  
  But the fact remains that when you clean up the wording, Claim 2 is general and is restricted to the Claim 1 context.
  
  Why are you fighting this Alex?
  
  >> Go look at the case law; e.g. Diamond v. Diehr, where all components were prior art.
  
  Yeah, and go look at the link Roy mentioned.
  
  I guess we proved that all patents are void.
  
  Yeah. I'll take that any day of the week over anything else I was trying to accomplish in this thread.
  
  Hip hip....! Yahoooooo!
  
  All patents are void!
  
  Seriously, though, the bar is too low. A major part of the "innovation" is the unique display of the combination. Anyone can do that.. just make it "engineerical" in nature.
  
  After all, how many people have not made it past elementary trigonometry? To an awful lot of people, many "engineerical" things, especially when you mix them up in combinations and wave your hand hysterically..
  
  .. are innovations.
  
  Bar too low. No prob for Microsoft here. Next.

• Jose_X

  2009-01-13 16:45:10

  Picking off where left here: http://boycottnovell.com/2009/01/11/ms-maintaining-gap-vs-linux/#comment-58335 ...
  
  Using the strategy mentioned, we find that company M can produce many patent claims that might otherwise have prior art, but avoid prior art if they can add sufficient restrictions. The restrictions need not be brilliant. If we AND enough (simple) requirements we can end up with a scope that has never been implemented before.
  
  Now, what if company M developed an API that by definition fell under their new patent claims? [Remember, these patent claims avoid prior art because enough unique context was added.]
  
  Note, what company M is not doing. They aren't trying to find an alternate way to implement a set functionality that they need but is patented. They don't have the mp3 bypass issue. Rather, they are trying to enshrine an existing patent (that they easily built) into an API. They are trying to build an API so that using components of the API will satisfy all requirements of one or more patent claims (eg, that they own). [The customer pov mp3 bypass question is dealt with below.]
  
  Is it difficult to develop an API that guarantees you will violate a given patent? It may be tricky (need to cross t's dot i's), but I think it's straightforward once you have done it a few times. [I'll expand a bit more on this in a following comment.]
  
  The result would be that anyone using that API will violate some patent claims. But now, can't the user avoid violations? Can the user do the mp3 bypass?
  
  One way is not to use the API.. oops, too late.
  
  Another is.. well, I'll let the reader look for that answer if they think it exists [see question at bottom of http://boycottnovell.com/2009/01/11/ms-maintaining-gap-vs-linux/#comment-58310 ]
  
  If the reader thinks that an ordinary API matched to violate an ordinary patent (no mp3 cleverness here anywhere) can be fixed AFTER the API has been used, then I welcome responses. [Make sure to read the last 2 large paragraphs near the bottom of this comment.]
  
  Keep this in mind, all requirements of the patent claim are violated by merely using the API (or a subset of it). The application has the violating conditions baked right into it when they used the API. The programming language doesn't matter. In other words, it doesn't matter how we bake the violating functionality into the app.
  
  Keep this in mind as well, the patent was made up of ordinary items (any not particularly inventive but the total combination would be unique). These ordinary requirements came from a precise list (the patent claims) as designed by the patent author. This unique (combination) functionality goodness would be baked right into all the apps that use of the API.
  
  OK, so reader is free to ponder on how to escape this in the general case (assuming the patent does not have flaws and does offer a unique combo of functionalities that an application cannot live without).
  
  So assuming we are screwed (assuming we don't have an easy answer to prior sticky issue), if we build many applications using these API scattered throughout, we might be in for a lot of redesigning and recoding.
  
  A key point is to note that the APIs are not patented literally. However, the API usage builds into the application certain functionality as per the API's definition if the implementation was correct. We assume such correctness when we use the API. We want correct applications, after all.
  
  In the future we can re-implement the API so that it doesn't add that same functionality (that violates the patent claims) into our apps, but our apps would presumably fail (when we relink) since we designed them with the original API semantics. After all, we want apps to do what we planned on them to do when we were coding them up with the API. To switch the API functionality (except in some specific lucky cases perhaps), in general, will change the application, doubtfully for the better. Remember that changing the libraries would impact ALL such applications. While one app may not suffer consequences, can we guarantee that for all of them? Can we guarantee that for those that made liberal use of the API?
  
  The only real solution is to redesign and recode each app.
  
  Had we known about the patent claims, we might have made some trivial changes so as to have fallen out of the scope of the patent claims; however, since we didn't anticipate this, in general, we likely relied on enough of these items in the claims that limited the scope so that removing any of them or even changing them might cause our application to fail. This isn't always the case, eg, we can replace one type of memory manager with a different type in some cases, but if we relied on the details of something that got patented, we'd be in for redesign and recode and more. That is, if we cannot afford to drop any of the "context" of the patent claims being violated without breaking the app, we have no choice but to redesign, etc.
  
  I'll repeat: if we cannot afford to drop any of the "context" of the patent claims being violated without breaking the app, we have no choice but to redesign, etc.
  
  One final tiny note: mono libs are much more extensive than mp3 libs. Damage by mono because of patent problems down the road (when many mono apps might exist) will be much more extensive than damage of mp3 lib patent problems.
  
  OK another note [this and next paragraph are the biggies]: the mp3 case had a single point of abstraction, "encode mp3". Here, however, there is no (set of) abstraction point that exists across all apps that if we re-implement that abstraction ("encode") in a non-violating way would fix the problem for all apps. There is no unique f() or unique set of f()'s that are to be re-implemented because the things that need to be re-implemented intermix in ways unique to each application. Applications each create different abstraction points (each mix) that would need to be re-implemented to avoid the patent. In other words, applications need to each be redesigned and recoded. There is no library redesign/recode short-cut.
  
  Re-clarify: Re-implementing the individual API is useless. When we re-implement the encode mp3 function, we have full leeway because the semantics that must be preserved is the "global" semantics of that function and not of the semantics of the sub-portions used in the implementation of that function; however, in the case mentioned here, we already know that we must preserve individual semantics of each part of the API, as this is the only way to ensure that *all* possible combinational uses of that API have the same effect (ie, don't break *any* app). But, if we thus preserve all individual API subcomponent semantics so that no apps break, then we will necessarily be violating the patents.. by definition.. by creation.. by design.
  
  Hope this makes sense. I may try and re-explain it later in some other way or improve on the above.
  
  Oh, let me not forget. Now I want to add some more on the process of creating such an API to guarantee a patent is violated. I haven't decided what I will write, but I basically already took the trouble to give an example (hopefully, the example has no bugs). Can people find a way around this: http://boycottnovell.com/2009/01/11/ms-maintaining-gap-vs-linux/#comment-58310 ?

• AlexH

  2009-01-13 16:54:20

  @Jose: first, I keep saying, this isn't a forum where you can be nonconcise, it doesn't work.
  
  Your points about claim 2: I suggest you go to any online patent writing resource and look up the technical term "dependent claim". Your whole theory on what that is saying is totally wrong, and your theory on "getting patents by being sufficiently narrow" is just a nonsense. Not only is it a nonsense, you're actually arguing against yourself that such a narrow claim could cover any implementation of a given API.
  
  And as I keep pointing out to you again and again and again and again, you cannot narrow claims to a specific technology. It just simply doesn't work like that.

• AlexH

  2009-01-13 17:02:05

  @Jose: also, your example is extremely unimpressive. You've basically written out an API and said "what if I patented that?", except you can't patent it, because it's an API. It doesn't tell you how to do anything.
  
  And because it's an API, there's a easy way around it anyway: you pre-interpret an app using it to rewrite the API to something you already have. That's how IKVM works (Java API translated to .net).

• Jose_X

  2009-01-13 17:44:18

  >> first, I keep saying, this isn’t a forum where you can be nonconcise, it doesn’t work.
  
  Alex, you are copping out. You need to be specific to what parts of what I said you think have mistakes.
  
  I can see how some things I wrote would need to be reworded, but you have to be specific because I don't know how you read any given part.
  
  >> I suggest you go to any online patent writing resource and look up the technical term “dependent claim”.
  
  From wikipedia http://en.wikipedia.org/wiki/Claim_(patent)
  
  >> Each dependent claim is, by law, more narrow than the independent claim upon which it depends. Accordingly, it might appear that there would be little purpose to the dependent claim. In reality, however, there are at least three very important advantages to the patent applicant in submitting and obtaining a full string of dependent claims:
  
  I won't quote the rest, but read over those three items. You will see references to "scope" "broad" "narrow" "limitation" etc.
  
  I'll quote one more line from there: "If the independent claim is determined to be invalid, however, a dependent claim may nevertheless survive, and may still be broad enough to bar competitors from valuable commercial territory."
  
  Really, Alex, I can't tell what is bothering so much and which parts you think are great?
  
  Since I have been on BN, I have generally felt that much more sure of myself after you have said "you are wrong.. go look it up."
  
  Thanks for the motivation to go and look things up so I can feel more sure, but I still want to be able to help *you* understand me if that is the problem.
  
  >> your theory on “getting patents by being sufficiently narrow” is just a nonsense.
  
  From prior comments, I can't help but think you have no idea what my "theory on" ... is.
  
  Do you want to recap this theory of mine that you are mentioning here?
  
  Taking one brief piece of text out of context is ridiculous. What am I to make of it?
  
  Keep the context Alex.
  
  Or at least tell me in your own words what you think I am saying.
  
  I'd also suggest you read the wikipedia article or maybe report back what you think is wrong with it. [Only need to read the part I highlighted. It's not too long.]
  
  >> Not only is it a nonsense, you’re actually arguing against yourself that such a narrow claim could cover any implementation of a given API.
  
  I have no idea where you think I am arguing against myself.
  
  Please, Alex, feel free to quote. If you can't quote, for all (any?) of these cases, I think you are just not understanding me.
  
  Or don't quote, but summarize what you think I am saying.
  
  Anyway, I have no idea what you meant with the remark I just quoted.
  
  >> And as I keep pointing out to you again and again and again and again, you cannot narrow claims to a specific technology.
  
  Surely you are not understanding me. I have said it *doesn't* matter *how* you implement the invention, just as long as you do implement it.
  
  Do you follow?
  
  What I added is that if the invention requires x y z conditions..
  
  Follow?
  
  ..and a particular platform automatically supplies those conditions..
  
  Follow still? No? Maybe?
  
  ..then using that platform/api, such that those requirements would thus be added to your application, *will* mean that the application will be violating the patent .. duh .. because it will fulfill all the requirements of the patent claim... duh.. why? because the platform adds those in.. duh.. it's in the API definitions. You wouldn't use those API if you didn't want those things baked into your application. Duh
  
  Did you make sense of that last part?
  
  Maybe you disagree on something, but you need to be more specific.
  
  You are cheating. My 5 year old niece can do what you are doing.
  
  She can simply say, "Jose, I'll tell you again for the 20th time, you are wrong, I am right, so there."
  
  And I would not believe a word because she failed to find any specific problems (or many as the case may be) with what I was saying.. so that her claims would be validated.
  
  So Alex, you can say all day that I am wrong in all of these things, but until you prove you allegations, until you validate them, you have shown zero.
  
  In particular, when you have quoted in the past, numerous times it has turned out that you were wrong or at least it became clear that perhaps you simply did not understanding me.
  
  But if I am wrong.. OK. show it. Validate your claims.. or you have shown zero.
  
  It's your choice. I am providing arguments. You aren't providing counter-arguments to what I am saying.. certainly not in the vast majority of the cases.
  
  And if you do find the mistakes in what I am saying, *I* will be able to *learn* and fix them. Think of me if not of yourself. I don't pretend that I don't make mistakes.

• AlexH

  2009-01-13 18:08:21

  @Jose: it's impossible to pick through everything you say piece by piece, because you write pages and pages, and necessarily a response would be even longer. What I'm pointing out to you are the fundamental assumptions you're making that are incorrect; the rest of it doesn't hang together because the starting point is wrong.
  
  So, your theory of narrow claims being patentable you stated earlier:
  
  

  Using the strategy mentioned, we find that company M can produce many patent claims that might otherwise have prior art, but avoid prior art if they can add sufficient restrictions.

  
  
  That strategy cannot work. There has to be something "new" in there, and if it's combined with prior art it's only that combination which is subject.
  
  Also, I don't really advise going to Wikipedia, but even that source is showing you that your theory of claims is also wrong. To recap, you said (of the MP3 patent):
  
  

  Claim 1 is a set of restrictions on Claim 2.

  
  
  It just isn't. It doesn't even make logical sense to put the restrictions before the things you're restricting. Claim 2 is a dependent claim on the first, and defines a more specific embodiment.
  
  

  What I added is that if the invention requires x y z conditions.. ..and a particular platform automatically supplies those conditions..

  
  
  You're still trying to define patent scope along product lines. I keep telling you that's not how it works. It's like saying that if I write a book in English, I don't have copyright over the French version.
  
  As I've said, multiple times now, for your theory of a .net-only patent to work, you have to show two things:
  
  a. that there is something featureful that we would like to have (like being able to play back an MP3 or something) b. that it only makes sense to have that feature in .net
  
  Absent *both* those conditions, your theory simply doesn't work, because without b. any patent you propose is simply a software patent on something we'd like to be able to do, like play back an MP3.

• Jose_X

  2009-01-13 18:15:22

  >> You’ve basically written out an API and said “what if I patented that?”, except you can’t patent it, because it’s an API. It doesn’t tell you how to do anything.
  
  The patent claims are very light. I need to add more meat. This re-write stemmed from the earlier examples. I do need to add more meat. Finally, you notice!
  
  Though I wrote up this fake patent section a while ago, in the explanations that followed, I left off where I want to get into details of how to go about coming up with patent claims and then "turning them into" an API.
  
  OK, so you are correct. That simplified patent was too simple. I'll revisit where I originally mentioned foo bar and see what else I might want to do.
  
  Yes, the patent claims will describe how to do something (or that is what I was looking at anyway).
  
  Thank you. I'll be back.
  
  [ API tell you how to do things (eg, methods do). foo bar are state values.. I stopped too short. Probably got distracted ;-) . There shouldn't be a problem in fixing things up, though.]
  
  >> And because it’s an API, there’s a easy way around it anyway: you pre-interpret an app using it to rewrite the API to something you already have.
  
  Changing dotnet to java doesn't solve the problem because it's not "dotnet" that is the problem. The problem is in the features included into the app through the use of dotnet. Any conversion would need to preserve semantics of the API pieces. You'd effectively re-implement those features in java post the conversion. If you change these features, then you break the app.
  
  OK. You are right that the foo bar write-up needs more work. After/As I do that, maybe things will be clearer (to you and as well to me). Thanks again.

• Roy Schestowitz

  2009-01-13 18:25:45

  You’d effectively re-implement those features in java post the conversion. If you change these features, then you break the app.

  
  
  That's an important point. Since even pro-Mono people like Dan O'Brian say that Winform may be a patent risk, this shows why Mono is a trap.

• AlexH

  2009-01-13 18:41:52

  @Jose:
  
  

  Changing dotnet to java doesn’t solve the problem because it’s not “dotnet” that is the problem. The problem is in the features included into the app through the use of dotnet. Any conversion would need to preserve semantics of the API pieces.

  
  
  The semantics don't matter a jot. Java's object semantics are different to .net's, yet Java runs on .net. So long as you know what they are coming in and what they should be going out, you're fine.
  
  If there is this hypothetical "API you cannot implement without infringing a patent", then you can't have it on Java (or anywhere else) either and you're screwed.

• Jose_X

  2009-01-13 19:06:08

  >> That strategy cannot work. There has to be something “new” in there, and if it’s combined with prior art it’s only that combination which is subject.
  
  I don't think you understand the "strategy" yet.
  
  The combination is a new thing (you agree), and that is what I am saying will always be there and create problems, no matter what. [there may be other new things, but the combination is enough to create problems]
  
  >> Also, I don’t really advise going to Wikipedia
  
  I did say that if you think there is something wrong on wikipedia and that affects your argument, state it.
  
  >> > Claim 1 is a set of restrictions on Claim 2. >> It just isn’t. It doesn’t even make logical sense to put the restrictions before the things you’re restricting. Claim 2 is a dependent claim on the first, and defines a more specific embodiment.
  
  This is an area that needs clarification (though I'd hope you pick up the intention from context.. but I understand we need precision here where possible, and I'm glad you are pointing things out).
  
  A more accurate statement (not necessarily without problems) would be:
  
  "Claim 1 has the effect of providing restrictions in scope to Claim 2."
  
  Also, note that I did quote the following from wikipedia:
  
  >> If the independent claim is determined to be invalid, however, a dependent claim may nevertheless survive, and may still be broad enough to bar competitors from valuable commercial territory.
  
  Anyway, this is a wording issue. Since I am not using formal jargon in a lot of places, I am bound to invent my own short-cuts and these may not make sense to other people (especially if they are accustomed to dealing with patents).
  
  I apologize for grief that may be inflicted through the use of these short-cuts (not sure what alternative I have if I want to communicate in real-time and this year).
  
  Fix as we go.
  
  >> > What I added is that if the invention requires x y z conditions.. ..and a particular platform automatically supplies those conditions.. >> You’re still trying to define patent scope along product lines.
  
  Not at all. If you use a set of Java API that match the effects of the dotnet ones, you'd also be in trouble. So this is not along product lines or technology lines. [I need to work on my language/jargon, I know.]
  
  To be more clear. You don't need to clone all of dotnet. Linking and making a particular single method call may in fact violate some claim because of a number of items that would thus be baked into the app. So you could violate in Java if you somehow baked the same things in.
  
  I keep restricting the example to something specific like dotnet for the only reason that, by doing this (by effectively limiting scope), the patent writer that is also creating that API has a high(er) probability of avoiding prior art.
  
  If Microsoft limits to dotnet-isms when in doubt, they are almost guaranteed that no other invention (app) anywhere will have been done just that way, in particular, inventions created from Java, C, etc. There is no guarantee of avoiding prior art, but there is a significantly improved probability of avoiding it if done thoughtfully. You always need a bit of luck as well.
  
  The Microsoft patent I looked at was general in many places, but it still touched upon components that can certainly be baked into an app, through the interworkings of a framework, simply by using various API from that framework.
  
  [I didn't verify that any MS API would get you in trouble because I haven't researched that.. I'm working on a proof of concept to show that many such API-patent examples can be created without too much trouble.]
  
  ["baked into" is one of the invented short-cuts. :-) ]
  
  >> As I’ve said, multiple times now, for your theory of a .net-only patent to work, you have to show two things: >> b. that it only makes sense to have that feature in .net
  
  Well, "dotnet-only" is not my theory, not literally.
  
  Do you know the answer now from reading over this reply?
  
  In short, there is nothing singling out dotnet. dotnet would be guaranteed to work (in the sense of always leading to violations), but it's always possible to violate the patent using any technology (though possibly with a lot of redesign.. eg, you may have to write up a particular type of runtime bytecode translator if that was a key component of the patent.. of course, I don't know too many people that would *want* to violate a patent).
  
  >> a. that there is something featureful that we would like to have (like being able to play back an MP3 or something)
  
  Definitely. I have to fix the foo bar example I gave to add verbs in there.
  
  However, there is no need for the mp3 bypass situation.. because the patent works differently.. it doesn't have to be that clever and thorough. [I said a lot on that in one or two of the earlier replies (search for "bypass") and also look for "abstraction" and "biggie".]
  
  Alex, I don't mean to be a pain as I have been at times, but your short answers that just assume all hope is lost can be frustrating to me.

• Jose_X

  2009-01-13 19:33:06

  >> The semantics don’t matter a jot. Java’s object semantics are different to .net’s, yet Java runs on .net. So long as you know what they are coming in and what they should be going out, you’re fine.
  
  I'd say we are misunderstanding each other. I'll continue to try to fix my language as I notice problems (or I'll explain the phrases that I think may give probs).
  
  OK, an example (but not a proof by any means):
  
  -- If a patent claim violation involves the transfer of an event message from X to Y, then no matter what language you use to implement the app or no matter how you translate the bits of the binary objects, you will have to preserve this functionality *in general*.
  
  Clever people may find that some features of some API can be factored out or changed without any possible detrimental issues to any app, but, in general, you can't change any functionality/semantics of the components of the API or the applications using it will break. You can change the appearance, but not the function.
  
  Now, in practice, if you translate (eg, to java-ness) at a stage after the source code stage that uses the API has been compiled (with the "API compiler"), then the concept of the API disappears. BUT the functionality that was baked in must be preserved or the app stops working as intended and people will not use such a translator.
  
  And patents cover functionality... that would be preserved.
  
  And, yes, my foo bar example is currently very weak (trivial actions/functionality at best).
  
  >> If there is this hypothetical “API you cannot implement without infringing a patent”, then you can’t have it on Java (or anywhere else) either and you’re screwed.
  
  Not sure what you meant, but I think I agree.
  
  My last reply (written after you wrote this one I think) may have made things clearer [or maybe this reply has].
  
  Yes, whatever gave you probs in dotnet would as well if replicated through any other language through whatever means would allow that lang/platform to bake those same things in.
  
  The significance of a specific "hot" API is that this means we have *guaranteed* violations whenever that API is used.. if everything was designed properly by the patent/API writer. Other API may or may not pose issues, much as may happen any day of the year in the software world, depending on how you combine things. So, while other API require certain combinations (usually very complex combinations, eg, like writing up a full event system that works a particular way), a hot API might be designed to accomplish the violations in as little as a single or even no explicit method call. Yes, maybe it would take more than one. This can still be effective since some portions of API are frequently used with other portions.. Well, you get the idea ..(?)
  
  [To do things "properly" (ie, to guarantee avoiding prior art for the patent), you want the API writer to be the patent writer. This way the patent writer would be inventor (of the API) and thus able to write up the patent, at least if no one beats him/her to the punch to publish.. at least I think that is how US law works. (and the author would have a full year to fill out the patent application... in the US.. iirc)]

• AlexH

  2009-01-13 21:33:59

  @Jose: perhaps you're getting somewhere now:
  
  

  >> You’re still trying to define patent scope along product lines.
  
  Not at all. If you use a set of Java API that match the effects of the dotnet ones, you’d also be in trouble.

  
  
  Precisely. You've found one half of the two attributes I said you needed.
  
  Now you have to convince me that there are APIs in .net which other platforms like Java don't have equivalents of, and maybe you would get somewhere.
  
  As for changing APIs - I already gave you an example which works extremely well: IKVM. So it's not really worth arguing how it doesn't work in theory, when it works very well in practice.

• Jose_X

  2009-01-13 23:46:28

  >> Now you have to convince me that there are APIs in .net which other platforms like Java don’t have equivalents of, and maybe you would get somewhere.
  
  If I understand you, then the answer seems to be "of course.. lot's of them".
  
  The differences don't have to be huge. Even without knowing dotnet, I can virtually guarantee anyone that the API's (Java's, dotnet's) are not clones of each other.
  
  Let's take a given difference that is not replicated in the other. Eg, maybe the getTime [I'm making this up] of one works like nothing else found in the other. That presents opportunity (at least without looking closer at the situation) for such a function to possibly violate a patent claim by its mere use while no single other function use in the other platform would fulfill the same requirements.
  
  Let's say that one getTime *must* check on the number of active threads (by definition of the getTime function.. not as a specific implementation decision) and calculates the time differently depending on circumstances. For example, past a threshold (eg, the returned value of getThresholdValue), the time is calculated through an algorithm that must test and possibly update a certain system cache, while otherwise a network-based algorithm is used or something else. [yes, I'm making this up as a hypothetical.]
  
  This algorithm requirement (note we aren't defining the full implementation details by a long shot, but we are standardizing general aspects that the algorithm must posses) is something that can be captured in a patent claim. Funnily, this requirement may end up being detrimental to the overall performance, but that is irrelevant. It can be captured in a patent claim is the point.
  
  Well, we now can see perhaps how a single call will only violate some particular claim when that single call is this getTime function (found only on platform X). Perhaps other patent claim requirements would involve "a time value is returned to the user space" "calculated as such: ..." "acl bit is checked before the system clock is queried" etc etc. [I'm being rough/approximate here.]
  
  Is this making sense? .. when combined with some of the other examples/descriptions/analogies in some earlier comments, perhaps?

• Jose_X

  2009-01-14 00:37:23

  >> As for changing APIs - I already gave you an example which works extremely well: IKVM. So it’s not really worth arguing how it doesn’t work in theory, when it works very well in practice.
  
  Are you referring to the conversion to/fro java/dotnet thing?
  
  If this is what you are talking about then...
  
  Look, any translation has to preserve how the app behaves in every fashion. If it doesn't preserve this then it is breaking the app and it is a faulty translation. If it preserves the app functionality, then you will find the same functionality in every way after the translation.
  
  Now, we can normally re-implement functionality (eg, the mp3 bypass issue).
  
  A key point for our case is that when you make a patent claim dependent on features that are required by some standard, then no matter how many times you translate the application, you can't take any short-cut in the translation that would affect a relationship that is standardized because that would violate the contract that supposedly the (eg) API promises the user developing the application.
  
  Ie, you can't break public (or standardized) contracts between software components because if you do the app would not be expected to behave the same. Patent claims that are based on relationships that are standardized will continue to be violated after any translation because these contract relationships will not be broken. This is a key point: to base the patent claims on contract relationships (by "contract" I mean that these relationships form part of the API semantics vs. parts that are implementation-defined).
  
  So in the case of getTime, you can't change the algorithm through any translation in a way that violates the spec definition. If you do, then you aren't implementing the contracts the developer coded into the app. However, if these algorithm constraints did not exist, then you might be able to change the whole algorithm as you translate.
  
  So for getTime, you'd build the patent claim on the parts you know must hold no matter what. The standards-defined parts and not the implementation-defined parts. Apps require the standards-defined parts never change no matter what. So the patent claims might require the algorithm constraints (also standardized).
  
  Analogy with encode-mp3:
  
  Imagine a patent claim that was based on internal components of encode-mp3 (eg, the patent you mentioned?). So if you find another way to implement encode-mp3 that causes any of these internal relationships to no longer hold, then you avoid the patent.
  
  But, what if these internal parts had their own API? What if the internal parts were exposed to developers to build applications (eg, maybe a Pipeline or ArrayCell object). Then developers that use these internal API would be screwed because if you change the encode-mp3 function so that these internal contracts would be violated, then you avoid the patent but you generally break the apps that relied on these internal API. And if you re-implement without breaking these contracts, then you will still violate the patent after the re-implementation.
  
  So the API-patent writer wants to enshrine in API whatever is required for a claim. This way any re-working of the implementations (which will preserve the software component contracts) will still preserve the properties that cause the patent claim to be violated.
  
  On mono:
  
  Mono would not be a problem if they were willing to violate an MS spec whenever that would be required to avoid a patent (eg, by not following the hypothetical getTime algorithm restrictions and hence no being under the scope of that patent claim), but how do the mono people know when to deviate? They don't until after the patent violation is brought to their attention. By then applications will be written and will be in violation. Another problem is that people don't like their (public) APIs to change from under then in future versions (backwards compat). [Remember, changing the API contracts (enshrined in the patent claims) is needed in order to avoid the patent claim violations.]
  
  And Samba:
  
  Now Samba (under an API-patent scenario) may need to be changed in the protocol, but only those that created interacting apps using the protocol would be affected. Most users basically wouldn't notice. They'd just replace the samba clients/servers. The samba devs would take care to fix the samba app. However, mono (under an API-patent scenario) is a problem because you'd have to change all applications using the "mono protocol", and by its nature, this is a problem that the mono devs cannot fix for their users. So Samba is one app and it gets reworked by the samba devs, but mono implies many apps need to be analyzed, redesigned, and recoded.
  
  The safe way forward for mono is simply to avoid implementing *any* MS API specs if you don't trust MS (and MS have been clear about their intentions.. which is to be expected considering the threat FOSS represents to their monopoly based businesses).
  
  I don't trust MS, so I don't use any mono app (or anything mono).. at least as long as mono is a clone of MS created API. I also naturally would really prefer that these apps not spread or attract developer time.
  
  [Well, I have other reasons besides the patent reason for not wanting to spread what helps Microsoft.]

• Jose_X

  2009-01-14 08:30:51

  Will post more later when have time, but I think I just realized the real strategy against FOSS.
  
  OK, let's accept (though I don't completely) that ecma and whatever are 100% patent safe.
  
  The problem is this. When mono has spread a lot and been imprinted in devs minds, they will not want to dump it or to use a totally different API (actually they might..). Now, say you want to stick to core 100% patent safe stuff. Well, as you try to broaden into areas that overlap with say aspdotnet and other unsafe things, you *may* find that all the natural ways to implement most things will be covered by patents through the API-patent thing. Ie, a lot of the patent claim reqs will automatically be fulfilled by the bulk of the dotnet core API. Then Microsoft need only "innovate" with a few obvious extra items (putting the novelty aspect aside) and poison anything we'd want to do. Ie, they couldn't otherwise patent some natural ways to communicate over the network, but they can if it's part of a wider invention with all the intricate dotnet-ish components cooked right in.
  
  So a claim candidate to affect a competitor to aspdotnet (clone or otherwise) might have 20 key items, but 18 might be fulfilled automatically through core dotnet API, while the last 2 would pose real obstacles to almost any realistic implementation.
  
  They could not get a patent granted on the 2 obvious items, but they could on 20 and we'd not be able to avoid the obvious 2 nor the 18 already cooked into the apis everyone is using automatically.
  
  Finally, *even* for core ecma mono, *trolls* might actually hold the patents (bought from Microsoft) and not be held back by the Microsoft covenant.
  
  Help.
  
  PS: aspdotnet is where you are most likely to end up with millions of applications (rather than say 1000) as dotnet spreads through the industry. The mono devs couldn't fix up 1000 apps. They surely couldn't fix up 1000000.
  
  PS2: This 2006 patent might be one of the deadly ones (was posted here by ushimitsudoki on dec 20 of last year): http://www.freepatentsonline.com/7013469.html Application program interface for network software platform

• AlexH

  2009-01-14 08:54:37

  @Jose: you're still stuck on this idea of patenting APIs, which as I keep showing is impossible: no such patent exists.
  
  You can patent things which would make the implementation of a given API (like MP3 playback) difficult, but that is nothing to do with the API.
  
  You also ignore the fact that free software APIs change all the time, and applications need to be updated to use them - API change is fine, in fact, free software developers prefer to change APIs to make them better than languish with bad APIs.
  
  I note you side-stepped the IKVM example again:
  
  

  Look, any translation has to preserve how the app behaves in every fashion. If it doesn’t preserve this then it is breaking the app and it is a faulty translation. If it preserves the app functionality, then you will find the same functionality in every way after the translation.

  
  
  That's clearly and obviously incorrect. Running on IKVM, an application might be doing very different things internally - what matters is that the app functions in the same way for the user. Same functionality "in every way" is irrelevant and unnecessary.
  
  So, in short:
  
  a. you overestimate the difficulty of changing APIs b. you underestimate the ease of creating a patent which prevents any implementation of some functionality. c. you still ignore the fact that any such patents that are broad enough to cover any .net implementation would by definition have to cover any non-.net implementation.

• Jose_X

  2009-01-14 16:28:43

  Alex, again you've gone back to quoting very little. That's a shame, but thanks for all the times in the past when you have challenged me directly.
  
  >> That’s clearly and obviously incorrect. Running on IKVM, an application might be doing very different things internally - what matters is that the app functions in the same way for the user. Same functionality “in every way” is irrelevant and unnecessary.
  
  I agree completely if you want to interpret "in every way" that way. I'm not sure why you took that interpretation given the context of that section and of my various comments. Nevertheless..
  
  .. the app does need to function the same "in every way," in all ways that are important to that app. If a particular app decides to loop over every interface it can access and query/change it, then for that app, you can't cheat and knock off parts that would cause that to fail. You may not remember, but the fake patent (to which I'll return to improve) gives an example of app code that does something right along those lines of looping over interfaces and query/changing values (see "AdvancedPseudo code" example of the fake patent).
  
  Bottom line, anything you make accessible to the app through this or that API or though any other method (though only the public stable access points are part of the contract with the developer in most cases) must be preserved in behavior. Whenever you mess with any of that, you better have done your analysis very well.
  
  I'm sure you understand what I just wrote, so I hope you will re-evaluate that earlier reply of mine (and maybe read any other you skipped over), and consider addressing it again if you still disagree or think I have not addressed/challenged your IKVM example successfully.
  
  Perhaps also consider quoting more since your conclusions and allegations over what I am saying are still incorrect. You aren't going to understand what I mean if you don't challenge it directly. Also search for "niece" on this thread because that comment still applies.

• AlexH

  2009-01-14 16:35:46

  @Jose:
  
  

  If a particular app decides to loop over every interface it can access and query/change it, then for that app, you can’t cheat and knock off parts that would cause that to fail

  
  
  Actually, yes I can. If I'm rewriting parts of the app - be it source or binary - I can change what it's doing as much as I like. All I need to do is refactor its use of APIs (which is what IKVM does).
  
  As an example, if we have an app which plays back MP3s, I don't need to replace PlayBackMP3(string file); calls with some equivalent API - I can replace it with:
  
  audioFile = FileLoad(file); audioPlayer = new OggPlayer(); audioPlayer.playFromStream(audioFile.getStream());
  
  ... and the app still works. Doesn't matter that the APIs are totally different.
  
  As for your "niece" insult, it's a nice try but I don't need to quote parts of your text to directly address your argument. Unless you accept that APIs do not represent patentable barriers, I'm not going to address arguments built on top of that faulty assumption.

• Jose_X

  2009-01-14 17:09:17

  >> you’re still stuck on this idea of patenting APIs, which as I keep showing is impossible: no such patent exists.
  
  You don't understand what I am saying, apparently. I have said very numerous times that the API is not actually patented. I have also said that the API is but one vehicle used to potentially bake into the application the required elements needed to violate a patent claim.
  
  >> You can patent things which would make the implementation of a given API (like MP3 playback) difficult, but that is nothing to do with the API.
  
  [I understand you. I hope you'll come around to understanding me.]
  
  ** Yes, now the problem is if you violate a patent claim whose described implementation relies on relationships enshrined as part of interfaces exposed to developers, eg, though an API. [This was a key sentence, so I will leave it along in this paragraph.] **
  
  If you avoid the patent, you'd necessarily be avoiding, that is breaking, these relationships which you had already promised to the developers would not change. If you change these relationships/contracts as you re-implement the library, then you will be advocating that applications be linked so that they break.
  
  If you don't do that (and I recommend such action), your only way to avoid the problem is for each violating app (which could be all of them) to be changed manually to avoid the problematic portions of the API and in the future stay away from those sections...
  
  ..Except of course if the problematic API are a deep and core part of the API that cannot be avoided if you link the app up to those libraries (eg, parts of an event infrastructure and many other core parts). In this case, you accept violations (and associated consequences) or dump the framework (at least fork and change it significantly).
  
  If you want another analogy to this, search to my recent comments for "Analogy with encode-mp3" since you may have skipped over those paragraphs.
  
  >> You also ignore the fact that free software APIs change all the time, and applications need to be updated to use them - API change is fine, in fact, free software developers prefer to change APIs to make them better than languish with bad APIs.
  
  Yes, and there are many ways to change API. I can warn of potentially devastating changes being needed to an API ASAP and of extremely costly re-workings needed ASAP to all apps using it (see http://boycottnovell.com/2009/01/11/ms-maintaining-gap-vs-linux/#comment-58389 ), but I can't make you drink the water.
  
  >> So, in short:
  
  blah blah.. sorry, buy you don't appear to me to have too many clues about the key concepts of what I am discussing.
  
  >> you still ignore the fact that any such patents that are broad enough to cover any .net implementation would by definition have to cover any non-.net implementation.
  
  I want to take up this one last piece.
  
  You can't cover inventions outside the "scope". This is what I mean:
  
  If for an invention to be violating you must have x y z characteristics be present in the invention, and x y z are baked into applications by usage of the dotnet (through linking say) but otherwise are rare to find in any other invention/app out there (perhaps because no other framework bakes those things into apps automatically), then that patent surely will not be effective against most applications out there that aren't dotnet.
  
  There are cases where inventions (apps) not created with dotnet would be affected by an API-patent attack targeting dotnet, but these non-dotnet-based apps, to be in violation, would essentially have had coded into them (manually perhaps and maybe very tediously) those dotnet characteristics targeted by such a patent.
  
  Dotnet "API" (ie, the behavior/interfaces exposed publicly through, say, a typical API such as what mono or MSdotnet expose) have unique characteristics. There are unique elements in that public contract that are not found in any public java interface/API contract, for example (ditto for python, perl, etc). Thus, Microsoft has a greater chance of avoiding prior art if they target those characteristics in such an API-patent attack. In that case, only inventions with those characteristics would be susceptible to the patent infringement, and likely all such inventions would have been made only *after* those API were published by Microsoft (ensuring no prior art).
  
  [A hypothetical example given earlier about exploiting these unique elements can be found in the discussion above about "getTime".]
  
  *****
  
  Alex, believe it or not, I do appreciate your continued input, even if it isn't always ideal from my pov.

• AlexH

  2009-01-14 17:18:11

  @Jose:
  
  First you say:
  
  

  I have said very numerous times that the API is not actually patented

  
  
  So on what basis can you then say:
  
  

  [T]he problem is if you violate a patent claim whose described implementation relies on relationships enshrined as part of interfaces exposed to developers, eg, though an API.

  
  
  Either using the API infringes a patent or it doesn't.

• Jose_X

  2009-01-14 17:28:33

  >> Actually, yes I can. If I’m rewriting parts of the app - be it source or binary - I can change what it’s doing as much as I like. All I need to do is refactor its use of APIs (which is what IKVM does).
  
  In the example you gave, you still had the same functionality achieved.
  
  The implementation described in the patent claim wasn't over that functionality, however, so re-implementing it doesn't solve the problem (since the claim was over something else).
  
  The implementation described in the patent claim simply required that that functionality be included as part of a larger set of instructions.
  
  So the mere fact you have to still include that functionality (after a IKVM manipulation) in order to preserve public interfaces (eg, the effect of "PlayBackMP3(string file)") means that you are still implementing that *step* in that violated patent claim.
  
  Does this explanation help?
  
  >> As for your “niece” insult, it’s a nice try but I don’t need to quote parts of your text to directly address your argument.
  
  No, but you aren't addressing my argument nearly too well in this discussion since you still don't understand what I am saying. By quoting each other we can more quickly get to the bottom of what is clogging up the communications channels since this way I/you don't have to imagine what, of all the words I/you've written, led you/me to think something.
  
  And in some cases, after I write a bunch, you effectively say little or nothing beyond "I am wrong and you are right."
  
  From here on out, I hope you won't be insulted when I reference the "niece". I like to keep prodding you to quote me when it appears you are off the mark and wrapping things up (and didn't quote very much). The niece message is important.
  
  >> Unless you accept that APIs do not represent patentable barriers, I’m not going to address arguments built on top of that faulty assumption.
  
  I accept that statement if it is saying what I think it is saying. To be safe, you can try and re-express it. ["barriers" to what? and in which way?]
  
  Good, so, now address directly what I have said in a bunch of these comments I've been writing. Start with the latest batch from today if you want.

• Jose_X

  2009-01-14 17:31:59

  >> Either using the API infringes a patent or it doesn’t.
  
  Yes, using an API can infringe a patent if the use of that API leads to the patent claim being violated because the components of the claim are baked into the app in a way that cannot be re-implemented without violating the public specs of the API.

• AlexH

  2009-01-14 17:43:13

  @Jose:
  
  

  Yes, using an API can infringe a patent if the use of that API leads to the patent claim being violated because the components of the claim are baked into the app in a way that cannot be re-implemented without violating the public specs of the API.

  
  
  Apart from the name of a library, name of the function(s) used and the order of parameters, what part of an API gets "baked into the app"?

• Jose_X

  2009-01-14 17:56:00

  >> Apart from the name of a library, name of the function(s) used and the order of parameters, what part of an API gets “baked into the app”?
  
  You know that I don't (yet) know the details of dotnet or of MS patents. I am trying to build up proof-of-concept and/or recipes so that people recognize the dangers.
  
  So, since you already know that...
  
  Should I interpret this last comment of yours to mean that: -- AlexH doesn't believe it is possible to create an API and patent claim such that: -- -- the use of that API would "bake" into the app all the ingredients necessary for the patent claim to be violated, and -- -- it would be impossible to re-implement any part of that API or of the application that used it (eg, through IKVM) so as to avoid the patent, without violating the original contract exposed to the API users. ?
  
  Here, to make things easy, let me repeat my reply again so that you need not flip the page upwards if you decide to address it again (addressing this last question I posed would be fantastic as well):
  
  >> Yes, using an API can infringe a patent if the use of that API leads to the patent claim being violated because the components of the claim are baked into the app in a way that cannot be re-implemented without violating the public specs of the API.

• AlexH

  2009-01-14 18:03:41

  @Jose:
  
  Apologies, but:
  
  

  You know that I don’t (yet) know the details of dotnet or of MS patents. I am trying to build up proof-of-concept and/or recipes so that people recognize the dangers.

  
  
  You don't know how .net works, but you feel confident enough to pronounce that there could be patent problems with .net APIs?!
  
  This is the problem. I've pointed out that APIs are purely descriptive and non-patentable many times, yet you persist in trying to construct scenarios which rely on them being patentable, and you also admit to not knowing how .net linkages work.

• Jose_X

  2009-01-14 18:14:51

  Alex,
  
  (a) you avoided answering directly a very short and sweet question [look for the "?" here http://boycottnovell.com/2009/01/11/ms-maintaining-gap-vs-linux/#comment-58457 ] (b) you also should know by now that what I am describing is a problem that I believe can apply to *any* API that is targeted by the so-called API-patent attack. I am claiming it isn't that difficult (relatively) to create such API/patent duos when you know what you are doing.
  
  We can address the relative risks between dotnet and say java or any other API once/if you accept my claims and if you want to then have this other conversation.

• Jose_X

  2009-01-14 18:17:12

  >> I’ve pointed out that APIs are purely descriptive and non-patentable many times, yet you persist in trying to construct scenarios which rely on them being patentable, and you also admit to not knowing how .net linkages work.
  
  So why don't you turn whatever it is you believe (I'm not judging it) and try to answer the question here: http://boycottnovell.com/2009/01/11/ms-maintaining-gap-vs-linux/#comment-58457
  
  Is your answer to the question I posed on that linked comment: Yes.. no ...??

• AlexH

  2009-01-14 19:01:11

  @Jose:
  
  a. your "short and sweet" (9 lines?!) question: no, it's not possible.
  
  b. your "API attack" just doesn't work. Not for .net, not for Java, not for any language: there has never been an example of such an API, and I can't imagine one.

• Roy Schestowitz

  2009-01-14 19:02:30

  Patents can poison APIs. Why don't you admit your defence is weak rather than say "I don't understand"?

• Roy Schestowitz

  2009-01-14 19:03:22

  As proof:
  
  http://boycottnovell.com/2008/02/28/patent-pill-is-in-openness-pledge/
  
  See?
  
  Protocols accompanied by patents.

• Jose_X

  2009-01-14 19:10:39

  >> your “short and sweet” (9 lines?!) question: no, it’s not possible. >>... and I can’t imagine one.
  
  Alright Alex. Thanks for this response and for all your comments on this thread because it has helped me recognize the key issues so as to better be able to write something up more properly than the back and forth on this forum.
  
  I think I have covered many of the important angles on this thread, but it is a very long thread so I don't expect a reader to necessarily have followed everything or even much of it perhaps (depends on reader's background).

• Jose_X

  2009-01-14 19:13:32

  >> Patents can poison APIs. Why don’t you admit your defence is weak rather than say “I don’t understand”?
  
  Roy, a formal proof (as if that is possible) hasn't been provided here. I am happy that others will come to different conclusions over what I have been writing, and that AlexH has helped push me forward to find important arguments to back such a claim as I believe (in disagreement with him) is true.

• AlexH

  2009-01-14 19:14:22

  @Roy: first, protocols aren't APIs, and second, your link doesn't describe what patent licenses are actually needed for. As an example, the SMB documentation has patents attached, but Samba managed to work around them. So, I'm not sure you've added anything to the discussions.
  
  @Jose: don't confuse my "I can't imagine.." statement for any possibility of being able to patent an API; the answer to the first question was definite. APIs are not patentable.

• Jose_X

  2009-01-14 19:30:23

  >> the answer to the first question was definite. APIs are not patentable.
  
  Well, I didn't ask if "APIs are patentable" or not.
  
  I asked: >> Should I interpret this last comment of yours to mean that: – AlexH doesn’t believe it is possible to create an API and patent claim such that: – — the use of that API would “bake” into the app all the ingredients necessary for the patent claim to be violated, and – — it would be impossible to re-implement any part of that API or of the application that used it (eg, through IKVM) so as to avoid the patent, without violating the original contract exposed to the API users. ? >>
  
  And you answered: >> no, it’s not possible.
  
  which presumably was an indirect answer (but as good as the direct answer) which meant:
  
  -- AlexH doesn’t believe it is possible to create an API and patent claim such that: – — the use of that API would “bake” into the app all the ingredients necessary for the patent claim to be violated, and – — it would be impossible to re-implement any part of that API or of the application that used it (eg, through IKVM) so as to avoid the patent, without violating the original contract exposed to the API users.
  
  What I have gotten from you on this thread is definitely more useful than if I had gotten nothing, also more useful than if I had gotten any other subset of what I got, and actually quite useful in many ways, if perhaps short of my goals. Honestly, thank you.
  
  Perhaps, I'll revisit this later when I have written something up that is easier to read from beginning to end...
  
  or, of course, as a direct reply to something you say that I can track back to this conversation (and decide to do so)...
  
  or ... [ :-) ]

• Jose_X

  2009-01-14 19:35:24

  >> As an example, the SMB documentation has patents attached, but Samba managed to work around them.
  
  Right. I had this to say on it earlier.. first: http://boycottnovell.com/2009/01/11/ms-maintaining-gap-vs-linux/#comment-58252 and later: http://boycottnovell.com/2009/01/11/ms-maintaining-gap-vs-linux/#comment-58261

• AlexH

  2009-01-14 19:39:11

  @Jose: you can even shorten it:
  
  

  [It's not] possible to create an API and patent claim such that the use of that API would “bake” into the app all the ingredients necessary for the patent claim to be violated

  
  
  An API is a description of an interface. A patent is a way of doing something. They're almost entirely orthogonal.

• Jose_X

  2009-01-14 19:43:17

  No, you can't shorten it.
  
  The answer to the short version is the opposite as to the long version.

• AlexH

  2009-01-14 19:53:24

  @Jose: er, no it's not.
  
  You joined on the next clause with an "and". That makes it more general than the longer. You asked if I disbelieved (X and Y); I'm also telling you I don't believe X.

• Jose_X

  2009-01-14 19:55:08

  Microsoft is sowing seeds. They'll know when to harvest for maximum impact (possibly after the EU is more software patent friendly ..and of course, after mono has spread more, after other MS protocols have been adopted more widely, after there will be fewer mature alternatives for FOSS developers to flock towards, etc.).

• AlexH

  2009-01-14 19:58:49

  @Jose: maybe they are, but they're certainly not doing it in the way you dream.

• Jose_X

  2009-01-14 21:18:26

  Short reply: I got confused for a moment and incorrectly answered that the correct answer (IMO) to the short and long were opposite.
  
  Do take a look at the "note" at the very bottom of this comment since it clarifies the question some.
  
  ***
  
  Sorry, for taking so long. Statements can always be read differently than intended (much context is always not made explicit). I wanted to verify before answering again that various ways of reading those two pieces were probably still covered in the original (the short leaves extra context out).
  
  My reply to the short version is that:
  
  -- I think it's possible to create an API and patent claim such that the use of that API would “bake” into the app all the ingredients necessary for the patent claim to be violated
  
  to the long:
  
  -- I think it's possible to create an API and patent claim such that the use of that API would “bake” into the app all the ingredients necessary for the patent claim to be violated and (such that) it would be impossible to re-implement any part of that API or of the application that used it (eg, through IKVM) so as to avoid the patent, without violating the original contract exposed to the API users.
  
  The second is more specific than the first. I implied by my last answer that I thought the first would be impossible. That was a mistake on my part. I must have gotten something confused.
  
  Now, I prefer the long version not be dropped because it adds context that one can later always pretend didn't exist.
  
  For example, you (AlexH) keep saying that an API can't be patented, but I have never stated or implied that except that I use various short-cut phrases that sound as if I might be saying that; however, I always try and clarify, yet you always continue to add that an API can't be patented.
  
  That's like me continuing to say that this site is boycottnovell even though you don't deny that.
  
  Anyway, I did get tripped up in part because I didn't want you to use the short version.
  
  For clarity: I am not saying an API can't be patented. Rather...
  
  .. I think it's possible to create an API and patent claim such that the use of that API would “bake” into the app all the ingredients necessary for the patent claim to be violated and (such that) it would be impossible to re-implement any part of that API or of the application that used it (eg, through IKVM) so as to avoid the patent, without violating the original contract exposed to the API users.
  
  Alex, when you get a chance (if you are in the mood) please reply to the first part of this http://boycottnovell.com/2009/01/11/ms-maintaining-gap-vs-linux/#comment-58453 (the IKVM section).
  
  [Note, "create an API" should mean "design an API and/or possibly provide an implementation to go with it"; "re-implement any part of that API" means "re-implement any part of a given implementation that implements that API"]

• Jose_X

  2009-01-14 21:21:12

  Alex,
  
  Of course, judging by your counter-arguments, it's difficult not to believe my dreams.
  
  :-)
  
  PS: my prior comment was a response to your X and Y thing.

• Jose_X

  2009-01-14 21:25:40

  ..and my prior comment was me again hinting that you should do less waving me off without replying more specifically .. since it's obvious to me that you are not understanding what I am describing.

• Jose_X

  2009-01-14 21:27:20

  >>For clarity: I am not saying an API can’t be patented. Rather…
  
  Darnnit, that was wrong. The correct:
  
  "For clarity: I am not saying that an API can be patented. Rather…"

• AlexH

  2009-01-14 21:53:34

  @Jose: let's just look at the first part of your proposition:
  
  

  For clarity: I am not saying an API can’t be patented. Rather…
  
  .. I think it’s possible to create an API and patent claim such that the use of that API would “bake” into the app all the ingredients necessary for the patent claim to be violated

  
  
  How can using an API infringe a patent when the API isn't what is patented?

• Jose_X

  2009-01-14 22:09:46

  Well, using your language, you can't patent an API. I can accept that. That is accurate; however, I will short-cut sometimes to give the impression I am saying you can patent an API. That last statement you quoted more clearly shows what I mean and is fairly consistent with most of what I have been trying to describe.

• AlexH

  2009-01-14 22:30:41

  @Jose:
  
  I'm asking you specifically why you think your latter statement is somehow different to "using the API".
  
  What is it that suddenly brings the usage of API into the purview of patent law, beyond the normal usage of API?

• Jose_X

  2009-01-14 22:44:37

  >> What is it that suddenly brings the usage of API into the purview of patent law, beyond the normal usage of API?
  
  You violate a patent by building an implementation that violates it.
  
  What are API use for?
  
  To build.
  
  What you build might violate a patent.
  
  Some APIs help you get to that violation point faster than others.
  
  With assembly, it would take a long time of coding to violate almost any patent.
  
  With higher level frameworks, you might violate a patent with a single call (the mp3 example, at least if you don't find a non-violating example).
  
  OK, I'm not sure what you are asking, but perhaps you want to look at the IKVM section of this: http://boycottnovell.com/2009/01/11/ms-maintaining-gap-vs-linux/#comment-58453

• Jose_X

  2009-01-14 22:47:48

  I misread your last question, but take a look at the link I gave just now.

• AlexH

  2009-01-14 22:49:33

  @Jose:
  
  Sorry, it's a simpler question than that. I program some software using an API. You and I both agree that an API is not patentable subject matter.
  
  What is it that is in my software, beyond the usual mechanics to access functions via an API, that is patentable subject matter?
  
  I don't know what your question about IKVM is/was, but the Ogg API I outlined avoids the MP3 patent - I'm not implementing any step with a patent infringement.

• Jose_X

  2009-01-14 22:53:14

  Anything that is patentable can be in your app and be violating. Your app in a product. If it works as described by a claim, it is violating it.
  
  [..keeping this discussion simple ..ie, ignoring exceptions and other issues like the patent being invalid etc]

• AlexH

  2009-01-14 22:55:51

  @Jose; you're side-stepping the precise question.
  
  You're claiming that there is a way you can use an API which could infringe some patent.
  
  How? What is the "thing" beyond the API which is patentable matter? What is it that is introduced into the program?

• Jose_X

  2009-01-14 22:56:52

  i'm assuming sofware running on a pc is in play wrt possible patent violations etc

• Jose_X

  2009-01-14 22:58:59

  You use an API (potentially, depending on the patent, maybe even just linking to some libs and writing an empty main program).
  
  You build your binary and run it.
  
  Now you have a product that may work as described by a patent claim.

• AlexH

  2009-01-14 22:59:47

  @Jose: let's get technical with this, then.
  
  When I have a program, I need source code. This source code may refer to functions which are in another library. In order to make use of those functions I need an API description, often in a header file.
  
  I compile my source into a binary. What is the stuff in the binary which is subject to some patent? Where did those bits come from?

• Roy Schestowitz

  2009-01-14 23:00:28

  Yes, patents describe routines and can do interfaces. It's abstract stuff.

• AlexH

  2009-01-14 23:03:29

  @Jose:
  
  If the program itself doesn't implement the patented method, it doesn't infringe a patent. That case is very simple. Next?

• Jose_X

  2009-01-14 23:03:48

  For example, the libs you linked to implement some standard. That standard requires certain things to happen before the main of any application is run.
  
  Those standardized actions being carried out must be carried out with some constraints or others (ie, the standard stipulates "this and this and that".. eg, a security manager working thusly must do this and this upon initialization of every app).
  
  Those same standardized actions coincide with the actions/details that would make a given product violate patent X, eg, "claim: the product has a security manager that does this and this upon initialization of every app".
  
  Of course, I don't pretend that a claim would actually sound like that, but that is the idea.

• AlexH

  2009-01-14 23:15:12

  Jose:
  
  You keep repeating your theory, but you never get precise about exactly what is going into the binary being created that is subject to patent law.
  
  We're assuming the code that we're writing doesn't infringe the patent, and we agree that the API itself isn't infringing. So what's the extra "thing" which goes into the software that is infringing?

• Jose_X

  2009-01-14 23:20:16

  In an extreme case [just to clarify that last example a bit more] the patent claim might simply say: the app starts up, runs the security manager as such and ends. This way an empty app would violate the patent. Some more complex app would also violate.
  
  If you change the implementation of the starting up to avoid the sec mngr, then you'd be breaking the API.
  
  Since apps/app writers expect the API to hold, if you change that behavior you should expect to have all/many apps break.
  
  And as long as you don't change the library impl, all of these apps are in violation.
  
  Only way out is to redo the app but avoid whatever gave you probs before. In this case you may conclude that using a different API/framework is best. In other cases, you may do something different. But in all of these cases, you have to dig into the app, on a per app basis. You can't fix the libraries.
  
  Also, could you imagine if all of the mono apps had to be redone from scratch using something besides mono? [That would be a very bad case scenario since it would mean you couldn't avoid the patent violation except through dramatic changes to the program.]

• Jose_X

  2009-01-14 23:22:52

  >> You keep repeating your theory, but you never get precise about exactly what is going into the binary being created that is subject to patent law.
  
  alex, I already told you/have been telling you through this extended example.

• Jose_X

  2009-01-14 23:24:19

  Earlier, you claimed that IKVM can bypass some situation of other and I replied with this http://boycottnovell.com/2009/01/11/ms-maintaining-gap-vs-linux/#comment-58453

• Jose_X

  2009-01-14 23:27:16

  >> We’re assuming the code that we’re writing doesn’t infringe the patent, and we agree that the API itself isn’t infringing. So what’s the extra “thing” which goes into the software that is infringing?
  
  You can assume what you want, but if linking leads to your app functioning as described by a claim, that is all that matters.

• AlexH

  2009-01-14 23:28:45

  @Jose:
  
  

  I already told you/have been telling you through this extended example

  
  
  No, you didn't. I want you to say precisely what is getting put in the binary - the actual bits, and where they come from - which is patentable matter.
  
  

  Earlier, you claimed that IKVM can bypass some situation of other and I replied with this

  
  
  And I replied to that telling you why you were wrong; the example I set out doesn't infringe any patent. The "step" you see is gone.

• Jose_X

  2009-01-14 23:28:56

  for a different patent/scenario maybe you have to use the date object or something. [past replies were based on the "sec mngr running violates a patent" example]

• Jose_X

  2009-01-14 23:34:56

  alex, just noticed you put the ogg in there instead of mp3. out of curiousity, why should there be an ogg version of the file you want?

• Jose_X

  2009-01-14 23:38:05

  alex, i'll wait for your answer to the ogg/mp3 so that I can better answer your earlier comment.
  
  But you are missing what I said there.
  
  Look, when you reimplement a function, you can bypass the mp3 claim
  
  but you do nothing as far as avoiding a claim where the "playing of the file" is a step. you still played the file.

• AlexH

  2009-01-14 23:38:52

  @Jose: I was pointing out that the API does not need to be the same and the application can still be refactored; it's not the case that you can only shim in new code with the same API.
  
  You still haven't answered the question: where does the patented pixie-dust come from?

• Jose_X

  2009-01-14 23:39:15

  i did notice the ogg thing before but i didn't look that carefully because as I just said you still would violate a step of a larger patent that requires "play music file"

• Jose_X

  2009-01-14 23:40:43

  >> pixie-dust
  
  come on. are you reading?

• Jose_X

  2009-01-14 23:43:06

  I'll likely leave within the hour, but I'll pick up where left off.

• Jose_X

  2009-01-14 23:51:54

  This issue would be fixed if patents had to be ultra specific, but they aren't. And I'm not sure what "ultra" would mean either.
  
  And I do think sw patents are garbage.. but currently they can be costly garbage if not taken out.

• Jose_X

  2009-01-14 23:54:37

  >> This issue would be fixed
  
  haven't thought too much if this is "would" or "might" because I don't like patents and don't really follow their stupidities through court

• AlexH

  2009-01-15 00:02:58

  @Jose:
  
  

  i did notice the ogg thing before but i didn’t look that carefully because as I just said you still would violate a step of a larger patent that requires “play music file”

  
  
  We were talking in the context of the MP3 patent..
  
  I still don't see a specific example of where patentable matter might come from. We have:
  
  a. source code not implementing a patented method b. an API which we both agree isn't patentable c. a binary built from the above.
  
  You're claiming there could be a problem with c. Where precisely is the problem, and where did it come from?

• Jose_X

  2009-01-15 01:00:38

  "play music file" implements a "step"/component of a particular patent claim (not shown, but not the mp3 patent)
  
  It doesn't matter how you try to hide that (IKVM or whatever), if the judge sees the app plays a music file, it is fulfilling a "step" in that other patent. [this is a hypothetical example of course]
  
  The bits don't matter if the file plays and the patent claim stipulates the file plays.
  
  [For a violation, you'd need to fulfill the other parts of the claim as well, of course.]
  
  So do you see how bit manipulation may matter for some patents (maybe mp3 patent somewhere) but not for others?
  
  >> a. source code not implementing a patented method >> b. an API which we both agree isn’t patentable >> c. a binary built from the above.
  
  The source code does implement it along with the help of the libraries that implement the API:
  
  music.play()
  
  It doesn't matter how you get the music to play. Perhaps you violate the mp3 patent or not, but you do violate a different patent claim, one in which all other reqs are met along with playing the music.
  
  Here is another way to look at it.
  
  Assume that a claim including this play music req is violated. Now, can you avoid the violation by avoiding the music playing requirement? No. You either play the music or not. In one way, you violate, in the other the app breaks.
  
  [Keep in mind I haven't specified the details of that claim. We are doing a thought experiment and it can be done to this point just by knowing that playing music (at any point in time) will violate it if the rest of the claim is met. The question became, can you avoid the claim by avoiding the required claim component of playing music? No, not without affecting the intended behavior of the app.]
  
  Alex, at some point I am going to have to abandon you. I can't make you drink water.

• Jose_X

  2009-01-15 01:10:17

  >> Alex, at some point I am going to have to abandon you. I can’t make you drink water.
  
  We explored new ground recently, which is useful to me, even if you don't seem to be trying very hard to integrate what I say into your model, so that perhaps we are spending more time than ideal.
  
  Anyway, at some point I will have satisfied my thirst and will now want to hang around the stream all that much longer. That's what I meant.

• Jose_X

  2009-01-15 01:12:54

  I don't expect to convince everyone any more than I expect to convince Microsoft to give it up or expect to witness some other low probability event.

• Jose_X

  2009-01-15 01:17:16

  >> The source code does implement it along with the help of the libraries that implement the API:
  
  Technically, the source code doesn't implement it in most use cases. The app (binary) implements it leveraging the library (binaries). The source are the instructions so that the build system can put the application together as intended. Source is blueprint not actual final product.

• AlexH

  2009-01-15 01:23:42

  @Jose:
  
  

  Technically, the source code doesn’t implement it in most use cases. The app (binary) implements it leveraging the library (binaries). The source are the instructions so that the build system can put the application together as intended. Source is blueprint not actual final product.

  
  
  There is your mistake. Nothing in the library is put into the final product (that's known as "static linking"). The source is translated, not "constructed" somehow.
  
  The application is emphatically not implementing the patented code.

• AlexH

  2009-01-15 01:26:13

  @Jose:
  
  Also:
  
  

  music.play()
  
  It doesn’t matter how you get the music to play. Perhaps you violate the mp3 patent or not, but you do violate a different patent claim, one in which all other reqs are met along with playing the music.

  
  
  We were talking in the context of the MP3 patent. The IKVM example I gave doesn't violate that patent, and I don't understand at all where you get this "different patent claim" from.
  
  If you think that simple function calls can be entirely subject to patent claims then there isn't really much hope at all for you. Thankfully, the world isn't like that - software patents are bad enough as they exist now, they would be impossible to deal with in this hypothetical world of patented function calls.

• Jose_X

  2009-01-15 01:46:20

  >> There is your mistake. Nothing in the library is put into the final product (that’s known as “static linking”). The source is translated, not “constructed” somehow. >> The application is emphatically not implementing the patented code.
  
  The app (the binary) is very much constructed.. from the translated source.
  
  We're playing with the meaning of words though. Not very relevant. Use a different word if you want (but let me know your definitions -- like I explained "patent API" to you).
  
  The final product could be a computer or computers with the application running on its/their hardware (eg, mem, registers, io port state, storage disks, etc). I think that is the theory behind patenting software (ie, the approach used to fool the judge and scare the defendants).
  
  "Static" vs anything else is a detail of how the machine is running that application. It doesn't change the fact that a patent, that would be violated if music plays, is being violated because music is playing.
  
  The details you mention (eg, static) can be relevant. It depends on the patent. On how it was worded. Ex: did it imply a single computer or did it leave that variable, for example?
  
  I do hope patents on re-programmable hardware running software are never enforced. That wouldn't rescue us completely, but it's probably good enough for me; however, I don't think patent law is quite there yet. I assume the patents will be upheld for the purposes of pointing things like this out. Lot's of people, regardless of personal views on sw patents, will still play it safe, so I factor that in. I'm playing it safe, today, before I have a real headache on my hands.

• Jose_X

  2009-01-15 02:03:43

  >> We were talking in the context of the MP3 patent. The IKVM example I gave doesn’t violate that patent, and I don’t understand at all where you get this “different patent claim” from.
  
  No, the main theme of this thread is about what I am calling API-patent attacks. I picked up on your mp3 example a number of times in order to create analogies and better communicate the theme of the thread.
  
  Read the "music.play()" reply that I wrote not long ago again to get an idea of where that hypothetical patent claim comes from.
  
  >> If you think that simple function calls can be entirely subject to patent claims then there isn’t really much hope at all for you.
  
  Here is an MS patent. http://www.freepatentsonline.com/7013469.html
  
  Go tell the judge the gov made a mistake in granting the patent.
  
  I'll quote some:
  
  >> 2. A method as recited in claim 1, wherein the set of types support an event model including an event delegate that connects an event with a handler of the event, the set of base classes and types further comprising: one or more classes that hold event data; and one or more delegates that identify a method to provide a response to an event.
  
  >> 1. A computerized method in a distributed computing system comprising: handling, by an application, requests submitted by applications executing on remote devices over a network; and presenting, by an application program interface, functions used by the applications to access network and computing resources of the distributed computing system, wherein the application program interface comprises a set of base classes and types that are used in substantially all applications executing on the remote devices submitting requests, wherein the set of base classes and types comprises: an AsyncCallback delegate supplied to an application, wherein the AsyncCallback delegate references a callback method to be called when a corresponding asynchronous operation is completed; and an IAsyncResult interface that enables determination of the status of an asynchronous operation, wherein the IAsyncResult interface includes: an AsyncState property that returns the object that was provided as the last parameter as part of a Begin call corresponding to the asynchronous operation; an AsyncWaitHandle property that returns a WaitHandle that can be used to allow the application to wait for a call to be completed without needing to poll; a CompletedSynchronously property that is set to true if the Begin call corresponding to the asynchronous operation completed synchronously; and an IsCompleted property that is set to true after processing of the asynchronous operation is completed.
  
  Tell the judge how all of these actions being described in this patent can be effected by writing simple function calls into an ordinary text editor holding the rest of the application source code, then building the app from such source code, and then running it.
  
  Tell the judge how all of these abstract nouns can be build through function calls and class declarations in a suitable programming environment.
  
  Report back if you do get in touch with a relevant judge and have a positive message for us.

• Jose_X

  2009-01-15 02:13:31

  >> http://www.freepatentsonline.com/7013469.html
  
  It's a laughable patent I know.. but Microsoft has some pretty big muscles. If the USPTO arm of the US gov yielded to them, many smaller users and developers surely will as well, and I don't blame them, especially when there is a simple remedy: avoid dotnet and other Monopolysoft protocols/platforms/etc.
  
  That's what I am doing, prevention, because I don't want to have to stand in front of a judge and say that "despite Microsoft warning me of its intention to defend its patents and despite me clearly knowing I was using Microsoft created technology surrounded by controversy, I stand here now having taken the action they swore to defend against, but I don't want to fight the legitimacy of the patent, rather, I want your honor to throw out the case because I look good."

• Jose_X

  2009-01-19 15:54:35

  >> you’re still stuck on this idea of patenting APIs, which as I keep showing is impossible: no such patent exists.
  
  For the record, if we read over the portions of the MS patent recently quoted (claim 1), we find that their invention is:
  
  "A computerized method in a distributed computing system comprising: handling, by an application, requests ... and presenting, by an application program interface...."
  
  And from claim 12:
  
  "A computerized system comprising: means for handling requests ... and means for presenting functions ...."
  
  And from this other patent http://www.freepatentsonline.com/y2003/0028685.html :
  
  "A software architecture for a distributed computing system comprising: an application configured to handle requests ... and an application program interface to present functions...."
  
  Thus, it appears to me Microsoft was not shy about their intentions to patent machines ("computerized system"), processes ("computerized method"), and even "a software architecture" which includes "an application" and "an application program interface [API]."

• Jose_X

  2009-01-19 19:41:29

  This is a draft write-up covering a lot of the issues of a "patent-api" attack discussed on this thread: http://www.linuxtoday.com/news_story.php3?ltsn=2009-01-19-003-35-RV-DT-SW-0000

• Jose_X

  2009-01-20 20:04:31

  That draft is awful. I may use it as a guide since it covers most of the important topics; however, the following is likely to serve as an ok introduction.
  
  http://www.linuxtoday.com/news_story.php3?ltsn=2009-01-20-015-35-NW-SW-0010

• Roy Schestowitz

  2009-01-20 22:17:45

  I can post this nonetheless when you feel happy with it.

• Robert Millan

  2009-01-20 23:12:43

  This "RAND" term is a form of Newspeak. They try to put the words "reasonable" and "non-discriminatory" in your mouth, when neither of them is true (see http://www.gnu.org/philosophy/words-to-avoid.html#RAND).
  
  "RAND-z" is also nasty in that it reinforces the notion that a "RAND" may exist that is not "zero-payment".
  
  On the discussion about patenting interfaces, I think it's wrong to assume there's a deterministic way to tell if something is patentable or not, because the patent offices are full of shit in first place. I wouldn't be surprised if a patent covers all possible ways to implement a given API.
  
  What we _can_ tell is that certain areas are more heavily patented than others, and the non-Ecma extensions to .NET are likely to be heavily encumbered.

• Roy Schestowitz

  2009-01-20 23:16:20

  I've just found this from the FSF's Matt Lee:
  
  

  Building desktop applications without C or C#

  
  
  "Both of these are useful measures against C#, and potentially good ways of doing things JavaScript is the best dynamic scripting language, with a sweet spot between familiar syntax and power, and Vala’s idea of translation to C worked well for the old d2c Dylan compiler."

• Jose_X

  2009-01-21 02:05:15

  Robert Millan, here is my answer to whether using "safe" mono and avoiding the extension API makes sense or is truly safe: http://www.linuxtoday.com/news_story.php3?ltsn=2009-01-20-015-35-NW-SW-0013 .
  
  In short, stay away from "safe" mono, it's very possibly a trap that will get you when you are far into development. The reason is that basic uses of the core may be allowed, but interesting things will not be even if you invent your own API/functions/classes and avoid the official MS extension API. Once you are using the core, avoiding the official extension API might become an academic exercise that will do little to protect your more interesting apps from violations of generalized extension patents.
  
  Roy, probably these two "simplification" comments (the above and http://www.linuxtoday.com/news_story.php3?ltsn=2009-01-19-003-35-RV-DT-SW-0000 ) are what I wanted to communicate. I'll wait a few days to see if I want to change or add.
  
  I very much would appreciate comments on the two links (sendhello core patent example and the extensions discussion follow-up). Do these make sense? Sound reasonable? Are they written clearly?

• Jose_X

  2009-01-21 02:12:18

  Sometimes Linux Today hyperlinks to specific comments break/switch around, so it might be useful to follow the link to the main posting, http://www.linuxtoday.com/infrastructure/2009012001535NWSW , then look for comments titled "Better explanation of unavoidable violations" and "Is mono patent safe? Does it matter?"

• Jose_X

  2009-01-21 02:26:04

  >> Roy, probably these two “simplification” comments (the above and http://www.linuxtoday.com/news_story.php3?ltsn=2009-01-19-003-35-RV-DT-SW-0000 ) are what I wanted to communicate.
  
  D'oh, the link should have been http://www.linuxtoday.com/news_story.php3?ltsn=2009-01-20-015-35-NW-SW-0010 .
  
  >> In short, stay away from “safe” mono, it’s very possibly a trap that will get you when you are far into development. The reason is that basic uses of the core may be allowed...
  
  I should have recapped as well that the API-patent trick/deception is fool-proof to the extent the patent and API were created carefully. There need be no real huge innovation here. The violations cannot be worked around if you use such an API, so hope you have a patent grant if you are using the API.. but, even with license to the base API, the extension patents will likely get you once you go beyond simple applications. Double whammy: (a) violations you can't work around if you merely use such an API, and (b) violations you can't work around when you want to do anything interesting beyond the base API even if you avoid the extension API... [..assuming Company X did their homework well.]

• Dan O'Brian

  2009-01-23 15:16:26

  Jose: Your theory is worthless unless you can prove that .NET actually has a patent like that that Mono infringes upon.
  
  If you can't prove that, then all you are doing is spreading FUD.

• Roy Schestowitz

  2009-01-23 15:24:03

  I don't think he's intimately familiar with Microsoft's broad portfolio (neither am I).
  
  http://boycottnovell.com/2008/02/28/patent-pill-is-in-openness-pledge/

• Baby in the Bathwater

  2009-01-23 17:36:20

  This justifies spreading FUD about Mono, how, exactly?
  
  Someone could just as easily spread patent FUD about ANY OTHER FOSS project with your "theoretical patents". That doesn't make the FUD true.
  
  You like to talk about how morally righteous you guys are, but clearly you have a lower moral standing than Novell if you stoop to spreading this kind of FUD and insisting that it's true without any real evidence to back it up.
  
  If companies had morals as poor as you guys clearly have, they'd be spreading the same lies you guys spread about all FLOSS projects insisting that they infringe on these theoretical patents you guys love so much.
  
  Think about that.
  
  Note: this comment was posted from Novell's headquarters.

• Roy Schestowitz

  2009-01-23 17:43:31

  @Novell:
  
  Have you considered battling patents (properly) rather than legitimising them while at the same time choosing patents-encumbered technologies you don't even need?

• Baby in the Bathwater

  2009-01-23 19:40:01

  Roy: have you considered correcting your childish trolling behavior and being a moral human being for once? Novell does not "legitimize" patents by obtaining patents, because the patent system is already legitimate in the eyes of the industry.
  
  Oh, btw, Novell /does/ fight patents by helping EFF.
  
  You might also note that Novell does not sue competitors over patents, they only use them for defensive purposes. And lest you forget, Novell also donates patents to OIN to PROTECT Linux and FOSS.
  
  You might also note that Apple and some other software companies /do/ sue over patents and if Novell did not have patents itself, it would not be able to protect itself. Are you truly arguing that Novell and other FLOSS companies (like Red Hat and Canonical, for example) should willingly make themselves vulnerable to patent suits?
  
  If that is your argument, then I seriously question your support of FLOSS. Sounds more likely that you want to badmouth FLOSS companies and demand that they bend over so that more aggressive proprietary software companies like Apple can sue FLOSS companies out of existence.
  
  Note: this comment was posted from Novell's headquarters.

• Roy Schestowitz

  2009-01-23 19:56:34

  Speaking of conventional criticism, the EFF's project against junk patents is more symbolic than effective. It's even weaker than Linux Defenders.
  
  

  You might also note that Novell does not sue competitors over patents, they only use them for defensive purposes. And lest you forget, Novell also donates patents to OIN to PROTECT Linux and FOSS.

  
  
  True. Novell deserves credit for that.
  
  

  Are you truly arguing that Novell and other FLOSS companies (like Red Hat and Canonical, for example) should willingly make themselves vulnerable to patent suits?

  
  
  Canonical is very small. Red Hat filed amicus brief in Bilski IIRC.
  
  

  If that is your argument, then I seriously question your support of FLOSS. Sounds more likely that you want to badmouth FLOSS companies and demand that they bend over so that more aggressive proprietary software companies like Apple can sue FLOSS companies out of existence.

  
  
  I often compare this to the biggest threat that Earth is facing: nuclear strikes. This threat has immediate impact, unlike environmental catastrophe that is gradual.
  
  In order to redeem, one must dismantle now, not later. Any act of hypocrisy -- which in this case includes or equates to IBM, Sun and Novell -- will be perceived as similar to US possession of nuclear warheads and active refinement of uranium for hydrogen bombs. To say "do as I say but not as I do" (or "it's all right for me, but not for you") is the reason we have arms races. The Bush regime even further increased focus on armament while increasing resentment from the 'trolls' (again, you hopefully see the parables).
  
  The reason I bring up political analogies is to show you that Novell's motives will be better served by behaving according to the goals. You can't establish freedom (e.g. software) by endlessly making compromises and hope that freedom will be an endowment. Change comes through struggles from below, rarely as a gift from up above.
  
  It's time for Novell to play ball for change.