Mentioned in SAL (#wikimedia-cloud) [2024-11-08T16:29:56Z] <arturo> add toolforge-standards-comittee as maintainer (T379340)

For clarity, this tool's source code has no obvious declared license. This puts the code in the US default copyright status of the lifetime of the author plus 70 years after their death. The tool itself predates the requirement introduced by Striker that new tools declare a default software license as a defense against this potential problem.

If you want to reimplement the tool (my very naive guess, without ever having seen the tool in action, is that it seems like a manageable task in principle – the existing source code I can see is some 200 lines of Python, 50 lines of CSS, and 120 lines of XML), I think we could still add you to the tool (after removing the old code), so that the rewrite can be reached under the same tool name. I can’t say whether this makes sense or not for this tool (whether a lot of users will want to continue using the same URLs, or whether it would be more confusing to users if a new implementation shows up there). Of course, you can also do a rewrite in a new tool.

In T379340#10305075, @LucasWerkmeister wrote:

If you want to reimplement the tool (my very naive guess, without ever having seen the tool in action, is that it seems like a manageable task in principle – the existing source code I can see is some 200 lines of Python, 50 lines of CSS, and 120 lines of XML), I think we could still add you to the tool (after removing the old code), so that the rewrite can be reached under the same tool name. I can’t say whether this makes sense or not for this tool (whether a lot of users will want to continue using the same URLs, or whether it would be more confusing to users if a new implementation shows up there). Of course, you can also do a rewrite in a new tool.

Hi @LucasWerkmeister, if let say the reimplementation of jawi tool is possible by rewriting the existing code extensively, so that the new code is significantly different, openly licensed, and could be accessed by our Malay Wikipedia community (without any access to the old code), I think it will be very welcomed by everyone of us. This is because our Malay Wikipedia community currently really needs a Rumi-Jawi script converter so that we could convert the Latin script in Malay language (this script is known as "Rumi script") into the Arabic script of Malay language (this script is known as "Jawi script"). If let say the "jawi" name should not be used as the new tool name due to it being copyrighted, perhaps the new tool could be named as "new-jawi".

I was under the impression that the jawi name would be unusable, since usurpation lists adoption as a requirement:

The tool must be adopted by the requesting maintainer following the adoption policy.

But if it's a possible option here and the standards committee will allow it, I think it'd be great. It'll certainly help reduce the confusion of having essentially a deadlink (jawi.toolforge.org) and some jawi2, new-jawi, or jawi-ng version (which editors will have to memorize) that's actively maintained.

@Hakimi97: If you or others from the Malay community need some help on this part, I can provide some engineering support. I think the hardest part of this, though, is the actual translation. Based on the code that @EmpAhmadK sent over back at Wikimania, it seems to be using some black-box binary that also doesn't seem to be open-source (or at least, I can't find the code for it to begin with). So that'll probably have to be rewritten, but I can't help much in that aspect because I'm not fluent in the language.

In T379340#10306182, @Chlod wrote:

@Hakimi97: If you or others from the Malay community need some help on this part, I can provide some engineering support. I think the hardest part of this, though, is the actual translation. Based on the code that @EmpAhmadK sent over back at Wikimania, it seems to be using some black-box binary that also doesn't seem to be open-source (or at least, I can't find the code for it to begin with). So that'll probably have to be rewritten, but I can't help much in that aspect because I'm not fluent in the language.

@Chlod: Yes, our Malay Wikipedia community would really appreciate additional engineering support for the development of Jawi-Rumi script converter. In terms of the logic behind the Rumi-Jawi script actual translation, I (perhaps together with @EmpAhmadK) could facilitate the process, maybe in terms of the development of dictionary-based converter, or even a simpler letter-to-letter converter but with some mechanism so that the letter-to-letter between two scripts could be matched perfectly.

In T379340#10304722, @JJMC89 wrote:

The tool's software is not in compliance with the Cloud Services Terms of use as it is not licensed under an OSI approved Open Software license. Only @Aviator can fix this.

In T379340#10304795, @bd808 wrote:

For clarity, this tool's source code has no obvious declared license. This puts the code in the US default copyright status of the lifetime of the author plus 70 years after their death. The tool itself predates the requirement introduced by Striker that new tools declare a default software license as a defense against this potential problem.

@JJMC89 @bd808: I am not sure whether this is valid/relevant or not but I noticed that @Aviator did mention that the jawi tool "is licensed under GPL". The link for reference is as below:

https://wikitech.wikimedia.org/w/index.php?title=Nova_Resource:Tools/Access_Request/Aviator&oldid=123631

Aviator here. The tool is indeed licensed under GPL. As for the binary, it was compiled from my own code that is written in C++ or Rust (I can't remember but I can dig my old files). I intended it to be in GPL as well. I just never released the source code.

Let me know if I should publish the code to ease the tool adoption process.

In T379340#10306370, @Aviator wrote:

Aviator here. The tool is indeed licensed under GPL. As for the binary, it was compiled from my own code that is written in C++ or Rust (I can't remember but I can dig my old files). I intended it to be in GPL as well. I just never released the source code.

Let me know if I should publish the code to ease the tool adoption process.

Hi @Aviator, we would really appreciate if you could add toolinfo description for the source code and license using the format like the following example:
https://toolsadmin.wikimedia.org/tools/id/svgtranslate

In T379340#10306370, @Aviator wrote:

Aviator here. The tool is indeed licensed under GPL. As for the binary, it was compiled from my own code that is written in C++ or Rust (I can't remember but I can dig my old files). I intended it to be in GPL as well. I just never released the source code.

Let me know if I should publish the code to ease the tool adoption process.

Welcome back, it’s great to see you :) yes, it would be great to publish the source code. You should be able to create a GitLab repository at https://toolsadmin.wikimedia.org/tools/id/jawi (after logging in with your Wikitech credentials¹), but you can also use GitHub or some other platform if you like. Please let us know if you encounter any issues.

(¹ Wikitech is actually becoming a SUL wiki, but you still log into toolsadmin with whatever your Wikitech username and password was, even if you already merged the wiki’s account with SUL in the meantime.)

In T379340#10306370, @Aviator wrote:

Let me know if I should publish the code to ease the tool adoption process.

Welcome back! Others have pointed you towards ideas about publishing the code with a proper license. You can also choose to add @Hakimi97 as a co-maintainer of the tool yourself via https://toolsadmin.wikimedia.org/tools/id/jawi/maintainers/ which gets rid of all of the constraints about how the adoption policy would apply to the Toolforge Standards Committee adding them without your explicit consent.

Hi @bd808 and @JJMC89, it has been 34 days since the last response from @Aviator. @Aviator has updated the license information to the GNU General Public License 3.0 or later. Is it possible for the adoption process to continue by adding me as co-maintainer?

Ping back @bd808 and @JJMC89 since the last response.

In T379340#10402199, @Hakimi97 wrote:

Is it possible for the adoption process to continue by adding me as co-maintainer?

I think so, yes… the policy only requires that the current maintainer(s) didn’t object (not that they stayed inactive), and if anything, I read this as an approval of the adoption:

In T379340#10306370, @Aviator wrote:

Let me know if I should publish the code to ease the tool adoption process.

Mentioned in SAL (#wikimedia-cloud) [2025-04-12T17:47:32Z] <lucaswerkmeister> add Hakimi97 to maintainers and remove toolforge-standards-committee (T379340)