The only questions remaining - why didn't the OP check with you, why didn't Slashdot editors check with you, and why hasn't there been an article update already?
Actually the IDG journalist involved did contact me; the text I posted above was copied from my reply to him! He even quoted the "build bridges" bullet...
I'm OSI's current president. Here are the facts that are missing from the OP:
OSI has not sent any legal notice to OSHWA, does not want to and has no plans to do so.
OSHWA approached OSI last year to ask about the relationship between the OSHW and OSI logos, which their internal discussion had identified as a problem.
Since then, there has been an ongoing conversation between OSI & OSHWA. It's not been perfect, but everyone involved is a volunteer doing their best in a complicated situation.
Last week OSHWA decided to consult its members/stakeholders about the matter before next steps with OSI.
The template trademark agreement from OSI that they published was not a proposal or demand, it was just an example document to assist them in making a proposal to OSI. It was requested by OSHWA prior to a meeting between OSI & OSHWA on June 29.
The discussions are ongoing and it's unhelpful to treat this as a conflict; neither OSI's Board nor (as far as I have been told) OSHWA's board do.
OSI is very keen indeed to devise an approach that brings maximum benefit to the whole open source community and which builds bridges to strengthen it.
When OSHWA's data-gathering ends (August 16) OSI will be ready with a strong proposal that fixes things.
While saying "Apple isn't blocking Sun/Oracle's ability to ship Java for the OS X platform" sounds wonderful, it neglects reality. I'm guessing you should read both Gosling's posting and my article. Gosling explains:
It simply isn't true that “Sun (now Oracle) supplies Java for all other platforms”. IBM supplies Java for IBM's platforms, HP for HP's, even Azul systems does the JVM for their systems (admittedly, these all start with code from Snorcle - but then, so does Apple). In the beginning, Microsoft provided Java for Windows... Apple was the same...
and I explain:
Having Oracle take over the development would be hard for several reasons:
First, the Java port in use includes a lot of Apple know-how that is not generally available (such as private interfaces) to make Java integrate well rather than using just X11.
Second, it belongs to Apple, so Oracle would either have to receive a copy of Apple's implementation or start again with all the UI and platform native code.
Third, distribution would move outside Apple's update mechanism so keeping it patched and secure would be difficult - a new installer and update mechanism will be needed.
Fourth, the new AppStore rules will make sure there's negligible demand for consumer Java on the Mac.
Your view would make a good Apple PR position but doesn't address the actual complexities of the situation.
There are perfectly fine versions of both LibreOffice and indeed OpenOffice.org for the Mac, and many people haven't used NeoOffice in an age (and I don't think it depends on Java anymore anyway).
Whatever the consequences of Jobs ditching Java might be (and I assert they are significant) they don't include a threat to open source office productivity apps.
The best way to put something as close to public domain as possible is the Creative Commons CC-Zero license. Anything less that that leaves too many legal uncertainties.
/* * Sun RPC is a product of Sun Microsystems, Inc. and is provided for * unrestricted use provided that this legend is included on all tape * media and as a part of the software program in whole or part. Users * may copy or modify Sun RPC without charge, but are not authorized * to license or distribute it to anyone else except as part of a product or * program developed by the user. * * SUN RPC IS PROVIDED AS IS WITH NO WARRANTIES OF ANY KIND INCLUDING THE * WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS FOR A PARTICULAR * PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE. * * Sun RPC is provided with no support and without any obligation on the * part of Sun Microsystems, Inc. to assist in its use, correction, * modification or enhancement. * * SUN MICROSYSTEMS, INC. SHALL HAVE NO LIABILITY WITH RESPECT TO THE * INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY SUN RPC * OR ANY PART THEREOF. * * In no event will Sun Microsystems, Inc. be liable for any lost revenue * or profits or other special, indirect and consequential damages, even if * Sun has been advised of the possibility of such damages. * * Sun Microsystems, Inc. * 2550 Garcia Avenue * Mountain View, California 94043 */
The new one is:
/* * Copyright (c) 2010, Oracle America, Inc. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions are * met: * * * Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * Redistributions in binary form must reproduce the above * copyright notice, this list of conditions and the following * disclaimer in the documentation and/or other materials * provided with the distribution. * * Neither the name of the "Oracle America, Inc." nor the names of its * contributors may be used to endorse or promote products derived * from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE * COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE * GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */
Check out the Illumos announcement. Slides 18 and 19 in the deck about that. The Illumos people have made a bootable system with closed bits of libc (including full locale support) replaced, replacements for the most critical closed source utilities and replacements for some drivers. Still to do:
NFS/CIFS lock manager
Full kcf module/daemon (crypto framework)
Trusted Extensions (labeld)
Many more drivers
That's plenty of work but there are people willing and able to get it done and they have a bootable system to evolve. The real question is when someone will kick off a full distro around it (since Illumos is purely a kernel).
Your description does not match any of the facts available to me as a new Board member, so I suggest you contact me via e-mail: webmink (at) opensource (dot) org
We believe everything is now up to date - the IRS filings were part of the same issue we inherited from the early days of OSI. We (mainly OSI's Treasurer Danese Cooper actually) worked on these issues last year with the help of DLA Piper (law firm donating their service) and today we are completely in the good graces of both the IRS and the California State Franchise Tax Board.
If you are aware of other issues that haven't popped up on our radar, please tell osi (at) opensource (dot) org so we can fix them. I realise that's not so much fun as posting them on Slashdot first, but it will help get things fixed faster just like filing a fix on Subversion fixes software faster than writing to The Register about it.
Re:we need OSI to keep their paperwork current
on
Why We Still Need OSI
·
· Score: 3, Interesting
Note that the story here was that, much to the current Board's surprise, it turned out that accounts for some previous years well in the past had been created but for some unknown reason not filed with the State of California. The first the current Board knew of this was when we heard about the suspension. We immediately located the old accounts and arranged for them to be retrospectively filed, and in response the State lifted its suspension.
Naturally there are people who want to keep the memory of this incident alive and are doing their best to raise it every time OSI is mentioned. While not desirable, we've since heard from many sources that this is an all-too-common event for all-volunteer organisations.
If you read the WayBack caches you'll see that the license has been the same since at least 2008 apart from the mention of Oracle. The way the licensing works is that you agree to the bulk of the terms in order to download Solaris, and then additionally get a certificate of entitlement to use it beyond the 90 day eval period when you register it. No register - no permanent license.
Messy but not a problem. And if it is a problem, there's always OpenSolaris.
To be clear, SPARC International is an independent trade association. You should not be blaming Sun, Hitachi, Fujitsu or any other SPARC licensee for this.
I just want to make it clear, on Sun's behalf, that this trademark action was not initiated by Sun and that all the hatred expressed towards Sun on this issue is misplaced. SPARC International is an independent trade association (it has been for a very long time) and makes its own decisions about trademark enforcement. I wouldn't have acted the way they are, and I have asked Sun's representative to SPARC International to investigate the issue, but beyond using its status as one of many licensees and members, I'm not aware of anything more that Sun can do.
Because the subset that every other cloud provider makes will be different, and then you'll need to refactor to run on other clouds. That extra friction will lead to you finding it hard to move between providers, and that's called "lock-in".
What we need is an agreed "Java Web Edition" profile from the JCP. Maybe Google could contribute their work?
Note that this means that if Sun pulls out of OASIS, future OASIS development of ODF is under a patent cloud.
No, that is not the case. In the unlikely event of Sun pulling out of the ODF TC at OASIS (which it currently chairs), future versions of the standard would be covered to the extent they implemented the specifications published while Sun was still a member. Sun's unlikely withdrawal would not invalidate previous covenant protection. Additions to the standard made once Sun was no longer a participant would not be covered. That seems completely reasonable considering anyone could add anything in Sun's absence.
As far as the necessary claims language goes, note that IBM has it, too. Open source developers seem to have managed to deal with it there, so I expect they'll manage to deal with it in Microsoft's covenant, too.
IBM's decision to restrict patent protection to only "necessary claims" is deeply regrettable and makes their promises of little value in giving developers certainty. IBM came to the patent covenant table even later than Microsoft, and so far open source developers have had very little time to consider the implications of that deficiency, so I think you're a bit premature calling the all-clear.
The cause of software freedom is ill-served by the tired re-application of discredited ideas from the patent-encumbered world of standards. We should be demanding full patent safety from standards bodies as a routine part of their process. Both IBM and Microsoft do us all a disservice by perpetuating "necessary claims" language because it results in a situation where the only people able to gain certainty about their actions are those with access to legal advice. To remind you of what I said in my blog about "necessary claims":
Whenever I see this phrase my lawyer alarm goes off as it immediately involves a judgment call which is the subjective right of the patent holder. It comes accompanied by the question "was our patent really necessary for this implementation? Surely you could have done it this other way and thus not needed it. It's actually not necessary so here's the invoice." I'd like to see that phrase replaced with language to indicate that no patent claims will be made against source code implementing the standard, with no necessity test involved.
That patent non-assert covenant is almost identical... to Microsoft's patent no- assert covenant
That's because Microsoft based their document on Sun's. I know that because the author of the Sun covenant is a colleague, because it was released at least a year before Microsoft copied it and because, after I pointed this out, Microsoft credited Sun for the original document.
(and the differences are in the parts that aren't important)
I disagree, and I have explained why before on my blog. Sun's covenant is intended to empower open source developers, and Microsoft has altered the parts that make that happen. Most notably, Sun's covenant grants all patents, Microsoft's is limited to "necessary claims". That is a very major difference since it means open source developers cannot be sure they have actually been given cover by Microsoft's covenant whereas they can be certain they have by Sun's. It is deeply regerttable that Microsoft added essential claims language in this way. For those who don't follow links, I also find the conformance requirements and the patent peace asymmetry poor in Microsoft's document.
Many have said that the latter is unacceptable for use with free software.
Indeed, and I am among them. However, your implication that the same applies to Sun's covenant is incorrect.
We (that's Sun Microsystems) chose the GPL as the license under which to release everything necessary to make an UltraSPARC T1 (and more recently, T2). We placed it all - RTL, tools, the lot - at OpenSPARC.Net. The license choice was for two main reasons:
We felt the GPL was widely accepted as a Free license. We hoped that would encourage all kinds of people to feel free to take a look.
We wanted those who used the code from OpenSPARC to publish the new work they built from it.
While releasing hardware sources under a Free license is a different deal to software, the GPL seems to encourage the same willingness to examine and use the code as it does in software. The mechanisms for community have to be different because of the capital-intensive nature of the processes to use the code. We've still seen people rework it to fit it on FPGAs, create single-core chips for embedding and run university degree courses on it. I remain pretty happy with the license choice we made.
Sounds like a populist position, or maybe troll flamebait. I'll be generous and assume the former, despite the fact your post seems like a digest from an anti-ODF briefing paper. Disclosure:My job includes the task of receiving complaints about Sun and trying to get Sun to fix whatever causes the problem. If you have proof of any of your accusations, let me know. I may have some of my facts wrong below as I'm working from memory; I'd welcome correction.
With a few small additions, ODF could have supported Office formats as well, but Sun would not allow this.
That is indeed the constant assertion that the three guys who comprise the Foundation make. However, I have personally asked members of the ODF working group at OASIS and they tell me its not so.
The Foundation guys wanted to add structures to ODF to preserve untranslateable tags in translated documents so they could be regenerated on the reverse translation. Sounds OK at first glance, but in practice it results in very brittle software solutions that work well in demos but not in real life.
The proposal was thus rejected by the whole working group (not just the Sun employees).
Rejected, that is, in conversation. A complete solution was never proposed for voting.
To say Sun would not allow it ignores the actual dynamic of the working group (see below).
Their policy is that ODF will support what is needed for StarOffice, and nothing more.
Naturally every member of a standards group in the traditional standards process is looking out for the code base where they implement a standard, and will have serious questions of any feature that they regard as unimplementable. The features actually put to a vote by the guys from the Foundation would have resulted in very brittle implementations, highly dependent on the version of MS Office with which they were coupled. It may have been possible to come up with a solution that reduced this problem, but the discussion was not sustained. The assertion you make is not true in the general case.
They control the ODF technical committee
Untrue. The ODF TC can have no more than three members from any one organisation and is not under the control of any organisation. The Foundation guys actually flaunted that rule at one point and sent many, many more representatives - OASIS had to step in to fix it. That intervention is one of the issues they have with OASIS, in fact. Sun happens to employ the people who act as Chair and Secretary to the TC but the voting remains democratic.
and their patent license allows them to stop the ODF TC if the ODF TC goes in a direction Sun does not like.
I've heard that interpretation of the patent non-assert covenant that Sun has made regarding ODF, but it's untrue. Sun covenants not to enforce any patents against ODF implementations based on any spec it participates in. To the extent that versions of the spec after Sun's departure are based on version in which Sun was involved, that covenant remains in effect even in the unlikely event of Sun leaving the TC. Sun can't stop the TC from continuing its work.
Are you relaying this all as hearsay, or do you actually have data to back up your accusations? If you have, I'd like to see it (genuinely).
Sorry, you're an anonymous troll or worse. Switching the subject to the endless twisty passages of flawed application of the GPL is a game and I'm not going there. You're twisting (or not reading) what I am writing (the legal opinion I linked was by SFLC, not FSF, and was on behalf of Apache; the use of the phrase "Essential Claims" by Moglen was part of a discussion of the OASIS patent policy where the term is used to define baseline RAND licensing; and so on).
I've given a reasoned interpretation and made assertions on Sun's behalf, and you're responding with sophistry and the sort of understanding of the law and courts one finds on certain mailing lists. I've read your posting history and seen that you never give up, so sorry, I'm not playing.
Slashdot Mirror
Seems the Slashdot editor has broken the link - the file is easily available from the link in the article.
The only questions remaining - why didn't the OP check with you, why didn't Slashdot editors check with you, and why hasn't there been an article update already?
Actually the IDG journalist involved did contact me; the text I posted above was copied from my reply to him! He even quoted the "build bridges" bullet...
I'm OSI's current president. Here are the facts that are missing from the OP:
Still wrong. The JVM Microsoft created for Windows (until they embarked on their fateful "embrace & extend") was a port of the Sun JVM.
and I explain:
Your view would make a good Apple PR position but doesn't address the actual complexities of the situation.
There are perfectly fine versions of both LibreOffice and indeed OpenOffice.org for the Mac, and many people haven't used NeoOffice in an age (and I don't think it depends on Java anymore anyway). Whatever the consequences of Jobs ditching Java might be (and I assert they are significant) they don't include a threat to open source office productivity apps.
It's not quite a BSD license if they require the source and binaries contain that notice.
That's a pretty vanilla 3-clause BSD licence just like you'd see anywhere else, I don't see a problem with it.
The best way to put something as close to public domain as possible is the Creative Commons CC-Zero license. Anything less that that leaves too many legal uncertainties.
The original license text was:
/*
* Sun RPC is a product of Sun Microsystems, Inc. and is provided for
* unrestricted use provided that this legend is included on all tape
* media and as a part of the software program in whole or part. Users
* may copy or modify Sun RPC without charge, but are not authorized
* to license or distribute it to anyone else except as part of a product or
* program developed by the user.
*
* SUN RPC IS PROVIDED AS IS WITH NO WARRANTIES OF ANY KIND INCLUDING THE
* WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS FOR A PARTICULAR
* PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE.
*
* Sun RPC is provided with no support and without any obligation on the
* part of Sun Microsystems, Inc. to assist in its use, correction,
* modification or enhancement.
*
* SUN MICROSYSTEMS, INC. SHALL HAVE NO LIABILITY WITH RESPECT TO THE
* INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY SUN RPC
* OR ANY PART THEREOF.
*
* In no event will Sun Microsystems, Inc. be liable for any lost revenue
* or profits or other special, indirect and consequential damages, even if
* Sun has been advised of the possibility of such damages.
*
* Sun Microsystems, Inc.
* 2550 Garcia Avenue
* Mountain View, California 94043
*/
The new one is:
/*
* Copyright (c) 2010, Oracle America, Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are
* met:
*
* * Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* * Redistributions in binary form must reproduce the above
* copyright notice, this list of conditions and the following
* disclaimer in the documentation and/or other materials
* provided with the distribution.
* * Neither the name of the "Oracle America, Inc." nor the names of its
* contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
* FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
* COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
* INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
* GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
* WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
* NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
That's plenty of work but there are people willing and able to get it done and they have a bootable system to evolve. The real question is when someone will kick off a full distro around it (since Illumos is purely a kernel).
Your description does not match any of the facts available to me as a new Board member, so I suggest you contact me via e-mail: webmink (at) opensource (dot) org
We believe everything is now up to date - the IRS filings were part of the same issue we inherited from the early days of OSI. We (mainly OSI's Treasurer Danese Cooper actually) worked on these issues last year with the help of DLA Piper (law firm donating their service) and today we are completely in the good graces of both the IRS and the California State Franchise Tax Board.
If you are aware of other issues that haven't popped up on our radar, please tell osi (at) opensource (dot) org so we can fix them. I realise that's not so much fun as posting them on Slashdot first, but it will help get things fixed faster just like filing a fix on Subversion fixes software faster than writing to The Register about it.
Note that the story here was that, much to the current Board's surprise, it turned out that accounts for some previous years well in the past had been created but for some unknown reason not filed with the State of California. The first the current Board knew of this was when we heard about the suspension. We immediately located the old accounts and arranged for them to be retrospectively filed, and in response the State lifted its suspension.
Naturally there are people who want to keep the memory of this incident alive and are doing their best to raise it every time OSI is mentioned. While not desirable, we've since heard from many sources that this is an all-too-common event for all-volunteer organisations.
If you read the WayBack caches you'll see that the license has been the same since at least 2008 apart from the mention of Oracle. The way the licensing works is that you agree to the bulk of the terms in order to download Solaris, and then additionally get a certificate of entitlement to use it beyond the 90 day eval period when you register it. No register - no permanent license.
Messy but not a problem. And if it is a problem, there's always OpenSolaris.
First I heard of it was on Friday evening.
To be clear, SPARC International is an independent trade association. You should not be blaming Sun, Hitachi, Fujitsu or any other SPARC licensee for this.
S.
I just want to make it clear, on Sun's behalf, that this trademark action was not initiated by Sun and that all the hatred expressed towards Sun on this issue is misplaced. SPARC International is an independent trade association (it has been for a very long time) and makes its own decisions about trademark enforcement. I wouldn't have acted the way they are, and I have asked Sun's representative to SPARC International to investigate the issue, but beyond using its status as one of many licensees and members, I'm not aware of anything more that Sun can do.
S.
(speaking officially for once)
Because the subset that every other cloud provider makes will be different, and then you'll need to refactor to run on other clouds. That extra friction will lead to you finding it hard to move between providers, and that's called "lock-in". What we need is an agreed "Java Web Edition" profile from the JCP. Maybe Google could contribute their work?
Indeed. Any addition can be made freely, and that addition will be the sole responsibility of those making it. Just like with software.
No, that is not the case. In the unlikely event of Sun pulling out of the ODF TC at OASIS (which it currently chairs), future versions of the standard would be covered to the extent they implemented the specifications published while Sun was still a member. Sun's unlikely withdrawal would not invalidate previous covenant protection. Additions to the standard made once Sun was no longer a participant would not be covered. That seems completely reasonable considering anyone could add anything in Sun's absence.
IBM's decision to restrict patent protection to only "necessary claims" is deeply regrettable and makes their promises of little value in giving developers certainty. IBM came to the patent covenant table even later than Microsoft, and so far open source developers have had very little time to consider the implications of that deficiency, so I think you're a bit premature calling the all-clear.
The cause of software freedom is ill-served by the tired re-application of discredited ideas from the patent-encumbered world of standards. We should be demanding full patent safety from standards bodies as a routine part of their process. Both IBM and Microsoft do us all a disservice by perpetuating "necessary claims" language because it results in a situation where the only people able to gain certainty about their actions are those with access to legal advice. To remind you of what I said in my blog about "necessary claims":
Whenever I see this phrase my lawyer alarm goes off as it immediately involves a judgment call which is the subjective right of the patent holder. It comes accompanied by the question "was our patent really necessary for this implementation? Surely you could have done it this other way and thus not needed it. It's actually not necessary so here's the invoice." I'd like to see that phrase replaced with language to indicate that no patent claims will be made against source code implementing the standard, with no necessity test involved.That's because Microsoft based their document on Sun's. I know that because the author of the Sun covenant is a colleague, because it was released at least a year before Microsoft copied it and because, after I pointed this out, Microsoft credited Sun for the original document.
I disagree, and I have explained why before on my blog. Sun's covenant is intended to empower open source developers, and Microsoft has altered the parts that make that happen. Most notably, Sun's covenant grants all patents, Microsoft's is limited to "necessary claims". That is a very major difference since it means open source developers cannot be sure they have actually been given cover by Microsoft's covenant whereas they can be certain they have by Sun's. It is deeply regerttable that Microsoft added essential claims language in this way. For those who don't follow links, I also find the conformance requirements and the patent peace asymmetry poor in Microsoft's document.
Indeed, and I am among them. However, your implication that the same applies to Sun's covenant is incorrect.
We (that's Sun Microsystems) chose the GPL as the license under which to release everything necessary to make an UltraSPARC T1 (and more recently, T2). We placed it all - RTL, tools, the lot - at OpenSPARC.Net. The license choice was for two main reasons:
While releasing hardware sources under a Free license is a different deal to software, the GPL seems to encourage the same willingness to examine and use the code as it does in software. The mechanisms for community have to be different because of the capital-intensive nature of the processes to use the code. We've still seen people rework it to fit it on FPGAs, create single-core chips for embedding and run university degree courses on it. I remain pretty happy with the license choice we made.
Sounds like a populist position, or maybe troll flamebait. I'll be generous and assume the former, despite the fact your post seems like a digest from an anti-ODF briefing paper. Disclosure: My job includes the task of receiving complaints about Sun and trying to get Sun to fix whatever causes the problem. If you have proof of any of your accusations, let me know. I may have some of my facts wrong below as I'm working from memory; I'd welcome correction.
That is indeed the constant assertion that the three guys who comprise the Foundation make. However, I have personally asked members of the ODF working group at OASIS and they tell me its not so.
Naturally every member of a standards group in the traditional standards process is looking out for the code base where they implement a standard, and will have serious questions of any feature that they regard as unimplementable. The features actually put to a vote by the guys from the Foundation would have resulted in very brittle implementations, highly dependent on the version of MS Office with which they were coupled. It may have been possible to come up with a solution that reduced this problem, but the discussion was not sustained. The assertion you make is not true in the general case.
Untrue. The ODF TC can have no more than three members from any one organisation and is not under the control of any organisation. The Foundation guys actually flaunted that rule at one point and sent many, many more representatives - OASIS had to step in to fix it. That intervention is one of the issues they have with OASIS, in fact. Sun happens to employ the people who act as Chair and Secretary to the TC but the voting remains democratic.
I've heard that interpretation of the patent non-assert covenant that Sun has made regarding ODF, but it's untrue. Sun covenants not to enforce any patents against ODF implementations based on any spec it participates in. To the extent that versions of the spec after Sun's departure are based on version in which Sun was involved, that covenant remains in effect even in the unlikely event of Sun leaving the TC. Sun can't stop the TC from continuing its work.
Are you relaying this all as hearsay, or do you actually have data to back up your accusations? If you have, I'd like to see it (genuinely).
As I understand it, the feature was broken by other key changes made to the code and the fix to the problem wasn't ready in time for the last release.
Sorry, you're an anonymous troll or worse. Switching the subject to the endless twisty passages of flawed application of the GPL is a game and I'm not going there. You're twisting (or not reading) what I am writing (the legal opinion I linked was by SFLC, not FSF, and was on behalf of Apache; the use of the phrase "Essential Claims" by Moglen was part of a discussion of the OASIS patent policy where the term is used to define baseline RAND licensing; and so on).
I've given a reasoned interpretation and made assertions on Sun's behalf, and you're responding with sophistry and the sort of understanding of the law and courts one finds on certain mailing lists. I've read your posting history and seen that you never give up, so sorry, I'm not playing.