Name must be changed to prevent trademark/copyright/GPL issues

[eeickmeyer]

Hi there! I'm the leader of Ubuntu Studio, and would love to package this to get it back into Ubuntu and/or Debian. However, there's one lingering issue: the name.

The DisplayCAL name is still owned by the original trademark holders. While the GPL allows you to fork the project, it doesn't allow you to keep the name. While I can package this, it must be reviewed by archive admins, and the first thing they look at is copyright and if those copyrights have been given express written consent for the name to be used. In this case, they haven't, so the name can't be used.

I know that in some countries a trademark or copyright must be registered, but in some jurisdictions, such as the United States, that's not the case so long as it can be proven that "prior art" existed. Since the "prior art" in this case is the Python 2 version of DisplayCAL, it would be easy for the archive admins to reject until the name issue is sorted.

Unfortunately, I don't have a solution for this as I'm horrible at naming things. So, I highly suggest discussing this and coming up with a unique name. I know this is no small task, but without it, the whole project is essentially violating the GPL.

So, I hope this doesn't come across as hostile, but more like concerned. I brought-up this issue with the previous fork, which turned into this fork. I'd really love to have this return to Ubuntu Studio (albiet in a different form) as it was a great application to have in the suite.

[eoyilmaz]

Hey Erich,

Around 1-1.5 months ago, I reached out to Florian to get his permission to be the next maintainer of DisplayCAL. But, to this day, he didn't return back. I'll try one more time.

But yeah, if we cannot hear back from Florian, I think renaming the project is the way we should go as I cannot return my changes to the original repository nor become the next maintainer (of DisplayCAL). Along the way we could change the license to a more relaxed license (ex. MIT, BSD etc.) too. As I see we can not change the license at all. But keeping the license as GPLv3 is not a problem.

[eoyilmaz]

I mailed Florian again. If he won't return, we start the discussion of the new name.

[eeickmeyer]

Hi Erkan,

Glad to hear it. But use caution if you wish to change the license as I'm not sure that's permissible under the terms of the GPL as it contains this clause:

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.

This means it can be redistributed and/or modified under the GPL or any later version. You've modified it under the GPL, which means that, I believe, it must remain under the GPL. I could be wrong about my interpretation here, but that's my understanding. Others are more than welcome to chime-in and correct me here.

Regarding Florian, I doubt you'll hear back if you haven't heard back yet. He seems largely uninterested in moving his own project forward beyond maintenance. It's been nearly 3 years since a release, so I'm not holding my breath. In the meantime, I've been using the flatpak just so I have something, but the package is definitely missed.

[eoyilmaz]

Did you try this repository version. It is properly working under Python 3.8, 3.9 and 3.10. And I would love to hear if there are any issues running it on your side.

Yeah, I can keep the license GPLv3, of course that's an option too.

[eoyilmaz]

For all who are interested in this issue, I think it is a good idea to post a screenshot of the emails I've previously sent to Florian Hoch about taking the maintainer-ship of the DisplayCAL project. We might need an advice from an attorney knowledgeable on abandoned Open Source projects on EU area (I believe Florian is from Germany so Germany's laws should apply here).

Let me repeat my intention, I want to be the next maintainer of DisplayCAL, I want to keep the license as GPLv3, and it is for public good.

We need to learn about:

• What are the legal steps to be followed to take the ownership of an OpenSource project which will be kept as an OpenSource project.
• Is there an expiration date or duration, after all the sources of contacts (DisplayCAL forum, Florian's email address on both the forum and the project metadata) have been tried and exhausted and no answer has been received.
• And yeah basically what steps should be taken.

[eoyilmaz]

Here are the source of the original email messages:

email_to_floarian_20220316.txt email_to_floarian_20220430.txt

[ignace72]

Hello. This is the status of the DisplayCAL brand: https://tsdr.uspto.gov/#caseNumber=77634900&caseType=SERIAL_NO&searchType=statusSearch The brand has been discontinued since 2009. Ignace.

[eoyilmaz]

Thank you for the information. But, I don't think that it applies to this OpenSource project. DisplayCAL is not a commercial product or brand.

[ignace72]

I was responding to what eeickmeyer said in his first post:

The DisplayCAL name is still owned by the original trademark holders. While the GPL allows you to fork the project, it doesn't allow you to keep the name.

The GNU GPL does not prohibit keeping the name of an abandoned project to make a fork. The GNU GPL requires the author of the fork to indicate that it is a work based on a previous work and to give credit to the author. The problem lies with the copyright of the name and not with the GNU GPL. I don't know the country where the original author of DisplayCAL is and that matters. Some countries require the name to be officially registered, others just require proof that the name has already been used (like in the USA). If the decision is made to keep the exact name, there will always be a risk that the original author of DisplayCAL will sue if he is in a country that just requires the name to have been used before. So the logical thing to do would be to change the name of the fork.

As for the choice of name, some choose to add a suffix to the original name (like LinCity-NG) others choose a completely different name. Personally I don't have a preference, the important thing for me is that it is a project that lasts for a long time, because there is no alternative to DisplayCAL on GNU/Linux. Ignace.

[eoyilmaz]

Aah okay, that's good to know. I'm still thinking that we should wait at least for 3 months before Florian returns to me. Actually, if my posts on DisplayCAL forum is considered, the 3 moths period should already have been passed. I can do a final forum post, calling for Florian and then we can go with a new name.

[ignace72]

For the name, it just needs to be not too complicated.

I confirm what has been said above about the GNU GPL. It is a viral license. If a program is a fork of another one under the GNU GPL, it has to keep the same license. So displaycal-py3 has no choice but to stay under the GNU GPL. Ignace.

[eoyilmaz]

Keeping the license as GPLv3 is not a problem for me.

[marillat]

@ignace72

As for the choice of name, some choose to add a suffix to the original name (like LinCity-NG) others choose a completely different name. Personally I don't have a preference, the important thing for me is that it is a project that lasts for a long time, because there is no alternative to DisplayCAL on GNU/Linux. Ignace.

I think renaming displaycal to displaycal-ng is a good idea to avoid problems.

For the record, I was the Debian maintainer for displaycal python2 I'll packages again displaycal python3 but before to be sure, I'll ask debian-legal about the name and the license Otherwise the package can be rejected by Debian.

I'll post the answer of debian-legal here.

Christian

[pabs3]

I'm not a lawyer but I think displaycal-ng (and displaycal-py3) is too similar to displaycal to be safe from claims of trademark infringement.

[Terrobility]

It makes no sense for Florian NOT to put Erkan as the maintainer. We know that Florian is hesitant to give his project away (he wants to keep it), and that he accepts donation money for it too. The only way to keep that going is to have a maintainer so that DisplayCAL keeps getting fresh updates.

The other option is to get Florian to change the license, or to accept someone else handling the project under the DisplayCAL name. This is unlikely though.

Idk why he isn't replying. I'm guessing he's probably overwhelmed. Or maybe he's just abandoned anything DisplayCAL related (but not abandoned taking people's donations 🤷‍♂️). We could always try reaching him another way. Don't give up.

[ignace72]

Good evening, Terrobility. The holder of a GNU/GPL licensed software cannot change the license. The only thing the holder can do is to dual license the software provided the added license is compatible with the GNU/GPL license.

[marillat]

Here is the reply from Francesco Poli in debian-legal list https://lists.debian.org/debian-legal/2022/07/msg00002.html

For me the only problem is the software name.

Well, first of all, I should say that the GNU GPL does not require a
name change for modified/derived/forked versions of a work.
And copyright law does not cover names, as far as I can tell.

Depending on the details of diplayCAL, and on the jurisdiction under
consideration (which may vary across different hypothetical lawsuits,
due to rules for the selection of venue...), trademark laws of a
specific country could impose a name change for a fork.

And anyway, in order to avoid confusion with the original project, I
personally think it would be nice that a fork adopted a distinct name.
Especially if the fork is significantly diverging from the original
project and created without talking to the original developers (because
they do not reply, in the present case, but that doesn't change the
fact that they were not got in touch with...).

I agree with Paul Wise (pabs3) that "diplayCAL-ng" (or
"displayCAL-py3") is probably too similar to the original name to avoid
confusion. You should come up with something more creative (maybe
"FreeScreenCalibrator"? or "calibscreen"?).

By the way, avoiding confusion is the main point of (sane) trademark
laws.

[Terrobility]

I just remembered, Graeme Gill (from ArgyllCMS) is in active contact with Florian. If you try contacting Graeme, I'm sure he can push Florian to get the project sorted out.

[Terrobility]

For me the only problem is the software name.

I agree with Paul Wise (pabs3) that "diplayCAL-ng" (or
"displayCAL-py3") is probably too similar to the original name to avoid
confusion. You should come up with something more creative (maybe
"FreeScreenCalibrator"? or "calibscreen"?).

Thing is, this project is DisplayCAL but updated. Giving it another name would just make it look like a DisplayCAL ripoff which is the last thing we want. Right now it has the same frontend, same GUI, same functionality, but just Py3 support and some new features. So the least it could do is retain some mention of DisplayCAL in the name.

If it was a non-similar name, it would have to be really distinct from DisplayCAL and at that point, you're verging into creating a brand new software entirely. I don't think that's the project's goal.

[ignace72]

The majority of OpenOffice developers made a fork that was called LibreOffice and there was no feeling of a scam. Libre was just preferred to Free to avoid confusion with free: not paying, but to assert Free as the freedoms granted by the free license.

[pabs3]

@ignace72 that isn't entirely correct about the owner not being able to relicense the code. The sole copyright holder (aka owner) of some software they previously released under the GNU GPL can change the license on new versions to whatever they want. The old versions remain released under the GNU GPL. When there are multiple copyright holders of some software, the same thing can happen but every single copyright holder must agree to the license change beforehand.

This situation you are talking about happens when a new person comes along to update an existing GNU GPL project. They can add new code under a different license, or relicense the parts of the code that they own, but they can't relicense parts of the code that they do not own, unless the license for those parts allows relicensing, or if the owner of those parts of the code agreed to the relicensing.

@Terrobility I agree not using a variant of the DisplayCAL name is unfortunate. If there were no trademark, I would normally suggest you keep the DisplayCAL name (without -ng or -py3) for continuity so that users of the old version move to this new continuation of the code, since it is basically the same thing but improved. Like @ignace72 though, I don't think a full change of name indicates a scam, especially since there is a trademark involved and especially if the README of the new project explains the history of the project, including the trademark of the project it was based on.

I hope this is a lesson to you all; if you ever create a new project, as early as possible, make it a multi-contributor project licensed under the GNU GPL to make it harder to relicense it as proprietary and if you register a trademark to protect the name of the project, transfer it to a non-profit fiscal sponsor of the project (such as Software Freedom Conservancy), who will manage it on behalf of the community who will be able to use it for the project.

-- bye, pabs

https://bonedaddy.net/pabs3/

[eeickmeyer]

I hope this is a lesson to you all

Woah there, no need to be condescending. I started this conversation in good faith. There was no malice in this project and it was started in good faith. All good faith efforts are being made and have been made, so please stay out of here with the condescending paternalism.

[pabs3]

I am sorry but I think you may have misinterpreted my message.

I certainly was not implying any malice on behalf of either project nor on behalf of you or anyone else in this thread.

I was only suggesting that there are better ways to do things and that ideally Florian would have done it that way and that if anyone here starts a new project not related to DisplayCAL, that you consider doing things the better way instead.

-- bye, pabs

https://bonedaddy.net/pabs3/

[ignace72]

@pabs3, I checked, there is no obligation to keep the GNU/GPL license but the license MUST be compatible with the GNU/GPL license because this license is viral. https://en.wikipedia.org/wiki/Viral_license. That is, if I understand correctly. But since @eoyilmaz pointed out that keeping the GNU/GPL was fine for him...

[pabs3]

@ignace72 that isn't quite correct. Under copyright law, only the copyright holder can apply a license to their code, or change the license of their code or give permission via the license etc for changing the license of their code. The GNU GPL does not give permission to change the license of their code and it requires all parts of the program to be under the GNU GPL. The other GPL compatible licenses do allow relicensing and so parts licensed under the GPL compatible licenses also have the GPL requirements applied to them. There is some more about this in the GPL FAQ:

https://www.gnu.org/licenses/gpl-faq.html#WhatIsCompatible

As I've been asked to stay away from this issue, this is my last post.

-- bye, pabs

https://bonedaddy.net/pabs3/

[flowerbug]

How about Nextcalibrator? Kind of a play on words calibrator, Excalaber and Next.

[eeickmeyer]

I think Nextcalibrator would be a great name!

[raghu-kamath]

How about

• LibreCalib
• Screencal
• FreeDispCal
• OpenScreencal

[24fpsDaVinci]

assuming DisplayCAL references argyllcms dispcal command, maybe you can call it DispcalGUI or DisplaycalGUI. I think theres people that already call it "DisplaycalGUI"

[ArchangeGabriel]

Actually, dispcalgui was the former name of DisplayCAL: https://sourceforge.net/projects/dispcalgui/