On Wed, Feb 18, 2009 at 7:40 AM, JS Kaplan <[email protected]> wrote: > I found this really cool extension for Open Office: > > http://extensions.services.openoffice.org/project/pdfimport > > Opens a draw window and "The PDF Import Extension allows modifying existing > PDF files for which the original source files do not exist anymore." > However, I found it can do a lot more. Coupled with the export to PDF > function, very nice indeed!
But notice that it's crippleware. From the same page you linked: "The PDF Import extension will also enable the PDF export into a hybrid PDF file, which is a PDF with the embedded source file as ODF. Hybrid PDF files will be opened in StarOffice as an ODF file without any layout differences, while users without StarOffice can open the PDF part of the hybrid file." The ODF-PDF hybrid package is a concept I and a friend who was also serving on the ODF TC at the time advanced years ago to become part of the ODF specification. Sun kept it out of the ODF spec but implemented the concept itself outside the standard with a proprietary vendor lock-in twist. I claim no originality in the concept. There's nothing new about compound documents. System storage capacity and the bandwidth of internet connections were the main obstacles to archival/editable hybrids until fairly recently. But there are tremendous advantages in packaging the archival and the editable in the same Zip file. Those hybrid documents that StarOffice is generating can't be generated by any other implementation of ODF. And the ODF code included in them can't be read by any implementations other than StarOffice. In case there's anyone reading who didn't already know it, StarOffice is a proprietary extension of the OOo code base distributed in binary form only. That's a critical fact because Sun is increasingly displaying a conflict of interest when it comes to its stewardship and governance of OOo. But the really big current conflict is StarOffice 9's ability to write to both ODF v. 1.1 and what is labeled as ODF v. 1.2 (ODF v. 1.2 is still in development). Sun stripped OOo of its ability to write to ODF v. 1.1 in the OOo 3.0 release, which writes only to "ODF v. 1.2." Guess which version of ODF Microsoft is building support for in Office and a few other apps? You guessed it, ODF v. 1.1. So all those folks who want interop with MS Office via ODF will have to buy StarOffice. There is no other featurefull office suite that can write to ODF v. 1.1. Sun's cozy relationship with Microsoft in regard to StarOffice and OOo is not something that's generally known. But Sun basically sold Microsoft unfettered patent hunting rights on OOo in 2004 for $900 million and annual renewal fees, whilst acquiring patent protection for Star Office. See Sun-Microsoft, Limited Patent Covenant and Stand-Still Agreement Dated April, [sic] 2004, <http://www.sec.gov/Archives/edgar/data/709519/000119312504155723/dex10109.htm> (see especially section IV, where the major subject is OpenOffice.org and StarOffice, although other sections are relevant). Microsoft claims to hold 45 patents reading on OOo. Roger Parloff, Microsoft Takes On the Free World, Fortune (14 May 2007), <http://money.cnn.com/magazines/fortune/fortune_archive/2007/05/28/100033867/>. Thankfully, the threat of software patents has ebbed substantially since 2004 on several continents. Blowing away OOo with software patents after the world was firmly hooked on ODF via OOo's free distribution turned out not to be a workable strategy. I suspect that the StarOffice/MS Office interop via ODF v. 1.1 may be the replacement strategy for the transition of ODF to predominantly proprietary apps and other-big-vendor detente with Microsoft, aided by the antitrust action under way in the E.U. involving Microsoft Office, which has IBM as its principle instigator/driver. The evidence is very strong that Sun granted IBM rights to use the OOo 3.0 code base in IBM's proprietary apps last year sometime in the late summer/early fall period. See e.g., IBM, IBM Commits to Future of ODF With Symphony Roadmap, IBM press release (5 November 2008), <http://www-03.ibm.com/press/us/en/pressrelease/25912.wss>: "By synchronizing Symphony's user interface with the underlying OpenOffice 3.0 code base, IBM expects the upcoming wave of planned contributions to make a significant impact to the OpenOffice developer community and its users throughout 2009 and beyond. "... IBM Lotus Symphony is based on OpenOffice code, with IBM enhancements that allow new capabilities through Eclipse plug-ins and incorporate some of the OpenOffice 3.0 code." (Lots more evidence out there.) One might suspect from the fact that IBM has not implemented ODF v. 1.1 write support in Symphony and its other proprietary apps that process ODF that a clause of the Sun-IBM agreement forbids it. So LGPL for the little guys, but proprietary rights to the OOo code base for the Big Two OOo code base players, with Sun holding the proprietary key to its lock on the OOo code base. Sun's lock is derived from its SCA contributor's agreement, <http://www.sun.com/software/opensource/sca.pdf>, and its predecessor Joint Copyright Assignment, <http://www.openoffice.org/licenses/jca.pdf>. OOo Contributors grant Sun joint ownership of their contributed code but acquire only the LGPL rights to the remaining portions of the code base. Only Sun has the right to license the main branch OOo code base, on any terms its managers please. See e.g., SCA agreement: "+ you hereby assign to us joint ownership, and to the extent that such assignment is or becomes invalid, ineffective or unenforceable, you hereby grant to us a perpetual, irrevocable, non-exclusive, worldwide, no-charge, royalty-free, unrestricted license to exercise all rights under those copyrights. This includes, at our option, the right to sublicense these same rights to third parties through multiple levels of sublicensees or other licensing arrangement ... ... "+ you agree that neither of us has any duty to consult with, obtain the consent of, pay or render an accounting to the other for any use or distribution of your contribution." These days, there's much to be said for running the oo-build branch of OOo absent compelling reasons to do otherwise. It's the biggest branch where all code is licensed *only* under the LGPL. The oo-build releases generally follow Sun releases by only a few days. The oo-build project site is at <http://go-oo.org/>. The oo-build patch contributors include Novell, SuSE, Debian, and Ubuntu. The Go.OO developers have been pushing back against Sun by refusing to grant Sun rights to their code beyond the LGPL license and publicizing Sun's refusal to honor its original commitment to place OOo stewardship and governance under an independent non-profit foundation. See Anon., Sun Microsystems Open Sources StarOffice Technology, Sun Microsystems press release (19 July 2000), <http://www.openoffice.org/press/sun_release.html> ("Sun also announced today the new OpenOffice.org Foundation, which will initially be modeled on other successful open source projects and will consist of a project management committee, source code maintainers, and developers. Sun will hold a equal membership position in the OpenOffice.org Foundation project management committee.") See also Deborah Gage, Smart Partner: Sun To Open StarOffice Code In October, Linux Today (19 July 2000), <http://www.linuxtoday.com/news_story.php3?ltsn=2000-07-19-016-04-PS-DT-SW>, quoting StarOffice creator Marco Boerries: "Sun also is creating an independent OpenOffice.org Foundation modeled on the Apache Foundation. Sun is funding the foundation to get it started but will hold a minority position and plans to name other partners soon." That unfulfilled commitment is coming to a boil in the OOo developers' community, in no small part driven by the rebranding of oo-build as Go-OO and attendant publicity. Novell OOo and OxygenOffice are oo-build distributions. Some oo-build patches make it into NeoOffice, running on the Mac. There are others; in fact, you might already be using oo-build without realizing it. The builds of OOo distributed via many Linux distributions --- e.g., Ubuntu, Mandriva, Debian, and OpenSuSE --- include oo-build patches. Those Linux distributions' developers also contribute patches to oo-build. Short story: oo-build has many features not found in Sun OOo. Sun has tried to blunt the oo-build threat to its hegemony over OOo by measures such as releasing its own OOo build for the OS X platform and replicating key features of the Go.OO branch, apparently hoping to lessen demand for Go.OO. I'll not go into detail here, but there is very substantial spill-over from the OOo situation into the ODF TC development work. What I've described is mere snapshots of the big vendor maneuvering that goes on largely behind the scenes with OOo and ODF. I'm not sure even a single book could do the subject justice. Certainly I cannot do so in a single email. None of the above is intended to argue that one company is more idealogically pure than any other. That said, I'm intimately familiar with the inter-corporate politics of OOo and ODF and it's a situation that in my opinion is overripe for reform. OOo and ODF are major connectivity bugs in the emerging Connected World. I'd really like to see the antitrust regulators bearing down on the problem. Those aiming to break one monopoly need also be concerned with the qualities of what rises from its ashes. An ODF cartel doesn't look a lot better than a Microsoft Office monopoly through my eyes. I do not suggest that you should not use the Sun PDF extension. But you might consider declining to accept those StarOffice PDF/ODF hybrids, depending on the circumstances. Anyone who generates one is perfectly able to generate an ODF document, in either ODF 1.1 or "1.2." Best regards, Paul ---- "Another reason to be proud, this being a citizen! For the poor it consists in sustaining and preserving the wealthy in their power and their laziness. The poor must work for this, in presence of the majestic quality of the law which prohibits the wealthy as well as the poor from sleeping under the bridges, from begging in the streets, and from stealing bread." -- Anatole France (Jacques-Anatole Thibault), Le Les Rouge (The Red Lily) (1894), (Project Gutenberg ed. 2003; English translation), <http://www.gutenberg.org/dirs/etext03/im06b10.txt> _______________________________________________ EUGLUG mailing list [email protected] http://www.euglug.org/mailman/listinfo/euglug
