Talk:Open file format

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Some problems[edit]

I think this page has some problems:

It doesn't cite its references for statements. It does include a list of references at the end but the statements made on this page contradict some of those on the referenced pages (e.g. the definition on this page does not agree with that on <http://www.openformats.org/en1>). No explanation or even acknowledgment of the differences is made, so this is not a neutral POV.

Specific details: -1- it says that open formats must be "free of legal restrictions on use" but many open formats are subject to licences (which grant wide-ranging rights, but nevertheless are legal restrictions). The point is that the rights are broad enough for users' intended purposes and the restrictions prevent abuse.

-2- it says that "In contrast to open formats, proprietary formats are controlled and defined by private interests". While it is true that propietary formats are almost always controlled by private interests, it is not the case that open formats CANNOT be defined by private interests, so "in contrast to open formats" is inaccurate (PDF would be a good example).

131.111.85.79 10:45, 12 February 2007 (UTC)[reply]

Compare with Free file format - perhaps some of the text here could be transferred to Free file format? The discussion above suggests to me that the two articles should not be merged, but both improved. Kctucker (talk) 12:02, 7 January 2008 (UTC)[reply]

Distinction between "open standard" and "open format"[edit]

The distinction between "open standard" and "open format" should be addressed in the article. --Bejnar (talk) 22:31, 10 December 2008 (UTC)[reply]

Agreed. For example, I would consider WebDAV a protocol, not a file format. Both protocols and file formats could fall under a greater category of standards, but then it should be reorganized and relabeled as such. 184.78.21.4 (talk) 15:47, 7 October 2012 (UTC)[reply]

Original research[edit]

Mostly missing reliable references.--Kozuch (talk) 11:04, 24 June 2008 (UTC)[reply]

Deletion Template[edit]

Another editor has added a deletion template to this article, proposing that the article be deleted. The stated reason is:

"Proposed Deletion, for same reason as Proprietary Format. / Concept, with no formal definition or notable references outside of biased mention. Article is full of opinion, nothing but an unsourcable definition to be salvaged."

Without a solid definition, it may be best to delete the article. However, if a rock-solid industry-wide agreed definition could be ascertained, then I would reconsider.--Lester

I think what we need is at least one reliable source for each non-obvious claim in this article. Claims for which no notable reference can be found should be deleted.
However, I don't think this article needs to be about an industry-wide agreed definition. It could also cover several definitions (only from notable sources of course) like in the article open standard. For now, I don't think removing the whole article is a good idea, because open formats are a well known concept in the software industry and we just need to find some good references. Ghettoblaster (talk) 23:53, 8 July 2008 (UTC)[reply]
We should also have an eye on Free file format. The main part also does not contain any references. I think merging both articles might be an option. Ghettoblaster (talk) 23:58, 8 July 2008 (UTC)[reply]
I wouldn't really describe it as notable in the sofware industry, hence i put it up for deletion. While there are people who think in terms of open and closed formats, it's only an insignificant proportion outside of the primary software market, and even if we took that as some notability of the topic, none of these terms are notable, and they are certainly not verifiable. - Jimmi Hugh (talk) 09:40, 9 July 2008 (UTC)[reply]
So, I see it was decided to merge articles on free formats and open formats rather than expand the definition of "free file format". Has anything been lost in the process? For example, a free file format requires a free software reference implementation. There used to be a list of free file formats which was really useful at times. The distinction between the terms are of interest beyond the software industry (free culture, free knowledge, ...). Wikipedia is central to the free knowledge movement and only accepts files in a free file formats (see the Wikimedia Commons policy on this). Let us not forget (and thereby undermine) the original vision for Wikipedia and free knowledge in general. -- K (talk) 13:05, 12 November 2009 (UTC)[reply]
Just picking up on one point you've got there - neither a "free file format" nor "open file format" require a free/open reference implementation. By definition, it just needs the specification freely/openly available for all to use. A reference implementation cetainly helps for verification purposes, etc, but isn't necessary. Nuwewsco (talk) 19:17, 12 November 2009 (UTC)[reply]

GIF and JPEG[edit]

Is there any reason that GIF and JPEG should not be listed as Open formats at this point? They are documented formats and all the patents have expired. Kaldari (talk) 18:01, 2 June 2011 (UTC)[reply]

Page should be split and reoordered.[edit]

The list of document formats needs to be in a table on a seperate page and ordered by popularity rather than alphabetically. The table should be amended with the default file extensions associated with the documents, and the Open Document Format section needs to be exploded into .ods .odf etc.

There needs to be a place where end-users can refer to for file format usage. If this was such a page I would href to it in my sig, as a way of saying: DON'T send me .doc files! — Preceding unsigned comment added by 67.163.106.233 (talk) 14:31, 11 July 2011 (UTC)[reply]

So...[edit]

...wikipedia is an FSF mouthpiece know? First of all, for us people in most of the wold, where software patents don't apply, MPEG4 is as "free" as Theora is. Just because the US and a minority of European states have crazy laws that allow software patents to exist, that doesn't mean anything for the rest of the world. What if the US votes for a law that puts a levy on "all codecs capable of using P-frames"? (to counter those evil pirates by making video compression less efficient for media distributed for free) In such scenario, does this mean Theora will suddenly become "non free" and the only "free" codec will be the DV codec? In plain english, just because the US and a couple of other countries have strange laws that allow strange royalty schemes to bloom, that doesn't mean anything to the world. Much like the prohibition of broadband in Iran doesn't mean anything to the rest of the world. As a side note, MPEG LA doesn't have anything to do with the MPEG organization or ITU

Also, the whole free/libre thing makes little sense for the reader that doesn't buy into the FSF propaganda (the "four freedoms" the FSF preaches about are not part of any UN chart and so people don't have to believe they are necessary freedoms). I think the word is "royalty-free". Since an article for "royalty-free" already exists, having an redirect for "free file format" is silly. "Free file format" is a term valid only for FSF believers and does not need to have an article or redirect.

I really hope some intelligent person gets to this post before any of the FSF zealots that patrol wikipedia articles and talk pages does and deletes it (they do that -deleting questions- instead of replying to them, being the ultra-democratic people they are) — Preceding unsigned comment added by 109.178.98.145 (talk) 21:18, 1 November 2012 (UTC) <!d by SineBot-->[reply]

Formats and protocols are explicit standards.[edit]

Why?

Standards are required to meet interoperability requirements that reduce risk and failure.

Standards for metal screws have specified requirements for application purposes. Why? A screw when applied to a purpose / product that unexpectedly brakes or melts is a failure (possibly catastrophic).

A protocol (TCP/IP, Regulation …) when applied correctly allows the successful completion of an interoperability task. Why? A brake in any formalized protocol requirement will cause immediate or eventual failure.

A format (.txt, .png, .odt …) allow applications to open, save, and share information (data/content). Why? Data/content is formatted for presentation by the application. Applications must be capable of reading the formatted information and applying the presentation components for use by humans, software a/o hardware for successful interoperability between humans, software a/o hardware.

Without standards (Protocols, Formats …) there is no interoperability (except by sneaker-net, snail-mail, paper, and mouth). Why? Standards sustain application (screw, XML, HTML, IP, TCP, .txt …) interoperability, by assuring application integrity.

Integrity of standards assures interoperability and successful application for meeting requirements. W3C, OASIS, ISO, IEEE, ITU … are standards bodies/organizations that do assure standards integrity. However, standards integrity can be broke or modified to suit a business purpose of maintaining market-share, obscuring competition-compliance [AKA: finger-point blame-storming], ITs’ better interpretation of the standard ….

So, Open Standards, Formats, Protocols, Architectures … are “Open” but not application assured by any company, organization, law, government. Assurance of standards compliance is always “DOES IT WORK” or information (engineering data, publication content …) WYSIWYG, because standards, hardware platforms, and software applications are the interoperability handlers. The proof of interoperability is WYSIWYG at all points of delivery independent of platform and applications.

One notorious example is MSOffice.odt and LibreOffice.odf file formats. Depending on the version of MSOffice the presentation of the same .odf file (no tapering) on a MSOS platform you will get different presentations of the information. So, WYSIWYG, I will not assume MS-OfficeOpen is Open, the same applies for the MSOffice save of the .odt format. Maybe MSOffice was fixed sence last I checked.

If the application of the standard does not provide open, save, share, import, export … WYSIWYG information to all users and systems. Yes, WYSIWYG logic applies to all information consumers (users and systems information exchanges).

Adelophilia (talk) 15:47, 8 January 2013 (UTC)[reply]

Open formats require an open licence?[edit]

The statement An open file format is licensed with an open license is not supported by its current reference from opendefinition.org. The reference calls its own content a draft and it appears to be user-generated content (see its evolution and also this GitHub thread about it). Perhaps a better source would be the Open Data Handbook glossary, but it also doesn't associate open formats with open licenses as defined in Free license (where I think a distinction between "open" and "free" is needed), so I think the statement should be removed or changed so as not to imply an association. Fernando Trebien (talk) 17:49, 3 March 2024 (UTC)[reply]

both links come to the conclusion that an open format needs an open license, so you seem to be arguing against yourself. I will add the new link to the article, thank you! Svnpenn (talk) 20:35, 3 March 2024 (UTC)[reply]
The first reference that points to opendefinition.org/ofd/, a draft document, states that:

The Open Definition has three key requirements for a work to be open: an open license, open access, and an open format.

It therefore states that an open work requires both an open license and an open format. It does not state that an open format requires an open license.
The (newly added) second reference to opendatahandbook.org does not mention licenses at all. Instead, is says that:

Often, but not necessarily, the structure of an open format is set out in agreed standards, overseen and published by a non-commercial expert body.

It also contrasts open format with proprietary format which it defines here as:

A proprietary file format is one that a company owns and controls. Data in this format may need proprietary software to be read reliably. Unlike an open format, the description of the format may be confidential or unpublished, and can be changed by the company at any time.

This definition, again, does not mention licensing of the format (that is, the standard: its documentation, usage fees, extensibility, branding, etc.), only the openness of software (and by extension, hardware) needed to handle data in such format. --Fernando Trebien (talk) 21:07, 3 March 2024 (UTC)[reply]
I think that, with too few participants and a never-ending edit war, this thread isn't going anywhere soon. So, for future participants, I recommend taking a look at Open standard, particularly Open standard § Comparison of definitions, where different definitions of the term "open" are summarized. The currently used references, opendefinition.org and opendatahandbook.org, are websites from the Open Knowledge Foundation, an advocacy group (Open Knowledge Foundation § Advocacy) that promotes The Open Definition, which is compatible with some of these definitions but incompatible with others. The article Open standard discusses the various meanings of those terms with quite some depth. So, I think that, to follow WP:NPOV, WP:WEIGHT and WP:LEAD, the leading section of this article on open file formats (which are open standards) should not endorse any specific definition over others that are also widely used and instead it should briefly mention the various meanings of the term "open" and point to Open standard for more details. The other two sections, “Specific definitions” and “Examples of open formats”, already cover the plurality of meanings, so there is no reason to impose a specific definition in the lead, as was the case until March 2022. --Fernando Trebien (talk) 14:06, 4 March 2024 (UTC)[reply]
how would you feel about simply removing the "open format" specifier? I think we can both agree that its not currently well defined, and might never be. "free format" is more or less clear without disagreement I think, so we should keep that.
instead of "open format", we could change the key to "open license" and/or "open access", in which case I think we could reach consensus on the status of those Svnpenn (talk) 19:42, 4 March 2024 (UTC)[reply]
instead of "open format", we could change the key to "open license" and/or "open access"
I think this is nonsense, it does not reflect the content and the language of the references used in the article. --Fernando Trebien (talk) 22:25, 4 March 2024 (UTC)[reply]
no, I mean this would stay as it is:
Open file format
other than maybe people can argue about the content of that page. personally the only interest I have in that page, is that its being linked here:
ISO base media file format
MP4 file format
if its no longer linked, then I dont care how "open file format" is defined. so I propose we remove the open format link from these pages:
ISO base media file format
MP4 file format
or instead change the key to "open license" and/or "open access", then link to appropriate articles, if they exist Svnpenn (talk) 22:38, 4 March 2024 (UTC)[reply]
Controversial changes to these articles should be discussed at their respective talk pages and it is already being discussed at Talk:MP4 file format § Edit request. On this talk page we are discussing controversial changes to the Open file format article. --Fernando Trebien (talk) 22:49, 4 March 2024 (UTC)[reply]
its important to discuss here as well. if the "open format" page is unlinked from ISOBMFF and MP4, then I would relinquish my opinion on the "open format" page, and for example, you could remove the text and links from "open format" that you disagree with. however as long as ISOBMFF and MP4 are linking to "open format", then I most hold an interest in the "open format" page as well. I am trying to find a middle ground here. Svnpenn (talk) 22:59, 4 March 2024 (UTC)[reply]

RfC on requirements defining open file format[edit]

Should the definition in the lead section restrict "open file format" to file formats whose specification is available only under open access, or with an open license, or both, or neither? Fernando Trebien (talk) 22:06, 8 March 2024 (UTC)[reply]

its probably best to accept that the term is not agreed upon, and just include opposing definitions as needed Svnpenn (talk) 00:38, 9 March 2024 (UTC)[reply]
(Summoned by bot) I personally tend towards a more restrictive definition of "open X" (so in this case I'd expect an "open file format" to mean one where the spec is freely available, freely redistributable, and freely implementable, where the creators claim no interest in the format itself) — but I also know that's not how everyone sees it. In this case, I can't imagine why something like "The definition of an 'open file format' is disputed, but commonly-cited critera include..." wouldn't work as long as sourcing exists. If there isn't a consensus outside Wikipedia on what the term means we certainly don't have to have one here either.
Box of wolves (feed) 06:05, 10 March 2024 (UTC)[reply]
I would limit it to formats not encumbered by intellectual property, e.g., public domain,permanent grant of permission for use of relevant patents. However, aren't we bound by WP:RS? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:24, 10 March 2024 (UTC)[reply]
Open standard has an acceptable summary of the situation. I don't think it is practical to include a summary of the issues surrounding the use of open wherever it is used. I would personally lean liberal on this especially of sources describe the item in question as open. Another alternative is to avoid using open and instead describe the IP issues directly: Is it available to anyone? Do you need to pay for documents? Is there a license fee? Is licensing RAND? ~Kvng (talk) 14:35, 11 March 2024 (UTC)[reply]
Comment: I think the item Kvng refers to is the MP4 file format. There is a related RfC just for MP4, here we are discussing the definition broadly, for all formats. The Library of Congress' Digital Preservation program is likely a reliable source for many file formats. Its Disclosure sustainability factor explanation says it indicates whether the format is an open standard, fully documented, partially documented, or poorly documented, and the detailed description suggests that the Library of Congress (LOC) defines "open standard" as having approval by a recognized standards body, which would include groups such as the IETF (with open access to standards) and ISO (usually paid access only). It also contrasts "open standard" with "proprietary standard", as in proprietary file formats. Most of the other secondary sources I've found so far have much less technical and legal detail than the LOC, and many, like the Digital Preservation Coalition, reference it, which I think is indicative of its recognition. --Fernando Trebien (talk) 21:40, 11 March 2024 (UTC)[reply]
We definitely should summarize what LOC has to say on this somewhere (I'd suggest at Open standard) but I don't think we should give the impression that what the LOC says is how everyone sees it. ~Kvng (talk) 22:56, 11 March 2024 (UTC)[reply]
I agree. --Fernando Trebien (talk) 00:44, 12 March 2024 (UTC)[reply]
Note. After the start of this RfC, LOC changed its documentation explicitly stating that MP4 is not an open format. As this RfC was caused by a dispute surrounding MP4, there may be implications for the discussion here. --Fernando Trebien (talk) 15:13, 15 March 2024 (UTC)[reply]
Comment: As I said at greater length in the similar discussion at Talk:ISO base media file format and as per Svnpenn and Kvng, the word "open" does not have a single clear universally-agreed meaning, and the same is true with the longer phrases "open standard" and "open file format" and other loaded words such as "proprietary". There are some people who advocate for some particular definition to be used, but it does not mean everyone agrees. Some people simply use the word in ways that some others don't like. Wikipedia should describe the various aspects and interpretations clearly without adopting or assuming a particular interpretation. Mulligatawny (talk) 22:16, 6 April 2024 (UTC)[reply]