|
|
Subscribe / Log in / New account

AlmaLinux's response to Red Hat's policy change

AlmaLinux's response to Red Hat's policy change

Posted Jun 30, 2023 0:11 UTC (Fri) by anselm (subscriber, #2796)
In reply to: AlmaLinux's response to Red Hat's policy change by pizza
Parent article: AlmaLinux's response to Red Hat's policy change

Because if they weren't, how could the GPL place conditions upon distributing binaries that you compiled yourself?

That's easy. As far as the GPL is concerned, the source code and the binary represent the same work. Since distributing the work is something that normally, as per copyright law, only the original copyright holder gets to do, the copyright holder – through the GPL – says that as a special gracious exception it's OK for you to distribute the work (in source or binary form) only under certain conditions, which are slightly different for binaries vs. source.

Once more, the object code cannot be a “derived work” of the source code, because works can only be produced by human authors. Monkeys don't qualify, and compilers certainly don't qualify. The thing about “translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation,” etc. is that in all of these a certain amount of creativity and original thought, by humans, is at play. In addition, as you quoted, “A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a ‘derivative work.’” (emphasis mine) – but compilers do not create “original works of authorship”; instead they perform a mindless sequence of uncreative, predetermined steps in order to make the source code of the work executable on a computer. Even if you performed the same sequence of steps yourself, as a human, this would change nothing because the compilation steps are not “editorial” – there is no creativity or authorship involved. Hence there is no way in which the executable could be considered a “derivative work” of the source code because it fails the most basic tests of what makes something a “work”, plus it isn't “derivative” in the sense prescribed by copyright law.


to post comments

AlmaLinux's response to Red Hat's policy change

Posted Jun 30, 2023 1:20 UTC (Fri) by pizza (subscriber, #46) [Link] (6 responses)

> That's easy. As far as the GPL is concerned, the source code and the binary represent the same work.

They are not the same work; the binary is derived from the source code via a transformative means, ie compiling it.

Consider that a compiled program nearly always includes not just the result of the source code, but 3rd party bits generated or inserted by the compiler. This compiled program is therefore a combination of, and thus derived from, at least two independent works.

This notion of "executables derived from the compiler" is why libgcc, nominally under the GPL, includes an explicit permissive grant to make it clear that binaries resulting from combining your compiled source code with libgcc does not make the result fall under the GPL. [1]

Or are you going to claim that a binary containing bits from your code and bits from libgcc is not somehow derived from both sources?

That said, one can make a reasonable argument that the mechanical transformation process of compilation constitutes fair use [2] of the source code. But to claim fair use you have to concede that what you did was otherwise infringing (ie not permitted by the copyright holder).

Since the GPL excplitly places no restrictions on "use", only distribution, this distinction is moot. However, the FOPL text specifically calls out creating derivatives as something that has field-of-use restrictions.

[1] https://www.gnu.org/licenses/gcc-exception-3.1.en.html
[2] One prong of the four-part fair use test [3] is "Transformative uses are those that add something new, with a further purpose or different character, and do not substitute for the original use of the work."
[3] https://www.lib.purdue.edu/uco/fair-use

AlmaLinux's response to Red Hat's policy change

Posted Jun 30, 2023 7:06 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

> > That's easy. As far as the GPL is concerned, the source code and the binary represent the same work.

> They are not the same work; the binary is derived from the source code via a transformative means, ie compiling it.

But, legally, (because mathematically,) they are the same thing!

When you walk into a maths exam, you are given a question paper. Before you leave, you hand in an answer paper. Legally, as far as the law is concerned, their questions and your answers are THE SAME WORK (barring your mistakes, which are your creative input :-)

A binary bears the same relationship to the source as your answers do to their questions.

Cheers,
Wol

AlmaLinux's response to Red Hat's policy change

Posted Jun 30, 2023 11:51 UTC (Fri) by pizza (subscriber, #46) [Link]

> But, legally, (because mathematically,) they are the same thing!

Source code is rarely purely functional/mathematical, so "mathematically equivalent" isn't "the same thing".

AlmaLinux's response to Red Hat's policy change

Posted Jun 30, 2023 9:29 UTC (Fri) by paulj (subscriber, #341) [Link] (2 responses)

No offence, but have you confused "transformative use" - which implies the addition of some human creativity - with "mechanical transformation"?

ICBW, but I really did think that it had been established that the binary form of some compiled (as in computer software compiler - not copyright compilation ;) ) software was the /same/ work as any source it was compiled from. This was /not/ originally the case in the early days of software and copyright, IIUC, but then the courts brought in this notion that mechanical transformation (i.e. computer compilation) did not create a new work, but rather the output was the same work.

AlmaLinux's response to Red Hat's policy change

Posted Jun 30, 2023 9:31 UTC (Fri) by paulj (subscriber, #341) [Link] (1 responses)

Oh, on the compiler thing - as I mentioned above - the binary may have constructs and even library code inserted from the compiler. So the binary may well be deriving from the compiler (but compiler licenses usually make it clear there are no restrictions, so this is not relevant to the discussion). However, the portions of the work that are directly translated from the source are just... the same work. (IMU)

AlmaLinux's response to Red Hat's policy change

Posted Jun 30, 2023 12:06 UTC (Fri) by pizza (subscriber, #46) [Link]

You're correct; I was considering the output of the compiler to be a "derived work" when it should probably be considered a "combined work" containing elements of the original source, bits of the compiler's runtime library, a bunch of OS-specific metadata, and more.

That said, creating that "combined work" is still something disallowed by copyright unless you have permission to do so.

AlmaLinux's response to Red Hat's policy change

Posted Jun 30, 2023 9:30 UTC (Fri) by anselm (subscriber, #2796) [Link]

You obviously don't read what I write.

The executable can't be a “derived work” of the source code because it does not even qualify as a separate work in the first place. A “work” in the sense of copyright law must have a human author and its production must involve a certain minimum amount of original, bespoke creativity. Neither of these preconditions are satisfied by compiler output, which is produced from the source code by a machine (not a human) following a series of rote instructions (which leave no room for originality). As far as copyright law is concerned, the source code of a work and the corresponding binary code are the same thing. The relationship between the source code and the executable is like that between the printed text of a novel and the text of the same novel converted to Braille.

The sort of “derived work” you're thinking about arises, e.g., if a script writer turns a novel into a motion-picture script, or a translator translates an English novel into French. In both these cases, a human being comes up with a separate (but derived) “work”, presumably expending significant creativity in the process, and this is completely different from what a compiler does with source code.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds