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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> > 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]