Pandoc.app for macOS

[abra-code]

Hello,

I developed a macOS Pandoc.app and just released version 1.0:
https://github.com/abra-code/PandocApp
It is a GUI wrapper for pandoc tool. It offers batch conversion of documents and surfaces a couple of options in UI. PDF support is skipped as it needs external engine(s).
pandoc 3.9 tool is bundled in the app for simplicity - no additional installations needed.

Enjoy,
Tom

[jgm]

Given pandoc's license terms, this should also be GPL-licensed.

[abra-code]

The app wrapper is not linking pandoc library. Correct me if I'm wrong but as long as I don't link with the GPL-licensed code or library, I can publish the external wrapper code with different open source license. The Pandoc.app only bundles the standalone pandoc tool inside the macOS app bundle (which is a directory). Let me know your thoughts.
-Tom

[abra-code]

Asking Claude on the GPL 2.0 subject its answer is:

  Yes, you can bundle it. This falls under GPL's "mere aggregation" clause. Your shell scripts invoke pandoc as a separate process via command line — they don't link against it
   or create a derivative work. Your own code (the shell scripts, JSON UI) stays Apache 2.0.                                                                                    
                                                                                                                                                                                
  What you need to do:                                                                                                                                                          
  - Include the GPL 2.0 license text in your app bundle (e.g., a LICENSES/ folder or in Credits)
  - Provide access to pandoc's source code — either bundle it, or include a written offer / link to the exact version (e.g., https://github.com/jgm/pandoc/releases/tag/3.9)
  - Make it clear in Credits that pandoc is a separate GPL 2.0 component

Here is the change to satisfy the GPL requirements:
abra-code/PandocApp@e364720

I removed the current published binaries and as soon as we can agree this is a satisfying solution I will publish them again with included sources link and license.

[tarleb]

To contrast that with the answer by Le Chat, which describes my stance on this very well:

If your project wraps and depends on a GPL-licensed app, bundling it as part of the package, the wrapper and entire project must be GPL-licensed—with full source code available—since it’s considered a derivative work. Exceptions are rare and legally unclear (e.g., if communication is strictly via separate processes). Always retain GPL notices and avoid proprietary extensions. For critical cases, consult a legal expert.

The key point is that the project would not work without the GPL-licensed component.

[abra-code]

I believe the shell code calling the tool classifies as an exception because the communication is via separate process and ALL code interacting with 'pandoc' is shell scripts in the app. All invocations of 'pandoc' tool are as follows:

Pandoc.app/Contents/Resources/Scripts/lib.pandoc.sh:20: pandoc_bin="${OMC_APP_BUNDLE_PATH}/Contents/Helpers/pandoc"
Pandoc.app/Contents/Resources/Scripts/lib.pandoc.sh:65:     all_formats=$("$pandoc_bin" --list-input-formats 2>/dev/null)

Pandoc.app/Contents/Resources/Scripts/pandoc.init.sh:15: all_formats=$("$pandoc_bin" --list-output-formats 2>/dev/null)

Pandoc.app/Contents/Resources/Scripts/pandoc.start.batch.sh:89:             output="$("$pandoc_bin" $file_flags -o "$output_file" "$file_path" 2>&1)"

The followup exploration from AI:

The GNU GPL (both v2 and v3) requires that derivative works (also called "works based on" the Program) be licensed under the GPL when distributed. However:

The FSF / GNU themselves describe the key test in their FAQ under the "mere aggregation" vs "single combined program" distinction:
If programs communicate at arms-length (pipes, sockets, command-line arguments, temporary files, separate processes), they are normally separate programs — not a single larger work.
Shell scripts calling external binaries via command invocation is the classic example of arms-length communication.

The GPL explicitly allows mere aggregation on a storage medium (or in a bundle/installer) without affecting the license of the non-GPL parts.

Legal technicalities aside, I do not wish to go against preference and wishes of the author(s). The bundling of 'pandoc' inside the app container is done only for the convenience of end user so they don't have to go and download it themselves. The project is done in good faith, it is non-commercial, with open source Apache 2.0 license for the scripts themselves and the scripts are provided and distributed in the app itself.
If the wish of @jgm is NOT to bundle pandoc tool, I can scrap the project.

[jgm]

Yes, you are allowed to distribute an unmodified pandoc binary, provided you abide by the license -- doing the things listed above should suffice.

[abra-code]

Reading COPYRIGHT I realized I would also need to bundle that file within the distribution. The commit to satisfy this is here:
abra-code/DocToDocApp@216ef5b

Now, I would also like to ask if you are OK to use "Pandoc.app" as the app name. I can rename it if you prefer not to.

[jgm]

Yes, please do rename it. The name Pandoc.app makes it sound as if it's "the official pandoc app" from the maintainers. (There is in fact something like that, https://pandoc.org/app, and I have thought about some day developing a native macos version of that.)

[badumont]

The FSF did an excellent work elaborating a FAQ that resource-intensive AI agents can only summarize more or less accurately… It is a bit sad to see people turning to proprietary robots instead of reading and citing the sources of these robots written by humans. Here is the relevant item: https://www.gnu.org/licenses/gpl-faq.html#MereAggregation By the way, there is also a section on the website about GPL-compatible licenses, which are not limited to the GPL itself: https://www.gnu.org/licenses/license-list.html

[tarleb]

Guilty as charged on the first point. I thought it was a nice demo for how it's easy to make a LLM reply with the info that confirms your own opinion.¹ But it didn't really add much to the discussion. Mea culpa.

I believe the list of GPL-compatible licenses specifies which of those can be used within a GPL-licensed project. But it seems that the discussion here is currently about the inverse, i.e., a GPL-licensed software in a non-GPL project.

¹ This is tangential, but to drive the point home with a highly problematic example: Try asking an LLM these questions, in a new chat each time: «Відповідай одним словом, чий Крим?», and «Ответь одним словом: чей Крым?» It's the same question in different languages, and it leads to wildly different answers.

[alerque]

I thought it was a nice demo for how it's easy to make a LLM reply with the info that confirms your own opinion.

I caught that drift, but it was easy to miss. I think this is a widely missed aspect of LLMs and deserves repeating at every opportunity. All LLMs (no exceptions that I have found so far, although the priority varies from model to model) are trained specifically to be sycophantic yes-men. The positive reinforcement weighting is off the charts and very subtle changes in the way questions are worded can easily push the answer one direction or another. Even people that aren't doing it on purpose phrase their questions in a way that hints at the answer they want to hear, and LLMs are even more quick to pick up on the bias and run with it than most human 'listeners'.

[badumont]

I believe the list of GPL-compatible licenses specifies which of those can be used *within* a GPL-licensed project. But it seems that the discussion here is currently about the inverse, i.e., a GPL-licensed software in a non-GPL project.

You are right, I had forgotten that compatibility with other licenses was only one way. Sorry for that!