A simple statement

Yesterday, I got into a discussion with Sean Eddy at Janelia farms over the change in HMMer. Today I saw this online.

Let me be clear. The name “HMMer” is Sean’s, and he can do with it what he wants. My concern was about something different, which we are going to adapt to. We are working to make sure we are correctly respecting his rights, while at the same time supporting users with a “business” case for using the existing code. This is not to say we get paid for this. We don’t. Entirely a spare time/effort thing.

But the statement needs to be made. There is no conflict. The forks will be renamed.

Viewed 9084 times by 1951 viewers

2 thoughts on “A simple statement

  1. Joe, I really think your worries about the trademark are a misunderstanding. I want to emphasize again (and again and again) that the main reason behind why we felt we needed the extra leverage of a trademark is that there are several companies that are using the name “HMMER” to advertise software that is (apparently) a closed-source independent implementation that shares no code with HMMER. That’s obviously not kosher, I hope you’d agree; such people can say stuff like “HMMER-compatible” but they shouldn’t be naming their software HMMER.

    MPI/GPU-HMMER are in a different situation. You’ve got a legitimate fork of the real HMMER code, and a strong piece of work you’ve added to it. So the issue between you and me is much more grey, and ought to be worked out by mutual agreement in an open-sourcey way. The issue is that when HMMER3 comes out, your fork becomes obsolete. There’s at least three ways this could go.

    First, you can do nothing, and just maintain/support MPI/GPU-HMMER as legacy code — in which case, I don’t have any real problem with the use of the name. The way you used it has been fair, especially given that HMMER2 development here was stagnant and you had no way to get your changes into our codebase.

    You could try to continue developing your fork, in which case (in my opinion) just because of the generational change of our codebase to HMMER3, you’d be creating an unfortunate and confusing situation in which your H2-based fork was named something too similar to to our active work. In this case, I’d just ask you to choose a different name if you want to continue innovating your own stuff without cooperating with me and my lab. And just so no one misunderstands, this is only about the name and identity of the project(s) — all our code is open source and freely available, period.

    Finally – and what I’d really prefer – we could find a way to work cooperatively to bring your MPI and GPU work into the HMMER3 codebase. That was the purpose of the meeting I invited you guys to at Janelia, which I really felt ended with you guys expressing little interest in cooperative development unless I paid for the work, which I’m unfortunately just not able to do. If my take on that was wrong, we should reopen the discussion and take it offline.

  2. I think we are aiming for #3, though there are enough users of MPI/GPU-H2 that we need to maintain it for a while.

    JP and Vipin would like to be able to compare H2 vs H3 as well as the GPU/MPI ports, in papers, at conferences, etc. More to the point, they (and I) would like to get MPI/GPU capability forward ported to H3. And work with your team in doing so.

    Dedicated resources are hard without financial backing. This is always an issue in academia. Business is more of a revenue issue. Without revenue, projects are background, as I have time/interest. I have a CUDA port going for some numerical work we were approached about, but the customer subsequently backed off on. We might push that out eventually, but not likely soon.

    As long as everyone is fine with non-dedicated resources (GPU/MPI-H2 are non-dedicated resourced projects), I think it would be fine.

    Will take it offline, send an email detailing this sometime this week.

Comments are closed.