Re: Licensing a file format (was Re: SVN Branch Description Format)

From: Jeff King <peff@peff.net>
Date: Mar 20, 2012, 22:59 UTC
Message-ID: <20120320225918.GA31958@sigill.intra.peff.net>
In-Reply-To: <4F6797AD.2070501@pileofstuff.org>

On Mon, Mar 19, 2012 at 08:31:41PM +0000, Andrew Sayers wrote:

Show 14 quoted lines

> > Yes.  By the way, I think fear of forking/discussion of potential
> > improvements/translation into other languages in the context of
> > standards is misguided.  If you would like legal protection for your
> > standard, that is what trademark law is for.
> [...]
> 
> Could you expand on this?  A quick tour of the git codebase suggests
> your objection is just to the "no derivatives" bit for documentation,
> and not to the MIT license for code?
> 
> It sounds like you're saying that forking isn't a big real-world
> problem, which I guess makes sense - it'll all work out in the end as
> long as a single standard is in everybody's interests.  So the CC-BY
> license is my favourite for now.

I think the problem is that there are two levels of forking. You want people to be able to build off of your standard for a number of legitimate reasons. Perhaps they are publishing a draft proposal of enhancements. Perhaps they are adapting parts of the content of your standard to a different domain. Perhaps the original author has become unresponsive and somebody else wants to pick up maintainership. Those are all things we do with code, and they help the ecosystem.

What _isn't_ good is somebody modifying your standard and then claiming that their implementation is "the real SVN History Description" format.

I think Jonathan's point is that CC-BY-ND doesn't allow the legitimate things in the top paragraph. And your real problem (in the second paragraph) is not derivatives, but derivatives claiming to be something they are not (the official standard). And trademarks are the legal tool for avoiding confusion like that.

In practice, I don't think this kind of name-hijacking is a big deal. There are many forks of git, and somebody could make a derivative git that is buggy, interacts badly with existing repository formats, or interacts badly with other git clients via the network protocol. But people are usually kind enough not to call their other implementations "git", and it just works out in practice. So you could probably get by with just a regular source code license (but I am far from an expert, so take the appropriate grain of salt).

-Peff