This is what I think about the Silverlight collaboration: d * If I were you, I would be just happy that Microsoft officially works towards supporting Silverlight in Linux, the banned word in Xbox live. * This move actually makes Silverlight a more open approach to multimedia in the web than Flash because AFAIK Adobe doesn't collaborate with gnash or other open source implementations.
But:
* I think we'll all agree that this collaboration can be seen as part of an strategy to gain acceptance in a flash dominated world. I've got no problem with that if this kind of competition benefits the users.. but why didn't Microsoft standarize Silverlight like they did with CLR and C#? This make me think that all this collaboration is temporal. They could drop it after getting a fair share of market. Of course, if anything this collaboration is better than nothing so even if people critizise it (and they will!), I don't feel you did a bad thing. * Will you continue to develop a parallel batery of open source test suite (like you have already) that are available not only to you but also to other independent open source developers? * What about microsoft patents? If I create my own linux distro or I use a distro that is not mainstream or just doesn't have a deal with the daemon.. err Microsoft.. like Novell has.. Will I have to suffer the shadow of Microsoft patents over Silverlight when using or developing Moonlight?
Thanks in advance, Eduardo Robles Elvira (Edulix).
* I think we'll all agree that this collaboration can be seen as part
> of an strategy to gain acceptance in a flash dominated world. I've got > no problem with that if this kind of competition benefits the users.. > but why didn't Microsoft standarize Silverlight like they did with CLR > and C#? This make me think that all this collaboration is temporal.
I do not blame them. OOXML is a superb standard and yet, it has been FUDed so badly by its competitors that serious people believe that there is something fundamentally wrong with it. This is at a time when OOXML as a spec is in much better shape than any other spec on that space.
Besides, it is always better to have two implementations and then standardize than trying to standardize a single implementation.
* Will you continue to develop a parallel batery of open source test
> suite (like you have already) that are available not only to you but > also to other independent open source developers?
Yes, those are some of the practices that we believe are core to Mono.
* What about microsoft patents? If I create my own linux distro or I
> use a distro that is not mainstream or just doesn't have a deal with > the daemon.. err Microsoft.. like Novell has.. Will I have to suffer > the shadow of Microsoft patents over Silverlight when using or > developing Moonlight?
Not as long as you get/download Moonlight from Novell which will include patent coverage.
> I do not blame them. OOXML is a superb standard and yet, it has been > FUDed so badly by its competitors that serious people believe that > there is something fundamentally wrong with it. This is at a time when > OOXML as a spec is in much better shape than any other spec on that > space.
> [...] > * What about microsoft patents? If I create my own linux distro or I
> > use a distro that is not mainstream or just doesn't have a deal with > > the daemon.. err Microsoft.. like Novell has.. Will I have to suffer > > the shadow of Microsoft patents over Silverlight when using or > > developing Moonlight?
> Not as long as you get/download Moonlight from Novell which will include > patent > coverage.
Do you seriously believe I owe you money for the privilege of reading text documents and browsing the web? What comes next?
On Sep 6, 12:37 am, "Miguel de Icaza" <miguel.de.ic...@gmail.com> wrote:
> Not as long as you get/download Moonlight from Novell which will include > patent coverage.
Is the patent coverage you are talking about here anything to do with Moonlight, or just the codec's Microsoft is providing Moonlight users? (I think I know the answer, but just to clear this point up).
> > Not as long as you get/download Moonlight from Novell which will include > > patent coverage.
> Is the patent coverage you are talking about here anything to do with > Moonlight, or just the codec's Microsoft is providing Moonlight > users? (I think I know the answer, but just to clear this point up).
All of Moonlight.
In fact the codecs will be downloaded from Microsoft and will have their own EULA.
> > Not as long as you get/download Moonlight from Novell which will > include > > patent coverage.
> Is the patent coverage you are talking about here anything to do with > Moonlight, or just the codec's Microsoft is providing Moonlight > users? (I think I know the answer, but just to clear this point up).
> All of Moonlight.
> In fact the codecs will be downloaded from Microsoft and will have > their own EULA.
Will that EULA be for non-commercial use only like the one we are discussing on the other thread?
I imagine the mpegla patent license will ve the same. But I have not seen that EULA.
You can choose to not get the MPEGLA license and use ffmpeg which contanins no such clause and is lgpl.
That being said, considering what I pointed out in the other thread, I suspect that "non-commercial" does not mean "use inside in a company" but "use the dxecoding for profit" considering that every MacOS has the exact same MPEGLA license terms.
On 9/7/07, Simon Phipps <webm...@gmail.com> wrote:
> On Sep 8, 2007, at 01:18, Miguel de Icaza wrote:
> > > Not as long as you get/download Moonlight from Novell which will > > include > > > patent coverage.
> > Is the patent coverage you are talking about here anything to do with > > Moonlight, or just the codec's Microsoft is providing Moonlight > > users? (I think I know the answer, but just to clear this point up).
> > All of Moonlight.
> > In fact the codecs will be downloaded from Microsoft and will have > > their own EULA.
> Will that EULA be for non-commercial use only like the one we are > discussing on the other thread?
On Sep 8, 5:38 am, "Miguel de Icaza" <miguel.de.ic...@gmail.com> wrote:
> That being said, considering what I pointed out in the other thread, I > suspect that "non-commercial" does not mean "use inside in a company" > but "use the dxecoding for profit" considering that every MacOS has > the exact same MPEGLA license terms.
That sounds reasonable, but note the terms say /personal/ and non- commercial...
On Sep 8, 3:24 pm, Webmink <webm...@gmail.com> wrote:
> That sounds reasonable, but note the terms say /personal/ and non- > commercial...
Yes, because you, as a *person*, are viewing video content in, let's say, your workplace (a commercial establishment), for yourself, not earning anything by that action (no commercial profit in it). Seeing that, as miguel as pointed out very thoroughly, MacOS comes with the very same licensing terms, and no one as any doubts that it can be used in the workplace, why do you keep pressing that maybe in this particular setting (silverlight), that very same words in that very same license might have a different meaning? Might it be you're thinking that, because it comes from Microsoft, they have somehow put a juju in it that makes the very same license say mean different things? :p
On 6 Sep., 07:37, "Miguel de Icaza" <miguel.de.ic...@gmail.com> wrote:
> OOXML is a superb standard and yet, it has been > FUDed so badly by its competitors that serious people believe that > there is something fundamentally wrong with it. This is at a time when > OOXML as a spec is in much better shape than any other spec on that > space.
Michael Meeks didn't seem to think so at FOSDEM 2007.
> >Will I have to suffer > > the shadow of Microsoft patents over Silverlight when using or > > developing Moonlight?
> Not as long as you get/download Moonlight from Novell which will include > patent > coverage.
You're saying two things here that really shock me. Please tell me I misunderstood.
1) You're saying that people _will_ have patent problems - i.e. Moonlight "infringes" MS patents and doesn't work around them. Even though Novell promised never to ship code that infringes MS patents - but always avoid them one way or another.
2) You're saying other distributors can't ship Moonlight legally (in the US) because of patent issues. Making Moonlight effectively non- free (as in freedom).
I hope it's just a matter of you being too fast on the trigger and your answer missing some elaboration - if this is the case you should really choose your words more carefully when talking about patents in the future - unless you want to hurt Novell.
If you're actually saying what it sounds like you're saying (see item #1 and #2) I can only say OMFG...
On 9/10/07, martin.schlan...@gmail.com <martin.schlan...@gmail.com> wrote:
> On 6 Sep., 07:37, "Miguel de Icaza" <miguel.de.ic...@gmail.com> wrote: > > OOXML is a superb standard and yet, it has been > > FUDed so badly by its competitors that serious people believe that > > there is something fundamentally wrong with it. This is at a time when > > OOXML as a spec is in much better shape than any other spec on that > > space.
> Michael Meeks didn't seem to think so at FOSDEM 2007.
That is odd. Michael and I have discussed this topic extensively. He certainly would like clarification in various areas and more details in some. But Michael's criticism (or for that matter, the Novell OpenOffice team working with that spec) seems to be incredibly different than the laundry list of issues that pass as technical reviews in sites like Groklaw.
The difference is that the Novell-based criticism is based on actually trying to implement the spec. Not reading the spec for the sake of finding holes that can be used in a political battle.
Finally, Michael sounded incredibly positive after the ECMA meeting last month when all of their technical questions were either answered or added to the batch of things to review. I know you are going to say "The spec is not owned by ECMA", well, currently the working group that will review the ISO comments is at ECMA.
For another view at OOXML look at what Jody Goldberg (no longer a Novell employee) has to say about OOXML and ODF from the perspective of implementing both:
I find it hilarious that the majority (not all) of the criticism for OOXML comes from people that do not have to write any code that interacts with OOXML. Those that know do not seem to mind (except those whose personal business is at risk because Microsoft moved away from a binary format to an XML format, which I also find hilarious).
> >Will I have to suffer > > > the shadow of Microsoft patents over Silverlight when using or > > > developing Moonlight?
> > Not as long as you get/download Moonlight from Novell which will include > > patent > > coverage.
> You're saying two things here that really shock me. Please tell me I > misunderstood.
1) You're saying that people _will_ have patent problems - i.e.
> Moonlight "infringes" MS patents and doesn't work around them. Even > though Novell promised never to ship code that infringes MS patents - > but always avoid them one way or another.
First of all, am not aware of such Novell promise to "never ship code that infringes MS patents". You can not make such statement because for one, the patent system is broken. Novell statements are wildly different, they are of the form "we do not believe that we infringe" and am sure they say something along the lines of "we dont plan on infringing, and we plan on removing infringing code". But I am not aware of all the promises Novell has made, and I can not comment on other parts of the organization. If you want an official answer, my personal blog on politics and poor attempts at humor is not the place to get an official answer. Contact Novell public relations for that.
But you might be referring to the policy that we use for Mono, and I will be happy to discuss those with you. The policies are on our FAQ, so you might want to read that before you post in panic again.
Moonlight does not have the same policy that Mono does in terms of us working around to remove infringing code. For one, we do not know what it could be (that is how the patent system works) and two we have agreed and have obtained permission from any patents that might exist in Moonlight to implement it. So our policy with Moonlight is different from Mono because of the requirements of this task (see mpegla.com for your own amusement).
That being said, in neither case are we aware of infringements. But like with any software piece, every 100 lines of code infringe someone's broken patent, there is just no way around that.
2) You're saying other distributors can't ship Moonlight legally (in
> the US) because of patent issues. Making Moonlight effectively non- > free (as in freedom).
Am not sure where you get the idea that the "US" is the only place where software patents exist. Free software people are under the mistaken impression that software patents are only a US thing, while many of the stake holders are European companies. The only difference is that in Europe your "software patent" is written to describe a machine. Law firms will offer you a set of checkboxes to "port" your patent from the US-wording to any other nation wording. And the patents are enforceable in most countries in the EU. Not surprising, as the EU owns many of patents on the media space.
We are obtaining covenants (from Microsoft) and patent licenses (from MPEGLA, the consortium of American, European and Asian companies that own the "media space") to be allowed to redistribute Moonlight with a minimal risk to the end user.
I say "minimal risk" and not "risk free", because that is the nature of software patents, we could be infringing a patent from some guy in Latvia for walking a linked list.
So that is the approach that we are taking to distribute for commercial use Moonlight, a plugin that operates in the media space: a patent rich and incredibly profitable space for the patent holders. The rights negotiated will give anyone patent coverage, as long as it is downloaded from Novell. Although I would like to fix the patent system, am not the one going to do so. It feels like boiling the ocean, and I have already done my share of ocean boiling, feel free to pick the good fight.
I hope it's just a matter of you being too fast on the trigger and
> your answer missing some elaboration - if this is the case you should > really choose your words more carefully when talking about patents in > the future - unless you want to hurt Novell.
Well, it certainly merits an extended explanation. I have tried to summarize some of the issues above media patents but the space is incredibly complicated and no amount of one-liners can precisely describe the problems, the limitations and all the special conditions attached to them.
The problem is that people think that the problem is as simple as "patents bad" and everyone wrapping his virtual kafia around his head and running to the streets yelling "death to patents" has no idea how complex the system is and how little effect yelling has on actually changing anything. If you want to engage on a serious patent discussion, I would love to do so, but you are going to need some legal training and get a lot more depth before we can have a productive discussion.
If you're actually saying what it sounds like you're saying (see item
> #1 and #2) I can only say OMFG...
Well, I did not say that. So you can put the Ventolin down and breathe.
On Sep 11, 1:26 am, "Miguel de Icaza" <miguel.de.ic...@gmail.com> wrote:
> The problem is that people think that the problem is as simple as "patents > bad" and everyone wrapping his virtual kafia around his head and running to > the streets yelling "death to patents" has no idea how complex the system is > and how little effect yelling has on actually changing anything. If you > want to engage on a serious patent discussion, I would love to do so, but > you are going to need some legal training and get a lot more depth before we > can have a productive discussion.
With respect to all of your deep understanding of the patent issue and your assumption that most of the people doesn't understand this *huge complicated* issue, i don't see the point of how it is not logical for one wanting to throw away patent (yelling "death to patent") just knowing the basic fact that it may hinder (which it usually does) the concept freedom. Somebody keeping a patent right on something and providing it for free to me is not good enough as there can be situation where this "providing for free" is discontinued.
Above all, what is the problem to get rid of a *very leagal serious complex* system which may result in the same situation as not having the system at all. If you don't understand this concept let me know, i will try to dumb it down.
Also one other note, i have seen the noise relating to this OOXML standard. Now that you are claiming OOXML to be "superb" I guess you are one real person (outside MS gallery. are you?!!?) who has a substantial understanding of the standard - you are one person to ask.
Can you verify if the concerns prompted in the following link is all FUD or not?
On 6 Sep, 07:37, "Miguel de Icaza" <miguel.de.ic...@gmail.com> wrote:
> OOXML is a superb standard and yet, it has been FUDed so badly by > its competitors that serious people believe that there is something > fundamentally wrong with it. This is at a time when OOXML as a spec > is in much better shape than any other spec on that space.
I have absolutely no commercial interest in the Office format space, but I still find the OOXML specification to be utter crap. As a developer, I think it's of so poor quality that it's very difficult to get even the simplest things right. Stéphane Rodriguez touches upon a couple of the problems in his blog post "OOXML is defective by design"[1].
I agree that there has been a lot of FUD over OOXML, but even after sorting through it and reading (parts of) the specification, I think it's catastrophic, from a technical standpoint. If the specification is so superb, then you might be able to explain how the backward compatibility flags "autoSpaceLikeWord95", "footnoteLayoutLikeWW8", "lineWrapLikeWord6", "mwSmallCaps", "optimizeForBrowser", "shapeLayoutLikeWW8", "supressTopSpacingWP", "truncateFontHeightsLikeWP6", "useWord2002TableStyleRules", "useWord97LineBreakRules", "useWord97LineBreakRules", "wpJustification", "wpSpaceWidth", "sldSyncPr", "securityDescriptor" and "revisionsPassword" are supposed to be implemented? Does the specification say?
How do you implement the different style labels used in the specification, like "chicago", "ideographDigital", "ideographLegalTraditional", "koreanDigital2" and "koreanLegal"? These labels are just named; how they are supposed to be implemented and look like is up to interpretation. Also, how is the "securityDescriptor" attribute supposed to be implemented interoperably? It has no defined semantics or data structure. It is impossible to know how to handle this without reverse engineering Microsoft Office 2007 documents using this attribute.
Do you think an international standard should contain wording like "For legacy reasons, an implementation using the 1900 date base system shall treat 1900 as though it was a leap year. [...] A consequence of this is that for dates between January 1 and February 28, WEEKDAY shall return a value for the day immediately prior to the correct day, so that the (non-existent) date February 29 has a day-of-the-week that immediately follows that of February 28, and immediately precedes that of March 1."?
Wouldn't it be more sane to just use the Gregorian calendar and preserve this backward compatibility through conversion filtering inside Microsoft Office instead? After all, the binary documents are still proprietary and closed source, so direct compatibility with those documents in other applications than Microsoft Office is a non- concern for the OOXML specification. Right?
And how can a "superb standard" implement features ("Basic String") that break XML conformance when used? And is it a "superb standard" worthy to use opaque bitmask integers to encode information instead of XML itself? I don't think that's very good XML design at least. I also think it's bad software design in general to use your own date formats (instead of relying on international standards like ISO-8601 or RFC-3339) and not even being consistent within the specification it's used. There are several incompatible date serialization formats used in OOXML, which all require their own deserialization/serialization algorithms, test suites, etc. This is a burden on the developer and will cause interoperability problems.
A standard, especially a "superb" one, should provide a summary of good and best practice based on consensus of expert opinion. OOXML is just an XML-serialized dump of Microsoft Office 2007's internal object hierarchy, and just by skimming quickly through the specification you should find so many glaringly ugly design decisions that you, as a developer, should be hard pressed to call it a "superb standard". It doesn't follow best practices, it ignores existing well-deployed and well-known global standards, it relies on proprietary, binary, unspecified and probably patented formats (like VML, EMF and WMF), it doesn't go into enough detail on a lot of properties that, if not implemented correctly (which is impossible with the current specification), will hurt interoperability.
Seeing that Microsoft and Brian Jones don't even commit to complying with OOXML[2], I don't see the value of the standard at all. It would provide some value, even in its current (far from perfect) form, but without support in Microsoft Office, it's just 6.000 pages of meaningless junk. So, do you still stand by your statement that OOXML is a "superb standard"? If you do, I'd love if you could go into detail on what makes it so superb, because all I see is a very poor specification that (in the future) doesn't even specify Microsoft Office's default formats.
Miguel wrote: > OOXML is a superb standard and yet, it has been > FUDed so badly by its competitors that serious people believe that > there is something fundamentally wrong with it.
There *is* something fundamentaly wrong with the proposed OOXML standard. In fact, more than one thing.
> The problem is that people think that the problem is as simple as "patents > bad" and everyone wrapping his virtual kafia around his head and running to > the streets yelling "death to patents" has no idea how complex the system is > and how little effect yelling has on actually changing anything.
First, I do believe software patents are bad.
Second, I do think the Mono project is great, and there patent policy makes sense for a product. (http://www.mono-project.com/ FAQ:_Licensing#Patents). However, for a spec to become an ISO standard, it should be open to be implemented legally, and if any patents are blocking that requirements, sound guarantees should be given.
But the patents problem is only one of the many problems surrounding OOXML. More fundamentally, the specification requires implementers to implement bugs (such as 29 February 1900) and to emulate strange behaviour of old Microsoft-products without describing what that behaviour is. That is, amongs other defections, most of them by design.
I have great doubts that anyone that claims that the OOXML spec is superb, actually read the spec, or even just parts of the spec.
Just one question as I've not made my mind up yet about the whole picture about OOXML, gnome, the open source and microsoft, I wont judge at this point the quality of OOXML specification, but it seems that microsoft has been bribing and playing not so nice to try to ensure the aproval of OOXML as ISO standard.
What do you think about that, rather than the technologic point of view?
Un saludo
On Sep 6, 7:37 am, "Miguel de Icaza" <miguel.de.ic...@gmail.com> wrote:
> * I think we'll all agree that this collaboration can be seen as part
> > of an strategy to gain acceptance in a flash dominated world. I've got > > no problem with that if this kind of competition benefits the users.. > > but why didn't Microsoft standarize Silverlight like they did with CLR > > and C#? This make me think that all this collaboration is temporal.
> I do not blame them. OOXML is a superb standard and yet, it has been > FUDed so badly by its competitors that serious people believe that > there is something fundamentally wrong with it. This is at a time when > OOXML as a spec is in much better shape than any other spec on that > space.
> Besides, it is always better to have two implementations and then > standardize > than trying to standardize a single implementation.
> * Will you continue to develop a parallel batery of open source test
> > suite (like you have already) that are available not only to you but > > also to other independent open source developers?
> Yes, those are some of the practices that we believe are core to Mono.
> * What about microsoft patents? If I create my own linux distro or I
> > use a distro that is not mainstream or just doesn't have a deal with > > the daemon.. err Microsoft.. like Novell has.. Will I have to suffer > > the shadow of Microsoft patents over Silverlight when using or > > developing Moonlight?
> Not as long as you get/download Moonlight from Novell which will include > patent > coverage.
> I find it hilarious that the majority (not all) of the criticism for OOXML > comes from people that do not have to write any code that interacts with > OOXML. Those that know do not seem to mind (except those whose personal > business is at risk because Microsoft moved away from a binary format to an > XML format, which I also find hilarious).
I was wondering if OOXML could be propery diff'd in CVS or any other sort of versioning system. If so, that would be much better than the binary .DOCs.
> > >Will I have to suffer > > > > the shadow of Microsoft patents over Silverlight when using or > > > > developing Moonlight?
> > > Not as long as you get/download Moonlight from Novell which will include > > > patent > > > coverage.
> > You're saying two things here that really shock me. Please tell me I > > misunderstood.
> 2) You're saying other distributors can't ship Moonlight legally (in
> > the US) because of patent issues. Making Moonlight effectively non- > > free (as in freedom).
> We are obtaining covenants (from Microsoft) and patent licenses (from > MPEGLA, the consortium of American, European and Asian companies that own > the "media space") to be allowed to redistribute Moonlight with a minimal > risk to the end user.
> I say "minimal risk" and not "risk free", because that is the nature of > software patents, we could be infringing a patent from some guy in Latvia > for walking a linked list.
> So that is the approach that we are taking to distribute for commercial use > Moonlight, a plugin that operates in the media space: a patent rich and > incredibly profitable space for the patent holders. The rights negotiated > will give anyone patent coverage, as long as it is downloaded from Novell. > Although I would like to fix the patent system, am not the one going to do > so. It feels like boiling the ocean, and I have already done my share of > ocean boiling, feel free to pick the good fight.
I don't think you have really addressed the question of the separation you have created between Novell and the other Linux distributors by means of this "covenant" and the implications thereof.
On Sep 7, 6:29 pm, "Miguel de Icaza" <miguel.de.ic...@gmail.com> wrote:
> Hello,
> Do you seriously believe I owe you money for the privilege of reading
> > text documents and browsing the web? What comes next?
> Who said so?
> You do not have to pay anyone any money. Duh.
That's nice. In that case, would you convince your employer's partners to issue a free, public grant for all patents covering OOXML and Moonlight ? I'd rather not have to pay for "protection" next time I am forced to open a "superb" document or visit a "superb" website.
> > >Will I have to suffer > > > > the shadow of Microsoft patents over Silverlight when using or > > > > developing Moonlight?
> > > Not as long as you get/download Moonlight from Novell which will include > > > patent > > > coverage.
> > You're saying two things here that really shock me. Please tell me I > > misunderstood.
> 2) You're saying other distributors can't ship Moonlight legally (in
> > the US) because of patent issues. Making Moonlight effectively non- > > free (as in freedom).
> So that is the approach that we are taking to distribute for commercial use > Moonlight, a plugin that operates in the media space: a patent rich and > incredibly profitable space for the patent holders. The rights negotiated > will give anyone patent coverage, as long as it is downloaded from Novell. > Although I would like to fix the patent system, am not the one going to do > so. It feels like boiling the ocean, and I have already done my share of > ocean boiling, feel free to pick the good fight.
It seems that you haven't really directly addressed the question of your separation between Novell and other Linux distributors with respect to "patent coverage", and the implications thereof.
Also one other note, i have seen the noise relating to this OOXML
> standard. Now that you are claiming OOXML to be "superb" I guess you > are one real person (outside MS gallery. are you?!!?) who has a > substantial understanding of the standard - you are one person to ask.
> Can you verify if the concerns prompted in the following link is all > FUD or not?
Well, the document talks about "legalities" but its based on a "cursory legal study". I did not even pay attention to the rest, it looks like the usual stuff people put out.
> That's nice. In that case, would you convince your employer's > partners to issue a free, public grant for all patents covering OOXML > and Moonlight ? I'd rather not have to pay for "protection" next time > I am forced to open a "superb" document or visit a "superb" website.
You do not have to pay anyone for using OOXML or Moonlight.
You might want to direct your fake outrage at an actual problem, rather than imaginary ones.
> I find it hilarious that the majority (not all) of the criticism for OOXML > comes from people that do not have to write any code that interacts with > OOXML.
|
