Hi Matthew, At 2024-10-13T12:11:24+0000, Matthew Polk wrote: > I want to in the future sometime, submit a nice macro package I'm > creating to savannah.
Good to hear! I'm curious--do you mean for distribution with groff or
as an independent Savannah project?
> However, can the macro package itself be licensed
With the important caveats that (a) I am not a lawyer and (b) this is
not legal advice, I will offer my lay understanding of the issues.
Every software developer requires some awareness of copyright law to do
their job right, in my opinion.
So to answer in terms of that lay understanding:
Yes. Anything you create and fix in tangible form (say by putting up a
web page or even just storing it to your hard drive, privately) that
manifests your "original expression", in the United States, carries your
copyright.
> and if yes, you must also use the same license like other types of
> programs say python (Where if you import a GPL licensed script, that
> too must be GPL)?
This is a tricky question to answer in generality. Here are a couple of
principles.
1. Your work's use of a programming interface does not cause the
copyright of an implementation of that interface to "stick" to your
work. This principle was most recently upheld at the U.S. Supreme
Court in the notorious Google v. Oracle case.[1]
2. How copyright affects the combination of a work and the APIs it
uses, or the combination of a programming language's compiler or
interpreter with a program in that language, depends on details of
how the combination manifests. The "fixture" of the combination in
"tangible form" is the ground upon which many battles over this
question are fought, and as far as I know there is no definitive
answer under law. Legislators have not bothered to specify the
matter in detail, nor have courts made many precedential rulings in
this area. This ambiguity has stayed stubbornly in place for my
entire career. I suspect it is a sort of stable equilibrium;
resolving the "linking issue" one way or the other could have large
financial consequences to firms that receive revenue predicated on
their copyright monopolies, or who avoid having to pay royalties on
same because their usage thereof is arguably transient. A large
firm will often play both roles, so before they can intelligently
spend money on campaign contributions to get Congress to enact their
will, they have to understand which outcome would put them ahead,
and whether any anticipated windfall would be large enough to make
the risk worth taking. One can't be certain what will happen in a
Congressional conference committee, or what an "originalist" Supreme
Court might decide about the application of copyright to software
given that, at the founding of the United States, the only works
thus protected were "maps", "charts", and "books".[2][3]
It's a Mexican standoff, with every Silicon Valley firm brandishing
its weapons at every other one like strapped hecatoncheires. (Argus
is boggling as we speak.)
That said, a popular interpretation among many Free Software
advocates, some software engineers, and others, is that if a
combination of works exists only "in RAM", it's "transient" and not
"fixed", whereas if the combination is written to long-term storage
(like hard drive platters or an SSD), it _is_ "fixed". Dynamic and
static linking of ELF objects are regarded as examples of each
of these, respectively, and the GNU Lesser General Public License is
written on the presumption that it is a valid interpretation.
So what about your macro package? Well, here I think the application of
the principles tends toward the pretty straightforward. All *roff
formatters known to me are interpreters. The combination of a document,
a macro package supporting that document, and the formatter that
interprets both exists only transiently, as an operating system process
that is born, runs, and dies in a span of a few seconds at most, in the
general case. The output that gets stored to disk is an output format
like PostScript, PDF, or other page description language.
(Occasionally, plain text output is stored.[4])
I am aware of no argument that documents formatted with a *roff system
necessarily carry the copyright of the formatter that prepared them *or*
of any macro packages involved in their production. Part of the reason
is that the original form of the document, and of any macro packages it
used, are utterly unrecoverable from the output format.[5]
With object files like ELF, things are sometimes not to simple. Two
examples of complication are "inline functions" that copy themselves (in
assembled form, of course) to an output binary, and "runtime libraries"
that are present to set up the support environment for the programming
language. (The C language historically obscured appreciation of this
point because, back in PDP-11 days, the C runtime library was so minimal
as to be almost imperceptible. 60 years later that is not quite so
true, and the C runtime is larded with things that disciples of Dennis
Ritchie would deride as "bloat", like `memset`, `memcpy`, and `setjmp`.)
This is why the licenses of the GNU C compiler has codicils like the
"GCC Runtime Library Exception".[6][7]
> It confuses me a bit how the licensing works for the macro package
> rather than the groff sources (C++) themselves.
Right. C++ programs and libraries tend to be compiled and stored
long-term, and are used as object files in combination with other object
files. *roff documents and macro packages are stored in source form, an
interpreted rather than compiled.
> This confusion arises from the license headers in the macro packages,
> much of it says the GPL, but say e.tmac (For the me macro package),
> it's under a permissive license rather than the GPL.
Right. The "LICENSES" file in groff's source repository attempts to
illuminate this.[10]
LICENSES:
Some files are part of groff but bear licenses in addition to the GPL,
or have been placed into the public domain, because they originated
elsewhere; often, the groff project has modified them, sometimes
extensively. These multi-licensed groff components are as follows.
Their file names are not always identical to those in their original
distributions, but we have kept them similar.
...
me macro package
================
"me" uses the BSD "three-clause" license; that is, it is subject to the
advertising clause rescission.
tmac/e.tmac
tmac/groff_me.man
doc/meintro.me
doc/meintro_fr.me
doc/meref.me
> So how does licensing work with macro packages? I want to ensure if I
> must use the GPL to ensure the macro package as well is under the GPL.
As long as you don't copy someone else's copyrightable, GPLed work into
your macro package, there is no reason it has to be under the GPL, as
far as I know.
> I also want to license freely my macro package so anyone can use it.
That's laudable! As long as your work is wholly original then I suspect
there are very few constraints on your choice of license.
Let me know if this helps, or doesn't. And--it should go without
saying--if you expect the answers to these questions to put your money
or your livelihood at stake, you should retain the services of an
attorney licensed in your jurisdiction and competent in copyright law.
Regards,
Branden
[1] https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc.
[2] https://www.arl.org/copyright-timeline/
[3] All this is to say that if Apple, Oracle, Microsoft, et al. want to
ensure that James Madison and Thomas Jefferson had stored-program
digital computers and the Church-Turing thesis clearly in mind when
fighting the British and founding the republic, they'd be well
advised to offer members of the current Supreme Court majority some
swanky vacations.[8][9]
[4] Example: https://github.com/bminor/bash/blob/master/doc/bash.0
[5] Unless someone goes to the explicit trouble of "quining" the
document's own source into the output.
https://git.savannah.gnu.org/cgit/groff.git/tree/contrib/sboxes/sboxes.am?h=1.23.0#n45
[6] One might reasonably wonder whether translation of "higher-level"
programming language source to machine language (commonly via
assembly language) doesn't shed the cloak of copyright as the
internals of a *roff macro package or formatter would when a
document is transformed to output. I don't have an answer. One
could argue that the sorts of code that get inlined during
compilation or are simple enough to put in a runtime (in unambitious
programming languages) don't get scrambled to the point that they
could be meaningfully decompiled. But on the other hand, where
transformation of a piece of code is sufficiently "mechanical" that
it can be reliably reversed, it may also be the most obvious or only
efficient means of getting a particular job done, in which case,
under conventional understandings of copyright, "original
expression" is not possible and thus copyright protection cannot
attach in the first place. This was one of the points which Google
v. Oracle turned.
(I am presuming that a *roff formatter or macro package doesn't take
it upon itself to deliberately inject its own original expression
into the output, say by emitting a macro package author's sonnet.
The analysis would change for that case, but it's a contrived one.
Or maybe not--something like this is behind "digital watermarking"
schemes. Concealing one's copyrighted logo upon which one also
holds a trade mark is a particularly enticing prospect for copyright
rentiers, because you can whack "offenders" with multiple causes of
civil action at once. SLAPP your customers and collect the rent!)
[7] https://www.gnu.org/licenses/gcc-exception-3.1.en.html
[8]
https://www.newsweek.com/scotus-gifts-explained-3-charts-supreme-court-justices-clarence-thomas-1909482
[9] Yes, this is an allusion to the _Bruen_ decision, and more so to its
right-wing champions.
https://en.wikipedia.org/wiki/New_York_State_Rifle_%26_Pistol_Association,_Inc._v._Bruen
[10] https://git.savannah.gnu.org/cgit/groff.git/tree/LICENSES?h=1.23.0#n39
https://git.savannah.gnu.org/cgit/groff.git/tree/LICENSES?h=1.23.0#n115
signature.asc
Description: PGP signature
