clojars

http://clojars.org discussion and “support”, see http://status.clojars.org for status.
gowder 2016-03-25T03:35:42.000087Z

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

danielcompton 2016-03-25T03:36:46.000088Z

TBH I don’t find trademark law too offensive

danielcompton 2016-03-25T03:36:58.000089Z

Patents and copyright yes, but trademark law is mostly sensible

gowder 2016-03-25T03:59:23.000090Z

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

gowder 2016-03-25T04:00:06.000091Z

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.

gowder 2016-03-25T04:02:45.000092Z

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

danielcompton 2016-03-25T04:19:43.000094Z

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:

jsa-aerial 2016-03-25T14:25:53.000095Z

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

arrdem 2016-03-25T14:28:24.000096Z

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

arrdem 2016-03-25T14:30:45.000097Z

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

gowder 2016-03-25T14:32:57.000098Z

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. ...

jsa-aerial 2016-03-25T14:33:02.000099Z

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

jsa-aerial 2016-03-25T14:34:53.000100Z

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

arrdem 2016-03-25T14:37:03.000101Z

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.

jsa-aerial 2016-03-25T14:49:53.000105Z

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

arrdem 2016-03-25T15:01:42.000106Z

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.

arrdem 2016-03-25T15:02:36.000107Z

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

gowder 2016-03-25T15:04:17.000108Z

That's a really great idea @arrdem

danielcompton 2016-03-25T17:41:22.000110Z

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.

danielcompton 2016-03-25T17:44:06.000111Z

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

danielcompton 2016-03-25T17:46:00.000112Z

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

gowder 2016-03-25T18:16:47.000114Z

@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?)

arrdem 2016-03-25T18:26:17.000115Z

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.