3 ms·

> I've found ArchiveTeam's wiki to be very useful for obscure file format details: http://fileformats.archiveteam.org/ http://fileformats.archiveteam.org/ I to

by cxr 5y ago

> I've found ArchiveTeam's wiki to be very useful for obscure file format details: http://fileformats.archiveteam.org/ http://fileformats.archiveteam.org/ I took a serious look at trying to contribute to the Archive Team's "just fix the file format problem" effort a while ago. I ran into the problem that they require contributions be public domain/CC0. This prohibits material derived from the vast corpus of FOSS (even the most permissively licensed stuff—e.g. MIT, BSD, etc.) Considering how rare public domain/CC0 is, essentially everything would need to be done from scratch.

kortex 5y ago
You should reach out to them and let them know. I don't know what the alternative would be - are there better CC licenses out there? Dual licensing CC+MIT/BSD? Pragmatically (but not legally speaking, INAL) you could probably get by with summarizing and linking (especially to web archive).
- TAForObvReasons 5y ago
  There are two problems that reasonably explain the decision of only accepting public domain info: licensing and provenance. "Licensing" is hard. The "Open Specifications Promise" [1], which covers a bunch of Microsoft-designed file formats, is merely a covenant not to sue. "Provenance" is tricky. For example, much of the knowledge of the Apple iWork formats were derived by reverse-engineering the source programs and extracting protobuf definitions. Many open source projects have freely copied from each other, making detailed analysis tricky [2]. [1] https://en.wikipedia.org/wiki/Microsoft_Open_Specification_Promise https://en.wikipedia.org/wiki/Microsoft_Open_Specification_P... [2] https://github.com/jazzband/tablib/issues/114 https://github.com/jazzband/tablib/issues/114
  - cxr 5y ago
    > There are two problems that reasonably explain the decision Boy do I hate these kinds of after-the-fact, speculative "explanations"—anachronistic rationalizations that come out of a mental exercise to justify what is by retroactively (and non-authoritatively) trying to invent a plausible why. And if you know the personality and values of the progenitor of the whole thing, then you know that this better-safe-than-sorry deference to hair-splittingly nuanced IP hurdles (that in practice don't really exist) is not the MO. Besides that, requiring public domain/CC0 doesn't solve either of those problems.
  - kortex 5y ago
    > "Provenance" is tricky. For example, much of the knowledge of the Apple iWork formats were derived by reverse-engineering the source programs and extracting protobuf definitions. Many open source projects have freely copied from each other, making detailed analysis tricky I wonder if the Google LLC v. Oracle America, Inc. ruling helps this in any way. Defining a specification (either with public docs, RE or empirically) of closed format for the sake of reading the data or long-term archival strikes me as emphatically free-use. But I could also easily seeing it ending up patent-troll bait.

by cxr 5y ago

kortex 5y ago

You should reach out to them and let them know. I don't know what the alternative would be - are there better CC licenses out there? Dual licensing CC+MIT/BSD? Pragmatically (but not legally speaking, INAL) you could probably get by with summarizing and linking (especially to web archive).

TAForObvReasons 5y ago
There are two problems that reasonably explain the decision of only accepting public domain info: licensing and provenance. "Licensing" is hard. The "Open Specifications Promise" [1], which covers a bunch of Microsoft-designed file formats, is merely a covenant not to sue. "Provenance" is tricky. For example, much of the knowledge of the Apple iWork formats were derived by reverse-engineering the source programs and extracting protobuf definitions. Many open source projects have freely copied from each other, making detailed analysis tricky [2]. [1] https://en.wikipedia.org/wiki/Microsoft_Open_Specification_Promise https://en.wikipedia.org/wiki/Microsoft_Open_Specification_P... [2] https://github.com/jazzband/tablib/issues/114 https://github.com/jazzband/tablib/issues/114
- cxr 5y ago
  > There are two problems that reasonably explain the decision Boy do I hate these kinds of after-the-fact, speculative "explanations"—anachronistic rationalizations that come out of a mental exercise to justify what is by retroactively (and non-authoritatively) trying to invent a plausible why. And if you know the personality and values of the progenitor of the whole thing, then you know that this better-safe-than-sorry deference to hair-splittingly nuanced IP hurdles (that in practice don't really exist) is not the MO. Besides that, requiring public domain/CC0 doesn't solve either of those problems.
- kortex 5y ago
  > "Provenance" is tricky. For example, much of the knowledge of the Apple iWork formats were derived by reverse-engineering the source programs and extracting protobuf definitions. Many open source projects have freely copied from each other, making detailed analysis tricky I wonder if the Google LLC v. Oracle America, Inc. ruling helps this in any way. Defining a specification (either with public docs, RE or empirically) of closed format for the sake of reading the data or long-term archival strikes me as emphatically free-use. But I could also easily seeing it ending up patent-troll bait.