Clojurians Log v2

Truth. Intellectual property is kinda broken and there are no easy solutions...

TBH I don’t find trademark law too offensive

Patents and copyright yes, but trademark law is mostly sensible

It's the least bad of the lot, to be sure. But that's not saying a whole lot. Much of the problem is from cases like this, where there's no way that two products are competing with one another, but someone overused a trademark for no real reason

Like really, is some dev utility for node going to compete in any way with some chat app for tweenies, or confuse any consumer ever? Nope.

And if people can get away with these overbroad claims because of intimidation, then there are no names left. If you search the registered trademark database for anything, no matter how common a word, you get a bizallion marks

I could be wrong on the specifics here, but my understanding is that this only came up when Kik wanted to publish a package to NPM and found that there was already an NPM package called Kik. Trademarks are there to protect consumers and avoid confusion. Kik as an NPM module vs the chat service there is low risk of confusion, but if Kik are now publishing an NPM module then it becomes a little more understandable that there is confusion possible. Not saying I like it, but this is the world we live in :simple_smile:

This sounds at root a problem with NPM not being able to provide a richer category / name-space to allow same names in separate spaces

That was my original reaction, but consider the case of someone making a stink for a group name.

Ex what if I pushed a jar to com.cognitect/foo. Would that be honored? How about com.factual/foo my former employer etc.

But now imagine the natural extension of that Kik-entering-npm example. Suppose the person who owns the Cat Lady trademark decides, "hey, I'm going to expand from selling cat toys or whatever into making a node app that produces cat ascii art." And then they're shocked, shocked, to find that there's a node app called cat lady. ...

Just have some 'canned' and 'obvious' spaces and don't allow users to create their own categories. Things like 'apps' and 'libs', http://et.al. and some simple subcategories. Not perfect, but would likely solve most such cases

You can break anything, but this sounds more like a case of a name clash preventing the other from being deployed at all - not so much the confusion stuff

Okay so let's say that in an attempt to avoid this sort of thing clojars were to require an application for org.\ and com.\, and me.$USERNAME is all a user "just gets". Now some has to review group name applications, and still there are problems. What if someone else comes along and wants me.arrdem because I'm dead and they have a trademark. What if someone wrongly issues a group name? What if a group becomes defunct and someone else sues for it etc.

Sure, most anything is possible, you are really just trying to reduce the probabilities.

One idea is to expose groups via two names. One is a uuid which we guarantee never to change or revoke, the other is a "human readable" groupname which may change in the future. On the tooling/client side users can then cache/override the upstream name to uuid mapping so if I wanted to use the old org.kik I just set a lein profile entry mapping that to the old uuid.

This requires reinventing less of Maven than other IPFS or Namecoin backed things I've seen thrown around recently. :/

That's a really great idea @arrdem

I highly recommend reading https://cyber.law.harvard.edu/metaschool/fisher/domain/tm.htm or some other 5 minute primer on trademark law, it was really helpful for me.

In the hypothetical cat lady example, Cat * is probably a descriptive mark, and so gets very little protection. If there was already a lib under cat-lady/cat-lady then that would probably be able to stay

Anyhoo, I think this is very unlikely to happen to Clojars for a few reasons: 1. Clojure folk are pretty mature 2. The Clojure community is pretty tiny 3. Group names are common which help the namespacing problem 4. The main problem would be group name squatting, not artifact name squatting, which is easier to adjudicate 5. Most Clojure libs get named either very straightforward descriptive names, or fanciful creative names

@danielcompton: I agree on the substantive legal point about the example (and I actually learned my IP law from Terry Fisher, albeit almost 20 years ago), but the issue isn't the substantive legal question, the issue is how much power holders of registered trademarks have to intimidate people without money to litigate to give way beyond the scope of their substantive legal rights... That was really the issue with the Kik thing, as I interpret it. (But anyway, this is turning into a kinda off-topic discussion about how problematic trademark law is... Back to the main question, what about @arrdem 's dual-naming idea, that way if this ever does come up in clojars trademark disputes can be handled without breaking library access?)

Disclaimer on the dual naming thing... I've been thinking for a while about how to do away with maven and manage dependencies via IPFS or bittorent or something else which provides different uniqueness properties and a fundamentally different distribution substrate. With some hacking I'm sure that you could write a leiningen plugin to support "hashdeps" or whatever you want to call these references, but the main idea in all that work is that names are not in fact a globally unique thing, rather they are largely contextual and so trying to come up with a naming permanence scheme which deals with all the complexities of IP law and assumes that whatever packages I publish under me.arrdem/* will be available until the heat death of the universe under that uncontested name is... silly. To @danielcompton's point I would agree. I think that by dint simply of having group names and using them, we're already way ahead of the Node crowd here and so rather than inventing a whole new dependency resolution system such as I was sketching at a simple statement of policy from the Clojars folks would probably be best.