Browse Source

updating events, fla, follow-up-pdf, freesoftware basics

svn path=/trunk/; revision=23959
pull/8/head
guest-sstavra 8 years ago
parent
commit
ee82b28d55
100 changed files with 10248 additions and 24 deletions
  1. +2
    -2
      about/basics/freesoftware.el.xhtml
  2. +20
    -0
      activities/ftf/fla.el.xhtml
  3. +31
    -0
      campaigns/pdfreaders/follow-up.el.xhtml
  4. +21
    -0
      events/2012/event-20120818-01.el.xml
  5. +25
    -0
      events/2012/event-20120925-01.el.xml
  6. +19
    -22
      freesoftware/basics/summary.el.xhtml
  7. +58
    -0
      news/legal-news.el.xhtml
  8. BIN
      projects/os/201003-odt-questions.odt
  9. +164
    -0
      projects/os/2012-06-uk-consultation-os.en.xhtml
  10. BIN
      projects/os/FSFE-response.questionnaire.pdf
  11. BIN
      projects/os/bsa-eif-letter-fsfe-response.pdf
  12. +400
    -0
      projects/os/bsa-letter-analysis.de.xhtml
  13. +394
    -0
      projects/os/bsa-letter-analysis.el.xhtml
  14. +162
    -0
      projects/os/bsa-letter-analysis.en.xhtml
  15. +155
    -0
      projects/os/bsa-letter-analysis.es.xhtml
  16. +154
    -0
      projects/os/bsa-letter-analysis.pt.xhtml
  17. BIN
      projects/os/bsa-letter-ec.pdf
  18. +105
    -0
      projects/os/bt-open-letter.en.xhtml
  19. +112
    -0
      projects/os/def.de.xhtml
  20. +111
    -0
      projects/os/def.el.xhtml
  21. +106
    -0
      projects/os/def.en.xhtml
  22. +115
    -0
      projects/os/def.es.xhtml
  23. +108
    -0
      projects/os/def.et.xhtml
  24. +114
    -0
      projects/os/def.fr.xhtml
  25. +104
    -0
      projects/os/def.hr.xhtml
  26. +103
    -0
      projects/os/def.it.xhtml
  27. +153
    -0
      projects/os/def.nl.xhtml
  28. +67
    -0
      projects/os/def.ro.xhtml
  29. +99
    -0
      projects/os/def.ru.xhtml
  30. +77
    -0
      projects/os/dfd.el.xhtml
  31. +46
    -0
      projects/os/dfd.en.xhtml
  32. +85
    -0
      projects/os/dfd.nl.xhtml
  33. +18
    -0
      projects/os/document-msooxml-converter-hoax.de.xml
  34. +18
    -0
      projects/os/document-msooxml-converter-hoax.el.xml
  35. +17
    -0
      projects/os/document-msooxml-converter-hoax.en.xml
  36. +11
    -0
      projects/os/document-msooxml-converter-hoax.fr.xml
  37. +17
    -0
      projects/os/document-msooxml-converter-hoax.it.xml
  38. +16
    -0
      projects/os/document-msooxml-converter-hoax.nl.xml
  39. +17
    -0
      projects/os/document-msooxml-idiosyncrasies.el.xml
  40. +18
    -0
      projects/os/document-msooxml-idiosyncrasies.en.xml
  41. +11
    -0
      projects/os/document-msooxml-idiosyncrasies.fr.xml
  42. +18
    -0
      projects/os/document-msooxml-idiosyncrasies.it.xml
  43. +20
    -0
      projects/os/document-msooxml-idiosyncrasies.nl.xml
  44. +15
    -0
      projects/os/document-msooxml-interoperability.de.xml
  45. +16
    -0
      projects/os/document-msooxml-interoperability.el.xml
  46. +15
    -0
      projects/os/document-msooxml-interoperability.en.xml
  47. +11
    -0
      projects/os/document-msooxml-interoperability.fr.xml
  48. +21
    -0
      projects/os/document-msooxml-interoperability.nl.xml
  49. +20
    -0
      projects/os/document-msooxml-questions-for-ms.de.xml
  50. +20
    -0
      projects/os/document-msooxml-questions-for-ms.el.xml
  51. +18
    -0
      projects/os/document-msooxml-questions-for-ms.en.xml
  52. +12
    -0
      projects/os/document-msooxml-questions-for-ms.fr.xml
  53. +18
    -0
      projects/os/document-msooxml-questions-for-ms.it.xml
  54. +18
    -0
      projects/os/document-msooxml-questions-for-ms.nl.xml
  55. +16
    -0
      projects/os/document-msooxml-questions.de.xml
  56. +16
    -0
      projects/os/document-msooxml-questions.el.xml
  57. +16
    -0
      projects/os/document-msooxml-questions.en.xml
  58. +17
    -0
      projects/os/document-msooxml-questions.es.xml
  59. +11
    -0
      projects/os/document-msooxml-questions.fr.xml
  60. +16
    -0
      projects/os/document-msooxml-questions.it.xml
  61. +16
    -0
      projects/os/document-msooxml-questions.nl.xml
  62. +18
    -0
      projects/os/document.de.xml
  63. +17
    -0
      projects/os/document.el.xml
  64. +11
    -0
      projects/os/document.en.xml
  65. +11
    -0
      projects/os/document.fr.xml
  66. +11
    -0
      projects/os/document.nl.xml
  67. +505
    -0
      projects/os/eifv2-01.el.xhtml
  68. BIN
      projects/os/eifv2-01.en.pdf
  69. +437
    -0
      projects/os/eifv2-01.en.xhtml
  70. +400
    -0
      projects/os/eifv2-01.fr.xhtml
  71. BIN
      projects/os/eifv2-02.odt
  72. BIN
      projects/os/eifv2-02.pdf
  73. +662
    -0
      projects/os/eifv2.el.xhtml
  74. BIN
      projects/os/eifv2.en.pdf
  75. +645
    -0
      projects/os/eifv2.en.xhtml
  76. +540
    -0
      projects/os/eifv2.fr.xhtml
  77. +46
    -0
      projects/os/guardian-open-letter.en.xhtml
  78. +103
    -0
      projects/os/leaflet-OS-about.de.xhtml
  79. +97
    -0
      projects/os/leaflet-OS-about.el.xhtml
  80. +87
    -0
      projects/os/leaflet-OS-about.en.xhtml
  81. +92
    -0
      projects/os/leaflet-OS-about.es.xhtml
  82. +73
    -0
      projects/os/leaflet-OS-about.fr.xhtml
  83. +80
    -0
      projects/os/leaflet-OS-about.it.xhtml
  84. +118
    -0
      projects/os/leaflet-OS-about.nl.xhtml
  85. +235
    -0
      projects/os/minimalisticstandards.de.xhtml
  86. +205
    -0
      projects/os/minimalisticstandards.en.xhtml
  87. +150
    -0
      projects/os/msooxml-converter-hoax.de.xhtml
  88. +156
    -0
      projects/os/msooxml-converter-hoax.el.xhtml
  89. +142
    -0
      projects/os/msooxml-converter-hoax.en.xhtml
  90. +152
    -0
      projects/os/msooxml-converter-hoax.es.xhtml
  91. +100
    -0
      projects/os/msooxml-converter-hoax.fr.xhtml
  92. +137
    -0
      projects/os/msooxml-converter-hoax.it.xhtml
  93. +163
    -0
      projects/os/msooxml-converter-hoax.nl.xhtml
  94. +90
    -0
      projects/os/msooxml-converter-hoax.sr.xhtml
  95. +261
    -0
      projects/os/msooxml-idiosyncrasies.el.xhtml
  96. +243
    -0
      projects/os/msooxml-idiosyncrasies.en.xhtml
  97. +147
    -0
      projects/os/msooxml-idiosyncrasies.fr.xhtml
  98. +244
    -0
      projects/os/msooxml-idiosyncrasies.it.xhtml
  99. +287
    -0
      projects/os/msooxml-idiosyncrasies.nl.xhtml
  100. BIN
      projects/os/msooxml-idiosyncrasies.pdf

+ 2
- 2
about/basics/freesoftware.el.xhtml View File

@@ -151,8 +151,8 @@ FAQ</a>:
<li><a href="/freesoftware/basics/sourcecode.html">Τι είναι
ο 'πηγαίος κώδικας';</a></li>

<li> <a href="/freesoftware/basics/openstandard.html">Τι είναι
τα 'Ανοιχτά Πρότυπα';</a></li>
<li> <a href="/activities/os/os.html">Τι είναι τα 'Ανοιχτά Πρότυπα';</a>
</li>

<li><a href="/freesoftware/basics/4freedoms.html">Πώς να εξηγήσετε
τις τέσσερις ελευθερίες στα παιδιά</a></li>


+ 20
- 0
activities/ftf/fla.el.xhtml View File

@@ -13,6 +13,26 @@
<p id="category"><a href="/activities/ftf/ftf.html">Νομικό Τμήμα</a></p>
<h1>Συμφωνητικό Εμπιστευτικότητας Άδειας Χρήσης (FLA)</h1>

<!-- <h3>Περίληψη</h3>

<p>Το Συμφωνητικό Εμπιστευτικότητας Άδειας Χρήσης (Fiduciary License
Agreement - FLA) είναι μία συμφωνία ανάμεσα στον κάτοχο του copyright
και στον θεματοφύλακα. Το FLA μεταφέρει κάποια από τα δικαιώματα χρήσης
από τον κάτοχο των πνευματικών δικαιωμάτων στο θεματοφύλακα. Εκτός από
μηχανισμός συλλογής το FLA αφορά την <i>ομαδοποίηση</i> των συμφερόντων
των κατόχων copyright στον θεματοφύλακα (και όχι τη διανομή του προϊόντος).</p>

<p>Η χρήση του λογισμικού διέπεται από τη συμφωνία άδειας χρήσης. Τα
προγράμματα ελεύθερου λογισμικού έχουν συνήθως περισσότερους από έναν κατόχους
πνευματικών δικαιωμάτων οι οποίοι εργάζονται συλλογικά σε κάθε πρόγραμμα.
Σε ενδεχόμενη παραβίαση της συμφωνίας άδειας χρήσης αυτά τα κατανεμημένα
πνευματικά δικαιώματα ίσως να προκαλέσουν προβλήματα επειδή σε περίπτωση
αγωγής ίσως απαιτηθεί η παρουσία όλων των κατόχων copyright.</p>

<p>Το FLA συγκεντρώνει όλα τα δικαιώματα των κατόχων copyright
στο θεματοφύλακα. Τότε αυτός θα είναι σε θέση να προβάλλει τα συμφέροντα
των κατόχων copyright στο δικαστήριο.</p> -->

<h3>Τι είναι το FLA;</h3>

<p>Το Συμφωνητικό Εμπιστευτικότητας Άδειας Χρήσης (Fiduciary Licence


+ 31
- 0
campaigns/pdfreaders/follow-up.el.xhtml View File

@@ -26,6 +26,37 @@
στις υπηρεσίες της χώρας σας ζητώντας τους να αφαιρέσουν τις διαφημιστικές
καταχωρήσεις μη-ελεύθερου λογισμικού από τους ιστοχώρους τους.</p>

<h2>Ελέγξτε πριν</h2>

<p>Πριν ξεκινήσετε να στέλνετε μηνύματα αλληλογραφίας ρίξτε μια ματιά στον
ιστότοπο της αναφερόμενης υπηρεσίας στη
<a href="/campaigns/pdfreaders/buglist.html">λίστα σφαλμάτων</a> και
ελέγξτε αν έχουν αφαιρέσει τη διαφήμιση. Αν δεν δείτε διαφήμιση κάνετε
τα ακόλουθα:</p>

<ul>

<li>Εξετάστε με μια μηχανή αναζήτησης αν κάποια άλλη λέξη "adobe" ή
"acrobat" υπάρχει στον τομέα, (π.χ. με site:www.exmaple.com). Αν βρεθεί
κάποιο, ενημερώστε τη λίστα σφαλμάτων με το νέο URL στο "bugs-XY.xml"
(μπορείτε να στείλετε και μήνυμα στην
<a href="mailto:web@fsfeurope.org">ομάδα ιστού</a> αν δεν έχετε πρόσβαση
για τροποποίηση του ιστοτόπου).</li>

<li>Αν δεν υπάρχει καμία, γράψτε στο <a
href="mailto:pdfreaders@lists.fsfe.org">pdfreaders@lists.fsfe.org</a>,
αναφέρετε την επιτυχία σας και ζητήστε να σημειωθεί το σφάλμα
ως διορθωμένο.</li>

<li>Έπειτα γράψτε ένα μικρό ευχαριστήριο μήνυμα στη δημόσια υπηρεσία.</li>

</ul>

<p>Αν η διαφήμιση είναι ακόμη ορατή στον ιστότοπο της δημόσιας υπηρεσίας
μπορείτε να δραστηριοποιηθείτε στέλνοντάς τους μήνυμα <a
href="/campaigns/pdfreaders/letter.html">με βάση το υπόδειγμα επιστολής
μας</a>.</p>

<h2>Να είστε πάντα ευγενικοί</h2>

<p>Ο θυμός δεν θα βοηθήσει καθόλου. Στείλαμε μια επιστολή που περιείχε μια


+ 21
- 0
events/2012/event-20120818-01.el.xml View File

@@ -0,0 +1,21 @@
<?xml version="1.0" encoding="utf-8" ?>
<eventset>
<event start="2012-08-18" end="2012-08-19">
<title>OggCamp 2012 Λίβερπουλ</title>
<body>
Το FSFE για ακόμη μία φορά θα έχει παρουσία στο Ogg Camp
με πληροφορίες, εμπορεύματα, φυλλάδια και την ευκαιρία εγγραφής.
Ελάτε και μιλήστε με τα Μέλη και τον συντονιστή του FSFE για το
Ηνωμένο Βασίλειο.
</body>
<link>http://oggcamp.org/</link>
<tags>
<tag>front-page</tag>
<tag>gb</tag>
<tag>fellowship</tag>
<tag>liverpool</tag>
<tag>booth</tag>
<tag>oggcamp</tag>
</tags>
</event>
</eventset>

+ 25
- 0
events/2012/event-20120925-01.el.xml View File

@@ -0,0 +1,25 @@
<?xml version="1.0" encoding="UTF-8"?>

<eventset>
<event start="2012-09-25" end="2012-09-25">
<title>World Computer Congress: Πώς οι πατέντες λογισμικού
καθυστερούν το μέλλον</title>
<body>
<p>
Στις 25 Σεπτεμβρίου στο 22ο IFIP World Computer Congress στο Άμστερνταμ,
στην Ολλανδία, ο Karsten Gerloff θα συμμετάχει σε μια συζήτηση ειδικών
για τις πατέντες στο λογισμικό. Η συζήτηση σχετικά με το αν «οι πατέντες
προάγουν την καινοτομία στο πεδίο του λογισμικού υπολογιστών» διοργανώνεται
από το European Patent Organisation.
</p>
</body>
<page>http://www.wcc-2012.org/</page>
<tags>
<tag>swpat</tag>
<tag>patents</tag>
<tag>policy</tag>
<tag>nl</tag>
<tag>front-page</tag>
</tags>
</event>
</eventset>

+ 19
- 22
freesoftware/basics/summary.el.xhtml View File

@@ -10,21 +10,27 @@
<h1>Ελεύθερο Λογισμικό</h1>
</div>

<p><a href="http://www.fsfe.org/about/basics/freesoftware.html">Ελεύθερο Λογισμικό</a> είναι το λογισμικό που
εγγυάται ένα σύνολο ελευθεριών για τον κάτοχό του. Είναι «ελεύθερο» όπως στην ελευθερία και όχι δωρεάν με την
απόδοση της έκφρασης free beer. Για την αποφυγή της σύγχυσης, άλλα ονόματα εμφανίστηκαν, όπως Ανοικτός Κώδικας,
Libre Software, FOSS, FLOSS... Στο FSFE, <a href="http://www.fsfe.org/documents/whyfs.html">προτιμάμε να μιλάμε
για «Ελεύθερο Λογισμικό»</a> επειδή αυτός ο όρος αντανακλά καλύτερα τη βασική φιλοσοφία με τις
<a href="http://www.fsfe.org/freesoftware/basics/4freedoms.html">τέσσερις ελευθερίες του Ελεύθερου Λογισμικού</a>.
<p><a href="http://www.fsfe.org/about/basics/freesoftware.html">Ελεύθερο
Λογισμικό</a> είναι το λογισμικό που εγγυάται ένα σύνολο ελευθεριών για τον
κάτοχό του. Είναι «ελεύθερο» όπως στην ελευθερία, όχι με την έννοια του δωρεάν.
Αν και <a href="/about/basics/freesoftware.html#terminology">μια ποικιλία
όρων</a> χρησιμοποιούνται για να αποδοθεί η σημασία αυτή, στο FSFE
<a href="/documents/whyfs.en.html">προτιμάμε να μιλάμε για ελεύθερο λογισμικό
</a> επειδή έτσι αντανακλάται καλύτερα η φιλοσοφία σχετικά με τις
<a href="/freesoftware/basics/4freedoms.en.html">τέσσερις ελευθερίες</a>
οι οποίες είναι εγγενείς σε αυτό.
</p>

<p>Το κίνημα του Ελεύθερου Λογισμικού προέρχεται από τον Richard Stallman το 1983 όταν εγκαινίασε το
<a href="http://www.fsfe.org/freesoftware/basics/gnuproject.html">GNU project</a>. Στηρίχθηκε στην ιδέα
ότι ο χρήστης αποκτά ισχύ αν έχει πλήρη έλεγχο στο λογισμικό που αγοράζει, και για αυτό χρειάζεται, ανάμεσα
στα άλλα, να έχει πρόσβαση στον <a href="http://www.fsfe.org/freesoftware/basics/sourcecode.html">πηγαίο κώδικα</a>.
Πέρα από την εργασία στο λογισμικό, ο αγώνας για την υιοθέτηση του ελεύθερου λογισμικού έχει επεκταθεί
και στον αγώνα για την υιοθέτηση νόμων για τα
<a href="http://www.fsfe.org/freesoftware/basics/openstandard.html">ανοικτά πρότυπα</a>.</p>
<p>Το κίνημα του Ελεύθερου Λογισμικού ξεκίνησε με τον Richard Stallman το 1983
όταν εγκαινίασε το
<a href="/freesoftware/basics/gnuproject.html">GNU project</a>. Στηρίχθηκε
στην ιδέα ότι οι άνθρωποι πρέπει να έχουν πλήρη έλεγχο στο λογισμικό που
κατέχουν. Ο Stallman αντιλήφθηκε ότι για να είναι αυτό εφικτό, η πρόσβαση στον
<a href="/freesoftware/basics/sourcecode.html">πηγαίο κώδικα</a> του
προγράμματος ενός υπολογιστή είναι μια θεμαλιώδης απαίτηση. Πέρα από το πεδίο
της βιομηχανίας υπολογιστών, ο αγώνας για την υιοθέτηση του ελεύθερου
λογισμικού έχει επεκταθεί και στον αγώνα για την υιοθέτηση νόμων για τα
<a href="/freesoftware/basics/openstandard.html">ανοιχτά πρότυπα</a>.</p>

<div class="related">

@@ -59,15 +65,6 @@ Libre Software, FOSS, FLOSS... Στο FSFE, <a href="http://www.fsfe.org/documen

</ul>

<!--h2>Κείμενα ομιλιών</h2>

<ul>
<li><a href="/freesoftware/transcripts/rms-2009-05-22-eliberatica.html">Διάλεξη του Richard Stallman
στο Βουκουρέστι στις 22 Μαΐου 2009</a></li>
<li><a href="/freesoftware/transcripts/rms-fs-2006-03-09.html">Διάλεξη του Richard Stallman στο Ζάγκρεμπ
στις 9 Μαρτίου 2006</a></li>
</ul-->

</div>

</body>


+ 58
- 0
news/legal-news.el.xhtml View File

@@ -0,0 +1,58 @@
<?xml version="1.0" encoding="utf-8" ?>

<html>
<head>
<title>Αρχειοθήκη Νομικών Ειδήσεων – FSFE</title>
</head>
<body>
<h1>Αρχειοθήκη Νομικών Ειδήσεων</h1>

<p id="introduction">
Η σελίδα αυτή συλλέγει όλες τις ειδήσεις νομικού ενδιαφέροντος που
δημοσιεύονται στον ιστοχώρο του FSFE. Στις Νομικές Ειδήσεις συλλέγουμε
ενδιαφέροντες συνδέσμους για την αδειοδότηση Ελεύθερου Λογισμικού,
για ζητήματα σχετικά με επιχειρήσεις Ελεύθερου Λογισμικού, για πατέντες
λογισμικού, για την Κυβέρνηση και για πολιτικές για το Ελεύθερο Λογισμικό,
για τα Ανοιχτά Πρότυπα και τη Δικτυακή Ουδετερότητα.
</p>
<legal-news/>
<h2>Σχετικά με τις Ειδήσεις Νομικού Ενδιαφέροντος για το Ελεύθερο Λογισμικό</h2>
<h2 id="subpages">Πλοήγηση</h2>
<ul>

<li>
<h3><a href="/news/legal-news.html">Στείλτε Νομικές Ειδήσεις</a></h3>
<p>Σύνδεσμοι σχετικα με την ειδησεογραφία για το Ελεύθερο Λογισμικό
συλλέγονται και μετά από επεξεργασία δημοσιεύονται σε εβδομαδιαία βάση
για την παρακολούθηση σημαντικών νομικών ζητημάτων. Καλωσορίζουμε
την υποβολή ειδήσεων με συνδέσμους σε μηνύματα αλληλογραφίας στο
legal-news at fsfeurope dot org</p>
</li>
<li>
<h3><a href="/activities/ftf/ftf.html">FSFE Νομικό Τμήμα -
Η Ομάδα Εργασίας Ελευθερίας</a></h3>
<p>
Το FSFE έχει δεσμευτεί να βοηθά άτομα, έργα, επιχειρήσεις και δημόσιες
υπηρεσίες στην εξεύρεση για το Ελεύθερο Λογισμικό νομικής πληροφόρησης,
ειδικών και υποστήριξης. Αποστολή μας είναι η διάδοση της γνώσης,
η επίλυση προβλημάτων και η ενθάρρυνση της μακροπρόθεσμης ανάπτυξης του
Ελεύθερου Λογισμικού.
</p>
</li>
</ul>

</body>
<timestamp>$Date: 2011-04-22 17:37:47 +0200 (ven. 22 avril 2011) $ $Author: ato $</timestamp>
</html>
<!--
Local Variables: ***
mode: xml ***
End: ***
-->

BIN
projects/os/201003-odt-questions.odt View File


+ 164
- 0
projects/os/2012-06-uk-consultation-os.en.xhtml View File

@@ -0,0 +1,164 @@
<?xml version="1.0" encoding="UTF-8" ?>

<html>
<head>
<title>FSFE's submission to the UK Open Standards Consultation 2012</title>
<meta content="FSFE's submission to the UK Open Standards Consultation 2012" name="description" />
<meta content="Open standards UK submission ICT Futures team Cabinet Office European interoperability framework Declaration on Standards Future of the Internet Document Freedom Day Definition Emerging Standards FSFE" name="keywords" />
</head>

<body>
<p id="category"><a href="http://www.fsfe.org/projects/work.html">Our Work</a> / <a href="/projects/os/os.html">Overview of Open Standards</a></p>
<h1>Submission to UK Open Standards Consultation 2012</h1>

<div id="introduction">

<p>This is FSFE's submission to the <a href="http://consultation.cabinetoffice.gov.uk/openstandards/">UK Open Standards Consultation</a>, held by the ICT Futures team in Cabinet Office, submitted on 1st June 2012.</p>
</div>

<h2>Chapter 1: Criteria for Open Standards</h2>

<h3>1. How does this definition of open standard compare to your view of what makes a standard 'open'?</h3>

<h4>What exactly is a "government body"?</h4>

<p>FSFE supports the content of the proposed definition, but some details in wording still have to be clarified, in order to ensure that the policy can be implemented effectively: </p>

<blockquote> 1. Government bodies must consider open standards for software interoperability, data and document formats and in procurement specifications should require solutions that comply with open standards, unless there are clear, documented business reasons why this is inappropriate.</blockquote>

<p>First, it is not clear what is meant by a “government body”. We fear that in the end just a small subset of public bodies will be covered by this term, and consequently by the policy.</p>
<p>Software and in particular document formats are subject to strong network effects, and one government body using proprietary formats might cause problems for many others using formats based on Open Standards.If an Open Standards policy is to be effective, it needs to address the largest possible set of organisations. We therefore propose to use “Public bodies or private bodies exercising public functions” instead of “government bodies”.</p>
<p>Furthermore, it is not clear from the available policy documents which public bodies will be within the scope of the policy. According to information provided by Cabinet Office representative Linda Humphries in a meeting on Open Standards and Leveling the Playing Field on May 29, 2012, the policy would only apply to central government bodies, not local governments or other government bodies. She also remarked that the G-Cloud Strategy would not be covered by the policy.</p>
<p>This limited reach would severely constrain the effectiveness of the policy, and heavily curtail the benefits it will provide. Local authorities, the education and health sectors, and a plethora of other public bodies will continue to be locked into overpriced, proprietary solutions, and lack guidance and support from central government to build vendor-independent IT systems. Small and medium IT companies will continue to be excluded from most of the public-sector market, as public-sector IT spending will remain heavily concentrated on a small number of large systems integrators.</p>
<p>These problems will be even more severe where the G-Cloud is concerned. If this central service is built on anything else than Open Standards, this will compound the current set of problems (concentrated procurement, vendor lock-in, amplified by network effects, leading to a lack of competition) for the entire UK public sector, and make it even more difficult for public bodies to pursue IT strategies which are orientated towards long-term sustainability and value for money. Given the network effects described above, the policy will only be effective if a broad set of government bodies are compelled to move to Open Standards.</p>
<p>Procurement teams will also require training in dealing with legacy software solutions, and breaking free from vendor lock-in. Without a proactive effort by the government, widespread vendor lock-in will all but guarantee the policy's failure.</p>
<p>The proposed "comply or explain" approach is largely suitable. However, we strongly recommend that compliance should be determined, and explanations provided, *before* the procurement actually proceeds. Once tenders are published and contracts are signed, corrections and alternative approaches are infinitely harder to implement.</p>
<p>Therefore, we propose the following wording:</p>

<blockquote> 1. [Public bodies or private bodies exercising public functions] must [use] open standards for software interoperability, data and document formats and in procurement specifications should require solutions that comply with open standards, unless there are clear, documented business reasons why this is inappropriate. </blockquote>

<p>It should however be made very clear that the fact that an organisation is currently subject to vendor lock-in on account of its use of proprietary formats is not a "clear, documented business reason" to refuse adopting Open Standards. UKG should provide education and assistance for overcoming the obstacles of current vendor lock-in to public bodies and private bodies exercising public functions.</p>
<p>This provides a strong impulse for change in line with the intent of the policy, while still preserving an option for those public bodies which are for some reason unable (rather than merely unwilling) to move to Open Standards.</p>

<h4>Licensing of patents in standards</h4>
<p>In </p>

<blockquote> 2. For the purpose of UK Government software interoperability, data and document formats, the definition of open standards is those standards which fulfill the following criteria: [...]</blockquote>

<p>FSFE sees problems in the following part of the definition:</p>

<blockquote>owners of patents essential to implementation have agreed to license these on a royalty free and non-discriminatory basis for implementing the standard and using or interfacing with other implementations which have adopted that same standard. Alternatively, patents may be covered by a non-discriminatory promise of non-assertion.</blockquote>

<p>Royalty-free (and restriction-free) licensing of patents contained in standards is the norm in IT, and more so in software standardisation. In software, so-called "FRAND" ("Fair, Reasonable And Non-Discriminatory) licensing of patents necessary to implementing a standard puts the patent holder in control of an entire product category, and is therefore inimical to competition and innovation in the market.</p>
<p>In particular, FRAND licensing is incompatible with the most widely used Free Software licenses, such as the GNU General Public License. Even in a hypothetical approach where patent royalty rates would be set to zero, the patent holder (usually a large corporation) would still be able to refuse a patent license to a Free Software project, or impose conditions which effectively prevent the project from implementing the standard. Even though recourse through the legal system might be available in theory, in practice the Free Software developers (often small companies) will rarely have the required resources to confront a multinational corporation in court.</p>
<p>It is therefore essential that UKG insists that patents included in standards for software are made available to any interested party without licensing fees or restrictions.</p>

<h3>2. What will the Government be inhibited from doing if this definition of open standards is adopted for software interoperability, data and document formats across central government?</h3>

<p>If the Government adopts a definition of Open Standards along the lines of what we propose in response to question 1, this would greatly increase the freedom of action which public bodies and private bodies exercising public functions - enjoy.</p>
<p>The only restriction they would suffer is that they would no longer be at liberty to lock themselves into proprietary formats owned by a single vendor; this can only be considered a good thing. In cases where there is currently no Open Standard available, or where it is not feasible to use, the policy provides sufficient alternative options ("comply or explain", which should be a step taken before a public body releases a call for tender.)</p>
<p>If, however, application of the policy is restricted to central government alone, this will lead to severe interoperability problems with the rest of the UK's public sector, which remains mired in vendor lock-in. We recommend that UKG should take a bolder stance, apply the policy as widely as possible, and take steps to enable all public sector organisations to implement it.</p>

<h3>3. For businesses attempting to break into the government IT market, would this policy make things easier or more difficult - does it help to level the playing field?</h3>

<p>Adopting the proposed policy including FSFE's amendments (see Question 1) would be a significant step towards leveling the playing field. Today, 60% of revenue from central government contracts goes to only 10 or so systems integrators. It is not acceptable for the government to pick winners in this fashion. </p>
<p>The policy, if implemented in full, will be an important step towards opening the UK's public sector IT market to competition. A comprehensive Open Standards policy would greatly lower the bar for UK businesses, in particular smaller ones, to compete for government contracts. In addition, Open Standards naturally circumvent vendor lock-in and therefore guarantee the freedom of choice for future government procurement and a vivid competition inside the government IT market.</p>

<h3>5. What effect would this policy have on improving value for money in the provision of government services?</h3>

<p>The policy would substantially open up competition for government business as Open Standards can be implemented by the widest possible range of software suppliers. For the buyers, this means lower prices, and better quality. The absence of a vendor lock-in would allow government bodies to switch suppliers comparatively easily.</p>
<p>By making it easy to move from one supplier to another, Open Standards guarantee maximum choice for customers This, in turn, leads to improved performance as vendors compete to keep government customers loyal. </p>
<p>In addition, using Open Standards will boost innovation, as new products can be based on existing ones. Innovation in software development is, and has always been, largely incremental, building on improvements made by others. Open Standards make these incremental innovations a lot easier, accelerating the rate of innovation, which will in turn lead to better products on the market.</p>
<p>The technologies that make up the Internet are best examples of an infrastructure which is built upon non-restrictive and royalty-free standards, thus enabling Free Software as well as proprietary programs to compete in the most vibrant and innovative environment.</p>

<h3>6. Would this policy support innovation, competition and choice in delivery of government services? </h3>
<p>The openness of standards for software, document formats and data is critical in this respect. Since Open Standards can be implemented without restrictions, the proposed policy would greatly contribute to supporting innovation, competition and choice in the delivery of government services. Standards provide a platform on top of which businesses can compete, and Open Standards mean that there is no limit to the number and approaches which businesses can take to satisfy government needs.</p>
<p>If public data, for example, is published or delivered in formats based on Open Standards, this makes it possible for anyone to build innovative software to interact with this data. This will enable citizens to take the initiative and develop applications to suit their needs and those of their communities.</p>
<p>As explained above, the policy would be key to introducing real competition into the market for public sector IT service contracts in the UK. Currently, most of the UK's public bodies are tied to a small number of large vendors, many of which are headquartered outside the UK. </p>
<p>If the policy is implemented in full, across all public bodies and private bodies exercising public functions, together with suitable training and education for procurement staff, it will become possible for a large number of UK businesses (both existing and new) to compete for public sector IT contracts, as barriers to market entry will decrease significantly. </p>

<h3>7. In what way do software copyright licences and standards patent licences interact to support or prevent interoperability? </h3>
<p>As explained above, FRAND licensing of patents in standards for software, data and document formats is incompatible with the most widely used Free Software licenses. At the same time, many of the main competitors to dominant programs in the market are Free Software. Deciding which patent licensing policies to accept in standards therefore turns into a choice between a free market and one dominated by an oligopoly. </p>
<p>To ensure software interoperability, copyright and patent licenses may only be included in an Open Standard under a non-restriction and non-assertion license. Otherwise this standard will exclude Free Software from using it and is not in any sense interoperable. (F)RAND licensing thereby prevents interoperability. Royalty-free licenses on the other hand are free to use, also for Free Software and therefore strongly support interoperability. Please see Question 8 for a more detailed analysis.</p>


<h3>8. How could adopting (Fair) Reasonable and Non Discriminatory ((F)RAND) standards deliver a level playing field for open source and proprietary software solution providers? </h3>

<p>(F)RAND standards cannot deliver a level playing field for participants in the software market because most (F)RAND standards require a royalty fee to be paid for each copy of a program that is distributed. Paying royalties of even a single penny per copy or less to implement a standard might appear "fair" to someone not familiar with the problem. </p>
<p>In addition, and maybe even more important, per-copy royalties are fundamentally incompatible with the GNU GPL, which is the most widely used Free Software license [See <a href="http://osrc.blackducksoftware.com/data/licenses/">statistic of “Top 20 Most Commonly Used Licenses in Open Source Projects”</a>] and covers key programs such as the Linux kernel and much of the GNU operating system. Moreover, such royalties are fundamentally incompatible with most of the Free Software licenses out there. According to the quantity of usage of different licenses, more than 80% of Free Software projects are distributed under licenses that are incompatible with patent royalty-bearing regimes. In reality, (F)RAND is unfair, unreasonable, and highly discriminatory against all Free Software.</p>
<p>The only solution that enables full competition is "zero-royalty" or "royalty-free" licensing for patents included in standards for software, data, and document formats. Because "zero-royalty" does not exclude Free Software from using the standard nor does it exclude proprietary (or even heavily patented) implementations. Indeed, "Zero-royalty" means that if certain technologies are mandated by a standard, they must be available to everybody without requiring running royalties. Meanwhile the implementations can be distributed under any given license and include any technology, provided that the standard is respected.</p>
<p>The exponential growth of the Internet and the World Wide Web, which are built entirely on the basis of restriction-free standards, clearly demonstrate the potential that the policy can unleash if UKG sticks to <a href="http://fsfe.org/projects/os/def.en.html">a definition of Open Standards that makes them available for implementation to all interested parties without restrictions</a>.</p>

<h3>9. Does selecting open standards which are compatible with a free or open source software licence exclude certain suppliers or products? </h3>
<p>Open Standards do not exclude anyone. On the contrary, since they can be implemented by anyone, they open up the market to all players.</p>
<p>Since by definition, there are no restrictions on implementing an Open Standard, developers of proprietary software have the option of including support for the relevant interfaces or file formats in their programs, at no cost beyond that of the implementation itself. Claims that requiring Open Standards would exclude one group of suppliers are generally without merit.</p>

<h3>10. Does a promise of non-assertion of a patent when used in open source software alleviate concerns relating to patents and royalty charging? </h3>
<p>Businesses serving government need a firm legal basis to build upon. While a promise not to assert a patent is generally a friendly gesture by the patent holder, it is no replacement for a clear policy requirement for Open Standards, which can be implemented without royalty payments or restrictions. Promises of non-assertion may eventually be rescinded (e.g. when the patents it covers are sold to another company). </p>

<h3>12. In terms of standards for software interoperability, data and document formats, is there a need for the Government to engage with or provide funding for specific committees/bodies? </h3>
<p>Regarding UKG's approach of setting up an Open Standards Board to steer the implementation of the policy, we consider it essential that discussions of the board are conducted in a transparent fashion. In order to ensure participation is not limited to representatives of the current large suppliers, there needs to be the opportunity for representatives of smaller companies to participate in the board and exercise equal influence. Board discussions need to be structured in a way that minimises the time burden especially on representatives of small companies. UKG should consider setting up a mechanism to encourage and support the participation of smaller companies in the board.</p>

<h2>Chapter 2: Open standards mandation</h2>

<h3>1. What criteria should the Government consider when deciding whether it is appropriate to mandate particular standards?</h3>
<p>Where it mandates a particular standard for software, data, or document formats, government must make sure that the standard is an Open Standard -- it must carry no restrictions on implementation, and must not require the implementer to pay patent royalties.</p>

<h3>4. Could mandation of competing open standards for the same function deliver interoperable software and information at reduced cost? </h3>
<p>Competition takes place on top of standards, not between standards. Competition on top of a standard removes barriers, increases interoperability and customer choice. Competition between standards reduces interoperability, fragments the market, and leads to vendor lock-in.</p>
<p>For example, the frequency used in alternating-current (AC) electricity networks -- 50 Hz -- is largely arbitrary. It might be equally possible to use a frequency of 40 Hz, or 70 Hz, instead. What is important is that everyone connecting to the network -- electricity generators as well as users -- use the same frequency. </p>
<p>If government decides to mandate standards, it would be best by recommending an initial set of Open Standards. These standards must strictly conform to the definition and should come with a large number of implementations, in order to provide a basis on which the policy can be successfully implemented. Other Open Standards can be added to this list at a later date.</p>

<h3>5. Could mandation of open standards promote anti-competitive behaviour in public procurement? </h3>
<p>Mandating Open Standards could not conceivably lead to anticompetitive behaviour in the software market. Quite to the contrary, they are the best way to open up competition in the software market. Since Open Standards carry no restrictions on implementation, smaller implementers (all else being equal) are in a better position to challenge incumbents. Conversely, standards with restrictions on their implementation have long been shown to foster anticompetitive behaviour (e.g. Microsoft's proprietary .doc format).</p>

<h3>7. How should the Government best deal with the issue of change relating to legacy systems or incompatible updates to existing open standards? </h3>
<p>Legacy systems and file formats are a cost factor in any case. Even with proprietary software and formats, new versions of a program frequently are unable to properly process older versions of what is notionally the same file format. Extracting data and converting files into new formats is a significant task in any IT migration. An organisation that adopts Open Standards will only have to do this once in order to move its files to a format that is fully and publicly documented. Thereafter, it is easy to use (and if necessary build) tools to convert files from one open format to another as needed.</p>
<p>However, UKG should be clear about the fact that breaking free from vendor lock-in will require an initial effort. Experience from numerous other countries in Europe and around the world shows that policies such as the one proposed can only be implemented if the people who are supposed to implement them -- procurement and IT teams in public bodies and private organisations exercising public functions -- receive training and assistance. </p>
<p>The costs of these efforts (which are really costs that the user organisation incurred at the time it chose a proprietary IT solution or document format) will be quickly offset by savings realised by buyers in a more competitive IT service market.</p>

<h3>9. How should the Government strike a balance between nurturing innovation and conforming to standards? </h3>
<p>This is the wrong question to ask. There is no balance to be struck. Standards, and Open Standards in particular, provide a basis for innovation because innovation happens on top of standards, not within standards. The great innovation space that is the Internet is based on a set of Open Standards that have either remained unchanged for decades, or have been updated slowly and carefully. It is exactly this "conservative" approach to standards that has turned the Internet into the basis of a huge number of innovations.</p>
<p>UK government would therefore best encourage innovation by relying on well-established Open Standards, and pushing for them to be used across the entire UK public sector. This will remove the barriers to innovation presented by proprietary formats and interfaces, and allow market participants to innovate and build tomorrow's solutions. </p>

<h3>11. Are there any are other policy options which would meet the objective more effectively? </h3>
<p>A strong mandate for Open Standards, together with an overhaul of procurement practices, is the single best policy option on the table to increase the government's value for money, and promote innovation in the software sector.</p>
<p>To guarantee these benefits, there should be a mechanism to give recognition to those public bodies which follow the policy. At the same time, public bodies which fail to follow the policy need to be identified, and actively encouraged to adhere to the policy in future. For example, there could be a peer-review procedure for some of the body's tenders. At the same time, UKG needs to ensure that bidders who were excluded due to a body's failure to adhere to the policy have an easy, low-cost route to challenging the tenders concerned.</p>
<p>Regarding UKG's approach of setting up an Open Standards Board to steer the implementation of the policy, we consider it essential that discussions of the board are conducted in a transparent fashion. In order to ensure participation is not limited to representatives of the current large suppliers, there needs to be the opportunity for representatives of smaller companies to participate in the board and exercise equal influence. Board discussions need to be structured in a way that minimises the time burden especially on representatives of small companies. UKG should consider setting up a mechanism to encourage and support the participation of smaller companies in the board.</p>


<h2>Chapter 3: International alignment</h2>

<h3>Is the proposed UK policy compatible with European policies, directives and regulations (existing or planned) such as the European Interoperability Framework version 2.0 and the reform proposal for European Standardisation?</h3>
<p>The proposed policy is not only fully compatible with European policies, regulations and directives. It faithfully transposes what the European Interoperability Framework has to say with regard to Open Standards into actionable national policy. The relevant parts of the EIF in turn build on the Ministerial Declarations made in Malmo and Granada, highlighting the need for all EU member states to produce compatible national interoperability frameworks by 2013.</p>
<p>The policy is also in line with the Digital Agenda for Europe, in particular the actions concerning the European Interoperability Framework (24, 25, 26, 27), the ICT procurement guidelines (Action 23), the Horizontal guidelines (22) and the European Standardisation Reform (21).</p>

<h3>Will the open standards policy be beneficial or detrimental for innovation and competition in the UK and Europe?</h3>
<p>The Open Standards policy, if implemented effectively across the UK's public sector and including private organisations exercising public functions, would be highly beneficial for innovation and competition in the IT markets of the UK and Europe. </p>
<p>Applied in this fashion, the policy would open up the UK market to full competition, lowering prices and increasing performance across the board.</p>
<p>Without a broad application of the policy, however, we fear that the policy will have little impact in practice. The UK's public bodies would then continue to suffer from vendor lock-in, and spending funds provided by UK taxpayers on overpriced proprietary IT solutions rather than more essential public services. The IT service market in the UK would remain highly concentrated, with more than 60% of public-sector contracts going to only 10 or so large suppliers and systems integrators. Finally, the Cabinet Office itself, having put such commendable efforts behind developing this policy, would lose quite a bit of credibility in the eyes of the IT industry, which may harm its negotiating position in future.</p>

<h3>Are there any are other policy options which would meet the objectives described in this consultation paper more effectively?</h3>
<p>The proposed policy seems largely suitable, if the modifications proposed in our response are implemented. Based on experience gained in other countries (e.g. Sweden, Italy, Spain, Germany, the Netherlands, and others), it will be essential for the policy's success that the government invests in training those who will have to implement the policy around the UK public sector, and in making it possible for them to receive advice on an ongoing basis.</p>
<p>There should be a mechanism to give recognition to those public bodies which follow the policy. At the same time, public bodies which fail to follow the policy need to be identified, and actively encouraged to adhere to the policy in future. For example, there could be a peer-review procedure for some of the body's tenders. At the same time, UKG needs to ensure that bidders who were excluded due to a body's failure to adhere to the policy have an easy, low-cost route to challenging the tenders concerned.</p>
<p>Sweden's approach of public-sector framework contracts for the procurement of Free Software has proved successful, and should be adopted in the UK. This approach has greatly helped to broaden IT choice for Sweden's public-sector buyers, and has provided them with an easy way to exercise that choice in practice.</p>
<p>Free Software use in the UK lags far behind the rest of Europe. The UK now is in the happy position to avail itself of the benefits of Free Software, while being able to learn from the experience of others. For the benefit of its citizens and businesses, the UK government should seize this opportunity.</p>

<h2>For further information about FSFE's work on Open Standards:</h2>
<ul>
<li><a href="http://fsfe.org/projects/os/def.en.html">FSFE`s definition of Open Standards</a></li>
<li><a href="http://fsfe.org/projects/os/os.en.html">Overview of FSFE`s work on Open Standards</a></li>
<li><a href="http://fsfe.org/projects/os/ps.en.html">Analysis on balance: Standardisation and Patents</a></li>
<li><a href="http://fsfe.org/projects/os/bsa-letter-analysis.en.html">Defending Open Standards: FSFE refutes BSA's false claims to European Commission</a></li>
<li><a href="http://fsfe.org/projects/igf/sovsoft.en.html">Open Standards, Free Software, and the Internet</a></li>
</ul>

</body>

<timestamp>$Date: 2012-04-21 17:12:14 +0200 (Sat, 21 Apr 2012) $ $Author: samtuke $</timestamp>
</html>
<!--
Local Variables: ***
mode: xml ***
End: ***
-->

BIN
projects/os/FSFE-response.questionnaire.pdf View File


BIN
projects/os/bsa-eif-letter-fsfe-response.pdf View File


+ 400
- 0
projects/os/bsa-letter-analysis.de.xhtml
File diff suppressed because it is too large
View File


+ 394
- 0
projects/os/bsa-letter-analysis.el.xhtml
File diff suppressed because it is too large
View File


+ 162
- 0
projects/os/bsa-letter-analysis.en.xhtml View File

@@ -0,0 +1,162 @@
<?xml version="1.0" encoding="UTF-8" ?>

<html>
<head>
<meta name="keywords" content="eif,european interoperability framework,open standards,fsfe,open source,commission,europe,standards" />
<meta name="description" content="The Business Software Alliance (BSA) is pressuring the European Commission to remove the last vestiges of support for Open Standards from the latest version of the EU's interoperability recommendations, the European Interoperability Framework (EIF)" />
<title>EIF BSA Letter</title>
</head>
<body>
<p id="category"><a href="/projects/os/os.html">Open Standards</a></p>
<h1>Defending Open Standards: FSFE refutes BSA's false claims to European Commission</h1>

<p id="introduction">The Business Software Alliance (BSA) is pressuring the European Commission to remove the last vestiges of support for Open Standards from the latest version of the EU's interoperability recommendations, the European Interoperability Framework.
<br /><br />
FSFE has obtained a copy of <a href="/projects/os/bsa-letter-ec.pdf">a letter sent to the Commission</a> by the BSA last week. In the following paragraphs we analyse the BSA's arguments and explain why their claims are false, and why Open Standards are key to interoperability and competition in the European software market. We have <a href="/projects/os/bsa-eif-letter-fsfe-response.pdf">shared this analysis</a> with the European Commission.</p>
<ol>
<li><a href="#1">Royalty-free patent licensing opens up participation and promotes innovation</a></li>
<li><a href="#2">The BSA's example standards are irrelevant to the software field</a></li>
<li><a href="#3">(F)RAND licensing in software standards is unfair and discriminatory</a></li>
<li><a href="#4">BSA not representative of even its own membership, much less of software industry as a whole</a></li>
<li><a href="#5">(F)RAND incompatible with most Free Software licenses</a></li>
<li><a href="#6">Recommended preference for Open Standards is entirely unrelated to EU's negotiating position vis-a-vis China</a></li>
<li><a href="#7">Restriction-free specifications will promote standardisation, competition and interoperability</a></li>
<li><a href="#8">Recommendations</a></li>
</ol>

<h2 id="1">Royalty-free patent licensing opens up participation and promotes innovation</h2>

<p>In its letter, the BSA argues that "[I]f the EU adopts a preference for royalty/patent-free specifications, this undermines the incentives that firms have to contribute leading-edge innovations to standardization - resulting in less innovative European specifications, and less competitive European products."</p>

<p>Actually this reflects a gross misconception of standards, their role and their working.</p>

<ol>

<li>Zero-royalty licensing conditions do not prevent patented technologies to be included in standards. Rather the contributor is required to avoid imposing running royalties on implementations.</li>

<li>The single most successful technology platform on Earth, the Internet, is built on standards that have been made fully available under zero-royalty licensing conditions. Indeed the W3C, the standard setting organization (SSO) that governs the web standards has through consensus adopted a zero-royalty "IPR policy", where royalty bearing technologies are allowed to be contributed only on a very exceptional base. Rather than stifling inventive activity, as the BSA claims, this has turned the Internet into a hotbed of innovation. Indeed, it is the very nature of standards that they stabilise a platform on top of which competitors can create innovative and interoperable solutions<a class="fn" href="#refs">1</a>.</li>

<li>Contrary to the BSA's claim, zero-royalty patent licensing policies open up participation in software standard-setting to the widest possible group of market players and implementers. As a result, software standards coming out of standard-setting organisations with zero-royalty patent licensing policies such as the W3C have been widely adopted, with the HTML standard only being the most prominent example.</li>

</ol>

<p>From a broader policy perspective, it is also questionable that innovators, who are already receiving an incentive through a patent, would need to be further incentivised by having that patent included in a standard. A patent does not equal a right to a guaranteed revenue stream.</p>

<h2 id="2">The BSA's example standards are irrelevant to the software field</h2>

<p>The BSA argues that "[m]any of today's most widely-deployed open specifications incorporate patented innovations that were invented by commercial firms...including WiFi, GSM , and MPEG." </p>

<p>This is an attempt to create a false dichotomy between "commercial" companies inventing patented technology, in contrast to "non-commercial" inventions which are not patented. In reality a great wealth of unpatented modern technology originating in commercial companies constitute globally implemented standards (such as HTML5), whilst continuing to provide their creators with revenue.
There is no such divide, either economical or ideological, between hardware and software technologies which are patented, and those which are not. Yet the BSA divisively implies there is a difference between conventional and accepted business methods, which they associate with patents, and un-businesslike non-commercial organisations, which they associate with patent-free technology. Given the increasing prevalence of Free Software in Europe's IT service market, such a claim is plainly false.</p>

<p>The standards which the BSA cites as examples (with the exception of MPEG<a class="fn" href="#refs">2</a>) relate to hardware based technologies. The economics of the hardware market are very different from the software market. While entry into the hardware market requires very substantial investments, software companies can be started with very small amounts of capital. Requiring such software start-up to pay royalties for implementing software standards would significantly raise the barriers to market entry, reduce innovation and hinder competition, as well as raising prices for consumers (including public sector organisations).</p>

<p>For software, however, it is clear that allowing patents to be included in software standards on (F)RAND terms will unduly and unnecessarily increase the barriers to entry into the European software market, making Europe's ICT economy less competitive.</p>

<h2 id="3">(F)RAND licensing in software standards is unfair and discriminatory</h2>

<p>The BSA argues that "[R]equirements that an open specification be "freely implement[able]" and capable of being shared and re-used are ambiguous, and suggest that the standard must be free of intellectual property rights (IPR)".</p>

<p>The BSA further argues that "[FRAND ensures that] implementers of a standard can utilize those innovations on fair terms. It allows inventors to charge a reasonable fee when their technologies are incorporated into specifications[.]"
In software standards, (F)RAND terms in fact discriminate against Free Software and any business model based on it. Most widely used Free Software licenses do not allow for imposing additional conditions upon downstream recipients. Yet (F)RAND would require such conditions to be imposed, usually in the form of running royalties, rendering (F)RAND licensing policies incompatible with Free Software. Where software standards are concerned, this renders the (F)RAND approach neither reasonable nor non-discriminatory.</p>

<p>Conversely, "zero-royalty" does not exclude proprietary (and even heavily patented) implementations. Indeed "Zero-royalty" means that if certain technologies are mandated by a standard, they must be available to everybody without requiring running royalties. Meanwhile the implementations can be distributed under any given license and include any technology, provided that the standard is respected.</p>

<p>The royalty-free HTML standard for example has been implemented in a plethora of browsers, both Free Software and proprietary. This clearly demonstrates that a royalty-free software standard can enable widespread adoption, and drive innovation through competition.</p>

<h2 id="4">BSA not representative of even its own membership, much less of software industry as a whole</h2>

<p>The BSA argues that "[EIF] could be read to mean that the most innovative European and foreign companies are not welcome to participate in standards processes if they own patents in the relevant technologies and seek compensation for their inventions if those patents are made part of the standard."</p>

<p>The BSA further claims that "[S]takeholders [recognize] the important link between IPR and standardization - and also [recognize] that FRAND-based standards are highly flexible and can be implemented in a broad range of solutions, open source and proprietary".</p>

<p>Contrary to the BSA's claim to represent a unified position of the software industry, we note that ECIS, which is formed by important industry stakeholders (some of which are also members of BSA) say the opposite<a class="fn" href="#refs">3</a>. Despite having a large patent portfolio, ECIS' members want standards for software interoperability to remain unencumbered of running patent royalty requirements []. To name just one example, Google has heavily contributed to zero-royalties standards by offering an industry-backed alternative to MPEG.</p>

<h2 id="5">(F)RAND incompatible with most Free Software licenses</h2>

<p>The BSA claims that "most OSS license are entirely compatible with FRAND-based licensing."</p>

<p>By any reasonable metric (whether based upon the quantity of code available or the importance of it, or both) the most relevant Free (open source) Software licenses are:</p>

<ol>

<li>GNU GPL and LGPL</li>
<li>Mozilla Public License</li>
<li>Apache Public License</li>
<li>BSD/MIT and other ultrapermissive licenses</li>
<li>EUPL</li>

</ol>

<p>All of which, with the only arguable but uncertain exception of the ultrapermissive category, are clearly incompatible with a patent royalty bearing regime. According to the statistics released by <a href="http://www.blackducksoftware.com/oss/licenses#top20">Black Duck Software</a>, more than 85% of Free Software projects are distributed under licenses that are incompatible with patent royalty-bearing regimes. The GNU General Public License (GPL) is demonstrated to be the most widely used Free Software license by far, accounting for almost half of all projects.
Including patented technologies in Free Software products, where it is possible, requires implementers to mix proprietary parts with Free Software in awkward ways. In such cases the resulting code is necessarily proprietary software<a class="fn" href="#refs">5</a>.</p>

<h2 id="6">Recommended preference for Open Standards is entirely unrelated to EU's negotiating position vis-a-vis China</h2>

<p>The BSA claims that "[t]he ambiguity of the EIF's proposed preference will no doubt compromise the Commission's ability to maintain its robust defence of Europe's IPR holders [against Chinese threats]."</p>

<p>Claims that a recommendation to express preference for open specifications will weaken the EU's negotiating position vis-a-vis China are plainly false. Recommendations regarding the use of open software specifications in the public sector have no bearing whatsoever on the Commission's stance. Moreover, it bears repeating that "zero royalty" standards do not contradict any "robust defence" of patents, copyright and trademarks.</p>

<p>We note that in the United States, similar concerns were submitted to the US Trade Representative in the preparation for the 2010 US Special 301 report on obstacles to trade. The US Trade Representative chose not to include those concerns in the report, clearly demonstrating that the government of the United States considers this a non-issue. While such claims may be made during efforts to influence public policy, there is a marked absence of attempts to get such preferences removed by legal means - presumably because those making these claims know full well that they have no backing in fact.</p>

<h2 id="7">Restriction-free specifications will promote standardisation, competition and interoperability</h2>

<p>The BSA claims that "the EIF's proposed preference for IP-free specifications will undermine...standardization, competitiveness and interoperability over the longer term."</p>

<p>We are unable to determine what the BSA means by "IP-free" specifications, although we do believe that such wording suggests an insufficient understanding of the standard-setting process on the BSA's part.</p>

<p>The claim that the current wording of EIF could undermine interoperability is simply unacceptable. It flows from unproven assumptions that we have shown to be false in the above discussion. Currently, lock-in effects resulting from the use of proprietary programs and file formats often prevent public administrations from freely choosing their IT solutions. Instead, they remain tied to a particular vendor. The difficulties of Brighton City Council and the Swiss canton of Solothurn (to name only two examples from recent months) along with numerous other public bodies in migrating from one IT solution to another illustrate how vendor lock-in caused by patent-encumbered software standards ties users to suboptimal solutions, at great cost to taxpayers.</p>

<p>Conversely, software standards which can be implemented without restrictions allow many competing implementations to interoperate with one another. In this setting, monopoly profits for a very limited number of big players are replaced with a vibrant, innovative market driven by fierce competition. This results in better solutions and services at lower prices.</p>

<h2 id="8">Recommendations</h2>

<p>In the light of the above considerations, we urge the Commission to encourage interoperability and competition in the European software market, rather than giving incumbent dominant companies an additional lever to maintain their control of the market. To this end, we ask the Commission not to add an endorsement of (F)RAND licensing policies for software standards.
Instead, we urge the Commission to maintain the recommendation that specifications can be considered only open if they can be implemented and shared under different software licensing models, including Free Software<a class="fn" href="#refs">6</a> licensed under the Gnu GPL.</p>

<p>We also urge the Commission to include in the revised European Interoperability Framework a robust recommendation for public bodies to avail themselves of the advantages of software based on Open Standards<a class="fn" href="#refs">7</a> in terms of choice, competition, freedom from lock-in and long-term access to data.</p>

<h2 id="fn">Footnotes</h2>

<ol id="refs">

<li>See e.g. Rishab Aiyer Ghosh, Philipp Schmidt (2006): United Nations University Policy Brief, Number 1, 2006: "Open standards, properly defined, can have the unique economic effect of allowing "natural" monopolies to form in a given technology, while ensuring full competition among suppliers of that technology." [emphasis added]</li>
<li>MPEG is specifically designed to expressly mandate patented technologies even where they are largely replaceable by (arguably) non patented encumbered alternatives. This is conceivably due to the need to extract as much profits as possible from the use of their peculiar implementation of certain mathematical principles than to the need to create a common and standardized platform for interoperability purposes.
<br />
Moreover, most of the MPEG standards were established in a time when codecs were made in hardware both because the available bandwidth was limited, the generic hardware was not sufficiently powerful and</li>
<li>See <a href="http://www.ecis.eu/documents/ECISStatementreEIF13.10.10.pdf">ECIS' reaction</a> from October 13, 2010 to the BSA's letter</li>
<li>For a discussion on hybrid solutions in network protocols see <a href="/projects/ms-vs-eu/fsfe_art18_reply_published_sourcecode.pdf">FSFE and Samba Team's response to Article 18</a>.</li>
<li>See <a href="http://fsfe.org/about/basics/freesoftware.en.html">FSFE's definition of Free Software</a></li>
<li>As defined in <a href="/projects/os/def.html">FSFE's definitions of an open standard</a></li>
</ol>
</body>

<timestamp>$Date: 2010-10-05 16:30:51 +0200 (Tue, 05 Oct 2010) $ $Author: samtuke $</timestamp>
<tags>
<tag>open-standards</tag>
</tags>
<author id="gerloff" />
<author id="piana" />
<author id="tuke" />
<date>
<original content="2010-10-15" />
</date>
<download type="pdf" content="/projects/os/bsa-eif-letter-fsfe-response.pdf" />
</html>

+ 155
- 0
projects/os/bsa-letter-analysis.es.xhtml View File

@@ -0,0 +1,155 @@
<?xml version="1.0" encoding="UTF-8"?>

<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<meta name="author-name-1" content="Karsten Gerloff" />
<meta name="author-link-1" content="/about/gerloff/gerloff.html" />
<meta name="author-name-2" content="Carlo Piana" />
<meta name="author-name-3" content="Sam Tuke" />
<meta name="author-link-3" content="/about/tuke/tuke.html" />
<meta name="publication-date" content="2010-10-15" />
<meta name="pdf-link" content="/projects/os/bsa-eif-letter-fsfe-response.pdf" />
<title>Carta de la BSA sobre el FEI</title>
</head>
<body>
<h1>Defendiendo los Estándares Abiertos: la FSFE refuta las falsedades que la BSA transmitió a la Comisión Europea</h1>

<p id="introduction">La Business Software Alliance (BSA) está presionando a la Comisión Europea para eliminar los últimos vestigios de apoyo a los Estándares Abiertos de la última versión de las recomendaciones de la UE en cuestión de interoperabilidad, el Marco Europeo de la Interoperabilidad. <br /><br /> La FSFE obtuvo una copia de <a href="/projects/os/bsa-letter-ec.pdf">una carta enviada a la Comisión</a> por la BSA la semana pasada. En los párrafos siguientes vamos a analizar los argumentos de la BSA y explicar por qué sus alegaciones son falsas, y por qué los Estándares Abiertos son esenciales para la interoperabilidad y la libre competencia en el mercado europeo de software. Hemos <a href="/projects/os/bsa-eif-letter-fsfe-response.pdf">compartido este análisis</a> con la Comisión Europea.</p>
<ol>
<li><a href="#1">El licenciamiento de patentes libre de royalties abre la participación y promueve la innovación</a></li>
<li><a href="#2">Los estándares que la BSA pone como ejemplo son irrelevantes para el área del software</a></li>
<li><a href="#3">El licenciamiento (F)RAND en estándares de software es injusto y discriminatorio</a></li>
<li><a href="#4">La BSA no es representativa ni siquiera de sus propios miembros, y mucho menos de la industria del software como un todo</a></li>
<li><a href="#5">L (F)RAND es incompatible con la mayoría de las licencias de Software Libre</a></li>
<li><a href="#6">La preferencia recomendada por los Estándares Abiertos es totalmente ajena a la posición en la negociación vis-a-vis entre la UE y China</a></li>
<li><a href="#7">Las especificaciones sin restricciones promoverán la libre competencia, la normalización y la interoperabilidad</a></li>
<li><a href="#8">Recomendaciones</a></li>
</ol>

<h2 id="1">El licenciamiento de patentes libre de royalties abre la participación y promueve la innovación</h2>

<p>En su carta, la BSA argumenta que "[] Si la UE adopta una preferencia por especificaciones libres de patentes y/o royalties, eso perjudica a los incentivos con los que las empresas contribuyen a innovaciones punteras para la normalización - lo que deriva en especificaciones europeas menos innovadoras y productos europeos menos competitivos. []"</p>

<p>La verdad es que eso refleja un desconocimiento grave de los estándares, de su papel y de su funcionamiento.</p>

<ol>

<li>Las condiciones de licenciamiento libres de royalties (Zero-royalty) no impiden que las tecnologías patentadas sean incluidas en los estándares. En cierto grado, se obliga al proponente a evitar la imposición de royalties sobre las implementaciones.</li>

<li>La plataforma de tecnología de mayor éxito en la Tierra, Internet, está basada en estándares que fueron puestos a disposición íntegramente en condiciones de licenciamiento zero-royalty. La verdad es que el W3C, la organización de normalización (SSO) que rige los estándares en la web ha adoptado por consenso una "política de derechos de propiedad intelectual" zero-royalty, donde los royalties sobre las tecnologías pueden ser aceptados sólo sobre unos fundamentos muy excepcionales. En vez de sofocar la actividad inventiva, como afirma la BSA, esto transformó internet en un foco de innovación. Verdaderamente, es la propia naturaleza de los estándares la que estabiliza una plataforma sobre la cual los competidores pueden crear soluciones innovadoras y interoperables<a class="fn" href="#refs">1</a>.</li>

<li>Contrariamente a lo que la BSA reclama, las políticas de licenciamiento de patentes zero-royalty abren la participación en la configuración de los estándares de software para el mayor número posible de participantes e implementadores del mercado. Como resultado, los estándares de software que salen de las organizaciones de normalización con políticas de licenciamiento de patentes zero-royalty, como el W3C, han tenido una amplia aceptación, como el patrón HTML, sólo por ser el ejemplo más notable.</li>

</ol>

<p>Desde una perspectiva política más amplia, también es cuestionable que los innovadores, que ya están recibiendo un incentivo a través de una patente, necesiten ser más incentivados por tener esa patente incluida en un estándar. Una patente no es igual a tener derecho a un flujo de rentas garantizado.</p>

<h2 id="2">Los estándares que la BSA pone como ejemplo son irrelevantes para el área del software</h2>

<p>La BSA argumenta que "[] muchas de las especificaciones abiertas que en la actualidad están más ampliamente implantadas incorporan innovaciones patentadas que fueron inventadas por empresas comerciales... incluyendo el WiFi, el GSM y el MPEG."</p>

<p>Esta es una tentativa de crear una falsa dicotomía entre las empresas "comerciales" que inventan una tecnología patentada, en contraste con las "no-comerciales" que no son invenciones patentadas. En realidad, un gran banco de riqueza de modernas tecnologías no patentadas con origen en empresas comerciales constituyen estándares aplicados a nivel mundial (como HTML5), aunque sigan proporcionando a sus creadores una renta. No hay forma de hacer la división, sea a nivel económico o ideológico, entre tecnologías de hardware y software que son patentadas, y aquellas que no lo son. Sin embargo, la divisibilidad de la BSA implica que hay una diferencia entre los métodos de negocio convencionales y aceptados, a los que asocian con las patentes, y las organizaciones no-eficientes y no-comerciales, que ellos asocian con la tecnología libre de patentes. Dada la creciente presencia del Software Libre en el mercado europeo de servicios de TI, tal afirmación es claramente falsa.</p>

<p>Las normas que la BSA cita como ejemplos (con excepción de MPEG <a class="fn" href="#refs">2</a>) están relacionadas con tecnologías basadas en hardware. La economía del mercado de hardware es muy diferente a la del mercado de software. Mientras que la entrada en el mercado de hardware requiere inversiones muy sustanciales, las empresas de software pueden iniciar su actividad con pequeñas cantidades de capital. Exigir a estos iniciantes en el software el pago de royalties para la implementación de estándares de software elevaría significativamente las barreras para entrar en el mercado, reduciría la innovación y dificultaría la libre competencia, y también aumentaría los precios para los consumidores (incluyendo las organizaciones del sector público).</p>

<p>Para el software, sin embargo, está claro que permitir la inclusión de patentes en los estándares de software bajo las condiciones (F)RAND va a aumentar indebidamente e innecesariamente las barreras para entrar en el mercado europeo de software, haciendo que la economía de las TIC de Europa sea menos competitiva.</p>

<h2 id="3">El licenciamiento (F)RAND en estándares de software es injusto y discriminatorio</h2>

<p>La BSA argumenta que "[] Los requerimientos de que una especificación abierta sea "libremente implementable" y capaz de ser compartida y reutilizada son ambiguas, y sugieren que el estándar debe estar libre de derechos de propiedad intelectual (IPR)."</p>

<p>La BSA también argumenta que "[La FRAND garantiza que] los implementadores de un estándar puedan utilizar las innovaciones en términos justos. Esto permite que los inventores cobren una tasa razonable cuando las tecnologías son incorporadas a las especificaciones[.]" En los estándares de software, las condiciones (F)RAND, de hecho, discriminan al Software Libre y a cualquier modelo de negocio basado en él. Las licencias de Software Libre más ampliamente utilizadas no permiten la imposición de condiciones adicionales a los posteriores receptores. Sin embargo, las (F)RAND exigirían que tales condiciones fueran impuestas, generalmente bajo la forma de royalties, interpretándose que las políticas de licenciamiento (F)RAND son incompatibles con el Software Libre. Cuando hablamos de estándares de software, se interpreta que el enfoque de las (F)RAND no es razonable ni no-discriminatorio.</p>

<p>Por otro lado, el "zero-royalty" no excluye las implementaciones privativas (ni siquiera las fuertemente patentadas). En realidad, "Zero-royalty" significa que, si ciertas tecnologías están comprometidas por un estándar, éstas deberán estar a disposición de todos sin exigir royalties. Sin embargo, las implementaciones pueden ser distribuidas bajo cualquier licencia e incluir cualquier tecnología, siempre que la norma sea respetada.</p>

<p>El estándar HTML libre de royalties, por ejemplo, fue implementado en una infinidad de navegadores, tanto en Software Libre como privativo. Esto demuestra claramente que un estándar de software libre de royalties puede permitir la adopción generalizada, e impulsar la innovación a través de la libre competencia.</p>

<h2 id="4">La BSA no es representativa ni siquiera de sus propios miembros, y mucho menos de la industria del software como un todo</h2>

<p>La BSA argumenta que "El Marco Europeo de la Interoperabilidad (EIF) puede ser leído con la interpretación de que las empresas europeas y extranjeras más innovadoras no son invitadas a participar en procesos de normalización si tienen patentes propias en tecnologías relevantes y buscan compensaciones por sus invenciones si esas patentes son integradas en el estándar."</p>

<p>La BSA además reivindica que "Los inversores reconocen que existe un vínculo importante entre el DPI y la normalización - y también reconocen que los estándares basados en las FRAND son altamente flexibles y pueden ser implementados en una amplia gama de soluciones de código abierto y privativo".</p>

<p>Contrariamente a lo alegado por la BSA para representar una posición unificada del sector del software, acordémonos de que la ECIS, que está formada por importantes miembros de la industria (algunos de los cuales también son miembros de la BSA) dice lo contrario<a class="fn" href="#refs">3</a>. A pesar de tener una grande cartera de patentes, los miembros de la ECIS quieren estándares para que la interoperabilidad del software permanezca sin las cargas de funcionar bajo los requisitos de royalties de las patentes []. Para citar sólo un ejemplo, Google ha contribuido enormemente a los estándares zero-royalty, ofreciendo una alternativa para MPEG patrocinada por la industria.</p>

<h2 id="5">Las (F)RAND son incompatibles con la mayoría de las licencias de Software Libre</h2>

<p>La BSA afirma que "la mayoría de las licencias de las OSS son totalmente compatibles con el licenciamiento basado en las FRAND."</p>

<p>Desde un punto de vista razonable (bien sea basado en la cantidad de código disponible, en la importancia del mismo o en ambas cosas) las licencias de Software Libre u open souce más relevantes son:</p>

<ol>

<li>La GNU GPL y LGPL</li>
<li>La Mozilla Public License</li>
<li>La Apache Public License</li>
<li>La BSD/MIT y otras licencias ultra-permisivas</li>
<li>La EUPL</li>

</ol>

<p>Todas ellas, con la única excepción discutible pero incierta de la categoría ultra-permisiva, son claramente incompatibles con un régimen de patentes con royalties. En consonancia con las estadísticas publicadas por <a href="http://www.blackducksoftware.com/oss/licenses#top20">Black Duck Software</a>, más del 85% de los proyectos de Software Libre son distribuidos bajo licencias que son incompatibles con los regímenes de patentes con royalties. Está demostrado que la GNU General Public License (GPL) es, de lejos, la licencia de Software Libre más ampliamente utilizada, por ser usada por casi la mitad de todos los proyectos. Incluir las tecnologías patentadas en productos de Software Libre, cuando es posible, exige que los implementadores mezclen partes privativas con Software Libre de forma inapropiada. En esos casos, el código resultante es necesariamente software privativo<a class="fn" href="#refs">5</a>.</p>

<h2 id="6">La preferencia recomendada por los Estándares Abiertos es totalmente ajena a la posición en la negociación vis-a-vis entre la UE y China</h2>

<p>La BSA afirma que "[la] ambigüedad de la preferencia propuesta por el EIF, sin ninguna duda, compromete la capacidad de la Comisión para mantener su firme defensa de los titulares de derechos de propiedad intelectual de Europa [contra las amenazas de China]."</p>

<p>Las alegaciones de que una recomendación para expresar preferencia por especificaciones abiertas va a debilitar la posición en la negociación vis-a-vis entre la UE y China son claramente falsas. Las recomendaciones relativas a la utilización de especificaciones de software abiertas en el sector público no tienen influencia alguna sobre la posición de la Comisión. Además de eso, merece la pena repetir que las normas "zero royalty" no están enfrentadas con la "defensa robusta" de las patentes, del copyright y de las marcas comerciales.</p>

<p>Nótese que en los Estados Unidos, preocupaciones semejantes fueron sometidas a la US Trade Representative en la preparación para el informe 2010 US Special 301 sobre los obstáculos al comercio. La US Trade Representative optó por no incluir estas preocupaciones en el informe, demostrando claramente que el gobierno de los Estados Unidos considera que esto no es un problema. Aunque tales alegaciones pueden ser hechas como esfuerzos para influenciar políticas públicas, hay una marcada ausencia de tentativas para suprimir esas preferencias por medios jurídicos - presumiblemente porque aquellos que hacen estas afirmaciones saben muy bien que ellos, de hecho, no tienen respaldo.</p>

<h2 id="7">Las especificaciones sin restricciones promoverán la libre competencia, la normalización y la interoperabilidad</h2>

<p>La BSA afirma que "la preferencia propuesta por la EIF por las especificaciones libres de PI va a minar... la normalización, la competitividad y la interoperabilidad, a largo plazo."</p>

<p>Nosotros somos incapaces de determinar lo que la BSA entiende por especificaciones "libres de PI", aunque creemos que tal formulación sugiere un conocimiento insuficiente del proceso de normalización por parte de la BSA.</p>

<p>La alegación de que la actual formulación de la EIF podría perjudicar a la interoperabilidad es simplemente inaceptable. Ella fluye de hipótesis no comprobadas que hemos demostrado que son falsas en la exposición anterior. Actualmente, los efectos de bloqueo resultantes de la utilización de programas y formatos de archivo privativos muchas veces impiden que las administraciones públicas escojan libremente sus soluciones de TI. En vez de eso, ellos permanecen atados a un determinado proveedor. Las dificultades del Municipio de Brighton y del cantón suizo de Solothurn (por citar sólo dos ejemplos de los últimos meses), junto con incontables otras entidades públicas, en la migración de una solución de TI para otra, ilustra como el aprisionamiento tecnológico causado por estándares de software cubiertos por patentes, vinculan a los usuarios con soluciones precarias, con un gran coste para los contribuyentes.</p>

<p>Por otro lado, los estándares de software que pueden ser implementados sin restricciones permiten muchas implementaciones concurrentes para interactuar unas con las otras. En este escenario, los lucros de los monopolios para un número muy limitado de grandes competidores son sustituidos por un mercado vibrante e innovador impulsado por una competencia feroz. Eso tiene como resultado mejores soluciones y servicios a precios más bajos.</p>

<h2 id="8">Recomendaciones</h2>

<p>En vista de las consideraciones expuestas, instamos a la Comisión a promover la interoperabilidad y la libre competencia en el mercado europeo de software, en vez de dar a la empresas dominantes un impulso adicional para mantener su control sobre el mercado. Con esta finalidad, pedimos a la Comisión que no apruebe las políticas de licenciamiento (F)RAND para los estándares de software. En vez de eso, instamos a la Comisión a mantener la recomendación de que las especificaciones puedan ser consideradas abiertas sólo si pueden ser implementadas y compartidas bajo diferentes modelos de licenciamiento de software, incluyendo el Software Libre <a class="fn" href="#refs">6</a> licenciado bajo la GNU GPL.</p>

<p>Pedimos también a la Comisión que incluya en la revisión del Marco Europeo de la Interoperabilidad una robusta recomendación para que los organismos públicos se beneficien de las ventajas del software basado en Estándares Abiertos <a class="fn" href="#refs">7</a> en términos de elección, libre competencia, libertad de aprisionamiento tecnológico y acceso a largo plazo a los datos.</p>

<h2 id="fn">Notas a pie de página</h2>

<ol id="refs">

<li>Ver por ej. Rishab Aiyer Ghosh, Philipp Schmidt (2006): Documento de
Política de la Universidad de las Naciones Unidas, Número 1, 2006: "Los estándares abiertos, definidos consistentemente, pueden tener el excepcional efecto económico de permitir que se formen monopolios "naturales" en una tecnología dada, al tiempo que se asegura una libre competencia completa entre los proveedores de tal tecnología."
[énfasis añadido]</li>
<li>El MPEG está diseñado específicamente para usar de manera explícita tecnologías patentadas, aún cuando son en gran medida substituibles (probablemente) por alternativas no patentadas que son menospreciadas. Esto es concebible debido a la necesidad de extraer el máximo lucro posible con la utilización de su peculiar aplicación de ciertos principios matemáticos, antepuesta a la necesidad de crear una plataforma común y normalizada para fines de interoperabilidad. <br /> Además de eso, la mayoría de los estándares MPEG fueron establecidos en una época en que los códecs fueron hechos en hardware tanto porque el ancho de banda disponible era limitado como porque el hardware genérico no era lo suficientemente potente.</li>
<li>Vea <a href="http://www.ecis.eu/documents/ECISStatementreEIF13.10.10.pdf">la reacción de la ECIS</a> ante la carta de la BSA, del 13 octubre de 2010</li>
<li>Para una exposición sobre soluciones híbridas en protocolos de red, vea <a href="/projects/ms-vs-eu/fsfe_art18_reply_published_sourcecode.pdf">la respuesta de la FSFE y el Samba Team al artículo 18</a>.</li>
<li>Vea la <a href="http://fsfe.org/about/basics/freesoftware.en.html">definición de Software Libre de la FSFE</a></li>
<li>Como definimos en las <a href="/projects/os/def.html">definiciones de la FSFE de un estándar abierto</a></li>
</ol>
</body>

<timestamp>$Date: 2010-10-21 01:11:07 +0200 (Thu, 21 Oct 2010) $ $Author: guest-pcgaldo $</timestamp>
<translator>pcgaldo</translator>

<translator></translator>
</html>

+ 154
- 0
projects/os/bsa-letter-analysis.pt.xhtml View File

@@ -0,0 +1,154 @@
<?xml version="1.0" encoding="UTF-8"?>

<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<meta name="author-name-1" content="Karsten Gerloff" />
<meta name="author-link-1" content="/about/gerloff/gerloff.html" />
<meta name="author-name-2" content="Carlo Piana" />
<meta name="author-name-3" content="Sam Tuke" />
<meta name="author-link-3" content="/about/tuke/tuke.html" />
<meta name="publication-date" content="2010-10-15" />
<meta name="pdf-link" content="/projects/os/bsa-eif-letter-fsfe-response.pdf" />
<title>Carta da BSA sobre o EIF</title>
</head>
<body>
<h1>Defendendo os Padrões Abertos: a FSFE refuta as falsidades que a BSA transmitiu à Comissão Europeia</h1>

<p id="introduction">A Business Software Alliance (BSA) está a pressionar a Comissão Europeia para eliminar os últimos vestígios de apoio aos Padrões Abertos da última versão das recomendações da UE em matéria de interoperabilidade, o Quadro Europeu da Interoperabilidade. <br /><br /> A FSFE obteve uma cópia de <a href="/projects/os/bsa-letter-ec.pdf">uma carta enviada à Comissão</a> pela BSA na semana passada. Nos parágrafos seguintes vamos analisar os argumentos da BSA e explicar por que as suas alegações são falsas, e por que os Padrões Abertos são essenciais para a interoperabilidade e a livre concorrência no mercado europeu de software. Temos <a href="/projects/os/bsa-eif-letter-fsfe-response.pdf">compartilhado esta análise</a> com a Comissão Europeia.</p>
<ol>
<li><a href="#1">O licenciamento de patentes livre de royalties abre a participação e promove a inovação</a></li>
<li><a href="#2">Os padrões que a BSA põe como exemplo são irrelevantes para a área do software</a></li>
<li><a href="#3">O licenciamento (F)RAND em padrões de software é injusto e discriminatório</a></li>
<li><a href="#4">BSA não é representativa tão sequer dos seu próprios membros, e muito menos da indústria do software como um todo</a></li>
<li><a href="#5">A (F)RAND é incompatível com a maioria das licenças de Software Livre</a></li>
<li><a href="#6">A preferência recomendada pelos Padrões Abertos é totalmente alheia à posição na negociação vis-a-vis entre a UE e a China</a></li>
<li><a href="#7">As especificações sem restrições promoverão a livre concorrência, a padronização e a interoperabilidade</a></li>
<li><a href="#8">Recomendações</a></li>
</ol>

<h2 id="1">O licenciamento de patentes livre de royalties abre a participação e promove a inovação</h2>

<p>Na sua carta, a BSA argumenta que "[] Se a UE adota uma preferência por especificações livres de patentes e/ou royalties, isso prejudica os incentivos com os que as empresas contribuem a inovações ponteiras para a padronização - o que resulta em especificações europeias menos inovadoras, e produtos europeus menos competitivos. []"</p>

<p>Na verdade isso reflete um desconhecimento grave dos padrões, do seu papel e do seu funcionamento.</p>

<ol>

<li>As condições de licenciamento livres de royalties (Zero-royalty) não impedem que as tecnologias patenteadas sejam incluídas nos padrões. Em certo grau, o contribuinte é obrigado a evitar a imposição de royalties sobre as implementações.</li>

<li>A plataforma de tecnologia de maior sucesso na Terra, a Internet, está baseada em padrões que foram disponibilizados integralmente em condições de licenciamento zero-royalty. Na verdade, o W3C, a organização de padronização (SSO) que rege os padrões na web tem adotado por consenso uma "política de direitos de propriedade intelectual" zero-royalty, onde os royalties sobre as tecnologias podem ser aceitadas apenas sobre uns fundamentos muito excepcionais. Ao invés de sufocar a atividade inventiva, como afirma a BSA, isso transformou a internet em um foco de inovação. Na verdade, é a própria natureza dos padrões a que estabiliza uma plataforma sobre a qual os concorrentes podem criar soluções inovadoras e interoperáveis<a class="fn" href="#refs">1</a>.</li>

<li>Contrariamente ao que a BSA reclama, as políticas de licenciamento de patentes zero-royalty abrem a participação na configuração dos padrões de software para o maior número possível de partícipes e implementadores do mercado. Como resultado, os padrões de software que saem das organizações de padronização com políticas de licenciamento de patentes zero-royalty, como o W3C foram amplamente aceites, como o padrão HTML, só por ser o exemplo mais notável.</li>

</ol>

<p>Desde uma perspectiva política mais ampla, também é questionável que os inovadores, que já estão recebendo um incentivo através de uma patente, precisem ser mais incentivados por ter essa patente incluída em um padrão. Uma patente não é igual a ter direito a um fluxo de rendas garantido.</p>

<h2 id="2">Os padrões que a BSA põe como exemplo são irrelevantes para a área do software</h2>

<p>A BSA argumenta que "[] muitas das especificações abertas que na atualidade estão mais amplamente implantadas incorporam inovações patenteadas que foram inventadas por empresas comerciais... incluindo o WiFi, a GSM e a MPEG."</p>

<p>Esta é uma tentativa de criar uma falsa dicotomia entre o empresas "comerciais" que inventam uma tecnologia patenteada, em contraste com as "não-comerciais" que não são invenções patenteadas. Na realidade um grande banco de riqueza de modernas tecnologias não patenteadas com origem em empresas comerciais constituem padrões aplicados a nível mundial (como HTML5), embora continuem a proporcionar aos seus criadores uma renda. Não há como fazer a divisão, seja a nível econômico ou ideológico, entre tecnologias de hardware e software que são patenteadas, e aquelas que não são. No entanto, a divisibilidade da BSA implica que há uma diferença entre os métodos de negócio convencionais e aceites, aos que associam com as patentes, e as organizações não-eficientes e não-comerciais, que eles associam com a tecnologia livre de patentes. Dada a crescente prevalência do Software Livre no mercado europeu de serviços de TI, tal afirmação é claramente falsa.</p>

<p>As normas que a BSA cita como exemplos (com excepção da MPEG <a class="fn" href="#refs">2</a>) estão relacionadas com tecnologias baseadas em hardware. A economia do mercado de hardware é muito diferente da do mercado de software. Embora a entrada no mercado de hardware requer investimentos muito substanciais, as empresas de software podem iniciar a sua atividade com pequenas quantidades de capital. Exigir a estes iniciantes no software o pago de royalties para a implementação de padrões de software elevaria significativamente as barreiras à entrada no mercado, reduziria a inovação e dificultaria a livre concorrência, e também aumentaria os preços para os consumidores (incluindo as organizações do sector público).</p>

<p>Para o software, no entanto, é claro que permitir a inclusão de patentes nos padrões de software baixo as condições (F)RAND vai aumentar indevidamente e desnecessariamente as barreiras à entrada no mercado europeu de software, tornando a economia das TIC da Europa menos competitiva.</p>

<h2 id="3">O licenciamento (F)RAND em padrões de software é injusto e discriminatório</h2>

<p>A BSA argumenta que "[] Os requerimentos de que uma especificação aberta seja "livremente implementável" e capaz de ser compartilhada e reutilizada são ambíguas, e sugerem que o padrão deve estar livre de direitos de propriedade intelectual (IPR)."</p>

<p>A BSA também argumenta que "[A FRAND garante que] os implementadores de um padrão podem utilizar as inovações em termos justos. Isto permite que os inventores cobrem uma taxa razoável quando as tecnologias são incorporadas as especificações[.]" Nos padrões de software, as condições (F)RAND, de facto, discriminam o Software Livre e qualquer modelo de negócio baseado nele. As licenças de Software Livre mais amplamente utilizadas não permitem a imposição de condições adicionais aos posteriores receptores. No entanto, as (F)RAND exigiria que tais condições foram impostas, geralmente sob a forma de royalties, interpretando-se que as políticas de licenciamento (F)RAND são incompatíveis com o Software Livre. Quando falamos de padrões de software, interpreta-se que a abordagem das (F)RAND não é razoável nem não-discriminatória.</p>

<p>Por outro lado, o "zero-royalty" não exclui as implementações privativas (nem sequer as fortemente patenteadas). Na verdade, "Zero-royalty" significa que, se certas tecnologias estão comprometidas por um padrão, estas deverão estar disponíveis para todos sem exigir royalties. Entretanto, as implementações podem ser distribuídas sob qualquer licença e incluir qualquer tecnologia, desde que a norma seja respeitada.</p>

<p>O padrão HTML livre de royalties, por exemplo, foi implementado em uma infinidade de navegadores, tanto em Software Livre como em privativo. Isto demonstra claramente que um padrão de software livre de royalties pode permitir a adoção generalizada, e impulsionar a inovação através da livre concorrência.</p>

<h2 id="4">BSA não é representativa tão sequer dos seu próprios membros, e muito menos da indústria do software como um todo</h2>

<p>A BSA argumenta que "O Quadro Europeu da Interoperabilidade (EIF) pode ser lido com a interpretação de que as empresas europeias e estrangeiras mais inovadoras não são convidadas a participar de processos de padronização se têm patentes próprias em tecnologias relevantes e buscam compensações pelas suas invenções se essas patentes são integradas no padrão."</p>

<p>A BSA ainda reivindica que "Os investidores reconhecem que existe um vínculo importante entre o DPI e a padronização - e também reconhecem que os padrões baseados nas FRAND são altamente flexíveis e podem ser implementados em uma ampla gama de soluções de código aberto e privativo".</p>

<p>Contrariamente ao alegado pela BSA para representar uma posição unificada do setor de software, lembremos que a ECIS, que está formado por importantes membros da indústria (alguns dos quais também são membros da BSA) diz o contrário<a class="fn" href="#refs">3</a>. Apesar de ter um grande portfólio de patentes, os membros da ECIS querem padrões para que a interoperabilidade do software permaneça sem as cargas de funcionar baixo os requisitos de royalties das patentes []. Para citar apenas um exemplo, a Google tem contribuído fortemente com os padrões zero-royalty, oferecendo uma alternativa para a MPEG patrocinada pela indústria.</p>

<h2 id="5">A (F)RAND é incompatível com a maioria das licenças de Software Livre</h2>

<p>A BSA afirma que "a maioria das licenças das OSS são totalmente compatíveis com o licenciamento baseado nas FRAND."</p>

<p>Desde um ponto de vista razoável (quer seja baseado na quantidade de código disponível ou a importância do mesmo, ou ambos) as licenças de Software Livre ou open souce mais relevantes são:</p>

<ol>

<li>A GNU GPL e LGPL</li>
<li>A Mozilla Public License</li>
<li>A Apache Public License</li>
<li>A BSD/MIT e outras licenças ultra-permissíveis</li>
<li>A EUPL</li>

</ol>

<p>Todas elas, com a única excepção discutível mas incerta da categoria ultra-permissiva, são claramente incompatíveis com um regime de patentes com royalties. De acordo com as estatísticas publicadas pelo <a href="http://www.blackducksoftware.com/oss/licenses#top20">Black Duck Software</a>, mais do 85% dos projetos de Software Livre são distribuídos sob licenças que são incompatíveis com os regimes de patentes com royalties. Está demostrado que a GNU General Public License (GPL) é, de longe, a licença de Software Livre mais amplamente utilizada, por ser usada por quase a metade de todos os projetos. Incluir as tecnologias patenteadas em produtos de Software Livre, quando é possível, exige que os implementadores misturem partes privativas com Software Livre de forma desajeitada. Nesses casos, o código resultante é necessariamente software privativo<a class="fn" href="#refs">5</a>.</p>

<h2 id="6">A preferência recomendada pelos Padrões Abertos é totalmente alheia à posição na negociação vis-a-vis entre a UE e a China</h2>

<p>A BSA afirma que "[a] ambiguidade da preferência proposta pelo EIF, sem dúvida compromete a capacidade da Comissão para manter a sua firme defesa dos titulares de direitos de propriedade intelectual da Europa [contra as ameaças da China]."</p>

<p>As alegações de que uma recomendação para expressar preferência por especificações abertas vai enfraquecer a posição na negociação vis-a-vis entre a UE e a China são claramente falsas. As recomendações relativas à utilização de especificações de software abertas no setor público não têm influência alguma sobre a posição da Comissão. Além disso, vale a pena repetir que as normas "zero royalty" não colidam com a "defesa robusta" das patentes, do copyright e das marcas comerciais.</p>

<p>Note-se que nos Estados Unidos, preocupações semelhantes foram submetidas à US Trade Representative na preparação para o relatório 2010 US Special 301 sobre os obstáculos ao comércio. A US Trade Representative optou por não incluir estas preocupações no relatório, demonstrando claramente que o governo dos Estados Unidos considera que este não é um problema. Embora tais alegações podem ser feitas como esforços para influenciar políticas públicas, há uma marcada ausência de tentativas para suprimir essas preferências por meios jurídicos - presumivelmente porque aqueles que fazem estas afirmações sabem muito bem que eles, de fato, não têm respaldo.</p>

<h2 id="7">As especificações sem restrições promoverão a livre concorrência, a padronização e a interoperabilidade</h2>

<p>A BSA afirma que "a preferência proposta pela EIF pelas especificações livres de PI vai minar... a padronização, a competitividade e a interoperabilidade, a longo prazo."</p>

<p>Nós somos incapazes de determinar o que a BSA entende por especificações "livres de PI", embora acreditamos que tal formulação sugere um conhecimento insuficiente do processo de normalização por parte da BSA.</p>

<p>A alegação de que a atual formulação da EIF poderia prejudicar a interoperabilidade é simplesmente inaceitável. Ela flui de hipóteses não comprovadas que temos demonstrado ser falsas na discussão exposta anteriormente. Atualmente, o efeitos de bloqueio resultantes da utilização de programas e formatos de arquivo privativos muitas vezes impede as administrações públicas escolherem livremente as suas soluções de TI. Em vez disso, eles permanecem ligados a um determinado fornecedor. As dificuldades do Município de Brighton e do cantão suíço de Solothurn (por citar apenas dois exemplos dos últimos meses), juntamente com inúmeras outras entidades públicas, na migração de uma solução de TI para outra ilustra como o aprisionamento tecnológico causado por padrões de software coberto por patentes, vinculam os usuários a soluções precárias, com um grande custo para os contribuintes.</p>

<p>Por outro lado, os padrões de software que podem ser implementados sem restrições permitem muitas implementações concorrentes para interagir umas com as outras. Neste cenário, os lucros dos monopólios para um número muito limitado de grandes competidores são substituídos por um mercado vibrante e inovador impulsionado por uma concorrência feroz. Isso resulta em melhores soluções e serviços a preços mais baixos.</p>

<h2 id="8">Recomendações</h2>

<p>À luz das considerações expostas, instamos a Comissão a promover a interoperabilidade e a livre concorrência no mercado europeu de software, ao invés de dar às empresas dominantes uma alavanca adicional para manter o seu controle sobre o mercado. Para este fim, pedimos à Comissão que não aprove as políticas de licenciamento (F)RAND para os padrões de software. Em vez disso, instamos a Comissão a manter a recomendação de que as especificações podam ser consideradas abertas apenas se podem ser implementadas e compartilhadas baixo diferentes modelos de licenciamento de software, incluindo o Software Livre <a class="fn" href="#refs">6</a> licenciado sob a GNU GPL.</p>

<p>Pedimos também à Comissão que inclua na revição do Quadro Europeu da Interoperabilidade uma robusta recomendação para que os organismos públicos se beneficiem das vantagens do software baseado em Padrões Abertos <a class="fn" href="#refs">7</a> em termos de escolha, livre concorrência, liberdade de aprisionamento tecnológico e acesso a longo prazo aos dados.</p>

<h2 id="fn">Notas de rodapé</h2>

<ol id="refs">

<li>Ver, por exemplo: Rishab Aiyer Ghosh, Philipp Schmidt (2006): Documento da
Política da Universidade das Nações Unidas, Número 1, de 2006: "Os padrões abertos, definidos de forma consistente, podem ter o efeito econômico excepcional de permitir a formação de monopólios "naturais" em uma determinada tecnologia, garantindo a livre concorrência plena entre os fornecedores dessa tecnologia." [ênfase adicionada]</li>
<li>A MPEG está desenhada especificamente para usar de maneira explícita tecnologias patenteadas, mesmo quando são em grande parte substituíveis (provavelmente) por alternativas não patenteadas que são menospreçadas. Isto é concebível devido à necessidade de extrair o máximo lucro possível com a utilização da sua peculiar aplicação de certos princípios matemáticos, anteposta à necessidade de criar uma plataforma comum e padronizada para fins de interoperabilidade. <br /> Além disso, a maioria dos padrões MPEG foram estabelecidos em uma época em que os codecs foram feitos em hardware tanto porque a largura de banda disponível era limitada como porque o hardware genérico não era suficientemente potente.</li>
<li>Veja <a href="http://www.ecis.eu/documents/ECISStatementreEIF13.10.10.pdf">a reação da ECIS</a> à carta da BSA, do 13 outubro de 2010</li>
<li>Para uma discussão sobre soluções híbridas em protocolos de rede, veja <a href="/projects/ms-vs-eu/fsfe_art18_reply_published_sourcecode.pdf">a resposta da FSFE e o Samba Team ao artigo 18</a>.</li>
<li>Veja a <a href="http://fsfe.org/about/basics/freesoftware.en.html">definição de Software Livre da FSFE</a></li>
<li>Como definimos nas <a href="/projects/os/def.html">definições da FSFE de um padrão aberto</a></li>
</ol>
</body>

<timestamp>$Date: 2010-10-21 01:11:07 +0200 (Thu, 21 Oct 2010) $ $Author: guest-pcgaldo $</timestamp>
<translator>pcgaldo</translator>

<translator></translator>
</html>

BIN
projects/os/bsa-letter-ec.pdf View File


+ 105
- 0
projects/os/bt-open-letter.en.xhtml View File

@@ -0,0 +1,105 @@
<?xml version="1.0" encoding="UTF-8" ?>

<html>
<head>
<title>Open letter to BT</title>
</head>
<body>
<h1>British Telecom: please include freedom in your new music service</h1>

<p>Dear BT,</p>

<p>
British Telecom is a leader of telecommunication and digital
content markets, and has a reputation for product innovation.
Plans recently reported for a new not-for-profit music download
service<a class="fn" href="#fn-1">1</a> for BT's 5.5 million
broadband customers have sparked much discussion, and once again
placed BT at the fore of the future of digital content delivery in
the UK.
</p>

<p>
Amongst those speculating about the nature of the new service are
the growing number of BT customers who use Free Software<a
class="fn" href="#fn-2">2</a> web-browsers, operating systems, and
multimedia players. Currently these and other Free Software users
are unable to enjoy many popular content delivery systems such as
Spotify, Steam, and iTunes, because they are not compatible with
Free Software, or require the waiving of users' rights and freedoms
in order to use them<a class="fn" href="#fn-3">3</a> <a class="fn"
href="#fn-4">4</a> <a class="fn" href="#fn-5">5</a>. The nature of
BT's new service, and the extent to which it respects the freedom of
it's users, are therefore of particular concern.
</p>

<p>
Powerful new Open Standards<a class="fn" hreF="#fn-6">6</a> like
HTML5 and CSS3, combined with widely used Free Software codecs for
rich multimedia like VP8 and Ogg Vorbis, make it easier than ever
to build powerful cross-platform applications which respect user
freedom whilst maintaining long term accessibility. Recent
adoption of these technologies by established content providers
such as YouTube, the Norwegian Broadcasting Corporation,
Dailymotion, and Deutschlandradio, reflect a growing industry
trend towards platform independence through use of Free Software
and Open Standards<a class="fn" href="#fn-7">7</a> <a class="fn"
href="#fn-8">8</a> <a class="fn" href="#fn-9">9</a> <a
class="fn" href="#fn-10">10</a>.
</p>

<p>
In addition to these web-based technologies exists Free Software
tools like Qt and Gtk, which continue to be used by thousands of
companies<a class="fn" href="#fn-11">11</a> to develop world-class
desktop applications compatible with all major operating systems.
</p>

<p>
BT already makes wide use of Free Software<a class="fn"
href="#fn-12">12</a>, and “recognises,
and welcomes the use of open source software”<a class="fn"
href="#fn-13">13</a>. Therefore we
ask that you recognise the value of your customer's freedom as you
design and deploy your new subscription service, and take the
opportunity to benefit from one of the many Free Software
technologies which will allow you to achieve this.
</p>

<p>
The Free Software Foundation Europe is happy to assist you with
any questions regarding this issue or Free Software and Open
Standards in general.
</p>

<p>
Yours Sincerely,
</p>

<p>
<strong><a href="/uk/">UK Team</a>, Free Software Foundation
Europe</strong>
</p>

<h2 id="fn">Footnotes</h2>

<ol>
<li id="fn-1"><a href="http://www.guardian.co.uk/technology/pda/2011/mar/28/bt-illegal-filesharing-music">http://www.guardian.co.uk/technology/pda/2011/mar/28/bt-illegal-filesharing-music</a></li>
<li id="fn-2"><a href="/about/basics/freesoftware.en.html">http://fsfe.org/about/basics/freesoftware.en.html</a></li>
<li id="fn-3"><a href="http://www.spotify.com/int/legal/end-user-agreement/#section-12">http://www.spotify.com/int/legal/end-user-agreement/#section-12</a></li>
<li id="fn-4"><a href="http://www.gamesindustry.biz/articles/2010-08-12-valve-on-steam-part-two-interview">http://www.gamesindustry.biz/articles/2010-08-12-valve-on-steam-part-two-interview</a></li>
<li id="fn-5"><a href="http://images.apple.com/legal/sla/docs/itunes.pdf">http://images.apple.com/legal/sla/docs/itunes.pdf</a></li>
<li id="fn-6"><a href="/projects/os/os.html">http://fsfe.org/projects/os/os.html</a></li>
<li id="fn-7"><a href="http://www.youtube.com/html5">http://www.youtube.com/html5</a></li>
<li id="fn-8"><a href="http://www.fsf.org/campaigns/playogg/sites/norway">http://www.fsf.org/campaigns/playogg/sites/norway</a></li>
<li id="fn-9"><a href="http://www.dailymotion.com/html5">http://www.dailymotion.com/html5</a></li>
<li id="fn-10"><a href="http://www.dradio.de/wir/ogg/">http://www.dradio.de/wir/ogg/</a></li>
<li id="fn-11"><a href="http://www.digia.com/C2256FEF0043E9C1/0/405002251">http://www.digia.com/C2256FEF0043E9C1/0/405002251</a></li>
<li id="fn-12"><a href="http://opensource.bt.com/ under 'products and projects'">http://opensource.bt.com/ under "products and projects"</a></li>
<li id="fn-13"><a href="http://www.selling2bt.bt.com/Downloads/BTOpenSourcePolicyextractsforsuppliersIssue1.pdf">http://www.selling2bt.bt.com/Downloads/BTOpenSourcePolicyextractsforsuppliersIssue1.pdf</a> ("Open source software" and "Free Software" refer to the same thing <a href="/documents/whyfs.en.html">with different connotations</a>)</li>
</ol>
</body>

<timestamp>$Date: 2010-10-05 16:30:51 +0200 (Tue, 05 Oct 2010) $ $Author: samtuke $</timestamp>
<translator></translator>
</html>

+ 112
- 0
projects/os/def.de.xhtml View File

@@ -0,0 +1,112 @@
<?xml version="1.0" encoding="UTF-8"?>
<html>
<head>
<title>Definition – Offene Standards – FSFE</title>
<meta content="Definition Offener Standards mit einem Kommentar über aufkommende Standards und Links zu anderen Defintionen." name="description"/>
<meta content="Open Standards certified open European interoperability framework SELF EU Project Geneva Declaration on Standards Future of the Internet Document Freedom Day Definition Emerging Standards FSFE pdf" name="keywords"/>
</head>
<body>
<p id="category"><a href="/projects/work.html">Unsere Arbeit</a> / <a href="/projects/os/os.html">Überblick zu Offenen Standards</a></p>

<h1>Offene Standards</h1>

<div id="introduction">
<p>Es gibt keine allgemein gültige Definition darüber, was
einen Offenen Standard ausmacht, aber eine Vielzahl von Vorschlägen.
Links zu einigen dieser Vorschläge sind unten aufgeführt. </p>
</div>

<p>Die FSFE wollte nicht noch eine weitere Definition vorschlagen. Wir
beschlossen, uns der Definition eines Offenen Standards anzuschließen, die
im Rahmen der Vorbereitungen
für <a href="http://www.certifiedopen.com">Certified Open</a> geschaffen
wurde. Die Arbeit an der Definition begann, bevor die FSFE sich an diesem
Projekt beteiligte und basierte zu Beginn auf der Definition des
<a href="http://ec.europa.eu/idabc/en/document/3473/5585.html#finalEIF">Europäischen
Rahmenprogramms zur Interoperabilität (EIF)</a> der Europäischen
Kommission.</p>

<p>Im Gespräch mit mehreren Schlüsselfiguren der Industrie, Politik und
Gemeinschaft wurde die Definition überarbeitet und in eine Definition von
fünf Punkten, denen alle Beteiligten zustimmten, umgearbeitet. Diese
Definition fand schließlich Anwendung
beim <a href="http://selfproject.eu/OSD">SELF-EU-Projekt</a>, der
Genfer <a href="http://www.openforumeurope.org/library/geneva/declaration/manifesto-with-logos-final.pdf">Erklärung
zu Standards und der Zukunft des Internets</a> 2008 oder
dem <a href="http://documentfreedom.org/openstandards.de.html">Document Freedom
Day</a>.</p>

<h2>Definition</h2>

<p>Ein Offener Standard ist ein Format oder Protokoll, das</p>
<ol>
<li>von der Öffentlichkeit vollinhaltlich geprüft und verwendet werden kann;</li>
<li>ohne jegliche Komponenten oder Erweiterungen ist, die von
Formaten oder Protokollen abhängen, die selbst nicht der Definition
eines Offenen Standards entsprechen;</li>
<li>frei von rechtlichen Klauseln oder technischen Einschränkungen ist,
die seine Verwendung von jeglicher Seite oder mit jeglichem
Geschäftsmodell behindern;</li>
<li>unabhängig von einem einzelnen Anbieter koordiniert und weiterentwickelt
wird, in einem Prozess, der einer gleichberechtigten Teilnahme von
Wettbewerbern und Dritten offen steht;</li>
<li>in verschiedenen vollständigen Implementierungen von
verschiedenen Anbietern oder als vollständige Implementierung
gleichermaßen für alle Beteiligten verfügbar ist.</li>
</ol>

<h3>Kommentar zu Entwicklungsstandards</h3>

<p>Wenn ein neues Format oder Protokoll entwickelt wird, kann der fünfte
Punkt wahrscheinlich nicht eingehalten werden. Die FSFE hält dies für
korrektes Verhalten, wenn technologische Reife benötigt wird. In
verschiedenen Szenarien wie etwa die Verwendung durch Regierungen können
Ausfallkosten sehr hoch ausfallen.</p>

<p>In Szenarien, die das Wachstum Offener Standards fördern wollen, könnte
eine strikte Anwendung der Klausel neue Offene Standards verhindern. Aus
Sicht der Definition würden solche Standards mit herstellergesteuerten
proprietären Formaten direkt konkurrieren. In solchen Fällen kann es sinnvoll
sein, „Entwicklungsstandards“ zu erlauben, der fünften Klausel nicht zu
entsprechen.</p>

<p>Welche Behandlung solche „Entwicklungsstandards“ erhalten, hängt zum
größten Teil von der Situation ab. Wo hohe Ausfallkosten anfallen, sollten
nur vollständig Offene Standards verwendet werden. Wo eine Förderung
Offener Standards erwünscht ist, sollten Entwicklungsstandards eine
besondere Förderung erhalten.</p>

<p>Allgemein formuliert: Offene Standards sind besser als
Entwicklungsstandards und Entwicklungsstandards sind besser als
herstellerspezifische Formate. Je mehr ein Format allen Punkten der
Definition entspricht, desto höher sollte es in Szenarien eingestuft
werden, bei denen Interoperabilität und zuverlässige
Langzeit-Datenspeicherung entscheidend sind.</p>

<h3>Links zu anderen Definitionen</h3>
<p>Wikipedia gibt einen Überblick zum Begriff <a
href="http://de.wikipedia.org/wiki/Offener_Standard">Offener Standard</a> und
führt verschiedene Definitionen an. Nachfolgend einige Bespiele für eine
Definition:</p>

<ul>
<li>
<a href="http://ec.europa.eu/idabc/en/document/3473/5585.html#finalEIF">Europäisches Rahmenprogramm</a>
</li>
<li>
<a href="http://www.ft.dk/Samling/20051/beslutningsforslag/B103/index.htm">Motion B 103 des Dänischen Parlaments</a>
</li>
<li><a href="http://perens.com/OpenStandards/Definition.html">Open Standards - Principles and Practice</a> von Bruce Perens</li>
<li><a href="http://www.digistan.org/open-standard:definition">Open Standards Definition</a> von Digistan</li>
</ul>

</body>
<timestamp>$Date$ $Author$</timestamp>
<translator>Andreas Aubele</translator>
</html>
<!--
Local Variables: ***
mode: xml ***
End: ***
-->

+ 111
- 0
projects/os/def.el.xhtml View File

@@ -0,0 +1,111 @@
<?xml version="1.0" encoding="UTF-8" ?>

<html>
<head>
<title>FSFE - Ανοιχτά Πρότυπα - Ορισμός</title>
<meta content="Ορισμός για τα Ανοιχτά Πρότυπα, με σχόλιο σχετικά με τα αναδυόμενα πρότυπα και συνδέσμους σε άλλους ορισμούς." name="description" />
<meta content="Ανοιχτά Πρότυπα certified open Ευρωπαϊκό Πλαίσιο Διαλειτουργικότητας SELF EU Project Διακήρυξη της Γενεύης για τα Πρότυπα Μέλλον του Διαδικτύου Ημέρα Ελευθερίας Εγγράφων Ορισμός Αναδυόμενα Πρότυπα FSFE pdf" name="keywords" />
</head>

<body>
<p id="category"><a href="http://www.fsfe.org/projects/work.html">Η Εργασία
μας</a> / <a href="/projects/os/os.html">Επισκόπηση στα Ανοιχτά Πρότυπα</a></p>
<h1>Ανοιχτά Πρότυπα</h1>

<div id="introduction">

<p>Δεν υπάρχει ένας κοινά αποδεκτός ορισμός για τα Ανοιχτά Πρότυπα,
αντίθετα υπάρχει μια πληθώρα προτάσεων. Σύνδεσμοι σε μερικούς από
αυτούς περιλαμβάνονται πιο κάτω.</p>
</div>
<p>Το FSFE δεν ήθελε να προτείνει άλλον έναν ορισμό. Αποφασίσαμε να
ακολουθήσουμε τον ορισμό του Ανοιχτού Προτύπου που τέθηκε ως τμήμα
της προετοιμασίας για το <a href="http://www.certifiedopen.com">Certified
Open</a>. Η εργασία για αυτόν τον ορισμό ξεκίνησε πριν την ανάμειξη του
FSFE στο πρόγραμμα και αρχικά βασίστηκε στον ορισμό του
<a href="http://ec.europa.eu/idabc/en/document/3473/5585.html#finalEIF">
Ευρωπαϊκού Πλαισίου Διαλειτουργικότητας (EIF)</a>
της Ευρωπαϊκής Επιτροπής.</p>

<p>Σε έναν διάλογο που περιείχε διάφορους παίκτες κλειδιά από τη
βιομηχανία, την πολιτική και τις κοινότητες, ο ορισμός αναθεωρήθηκε
σε ένα σύνολο πέντε σημείων το οποίο κέρδισε τη συναίνεση όλων των
ενδιαφερομένων. Ακολούθως, ο ορισμός υιοθετήθηκε από το
<a href="http://selfproject.eu/OSD">Πρόγραμμα SELF της ΕΕ</a>, τη
<a href="http://www.openforumeurope.org/library/geneva/declaration/manifesto-with-logos-final.pdf">
Διακήρυξη σχετικά με τα Πρότυπα και το Μέλλον του Διαδικτύου</a> της Γενεύης του 2008 και
την
<a href="http://documentfreedom.org/openstandards.el.html">Ημέρα Ελευθερίας Εγγράφων</a>.</p>

<h2>Ορισμός</h2>

<p>Ένα Ανοιχτό Πρότυπο αναφέρεται σε έναν τύπο αρχειοθέτησης ή ένα
πρωτόκολλο</p>
<ol>
<li>το οποίο υπόκειται σε πλήρη δημόσια αξιολόγηση και χρήση χωρίς
περιορισμούς με τρόπο ισότιμα διαθέσιμο σε όλους τους
ενδιαφερόμενους·</li>
<li>χωρίς τμήματα ή επεκτάσεις που να εξαρτώνται από τύπους αρχειοθέτησης
ή πρωτόκολλα τα οποία δεν πληρούν τα ίδια τον ορισμό του Ανοιχτού
Προτύπου·</li>
<li>ελεύθερο από νομικές ή τεχνικές διατυπώσεις που περιορίζουν τη
χρηστικότητά του από οποιονδήποτε ενδιαφερόμενο ή επιχειρηματικό
μοντέλο·</li>
<li>με διαχείριση και επιπλέον ανάπτυξη ανεξάρτητα από οποιονδήποτε
μοναδικό προμηθευτή σε μια διαδικασία ανοιχτή στην ισότιμη συμμετοχή
ανταγωνιστών και τρίτων·</li>
<li>διαθέσιμο σε πολλαπλές πλήρεις υλοποιήσεις από ανταγωνιστικούς
προμηθευτές ή ως πλήρης υλοποίηση ισότιμα διαθέσιμο σε όλους τους
ενδιαφερόμενους.</li>
</ol>

<h3>Σχόλιο για τα Αναδυόμενα Πρότυπα</h3>

<p>Όταν ένα νέος τύπος ή πρωτόκολλο είναι σε φάση ανάπτυξης, το σημείο 5
δεν είναι δυνατό να πληρείται. Το FSFE θεωρεί ότι αυτή είναι η σωστή
συμπεριφορά σε περιπτώσεις στις οποίες απαιτείται τεχνολογική ωριμότητα.
Σε διάφορα σενάρια, όπως στη περίπτωση ανάπτυξης κυβερνητικών έργων, το
κόστος της αποτυχίας μπορεί να είναι πολύ υψηλό.</p>

<p>Σε σενάρια όπου το ζητούμενο είναι η προώθηση των Ανοιχτών Προτύπων,
η αυστηρή εφαρμογή του σημείου θα εμπόδιζε νέα Ανοιχτά Πρότυπα. Από
την άποψη του ορισμού, τέτοια πρότυπα θα ανταγωνίζονταν απ' ευθείας με
ιδιοκτησιακούς τύπους που προτείνουν προμηθευτές. Σε τέτοιες περιπτώσεις
μπορεί να έχει νόημα να επιτρέπεται η αποτυχία του σημείου 5 για τα
''Αναδυόμενα Πρότυπα''</p>

<p>Ποια μεταχείριση επιδέχονται τέτοια ''Αναδυόμενα Πρότυπα'' εξαρτάται
από την περίπτωση. Όπου το κόστος της αποτυχίας είναι υψηλό, μόνο
πλήρως Ανοιχτά Πρότυπα πρέπει να χρησιμοποιούνται. Όπου η προώθηση των
Ανοιχτών Προτύπων είναι το ζητούμενο, τα Αναδυόμενα Πρότυπα πρέπει να
τυγχάνουν ειδικής προβολής.</p>

<p>Σε γενικές γραμμές: Τα Ανοιχτά Πρότυπα είναι καλύτερα από τα Αναδυόμενα
Πρότυπα και τα Αναδυόμενα Πρότυπα είναι καλύτερα από τους τύπους που
εξαρτώνται από προμηθευτές. Όσο πιο κοντά ένας τύπος βρίσκεται στο να
πληρεί όλα τα σημεία του ορισμού, τόσο υψηλότερα θα πρέπει να κατατάσσεται
σε σενάρια όπου η διαλειτουργικότητα και η αξιόπιστη μακροπρόθεσμη
αποθήκευση είναι το ουσιαστικό.</p>

<h3>Σύνδεσμοι σε άλλους ορισμούς</h3>

<p>Η Wikipedia έχει μια επισκόπηση του όρου
<a href="http://en.wikipedia.org/wiki/Open_standard">Ανοιχτό Πρότυπο</a>
και διάφορους ορισμούς. Οι ακόλουθοι είναι ένα δείγμα από αυτούς:</p>

<ul>
<li><a href="http://ec.europa.eu/idabc/en/document/3473/5585.html#finalEIF">European Interoperability Framework</a></li>
<li><a href="http://www.ft.dk/Samling/20051/beslutningsforslag/B103/index.htm">Motion B 103 of the Danish Parliament</a></li>
<li><a href="http://perens.com/OpenStandards/Definition.html">Open Standards - Principles and Practice</a> by Bruce Perens</li>
<li><a href="http://www.digistan.org/open-standard:definition">Open Standards Definition</a> by Digistan</li>
</ul>

</body>

<timestamp>$Date$ $Author$</timestamp>
</html>
<!--
Local Variables: ***
mode: xml ***
End: ***
-->

+ 106
- 0
projects/os/def.en.xhtml View File

@@ -0,0 +1,106 @@
<?xml version="1.0" encoding="UTF-8" ?>

<html>
<head>
<title>FSFE - Open Standards - Definition</title>
<meta content="Definition of Open Standards, with comment on emerging standards and links to other definitions." name="description" />
<meta content="Open standards certified open European interoperability framework SELF EU Project Geneva Declaration on Standards Future of the Internet Document Freedom Day Definition Emerging Standards FSFE pdf" name="keywords" />
</head>

<body>
<p id="category"><a href="http://www.fsfe.org/projects/work.html">Our Work</a> / <a href="/projects/os/os.html">Overview of Open Standards</a></p>
<h1>Open Standards</h1>

<div id="introduction">

<p>There is no universally accepted definition of what constitutes
an Open Standard and no shortage of proposals. Links to some of
them have been included below. </p>
</div>
<p>FSFE did not want to propose yet another definition. We decided
to go with the definition of an Open Standard that was developed
as part of the preparations
for <a href="http://www.certifiedopen.com">Certified
Open</a>. Work on this definition began before FSFE's involvement
on the project and was initially based on the definition in
the <a href="http://ec.europa.eu/idabc/en/document/3473/5585.html#finalEIF">European
Interoperability Framework (EIF)</a> of the European
Commission.</p>

<p>In a dialog involving various key players in industry, politics
and community, the definition was reworked into a definition of
five points that found consensus among all the involved. The
definition has subsequently been adopted by
the <a href="http://selfproject.eu/OSD">SELF EU Project</a>, the
2008 Geneva
<a href="http://www.openforumeurope.org/library/geneva/declaration/manifesto-with-logos-final.pdf">Declaration
on Standards and the Future of the Internet</a> or
the <a href="http://documentfreedom.org/openstandards.en.html">Document
Freedom Day</a>.</p>

<h2>Definition</h2>

<p>An Open Standard refers to a format or protocol that is</p>
<ol>
<li>subject to full public assessment and use without
constraints in a manner equally available to all parties;</li>
<li>without any components or extensions that have dependencies
on formats or protocols that do not meet the definition of an
Open Standard themselves;</li>
<li>free from legal or technical clauses that limit its
utilisation by any party or in any business model;</li>
<li>managed and further developed independently of any single
vendor in a process open to the equal participation of
competitors and third parties;</li>
<li>available in multiple complete implementations by competing
vendors, or as a complete implementation equally available to
all parties.</li>
</ol>

<h3>Comment on Emerging Standards</h3>

<p>When a new format or protocol is under development, clause 5
cannot possibly be met. FSFE believes this is the correct
behaviour in cases where technological maturity is required. In
several scenarios, e.g. governmental deployment, the cost of
failure can be very high.</p>

<p>In scenarios that seek to promote the growth of Open Standards,
strict application of the clause could prevent new Open
Standards. From the view of the definition, such standards would
compete directly against vendor-driven proprietary formats. In
such cases, it can make sense to allow failure of clause 5 for
"Emerging Standards."</p>

<p>Which treatment such "Emerging Standards" receive is largely
dependent on the situation. Where cost of failure is high, only
fully Open Standards should be used. Where promotion of Open
Standards is wanted, Emerging Standards should receive special promotion.</p>

<p>Generally speaking: Open Standards are better than Emerging
Standards and Emerging Standards are better than vendor-specific
formats. The closer a format comes to meeting all points of the
definition, the higher it should be ranked in scenarios where
interoperability and reliable long-term data storage is
essential.</p>

<h3>Links to other definitions</h3>

<p>Wikipedia has an overview of the term <a href="http://en.wikipedia.org/wiki/Open_standard">Open Standard</a> and various definitions. The following is a sample of some definitions:</p>

<ul>
<li><a href="http://ec.europa.eu/idabc/en/document/3473/5585.html#finalEIF">European Interoperability Framework</a></li>
<li><a href="http://www.ft.dk/Samling/20051/beslutningsforslag/B103/index.htm">Motion B 103 of the Danish Parliament</a></li>
<li><a href="http://perens.com/OpenStandards/Definition.html">Open Standards - Principles and Practice</a> by Bruce Perens</li>
<li><a href="http://www.digistan.org/open-standard:definition">Open Standards Definition</a> by Digistan</li>
</ul>

</body>

<timestamp>$Date$ $Author$</timestamp>
</html>
<!--
Local Variables: ***
mode: xml ***
End: ***
-->

+ 115
- 0
projects/os/def.es.xhtml View File

@@ -0,0 +1,115 @@
<?xml version="1.0" encoding="UTF-8" ?>

<html>
<head>
<title>FSFE - Estándares Abiertos - Definición</title>
</head>

<body>
<p id="category"><a href="http://www.fsfe.org/projects/work.html">Nuestra Acción</a> / <a href="/projects/os/os.html">Estándares Abiertos</a></p>
<h1>Estándares Abiertos</h1>

<div id="introduction">

<p>No hay una definición universalmente aceptada de qué constituye
un Estándar Abierto, aunque hay muchas propuestas al respecto. Más
abajo hay enlaces a algunas de ellas.</p>

</div>
<p>La FSFE no quiere proponer una definición más. Hemos decidido
usar la definición de Estándar Abierto desarrollada como parte de
los preparativos para el
<a href="http://www.certifiedopen.com">Certified Open</a>. Se
empezó a trabajar en esta definición antes de que la FSFE se
involucrara en el proyecto y estaba basada en la definición de la
<a href="http://ec.europa.eu/idabc/en/document/3473/5585.html#finalEIF">European
Interoperability Framework (EIF)</a> de la Comisión Europea.</p>

<p>En un diálogo en el que intervinieron varios actores
principales de la industria, la política y la comunidad, la
definición fue convertida en una definición de cinco puntos que
consiguió el consenso de las partes implicadas. Posteriormente, la
definición ha sido adoptada por el
<a href="http://selfproject.eu/OSD">SELF EU Project</a>, la
<a href="http://www.openforumeurope.org/library/geneva/declaration/manifesto-with-logos-final.pdf">Declaration
on Standards and the Future of the Internet</a> de 2008 en Genova
o el <a href="http://documentfreedom.org/openstandards.es.html">Document
Freedom Day</a>.</p>

<h2>Definición</h2>

<p>Un Estándar Abierto hace referencia a un formato o protocolo
que</p>
<ol>
<li>esté sujeto a una evaluación pública completa,
se pueda usar sin restricciones y esté disponible por igual para
todas las partes;</li>
<li>no necesite ningún componente o extensión adicional que
tenga dependencias con formatos o protocolos que no cumplan la
definición de un Estándar Abierto;</li>
<li>esté libre de cláuslas legales o técnicas que limiten su
utilización por cualquier parte o en cualquier modelo de
negocio;</li>
<li>esté gestionado y pueda ser desarrollado independientemente
por cualquier compañía en un proceso abierto a la participación
equitativa por parte de competidores y terceras partes;</li>
<li>esté disponible en varias implementaciones completas por
compañías en competencia, o como una implementación completa
disponible para todas las partes.</li>
</ol>

<h3>Comentarios sobre los Estándares Emergentes</h3>

<p>Cuando un nuevo formato o protocolo está siendo desarrollado,
la cláusula 5 no puede ser cumplida. La FSFE cree que este es el
procedimiento correcto en los casos en los que la madurez
tecnológica sea un requisito. En varias situaciones, como por
ejemplo, en despliegues gubernamentales, el costo del fracaso
puede ser muy alto.</p>

<p>En las situaciones que busquen promover el crecimiento de los
Estándares Abiertos, la aplicación estricta de esta clausula puede
prevenir nuevos Estándares Abiertos. Desde el punto de vista de la
definición, estos estándares estarían en competencia directa con
formatos propietarios de una compañía. En estos casos, tiene
sentido permitir que no se cumpla la clausula 5 para los
«Estándares Emergentes».</p>

<p>El tratamiento que estos «Estándares Emergentes» recibirán es
bastante dependiente de la situación. Cuando el coste del fracaso
es alto, sólo se deberían usar Estándares Abiertos completos.
Cuando se pretende la promoción de los Estándares Abiertos, los
Estándares Emergentes deberían recibir una promoción especial.</p>

<p>En general, los Estándares Abiertos son mejores que los
Estándares Emergentes y los Estándares Emergentes son mejores que
los formatos específicos de una compañía. Cuanto mejor cumpla un
formato todos los puntos de la definición, más en consideración se
deberá tener en aquellas situaciones en las que la
interoperabilidad y el almacenamiento de datos fiable a largo
plazo sean esenciales.</p>

<h3>Enlaces a otras definiciones</h3>

<p>La Wikipedia tiene una visión general del término
<a href="http://es.wikipedia.org/wiki/Estándar_abierto">Estándar
Abierto</a> y varias definiciones. Algunas otras definiciones de
Estándar Abierto son las siguientes:</p>

<ul>
<li><a href="http://ec.europa.eu/idabc/en/document/3473/5585.html#finalEIF">European Interoperability Framework</a></li>
<li><a href="http://www.ft.dk/Samling/20051/beslutningsforslag/B103/index.htm">Motion B 103 of the Danish Parliament</a></li>
<li><a href="http://perens.com/OpenStandards/Definition.html">Open Standards - Principles and Practice</a> por Bruce Perens</li>
<li><a href="http://www.digistan.org/open-standard:definition">Open Standards Definition</a> por Digistan</li>
</ul>

</body>

<timestamp>$Date$ $Author$</timestamp>
<translator>Javier Merino</translator>
</html>
<!--
Local Variables: ***
mode: xml ***
End: ***
-->

+ 108
- 0
projects/os/def.et.xhtml View File

@@ -0,0 +1,108 @@
<?xml version="1.0" encoding="UTF-8" ?>

<html>
<head>
<title>Definitsioon - Avatud standardid - Euroopa Vaba Tarkvara Fond</title>
</head>

<body>
<p id="category"><a href="http://www.fsfe.org/projects/work.html">Tegevus</a> / <a href="/projects/os/os.html">Ülevaade - avatud standardid</a></p>
<h1>Avatud standardid</h1>

<div id="introduction">
<p>Puudub üheselt aktsepteeritav definitsioon sellest, mis teeb ühest
standardist avatud standardi. Pakkumisi on mitmeid, viited neist
mõnele on toodud allpool.</p>
</div>
<p>Me ei soovinud pakkuda välja järjekordset definitsiooni ning
otsustasime seetõttu kasutada
<a href="http://www.certifiedopen.com"><em>Certified Open</em></a>i
jaoks loodud definitsiooni, mille väljatöötamist alustati enne
FSFE seotust projektiga. Esialgu põhines siinne definitsioon Euroopa
Komisjoni
<a href="http://ec.europa.eu/idabc/en/document/3473/5585.html#finalEIF">
Euroopa interoperatiivsuse raamvõrgustikul (<em>European
Interoperability Framework</em>)</a>.</p>

<p>Koostöös mitmete põhitoimijatega ettevõtluses, poliitikas ning
kogukonnas töötati raamvõrgustiku definitsioon ümber uueks viiest
punktist koosnevaks definitsiooniks, mis oli vastuvõetav kõigile
asjaosalistele. Uue definitsiooni on omaks võtnud
<a href="http://selfproject.eu/OSD">SELF EU projekt</a>, 2008. aasta
Genfi
<a href="http://www.openforumeurope.org/library/geneva/declaration/manifesto-with-logos-final.pdf">
Interneti standardite ja tuleviku deklaratsioon
(<em>Declaration on Standards and the Future of the Internet</em>)</a>
ja <a href="http://documentfreedom.org/openstandards.et.html">
dokumendivabaduse päeva</a> korraldajad.</p>

<h2>Definitsioon</h2>

<p>Avatud standard on protokoll või formaat, mis vastab järgmistele
tunnustele:</p>
<ol>
<li>on avatud avalikkuse hinnangutele ning piiranguteta kasutatav
kõikide osapoolte poolt võrdsetel alustel;</li>
<li>ei oma komponente ega laiendeid, mis on sõltuvad formaatidest või
protokollidest, mis ei vasta avatud standardi definitsioonile;</li>
<li>puuduvad juriidilised ja tehnilised tõkked piiramaks standardi
rakendamist mõne osapoole poolt või mõnes ärimudelis;</li>
<li>haldus- ja arendustegevus toimuvad sõltumatult mõnest kindlast
tootjast ning on avatud konkurentide ning kolmandate osapoolte
osalusele;</li>
<li>saadaval on mitu erinevat täielikku implementatsiooni
konkureerivate tootjate poolt või täielik ja kõigile võrdsetel
alustel kättesaadav implementatsioon.</li>
</ol>

<h3>Arenevad standardid</h3>

<p>Kui uut protokolli või formaati alles arendatakse, ei ole viiendat
tunnust võimalik omada. FSFE arvates on see igati soovitav ning õige
käitumine situatsioonides, kus on vajalik tehniline küpsus. Näiteks
valitsusasutustes võiks läbikukkunud rakendamiskatse väga kalliks
ostutuda.</p>

<p>Kui eesmärgiks on avatud standardite hulga suurenemine, siis ei
pruugi viienda tunnuse olemasolu range nõudmine võimaldada uute
avatud standardite loomist. Definitsiooni poolest oleks sellised
standardid samaväärsed ühe tootja kinniste formaatidega. Sellises
olukorras oleks mõistlik loobuda viienda tunnuse täitmise nõudest
arenevate standardite puhul.</p>

<p>Arenevatele standarditele soodustuste tegemine peaks sõltuma
konkreetsest olukorrast: kui eesmärgiks on avatud standardite
edendamine, tuleks arenevatele standarditele mööndusi teha; kui
rakendamise läbikukkumine läheks kalliks maksma, tuleks kasutada
vaid täielikult definitsioonile vastavaid standardeid.</p>

<p>Üldiselt on avatud standardid paremad kui arenevad standardid ning
arenevad standardid paremad kui tootjaspetsiifilised formaadid. Mida
rohkem avatud standardi tunnuseid formaadil on, seda kõrgemalt tuleks
seda hinnata stsenaariumites, kus interoperatiivsus ja usaldusväärne
pikaajaline andmete hoiustamine on hädavajalikud.</p>

<h3>Viited teistele definitsioonidele</h3>

<p>Vikipeedial on ülevaade terminist
"<a href="http://en.wikipedia.org/wiki/Open_standard">avatud standard</a>"
ning selle mitmetest definitsioonidest. Järgnev on loetelu mõndadest
definitsioonidest:</p>

<ul>
<li><a href="http://ec.europa.eu/idabc/en/document/3473/5585.html#finalEIF">Euroopa interoperatiivsuse raamvõrgustik</a> (inglise k)</li>
<li><a href="http://www.ft.dk/Samling/20051/beslutningsforslag/B103/index.htm">Taani parlamendi esildis B 103</a> (taani k)</li>
<li>Bruce Perensi <a href="http://perens.com/OpenStandards/Definition.html">Avatud standardid: printsiibid ja praktika</a> (inglise k)</li>
<li>Digistani <a href="http://www.digistan.org/open-standard:definition">Vaba ja avatud standardi definitsioon</a> (inglise k)</li>
</ul>

</body>

<timestamp>$Date: 2011-02-21 15:15:12 +0000 (Mon, 21 Feb 2011) $ $Author: nicoulas $</timestamp>
<translator>Heiki Ojasild</translator>
</html>
<!--
Local Variables: ***
mode: xml ***
End: ***
-->

+ 114
- 0
projects/os/def.fr.xhtml View File

@@ -0,0 +1,114 @@
<?xml version="1.0" encoding="UTF-8" ?>

<html>
<head>
<title>FSFE - Standards Ouverts - Définition</title>
</head>

<body>
<p id="category"><a href="http://www.fsfe.org/projects/work.html">Notre action</a> / <a href="/projects/work.en.html">Aperçu des standards ouverts</a></p>
<h1>Standards Ouverts</h1>

<div id="introduction">

<p>Il n'y a pas de définition universellement acceptée de ce qui
constitue un Standard Ouvert, d'autant que les propositions ne
cessent d'abonder. Des liens vers quelques unes d'entre elles
sont listées en bas de la page.</p>
</div>
<p>La FSFE ne voulait pas proposer une définition supplémentaire.
Nous avons décidé de nous rallier à la définition d'un Standard
Ouvert qui a été rédigée lors de la conception de
<a href="http://www.certifiedopen.com">Certified Open</a>.
Cette définition est basée sur celle de l'<a href="http://ec.europa.eu/idabc/en/document/3473/5585.html#finalEIF">
European Interoperability Framework (EIF)</a> de la Commission
Européenne, qui a été écrite avant que la FSFE rejoigne le projet.</p>

<p>En dialoguant avec différents acteurs clés de l'industrie,
du monde politique et des communautés, le texte a été remanié pour
parvenir à une définition contenant cinq points consensuels. Cette
définition a par la suite été adoptée par le
<a href="http://selfproject.eu/OSD">projet SELF de la CE</a>, la
<a href="http://www.openforumeurope.org/library/geneva/declaration/manifesto-with-logos-final.pdf">
Geneva 2008 Declaration on Standards and the Future of the Internet</a>
(manifeste sur les standards et le futur de l'Internet, Genève 2008) ou
encore la <a href="http://documentfreedom.org/openstandards.fr.html">journée de
libération des documents.</a>.</p>

<h2>Définition</h2>

<p>Est entendu par Standard Ouvert un format ou protocole qui est&#160;:</p>
<ol>
<li>sujet à la pleine appréciation du public, libre de toute
contrainte d'utilisation et accessible sans discrimination à
toutes les parties&#160;;</li>

<li>dénué de tout composant ou extension dépendant de formats
ou protocoles qui ne répondent pas eux-mêmes à la définition
d'un Standard Ouvert&#160;;</li>

<li>affranchi de toute clause légale ou technique qui limite
son utilisation pour un utilisateur donné ou une situation
commerciale donnée&#160;;</li>

<li>administré et développé indépendemment de
tout fournisseur dans un processus ouvert, sans discrimination à la
participation des concurrents et des tierces parties&#160;;</li>

<li>disponible sous différentes implémentations complètes
réalisées par des fournisseurs concurrents, ou sous une seule
implémentation complète accessible sans discrimination à toutes
les parties.</li>
</ol>

<h3>Remarque sur les standards émergents</h3>

<p>Lorsqu'un nouveau format ou protocole est en cours de développement,
la clause 5 ne saurait être remplie. La FSFE pense qu'il s'agit d'une
bonne clause dans les cas où une certaine maturité de la technologie est
requise. Dans certaines situations, par exemple dans le cadre d'un
déploiement gouvernemental, le prix d'un échec peut être très élevé.</p>

<p>Dans les situations où l'on cherche à promouvoir l'essor des
Standards Ouverts, la stricte application de cette clause pourrait
faire avorter de nouveaux standards. Du point de vue de la définition,
de tels standards concurrenceraient directement des formats
propriétaires. En ce cas, il peut être sensé de permettre le non-respect
de la clause 5 pour les «standards émergents».</p>

<p>Ce qu'il advient de tels «standards émergents» dépend en grande
partie de la situation. Lorsque le coût de l'échec est important,
seuls des standards complètement ouverts devraient être employés.
Lorsque la promotion des Standards Ouverts est désirée, les Standards
Émergents devraient être la cible d'une promotion particulière.</p>
<p>De manière générale, les Standards Ouverts valent mieux que les
Standards Émergents, et les Standards Émergents valent mieux que
les formats propriétaires. Plus un format adhère à la définition,
plus il devrait être favorisé dans les cas où l'interopérabilité
et la fiabilité du stockage à long terme sont essentiels.</p>

<h3>Liens vers d'autres définitions</h3>

<p>Wikipédia (EN) propose un aperçu du terme «<a href="http://en.wikipedia.org/wiki/Open_standard">
Open Standard</a>» ainsi que des définitions variées. Quelques exemples
de définitions sont cités ci-dessous (en anglais)&#160;:</p>

<ul>
<li><a href="http://ec.europa.eu/idabc/en/document/3473/5585.html#finalEIF">European Interoperability Framework</a></li>
<li><a href="http://www.ft.dk/Samling/20051/beslutningsforslag/B103/index.htm">Motion B 103 of the Danish Parliament</a> (Motion B 103 du Parlement Dannois)</li>
<li><a href="http://perens.com/OpenStandards/Definition.html">Open Standards - Principles and Practice</a> (Standards Ouverts, principes et pratique) par Bruce Perens</li>
<li><a href="http://www.digistan.org/open-standard:definition">Open Standards Definition</a> (Définition d'un Standard Ouvert) par Digistan</li>
</ul>

</body>

<timestamp>$Date$ $Author$</timestamp>
<translator>Jil Larner (Mont-Blanc - France)</translator>
</html>
<!--
Local Variables: ***
mode: xml ***
End: ***
-->

+ 104
- 0
projects/os/def.hr.xhtml View File

@@ -0,0 +1,104 @@
<?xml version="1.0" encoding="UTF-8" ?>

<html>
<head>
<title>FSFE - Otvoreni standardi - Definicija</title>
</head>

<body>
<p id="category"><a href="http://www.fsfe.org/projects/work.html">Naš rad</a> / <a href="/projects/os/os.html">Pregled otvorenih standarda</a></p>
<h1>Otvoreni standardi</h1>

<div id="introduction">

<p>Ne postoji opće prihvaćena definicija što čini otvoreni standard,
no postoji mnogo prijedloga. Poveznice na neke prijedloge
su niže navedene. </p>
</div>
<p>FSFE nije htio predložiti još jednu definiciju. Odlučili smo
prihvatiti definiciju otvorenog standarda koja je nastala kroz
pripreme za
<a href="http://www.certifiedopen.com">Certified
Open</a>. Rad na ovoj definiciji počeo je prije nego se FSFE uključio
u projekt i inicijalno se bazirala na definiciji iz
<a href="http://ec.europa.eu/idabc/en/document/3473/5585.html#finalEIF">Europskog
okvira za interoperabilnost (EIF)</a> Europske
komisije.</p>

<p>U dijalogu u kojem su sudjelovali razni ključni industrijski igrači,
politika i zajednica, definicija je preoblikovana u definiciju
pet točaka oko kojih se postigao konsenzus.
Definiciju je potom usvojio
<a href="http://selfproject.eu/OSD">EU-ov projekt SELF</a>,
ženevska
<a href="http://www.openforumeurope.org/library/geneva/declaration/manifesto-with-logos-final.pdf">Deklaracija
o standardima i budućnosti Interneta</a> iz 2008. i
<a href="http://documentfreedom.org/openstandards.hr.html">Document
Freedom Day</a>.</p>

<h2>Definicija</h2>

<p>Otvoreni standard odnosi se na format ili protokol koji je</p>
<ol>
<li>podložan potpunoj javnoj procjeni i korištenju bez
ograničenja tako da je jednako dostupan svim stranama;</li>
<li>bez komponenti ili proširenja koji su ovisni
o formatima ili protokolima koji sami ne zadovoljavaju
definiciju otvorenog standarda;</li>
<li>lišen pravnih i tehničkih klauzula koje bilo koga ili
bilo koji poslovni model ograničavaju u korištenju;</li>
<li>otvoren za ravnopravno sudjelovanje konkurenata i trećih
strana u upravljanju i daljnjem razvoju, neovisan o pojedinom
proizvođaču;</li>
<li>dostupan u više potpunih implementacija konkurentskih
proizvođača ili koji je kao potpuna implementacija svima
jednako dostupan.</li>
</ol>

<h3>Napomene za standarde u nastajanju</h3>

<p>Kada je novi format ili protokol u razvoju, 5. klauzula nije
ostvariva. FSFE drži da je ovo ispravno stajalište u
slučajevima u kojima je potrebna tehnološka potpunost. U nekim
situacijama, npr. u primjeni za vladu, trošak zbog pogreške
može biti vrlo visok.</p>

<p>U situacijama u kojima se želi promicati razvoj otvorenih
standarda strogo pridržavanje klauzula može onemogućiti nove otvorene
standarde. Sa stajališta definicije takvi standardi bi izravno
konkurirali vlasničkim formatima pod kontrolom proizvođača. U
takvim slučajevima razumno je dozvoliti neispunjavanje 5. klauzule
"standarda u nastajanju".</p>

<p>Kakav tretman primaju takvi "standardi u nastajanju" u velikoj mjeri
ovisi o situaciji. Tamo gdje je trošak zbog pogreške vrlo visok trebaju
se koristiti samo potpuno otvoreni standardi. Standarde u nastajanju
treba posebno promicani tamo gdje se želi promicati otvorene standarde.</p>

<p>Općenito govoreći, otvoreni standardi su bolji od standarda
u nastajanju i standardi u nastajanju su bolji od formata specifičnih
pojedinom proizvođaču. Što se format više približi ispunjenju svih
točaka definicije, više ga treba rangirati u situacijama gdje su
interoperabilnost i pouzdana dugotrajna pohrana podataka od
iznimne važnosti.</p>

<h3>Poveznice na druge definicije</h3>

<p>Wikipedija pruža pregled termina <a href="http://en.wikipedia.org/wiki/Open_standard">otvoreni standard</a> i razne definicije. Slijedi skup nekih definicija:</p>

<ul>
<li><a href="http://ec.europa.eu/idabc/en/document/3473/5585.html#finalEIF">Europski okvir za interoperabilnost</a></li>
<li><a href="http://www.ft.dk/Samling/20051/beslutningsforslag/B103/index.htm">Interpelacija B 103 danskog parlamenta</a></li>
<li><a href="http://perens.com/OpenStandards/Definition.html">Otvoreni standardi - načela i praksa</a>, Bruce Perens</li>
<li>Digistanova <a href="http://www.digistan.org/open-standard:definition">Definicija otvorenih standarda</a></li>
</ul>

</body>

<timestamp>$Date: 2010-11-07 19:22:58 +0100 (Sun, 07 Nov 2010) $ $Author: guest-mdim $</timestamp>
</html>
<!--
Local Variables: ***
mode: xml ***
End: ***
-->

+ 103
- 0
projects/os/def.it.xhtml View File

@@ -0,0 +1,103 @@
<?xml version="1.0" encoding="UTF-8" ?>

<html>
<head>
<title>FSFE - Standard Aperti - Definizione</title>
</head>

<body>
<p id="category"><a href="http://www.fsfe.org/projects/work.html">Il Nostro Lavoro</a> / <a href="/projects/os/os.html">Standard Aperti</a></p>
<h1>Standard Aperti</h1>

<div id="introduction">
<p>Non esiste una definizione universalmente accettata di cosa costituisca
uno Standard Aperto, ma non mancano le proposte. I link ad alcune
di queste sono stati inseriti a fondo pagina. </p>
</div>
<p>FSFE non ha voluto proporre un'altra definizione. Abbiamo deciso
di utilizzare la definizione di Standard Aperto che è stata sviluppata
come parte dei preparativi
per <a href="http://www.certifiedopen.com">Certified
Open</a>. Il lavoro su questa definizione iniziò prima del coinvolgimento di FSFE
nel progetto e fu basato inizialmente sulla definizione presente
nel <a href="http://ec.europa.eu/idabc/en/document/3473/5585.html#finalEIF">Quadro
Europeo per l'Interoperabilità (EIF)</a> della Commissione
Europea.</p>

<p>In un dialogo che ha coinvolto vari attori chiave dell'industria, della politica
e della comunità, la definizione è stata rielaborata e strutturata su
cinque punti, incontrando il consenso di tutte le persone coinvolte. La
definizione è stata successivamente adottata dal
<a href="http://selfproject.eu/OSD">Progetto SELF EU</a>, dalla
<a href="http://www.openforumeurope.org/library/geneva/declaration/manifesto-with-logos-final.pdf">Dichiarazione
sugli Standard e il Futuro di Internet</a> di Genova 2008 e
dal <a href="http://documentfreedom.org/openstandards.it.html">Document
Freedom Day</a>.</p>

<h2>Definizione</h2>

<p>Uno Standard Aperto si riferisce a un formato o ad un protocollo che è</p>
<ol>
<li>soggetto a una completa va