Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 36 reacties
Bron: Brian Jones, submitter: 80466

Brian Jones, bij Microsoft werkzaam binnen de Office-groep en daar verantwoordelijk voor de XML-functionaliteit, heeft via zijn weblog een artikel gepubliceerd waarin hij uitleg geeft over de mogelijkheden om het Open XML-bestandsformaat te gebruiken. In het verleden is meerdere malen door nieuwssites geschreven dat de door Microsoft gekozen licentie interoperabiliteit in feite onmogelijk maakte. Ook zorgde die licentie ervoor dat de rechten van softwareontwikkelaars die Open XML wilden interpreteren erg beperkt waren. In december vorig jaar heeft het Redmondse sofwarebedrijf daarom besloten de licentie af te zweren en over te stappen op een zogenaamd 'Covenant Not to Sue'. Aangezien er volgens Jones veel onduidelijkheid bestond over wat dit inhoudt, heeft Microsoft een onderzoek laten uitvoeren.

Microsoft Office 2007 logoDit is uitgevoerd door het Londense advocatenkantoor Baker & McKenzie en is in pdf-vorm van de site van de juristen te halen. In het document wordt onder meer een uitleg gegeven over wat Microsofts 'Covenant Not to Sue' inhoudt, namelijk dat het softwarebedrijf onherroepbaar aangeeft dat er geen actie zal worden ondernomen om patentclaims op de Open XML-specificatie te bekrachtigen. Verder is opgenomen dat het recht om de specificatie te gebruiken en te implementeren, voor een individu of organisatie vervalt als door hen wel juridische procedures gestart worden met betrekking tot patenten. Volgens Baker & McKenzie is het 'Covenant Not to Sue' anders dan de eerdere patentlicentie. Daarin werden gebruikers namelijk in hun vrijheden beknot.

Zo mocht de specificatie alleen op bepaalde manieren gebruikt worden, moest verwezen worden naar Microsoft in de software en mocht de Open XML-licentie niet worden overgedragen. Deze verplichtingen zijn echter niet aanwezig in het 'Covenant Not to Sue', aldus Baker & McKenzie. De huidige inhoud van de 'licentie' komt overeen met wat normaal is binnen de software-industrie, waarbij verwezen wordt naar vergelijkbare uitlatingen van Sun over het Open Document-formaat. Tot slot wordt in het document bekeken hoe Microsofts 'Covenant Not to Sue' compatibel is met de LGPL, die in OpenOffice.org gebruikt wordt. Volgens de onderzoekers zouden deze twee licenties samen geen problemen moeten geven en zou OpenOffice.org het Open XML-formaat moeten kunnen implementeren.

Lees meer over

Moderatie-faq Wijzig weergave

Reacties (36)

In hoeverre zijn de vermaarde proprietaire (binaire) plugins hierbij inbegrepen?
Alle Office formaten kunnen propriety binary files bevatten. Ook in OpenDocument kun je je eigen verzonnen binary image formaat gewoon opbergen. Er is in OpenDocument geen restrictie om bij het embedden open standaarden te gebruiken.

Het enige binary propriety formaat wat bijvoorbeeld de microsoft kan toevoegen en waar je met andere applicaties zeker niets mee kunt is gecompileerde VBA scripts. Het is echter logisch dat als je gecompileerde binary code in je office hebt dat je dan ook de binary interpreter moet hebben (oftewel MS office).
waar je met andere applicaties zeker niets mee kunt is gecompileerde VBA scripts.
Op Win32 kun je die in principe gewoon uit laten voeren en office calls "emuleren". Moet in principe niet zo lastig zijn. Als ze er even werk van maken moet het onder Linux ook wel kunnen icm Wine.
Microsoft is niet van plan het Open Document formaat te implementeren/ondersteunen. Op zich begrijpelijk.
Dit is in mijn ogen echter een waardig alternatief. Er zijn echter enkele addertjes onder het gras....
In de bewuste pdf wordt duidelijk aangegeven dat bedrijven enkel recht hebben dit formaat vrij te implementeren zolang ze geen rechtzaken inzetten ivm patentclams. Dus ook niet wanneer de eigen patenten door Microsoft geschonden worden..... Microsoft dekt zich hiermee enorm in tegen mogelijke patentclaims.....
Daarbij blijft Microsoft alleenzeggenschap hebben over de standaard. Hij is welliswaar open en mag door iedereen gebruikt worden alleen de volledige specificaties kunnen/mogen enkel door Microsoft gewijzigd worden. Andere gebbruikers hebben dus geen inspraak.
Dit lijkt een beetje op de overeenkomsten die Microsoft al langer heeft met andere grote softwareboeren (denk aan Autodesk, Adobe,...) waar de deelnemers een soort van vrijwillige geven en nemen verstandhouding hebben. In dit geval is het Microsoft dat het formaat aanreikt en de rest van de bedrijven dienen een stukje eigenheid in te leveren.
Nu ja van een commercieel bedrijf was niet te verwachten dat ze zomaar even open standaarden gingen ontwikkelen en te grabbel gooien. Ook het implementeren van het Open Document formaat was niet echt een optie in die zin dat Microsoft op dat moment een groot stuk van de meerwaarde van Microsoft Office zou verliezen. Namelijk het feit dat 90% van de office documenten enkele 100% compatibel zijn met Microsoft Office.
Microsoft is niet van plan het Open Document formaat te implementeren/ondersteunen. Op zich begrijpelijk.
Microsoft gaat ODF gewoon ondersteunen middels een Open Source plugin, in ieder geval voor Office 2007, waarschijnlijk komt het er ook wel voor eerdere versies.

http://www.microsoft.com/...6OpenSourceProjectPR.mspx
http://www.betanews.com/a...t_OpenDocument/1152166759
http://sourceforge.net/projects/odf-converter
MS gaat openDocument niet ondersteunen, ze steunen een plugin project financieel, en dat is het dan ook, ondersteunen wil zeggen implementeren in hun eigen projecten, mensen moeten nog altijd de plugins zelf installeren. Ik denk dat OpenOffice.org openXML ondersteuning wel gaat inbakken, maar OpenDocument blijft toch de standaard.
Word eens wakker. Eens was *.WPD de standaard. Met de inmense gebruikersdichtheid van MS Office maakt openXML ondersteuning echt hele goed kansen.

Jammer dat het een extra actie van gebruikers vereist maar ik neem aan dat het een actie is die ongeveer even eenvoudig is als het kiezen van een standaard lettertype in alle documenten.

Als het inderdaad een eenvoudige stap is zal het in het bedrijfsleven goed gebruikt gaan worden. Ik zal dan zeker overstappen op OpenOffice.org. Nu is de conversie niet 100% en dus niet werkbaar.
Zeeer goed gezien! Het komt hier eigenlijk gewoon op neer:

Implementeer OpenXML en wij verwerven automatisch gebruiksrecht op AL je patenten.

Hoezo, "fair use" |:(
Onzin.
Niks al je patenten.
Het gaat om patenten met betrekking tot de OOXML specificaties.
This covenant shall not apply with respect to any person or entity that asserts, threatens or seeks at any time to enforce a patent right or rights against Microsoft or any of its affiliates relating to any conforming implementation of the Specifications.
Als je dus de specs van MS gebruikt en gevrijwaard wilt zijn van MS claims dan moet je geen eigen patent claims op diezelfde specs proberen uit oefenen.
Op deze entry van de blog: An Antic Disposition maakt de schrijver een ander struikelblok duidellijk van de OpenXML, waar de Convenant Not to Sue (waarschijnlijk) niet duidelijk over is.
Het gaat over paginaranden. MS Word heeft, buiten de uit lijnen opgebouwde randen, ook de keuze uit zo'n 200 plaatjes om randen op te bouwen. (oa. plaatjes van taarten, schelpen, pompoenen)
Ipv dat OpenXML het plaatje meeverpakt in het document, hebben ze ervoor gekozen alle 200 te beschrijven in de specs: section 19.17.4 van de 1.3 Draft Ecma Office Open specification (pagina 1617-1671 volgens de spec-nummering)

Dit brengt dus, voor een implementatie van OpenXML ook copyright problemen met zich mee, en niet alleen patentzaken!


@Thorchar:
Nee, je wil JUIST dat het er op elk systeem hetzelfde uitziet. Dat is het nut van duidelijke, open, standaarden. Daar heeft MS ook aan proberen te voldoen met OOXML.
Ze hebben echter de grote fout/keuze gemaakt, 200 verschillende artborders in de documentatie op te nemen.
Als je het stuk leest, zie je dat als er bijvoorbeeld staat:
<simpleType name="ST_Border">
<restriction base="xsd:string">
<enumeration value="birdsFlight"/>
</restriction>
</simpleType>
Moet het, in de spec's gespecificeerde plaatje, als artborder gebruikt worden.
Vandaar de term standaard. En niet, richtlijn.
Echter, in de convenant not to sue, staat NIET dat je die plaatjes mag gebruiken, zonder dat ze gaan klagen (of de oorspronkelijke ontwerper) gaat klagen over copyrightschending. Om OOXML volledig, en correct, te implementeren moet je juist WEL de oorspronkelijke plaatjes gebruiken. Anders gaan de gebruikers weer klagen (en terecht) dat de plaatjes per officepakket verschillen!
(overigens kan ik mij best voorstellen waarom ze het niet als binary-plaatje in de file stoppen. Immers, je koopt een licentie op MS Office, daarbij krijg je ook het recht om die plaatjes te gebruiken. Echter, dat geeft je weer niet het recht om ze te versprijden, ivm auteursrechten)

Als het enkel om de informatie gaat, kan je net zo goed met notepad.exe werken. Voor templates zijn standaarden noodzakelijk. En waarom denk je dat pfd zo populair is? Juist, omdat het er op elk systeem precies hetzelfde uitziet (mits je pdf-reader alle functies kan uitvoeren).

@hAl: Good poin :7
Je moet wel begrijpen dat alle open office formaten het altijd aan applicaties toestaan om willekeurige images in de formaten te embedden. Volgens mij worden de plaatjes om de randen op te bouwen gewoon door applicatie die het document creert in binary vorm in het document ge-embed bijvoorbeeld als kleine bmp, gif of png.

Het kan daarnaast ook als een DrawingML object in OOXML worden opgenomen omdat de OOXML standaard een uitgebreide mogelijkheid biedt tot het toevoegen van drawings in XML formaat.

edit:
Hmmm, ik heb nu gezien wat je bedoeld in de specs. Lijkt me inderdaad lastig. Misschien bedoeld om backwards competabiliteit te garanderen.
@FrankNStein:

Ik zie niet zo goed wat daar het probleem aan is?

Je kunt in Open Office of whatever pakket gewoon een eigen library met replacement images erbij stoppen. Natuurlijk zien die er niet hetzelfde uit als bijvoorbeeld de Microsoft plaatjes maar dat moet niet zo'n punt zijn.

Voor zo ver ik weet is dit bestandsformaat bedoelt om informatie op te slaan mbt office documenten, informatie staat voorop, opmaak zit er ook in maar veel minder.

Zo zal een documentje op het ene systeem waarschijnlijk nooit hetzelfde zijn als op een ander systeem. Zelfs de geinstalleerde printer en printer instellingen kan zaken aan de opmaak veranderen (denk aan marges, pagina grootte etc).

Gezien het bestandsformaat niet bedoelt is om opmaak in op te slaan moet het geen enkel probleem zijn dat de randjes er iets anders uit zien. Het zal een potentiele gebruiker ook weinig uitmaken hoe de pompoenen eruit zien, als het maar pompoenen zijn.

Als je een bestandsformaat wil hebben wat meer rekening houdt met opmaak kun je waarschijnlijk het beste PDF kiezen (niet het beste qua opmaak, maar beter in opmaak en vrijwel overal te openen).
overigens kan ik mij best voorstellen waarom ze het niet als binary-plaatje in de file stoppen. Immers, je koopt een licentie op MS Office, daarbij krijg je ook het recht om die plaatjes te gebruiken. Echter, dat geeft je weer niet het recht om ze te versprijden, ivm auteursrechten
Door de plaatjes in het standaards document op te nemen en deze rechtenvrij ter beschikking te stellen via een standaardsorganisatie kun je gewoon de plaatjes uit het standaards document kopieren en in je applicatie toepassen. Het is alleen wat omslachtig maar het beperkt niet je rechten. Dat zou alleen het geval geweest zijn als er wel aan de plaatjes gerefereeerd werd maar als de plaatjes niet in de standaard verwerkt waren maar alleen in de Office applicatie aanwezig waren.
probleem blijft natuurlijk dat 'Open XML' helemaal niet open is maar een standaard die door microsoft alleen bepaald wordt.

ms zal dus altijd een edge hebben over andere bedrijven omdat zij bepaalt wat er in de open xml standaard komt.

de applicaties van microsoft zullen ook altijd voorlopen op applicaties van derden omdat ms weet "wat er komen gaat" mbt tot open xml. ze zeggen alleen dat andere bedrijven open xml mogen gebruiken. net zoals er ook bedrijven zijn die .doc formaat kunnen gebruiken.

business wise verandert er dus niet zoveel wat ms betreft in de overstap van .doc naar open xml! betere keuze voor de industrie: open document.
In wezen is het net zo open als bijvoorbeeld PDF.

Iedereen kan opzoeken hoe je een PDF maakt.
Iedereen mag een programma schrijven dat PDF's leest, schrijft en converteert.
Alleen Adobe bepaalt wat er aan de standaard verandert (en gelukkig maar).
Uit PDF zijn wel degelijk ISO standaarden voortgekomen: PDF/X en PDF/A.
Mag jij me effe uitleggen waaromde "industrie" hier een probleem mee zou hebben. Volgens mij net niet aangezien het 1 standaard is en niet 1 standaard + 10 afgeleiden.
PDF wordt ook al jaar en dag bepaald door Adobe en nooit zijn er problemen geweest.

leg dan effe uit waarom een overstap naar open document beter is want ik zie het echt niet.
ik denk dat het daarom dan ook geen probleem hoeft te zijn.

ik kan dus gewoon in Open Office mijn documenten maken, bewaren doorzoeken en welke opties er ook ooit zulle komen.
en wanneer ik een MS-xml bestandje krijg kan ik zelfs dat nog 's openen, bewerken en terug sturen ...

gewoon een meerwaarde dat ik als OOo gebruiker strax wellicht ook met office2007 users kan comuniceren....

terweil ODF gewoon de standaard blijft,
definieer open?

OpenXML is bij ECMA als standaard gedeponeerd. Mag jij uitleggen wat je nog meer moet doen om het voor jou 'open' te laten zijn.
Microsoft denkt daarmee de concurenten een stap voor te wezen.
De concurenten adverteren dan namelijk dat het het Open XML formaat van Microsoft ondersteunt.

Als Microsoft ziet dat ze veel aan bepaalde software verdienen door de Open XML implementatie, kan Microsoft onbestraft patenten van de concurent gebruiken.

Immers, bedrijven mogen geen claims tegen Microsoft indienen. Als ze dat wel doen, zijn ze in overtreding t.o. de 'Covenant Not to Sue'
Ik geloof niet dat dit document betrekking heeft op alles in de zaken wereld mbt microsoft en aanklachten, maar dat het alleen over patent aanklachten e.d. binnen Open XML gaat.

Zoals ik het snap mag je geen patent aanvragen of aanklagen over een patant van bijvoorbeeld je eigen Open XML template (om maar iets doms te noemen)

Ik vind dit een erg goeie zet van MS, hun software gratis ondersteunen in je eigen pakket.

En om flamers voor te zijn: als je het toch niet wil gebruiken? dan gebruik je het toch niet! de Softwaremakers hebben die keuze, en wij ook!
This covenant shall not apply with respect to any person or entity that asserts, threatens or seeks at any time to enforce a patent right or rights against Microsoft or any of its affiliates relating to any conforming implementation of the Specifications.
van Gates himself dus je moet ze alleen niet aanklagen omdat MS hun eigen Open XML gebruikt, wat ik natuurlijk helemaal logisch vind. je gaat adobe toch ook niet aanklagen omdat ze een PDF writer hebben, of licht dit aan mij.

En dat Microsoft zelf zijn formaat onderhoud moeten ze zelf weten, maar ik ben bang dat er elk jaar 100 paginas specificaties bij komen
100 pagina's is niet veel.
De huidige EMCA specificaties zijn al 4000 pagina's en zijn nog niet af.

Ook bevatten de huidige office formaten nog bijvoorbeeld geen office databaseondersteuning.
Een uitgebreide documentatie is juist goed. Om een voorbeeld te noemen: de MPEG-4 container is super complex met honderden pagina's documentatie en allerlei devs vonden het in het begin maar lastig, maar het staat er wel allemaal netjes in. En "losjes" gedefinieerde formaten als OGG en MP3 zijn inmiddels een puinhoop van custom extensies en tag formaten geworden.
Ik dacht dat we hier op tweakers het woord M$ niet meer mochten gebruiken?

En nu denk jij de term "open sores" wel te mogen gebruiken?

Open je ogen kerel, "sores" heb je overal, en dat licht niet aan de software, dat ligt aan het feit dat niet alles overal zomaar werken kan. (en dat hangt weer grotendeels af van patenten en afgeschermde formats en protocollen, thank you very much MS)

Bij open source problemen kun je er iig nog iets aan doen, bij MS kun je alleen maar jaren en jaren en jaren gaan zeuren. (en dan nog gaan ze pas iets doen als er concurentie op komt, zie firefox -> ie, png support)
Iets met splinter en balk. Ondanks het feit dat ik de term 'open sores' gebruik, betekent het niet dat ik open source als zodanig geen warm hart toedraag; ikzelf ben ook ontwikkelaar van open source code, en heb een wat meer zwart-witte kijk wat dat betreft (GPL bijvoorbeeld kan mijn goedkeuring niet krijgen, daar ik het een te restrictieve licentie vind). Maar feit blijft dat met open source ook de slechte dingen voor iedereen zichtbaar zijn, dus, de sores zijn open(baar) :).

In ieder geval vind ik je reactie danig overtrokken, en leid je veel te veel af van mijn woordkeuze dan die woordkeuze rechtvaardigt. Ik hoop dat je de volgende keer wat terughoudender zal zijn met het voorbarig uiten van beschuldigingen :).
Gnumeric (een OSS spreadsheet) ondersteunt reeds beperkt OOXML in versie 1.7 Het is daarmee de eerste final versie programmatuur die OOXML ondersteunt omdat bijvoorbeeld MS Office nog geen final versie uitheeft die dat doet.
"Open" in relatie tot standaarden heeft 2 betekenissen.
1. De documentatie is open.
2. de ontwikkeling is open.
Dat laatste ontbreekt dus duidelijk in Open XML. Dat dat voor pdf ook zo is (wordt alleen door Adobe gedaan) hoeft niet te betekenen, dat, nu er in software land, net als in vrijwel alle andere technische disciplines, open standaarden in beide betekenissen gaan ontstaan, dit onnodig gevonden wordt omdat Adobe het ook niet doet.
Voor een gezonde ontwikkeling is openheid in beide betekenissen nodig.
dat niet iedereen zomaar de standaard mag veranderen of aanvullen is een ander verhaal. Techniek ontwikkelt zich altijd. Buiten-standaard oplossing zullen er ook altijd zijn, en zijn ook nodig voor een gezonde ontwikkeling. Alleen, op een bepaald moment horen veel gebruikte oplossingen ook weer in de standaard geïntegreerd te worden.
Nog een reactie:
De ECMA fast track standaardisatie route maakt het mogelijk snel een Standard door te drukken als ISO standaard. Zoals ik het begrijp heeft MS enkele gebruikers “geregeld” die vol bewondering meekijken met wat MS allemaal bedact heeft. Dit zou de standaard ook open maken in 2e zin (zie vorige recatie).
Zover ik het begrijp is de standaard echte (te ) ingewikkeld (wat moeten we met 200 verschillende documentrandjes?).
Een wijze beperking in mogelijkheden zou het werkbaarder en waarschijnlijk ook vooral betrouwbaarder maken. Ik maak op mijn werk noodgedwongen gebruik van MS Word, met werk veel liever met Open Office (dat ik thuis gebruik), dat een veel stabieler indruk maakt.
Waar ik bang voor ben is dat op grote schaal toepassen van OpenXML plugins andere tekstverwerkers met dezelfde instabiliteiten opzadelt als ik nu uit Word ken: Zolang je iets simpels doet werkt het enorm snel., maar zodar je wat veel plaatjes invoert, begrijp het programma niet meer wat je wilt, en klust alles door elkaar.
Voor internationale uitwisseling van documenten met een “simpel” formaat zou je eigenlijk een soort controle programma willen hebben, dat controleert of er wel volgens de standaard gewerkt is, zodat de ontvanger, welk programma hij ook gebruikt, het document op de bedoelde wijze gepresenteerd krijgt.
OpenXML is volgens mij de zoveelste truck van MS om klanten aan zich te binden. Dit is geen werkelijke vernieuwing, maar een (slimme?) manier om blijvend omzet te genereren.
Volgens de onderzoekers zouden deze twee licenties samen geen problemen moeten geven en zou OpenOffice.org het Open XML-formaat moeten kunnen implementeren
Wie denkt dat OOo dit zal doen :?
Ik!
Waarom zouden ze het niét doen als ze het kunnen :? Het maakt de overstap van MS naar Open zoveel makkelijker :)
Ik vermoed dat men er zo snel mogelijk werk van zal maken. Interoperabiliteit is zeer belangrijk.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True