[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DocView now supports OpenDocument & MS Office formats

Subject: Re: DocView now supports OpenDocument & MS Office formats
Date: Mon, 3 Jan 2011 03:25:43 -0500

On Sun, Jan 2, 2011 at 5:11 PM, Richard Stallman <address@hidden> wrote:
>    Oracle's stated intent is to supply the Oracle OpenOffice deliverables
>    with SaaS capabilities. This is not a theoretical matter, its
>    happening.
> "SaaS capabilities" is rather vague -- could you tell me what this
> refers to?

Please take the opportunity to re-read my original post. Presumably,
that which you earlier
deemed sarcastic:

| > The "service" is Free Software
| Its LGPL free as in "Oracle"...
| Tune in for Episode 3 entitled "We are the Cloud, now get assimilated":
| In which our benevolent dictator markets their branded version of
| 'Oracle Open Office' under the moniker 'Oracle Cloud Office' complete
| with PHB targeted hype-speak:
|  "Oracle Cloud Office Web-scale architecture can be used for on-premise,
|  on-demand, or software-as-a-service (SaaS) deployments."

The indented quote above was lifted verbatim from the referenced URL
(which, IMO tells the tale).

Again, the irony here is that after all of the effort and work
extended to get Sun Microsystems to open up the the Java codebase and
to get governments and corporations to support the ODF as opposed to
MScorps "Office Open XML", along comes Oracle in 2010-01-27 with a
cool US$ 7.4 Billion and ends up with a controlling interest in both
Java and ODF along with a strong interest in selling to enterprises
both "Software-as-a-Service" and the software and servers that deliver
these services while simultaneously extolling to these same
enterprises the virtues of the "Open Standards" based
software/services though clearly they do not intend to support such
"Open Standards" in an vendor neutral manner.

> The issue is important because OpenOffice is important.

OpenOffice is _not_ important. After all, its just branding for a bunch
of LGPL'd code. This said, ODF _is_ important, as is LibreOffice's
support of the format.

> I am not yet sure it related to Emacs,

Many Emacs users would probably benefit by having an interface to ODF.
Besides which, I'm pretty sure the GNU project has advocated strongly
in favor of this format and it would be a shame if Emacs is unable
to support it.

> but I should learn about it anyway.

Yes you should, esp. as you are already (quite recently) on record
endorsing LibreOffice in lieu of OpenOffice:

| FSF President Richard Stallman welcomed LibreOffice release and
| it's stated policy of only recommending free software. "I'm very
| pleased that the Document Foundation will not recommend nonfree
| add-ons, since they are the main freedom problem of the current
| OpenOffice.org. I hope that the LibreOffice developers and the
| Oracle-employed developers of OpenOffice.org will be able to
| cooperate on development of the body of the code".
`---- :SOURCE (URL `http://www.documentfoundation.org/supporters/')

>    In order for an Emacs to gain ODF support via the proposed docview.el
>    interface one must leverage python/pyuno/UNO/OpenOffice/Java
>    The point is:
>     - interaction with the UNO bridge is not (necessarily) simple RPC;
> That is too vague to draw conclusions from.
Please don't minimize the conclusion on the basis of a bullet-point.
In the context of my earlier posts I wasn't quite so vague.

>     - the UNO SDK is a poorly specified;
> That would be a problem if we cannot make it work.

This incorrectly inverts the issue without acknowledging that you've
understood the problem. Obv. we are not trying to "make it work" b/c
we are relying on multiple pieces of third party software in order to
interface with the UNO SDK. Not only is it unclear if these software
are able to "make it work" by doing so cleanly/safely/transparently
and in a manner which protecting the users freedom, but it is
increasingly unclear that the core developers/implementers of the SDK
itself are willing and able to continue supporting it (witness the
LibreOffice fork).

>     - Its protocol is compromised in lieu of the Sun/Oracle merger;
> "Compromised" is rather vague, so I am not sure this is an issue.

OK, hows this:

- Oracle purchases/merges-with Sun;

- Oracle gains oversight of OpenOffice/UNO/Java;

- Oracle begins marketing Oracle Open Office;

- Some key OpenOffice developers decide to fork OpenOffice in late
  September of this year as it becomes increasingly clear that Oracle
  is not intent on remaining vendor neutral with its newly acquired

- LibreOffice begins an initiative to srub the forked OpenOffice
  codebase of pre-existing in-source comments. Presumably the
  "scrubbing" has some relation to issues around this:
  (URL `http://www.oasis-open.org/committees/office/ipr.php')

- It is not clear that the existing OpenOffice codebase will remain
  free of contest. For example, see the recent 2010-09-28 LWN.net
  interview with Michael Meeks:

| LWN: There have been occasional hints that Sun had patents on some
|      StarOffice/OpenOffice components and we have seen that Oracle
|      is not terribly shy about patent litigation; does the project
|      have any concerns about patents or patented technology in the
|      codebase?
| MM: The OpenOffice.org code-base that LibreOffice is derived from is
|     licensed under the LGPLv3 - which gives us all a strong
|     explicit patent license, and a good copyright license, so
|     no. Clearly for new code we would want a plus ["or any later
|     version"] license, so we are considering recommending a LGPLv3+
|     / MPL combination for entirely new code.
`---- :SOURCE (URL `http://lwn.net/Articles/407339/')

Maybe we should wait to see what happens between the Oracle and The
Document Foundation before actively endorsing a particular
implementation of "OpenOffice".

>     - asking Emacs users to embrace these dependencies just to gain ODF
>       support is tantamount to a tacit endorsement of Oracle's reframing
>       of software as service in a distributed manner;
> I am not sure "Software as a Service in a distributed manner" is
> coherent.

It is difficult to anticipate exactly what Oracle intends for
OpenOffice.  No doubt if we each had crystal balls things would be
different. None the less, given what we can observe, the assertion
that Oracle (among others) may be reframing the scope of software
freedom is IMO far more coherent than denying the possibility by
virtue of semantic chicanery around the ambiguity of the term

> Often the alternative to a centralized network service is a
> distributed system in which users' machines cooperate.

Indeed, a zombied machine in a botnet fits this description as well.

The issue isn't whether and how the distribution of the system happens,
but if the collective of machines cooperating do so with user(s)
awareness and permission and whether the user has reasonable recourse
to recover/retain her processed data according her needs and wishes.

>     - asking Emacs users to install the python/pyuno/UNO/OpenOffice/Java
>       dependencies just to gain ODF support is ironic given the extent to
>       which the Emacs-Devels have endeavored to keep the Emacs footprint
>       small;
> People who want to use ODF need to install OpenOffice anyway,
> so I am not sure this is a terrible problem.

AFAIK the ODF acronym expands to "OpenDocument Format" an XML oriented
document file format standardized by ISO/IEC and was designed to be
vendor neutral and implementation agnostic.  It is certainly supported
by more than just "OpenOffice". Indeed, IIRC there is already a third
party Emacs based solution for pulling ODF conversions from GoogleDocs.

> If there's another way to do the job, it might be better.

It would be interesting if you could learn from the the LibreOffice
people whether they intend to support/extend the UNO SDK's C bridge.

Better still would be if some brilliant C hack could play matchmaker
with the ODF XML and Emacs' new libxml based features.

> Richard Stallman


reply via email to

[Prev in Thread] Current Thread [Next in Thread]