Is the NBT format proprietary?

Discussion in 'Plugin Development' started by Bone008, Jul 1, 2013.

Thread Status:
Not open for further replies.
  1. Hwy, so this question is only partially related to Plugin Development, but I don't think it fits any other forum.
    As far as I am aware, the NBT file format was created by Mojang (Notch). My question is: Is it proprietary?
    May I use a format following its specifications in another commercial product unrelated to Minecraft without getting into trouble?
    I'm not talking about the NMS source code implementing the format, by the way, I wouldn't copy that one, I'm talking about the format itself.

    I have no idea of software patents, not sure if a format specification can even be protected, I just wanted to make sure ;)

    Any references would be appreciated, thanks :)
     
  2. Offline

    LucasEmanuel

    Bone008
    In the world of software patents, everything can be patented, according to the americans ;)
     
  3. Okay, maybe it can, but is NBT?
    From what I have read from Notch's opinion about software patents (tumblr post), I feel like Mojang wouldn't mind, but I want to go sure.

    Is there any way for me to find out? Does anybody know?
     
  4. Offline

    LucasEmanuel

    Bone008
    Well, according to the last line in that post I don't think he would mind :)
     
  5. Offline

    lancevincent

    I think format should not be patented and i guess they are not patented (not sure though). Only the methods are patented and the logos too. business method patents
     
  6. Offline

    Comphenix

    It doesn't sound like you need this for interoperability with Minecraft, so why expose your commercial product to any unnecessary risk? True, I doubt Mojang would ever (even it it could) pursue commercial entities for use of its proprietary formats, but leadership can change. I don't think could imagine Sun suing Google for making its own independent Java implementation, but then Oracle happened ... Oracle was obviously in the wrong, but they still managed to sue and waste a ton of time and goodwill with the Java community.

    In any case, I think you should consider a open format instead. Of which, there are many competing binary XML formats, each with their own individual strengths and weaknesses. Do you need the ability to quickly look up individual elements, without scanning the entire file? Use BSON or EBML. Is read or write speed a concern? Memory/space usage? Extensibility? Support for special data types? Good APIs? Perhaps interoperability with other languages? Protocol Buffers. I don't think NBT comes ahead on any of these aspects, apart from having a relatively simple API.

    Simplicity is a plus, of course, as it encourages simple APIs and additional language implementations, but then why not just go for compressed JSON/XML? That may even be built into your current language.
     
  7. Hey, the forgotten thread is back alive!

    That's a good point. The future is long, and assuming the project stays alive for a while, there would always be that little problematic thing waiting for potential trouble.

    No, I don't need to look up individual elements, I'm not very worried about performance, I don't need support for other languages. Actually, my requirements are not very demanding. This is why I picked NBT:
    • I need to store rather large binary blobs of data with additional string/numeric metadata.
    • It needs to be forward-compatible (I don't want special handlers or converters whenever just one property changes) - this is mainly an advantage over plain binary serialization.
    • I can use external programs to easily view and modify the data.
    • It's so dead simple to read and write structured information, because of the simple key/value pairs.
    My language of choice is Java, and any textual format like JSON/XML falls flat for me because of the major percentage of binary data whose text representation would be huge.
    Also, I hate using XML for anything outside the web/JavaScript because the DOM API is just so bloated to use in languages like Java or C# (IMHO).

    I have yet to find something that reaches the simplicity of e.g. this:
    Code:
    compBounds.setString("type", "cylinder");
    compBounds.setList("origin", Arrays.asList(origin.x, origin.y, origin.z));
    // i'm proud of the list part of my NBT library, it even supports nested lists, all with one method :P
    compBounds.setDouble("radius", radius);
    compBounds.setDouble("height", height);
    
    I feel like most of the binary approaches that are based on XML or JSON are not really created to create a direct mapping from basic variable types of high level languages.
    Given a Java object with some simple primitive fields, an array of numbers and a list of objects of another "serializable" class, I want to be able to serialize and deserialize as easily as possible.

    Like using a DataOutputStream, just without its drawbacks (the primary ones being order-sensitive and not allowing fields to be added/removed).

    I know, my requirements are pretty nit-picky, but NBT provides exactly that. Whether I need to store 200 KB vertex data or a 5-character string, it's all coming down to the same output. And I can read it back like key/value-pairs.

    Is there anything with similar possibilities and simplicity? :)
     
  8. Offline

    Comphenix

    I've been looking through a lot of alternatives, and it is fairly difficult to beat a dead-simple JSON-like (with more data types) binary format, at least in terms of API simplicity.

    But NBT still requires you to manually write the serialization and deserialization code. So perhaps something like Kryo would be an improvement? It's reminiscent of Java serialization, only faster, but it also appears to handle incompatible changes to objects through TaggedFieldSerializer or CompatibleFieldSerializer. It's also used by a couple of other projects, which is promising.

    I also considered Protocol Buffers, but the added complexity is probably not necessary in your case. There's also MessagePack, but it seems fairly outdated and the Java documentation is almost none existing.
     
  9. Offline

    robotnikthingy

    Now that i think about it, NBT really reminds me of the RGD format used by many relic games such and Dawn of War and COH (though RGD is a bit more flexible)

    I wouldnt really worry too much about infringing on anything, since many formats seem to have similarities in one way or another, but for safety try using an open format like mentioned above
     
  10. Offline

    xTrollxDudex

  11. Offline

    hatstand

    The stock DOM API for Java (org.w3c.dom) is trash. It was implemented before a lot of Java features that would have made it much less unwieldy. So I use JDOM, which is much nicer. If you need serialisation, check out XStream, it's pretty awesome.
     
  12. Bone008 You could always try asking Mojang itself. Although since it's(the company) small you might not be able to, but since this is a legal question i think you should be able to.
     
  13. Offline

    Wingzzz

    If NBT is what you're leaning towards, perhaps check out this: JNBT
     
  14. I took a look at KryoNet when I was planning my network protocol but decided against it because I didn't need all the automation and high-level functions it provided. I was fine with just writing and reading data manually, I don't really need more.
    I feel like I can't make too much benefit from Kryo's "give me object, I give you bytes" as well. Having tools to inspect the data easily from the outside is pretty important for me now at the beginning. And Kryo is "just" a serialization tool, without a unified file format.
    Maybe I will replace it later with an own serializer that supports named fields but uses a different format. Essentially, my API would support a pluggable format right now (if you're curious, this is the only visible interface + a helper class to read and write compounds, all other NBTTag types are 100% encapsulated).

    Couldn't really find anything on RGD, and I doubt it's an open format ;)

    Wow, thanks for the hint to JDOM, it looks a lot cleaner. XStream would be cool if I used XML for data classes, but right now all I need it for is hand-written config files. I'll definately look into JDOM, though!

    I tweeted Dinnerbone once, but that was probably not the best way to go about this :p

    Thanks, but I've already written my own NBT library (another advantage of such a basic format). Not a fan of how existing libraries expose the different tag types so much :)

    ---

    Thank you for all the suggestions. I think I will stick to my current solution right now. The project is far from actually going commercial or big, and if it does, I might have a lot more potential to come up with something ;)
     
Thread Status:
Not open for further replies.

Share This Page