AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
Posted Jun 29, 2023 8:30 UTC (Thu) by milesrout (subscriber, #126894)In reply to: AlmaLinux's response to Red Hat's policy change by paulj
Parent article: AlmaLinux's response to Red Hat's policy change
But the whole point of the GPL is to allow users that get binaries to get source code, but to still allow companies like Red Hat to do exactly what they're doing. This isn't unintended.
> I.e., the ability to discharge source distribution requirements of the GPL by distributing /only/ to those you've given binaries to in the GPL is anachronistic and needs to be removed. It dates from a time when Internet access was not universal, and even when available could be very expensive.
It has nothing to do with the Internet. It's an intentional choice by GNU, designed to create a copyleft software licence that gives *users* of the software freedom. Not general access to source to everyone. Source code access to people that use the binaries. That's crucial! Why would someone that doesn't have access to software binaries need to have any access to the source code?
Posted Jun 29, 2023 8:50 UTC (Thu)
by paulj (subscriber, #341)
[Link] (39 responses)
The GPL was indeed structured to require that recipients of modified Free Software would receive or could obtain the modifications, and allow them to redistribute onwards - encouraging the spread.
As explained, the world has moved on. We have cloud companies and companies using restrictive side-contracts, who have figured out how to effectively make their modifications be lost to the rest of society. Their engineers and their customers can not (effectively) pass these modifications on.
Just as the world evolves, so can - and should - copyleft, to *CONTINUE* to serve that aim that RMS had.
Posted Jun 29, 2023 13:12 UTC (Thu)
by pizza (subscriber, #46)
[Link] (38 responses)
Still, requirements to force these cloud companies (etc) to make all source available will also bite everyone else -- Will I have to make all corresponding sources publicly available to the world because I'm using some copyleftplus software to process photos on my laptop? Will everyone running a Debian server behind their home/business/enterprise firewall be effectively forced to maintain their own public source mirror that the world+dog can access?
Requiring source distribution to "the world" regardless of the scope of binary distribution or scope of use is completely impractical. And I should point out that any scope-of-use restrictions run smack into "Freedom Zero".
Far smarter people than I have tried to come up with a solution to this and failed, badly.
Posted Jun 29, 2023 15:25 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (1 responses)
We need to stop doing business with these people, too.
Cheers,
Posted Jun 29, 2023 15:49 UTC (Thu)
by paulj (subscriber, #341)
[Link]
People will choose the licences they believe work best for them.
Note: The same person may choose permissive for one work, and strong copyleft [as intended with FOPL] for another work.
Posted Jun 29, 2023 15:42 UTC (Thu)
by paulj (subscriber, #341)
[Link] (35 responses)
There is no such requirement simply through use.
Posted Jun 29, 2023 17:34 UTC (Thu)
by pizza (subscriber, #46)
[Link] (34 responses)
And I quote:
"Deploy means to use, sublicense or distribute Covered Software other than for Your internal research and development (R&D) and/or Personal Use, and includes without limitation, any and all internal use or distribution of Covered Software within Your business or organization, except for R&D use and/or Personal Use, as well as direct or indirect sublicensing or distribution of Covered Software by You to any third party in any form or manner."
So, yeah, those requirements are triggered simply through "use". Trying to put exceptions for certian kinds of "use" makes that intention abundantly clear.
Posted Jun 29, 2023 19:02 UTC (Thu)
by paulj (subscriber, #341)
[Link] (33 responses)
The examples you gave did not imply modification:
"I'm using some copyleftplus software to process photos on my laptop? Will everyone running a Debian server behind their home/business/enterprise firewall be effectively forced to maintain their own public source mirror that the world+dog can access?"
The vast majority of Debian users havn't modified it, nor have most users of photo software.
My reply was in the context of your examples and, no, everyone running Debian would NOT have to also maintain a mirror.
Posted Jun 29, 2023 19:32 UTC (Thu)
by pizza (subscriber, #46)
[Link] (17 responses)
*compilation* counts as modification, because it's "creating a derivative work". And that license text states that a "Modifications means the Source Code and Executable form of any of the following: [...] B. Any new work that is based on, adapted from, or deriving of the Original Software or previous Modifications."
So, if I compile the software and use it, I have to publish the sources publicly. However, if I obtain the compiled binary from someone else (eg Debian), I don't have to publish the sources.
....It turns out that writing a license is really tricky!
Posted Jun 29, 2023 19:50 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link]
Posted Jun 29, 2023 20:08 UTC (Thu)
by paulj (subscriber, #341)
[Link] (4 responses)
So my understanding was the compilation does not result in a binary that is a derived work. The binary _is_ the work (deriving from the compiler too perhaps, but...). But ICBW.
Regardless, changing the wording to make the intent - deploying or distributing unmodified code shouldn't trigger source distribution requirement - clear would be good.
Thanks.
Posted Jul 2, 2023 16:43 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
What about a compiler with a builtin `-Dsome_internal_function=some_other_internal_function` definition (or similar)? The source isn't modified, but the interpretation is.
Posted Jul 3, 2023 10:49 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (2 responses)
Note that you have a potential loophole any time I can distribute a binary without source, where I can play a shell game to ensure that the entities you can pursue for damages don't deploy or distribute modified code, and the entity that modifies code stops existing the moment you try to get hold of the modified code.
If, instead, you put an obligation on all distributors of binaries to ensure source is available (similar to the one I've drafted in this pull request to your FOPL repo), then the loophole is closed. Note, too, that "ensure source is available" does not necessarily require you to host source yourself - if you get a binary from Debian, and you trust Debian to keep source available indefinitely, then you can rely on that safely. Similarly, in a commercial situation, you can pay Collabora to keep hosting source for the binary they gave you until 2 years after you stop using the binary, and thus not have a problem.
Where it gets murky is when binaries are being passed around between individuals - if I die unexpectedly, then sources I'm hosting may go offline. If you're depending on me to host source for a binary that I created as a modification of someone else's source code, and my hosting goes offline, you're now in a problem case - you may not even have bothered to get a copy of the source before the offlining event. But this is somewhere where I'd consider it reasonable to rely on the discretion of the licensors if it happened, since it's a rare case.
Posted Jul 3, 2023 12:03 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (1 responses)
So if they do modify source, they're under pressure to upstream it :-)
Cheers,
Posted Jul 3, 2023 12:43 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
Then you get into the problem of defining "upstream source" sufficiently well to avoid the shell game, without other unintended consequences.
The shell game has party A modify the source, and distribute binaries. Party B gets source and binaries from A, and passes on an unmodified binary to party C. Party C is now in a position to claim that as far as they know, they're distributing binaries from unmodified upstream source; this is backed by an affidavit from party B that they are distributing the binary as supplied to them by party A.
You find out that party C is distributing a binary that doesn't match your source, and start the enforcement process; party C notifies party B who notifies party A, causing party A to be wound up by its owner. Now you have a problem - party C does not have source, but is distributing a binary that's unmodified from the sources party A published (but has stopped publishing now they're out of business). Party B has source, so can seed a new party A, but you've run out of enforcement options, since party B can also prove that they distributed a binary built from unmodified sources from A, and thus they do not have a requirement to publish source, either. Party A does have an obligation to publish their sources, but they no longer exist, so you can't enforce against them.
This is why I've proposed an "ensure people can get the source" requirement, instead of a "distribute sources" requirement - C is then requirement to make sure that people can get the source, but if A is distributing sources, then C meets their requirements by pointing to A's distribution, for as long as A continues to distribute. If A stops distributing, C can't do that any more, and has to find a new way to meet their obligations.
Posted Jun 29, 2023 22:19 UTC (Thu)
by anselm (subscriber, #2796)
[Link] (10 responses)
That's what you say. The GPL, for example, seems to disagree – it talks about “the Program”, either “the Program's source code” or “the Program in object code or executable form”. This makes it clear that to the FSF at least, the source code and executable both represent the same work. Copyright law says that only “original works of authorship” are eligible for copyright, and a compiler isn't an author and does not produce original results (its output is algorithmically determined by its input), so compiling some source code does not make the resulting object code or executable a separately copyrightable work – if the executable is eligible for copyright at all, then only through its corresponding source code.
According to the GPL, a “work based on the Program” is “either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language” – where, given the previous paragraph, “another language” presumably means “source code language”: If the Program is in C and you (as a human author exercising creativity) rewrote it in Rust, for example, you'd be creating a “work based on the Program” that would still fall under the GPL because it is derived from the original C code.
Posted Jun 29, 2023 22:49 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Jun 29, 2023 23:36 UTC (Thu)
by pizza (subscriber, #46)
[Link] (8 responses)
A “derivative work” is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. 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.”
( 17 U.S.C § 101 -- https://www.law.cornell.edu/uscode/text/17/101 )
While I'm sure that definition has been heavily augmented by case law over the years, I don't think anyone could seriously argue that compilation isn't "transformation" or "adaptation" of the source code into executable. But while that (algorithmic and deterministic) transformative compilation creates a derivative of the original work, I agree that it won't meet the creativity threshold for that derived work to become independently copyrightable.
If you think about it, this makes complete sense, and the likes of the GPL relies on the fact that binaries are derivative works of the source code. Because if they weren't, how could the GPL place conditions upon distributing binaries that you compiled yourself?
Posted Jun 30, 2023 0:11 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (7 responses)
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.
Posted Jun 30, 2023 1:20 UTC (Fri)
by pizza (subscriber, #46)
[Link] (6 responses)
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
Posted Jun 30, 2023 7:06 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (1 responses)
> 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,
Posted Jun 30, 2023 11:51 UTC (Fri)
by pizza (subscriber, #46)
[Link]
Source code is rarely purely functional/mathematical, so "mathematically equivalent" isn't "the same thing".
Posted Jun 30, 2023 9:29 UTC (Fri)
by paulj (subscriber, #341)
[Link] (2 responses)
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.
Posted Jun 30, 2023 9:31 UTC (Fri)
by paulj (subscriber, #341)
[Link] (1 responses)
Posted Jun 30, 2023 12:06 UTC (Fri)
by pizza (subscriber, #46)
[Link]
That said, creating that "combined work" is still something disallowed by copyright unless you have permission to do so.
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.
Posted Jun 29, 2023 20:43 UTC (Thu)
by pizza (subscriber, #46)
[Link] (14 responses)
*compilation*, by virtue of creating a derivative work [1], counts as modification, due to this clause: "Modifications means the Source Code and Executable form of any of the following: [...] B. Any new work that is based on, adapted from, or deriving of the Original Software or previous Modifications."
So, if I compile the software and use it, I have to publish the sources publicly. However, you are correct that if I obtain the compiled binary from someone else (eg Debian), I don't have to publish the sources.
....It turns out that writing a license is really tricky!
[1] According to US copyright law, at least.
Posted Jun 29, 2023 21:22 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (13 responses)
And note that there's a loophole lurking here that we definitely want closed: Person A distributes source publicly until they cease to exist. Person B receives a binary from Person A, and forwards it to Person C unmodified, which does not trigger obligations on Person B or Person C. Person A and Person B then turn out to be subsidiary companies of a bigco, which are promptly dissolved.
Hey presto! I have a binary, built from modified sources, where the entity that breached the licence no longer exists to be pursued for copyright infringement, and where the two entities that do still exist and handled it. As Person C still exists, they can distribute the binary, since they haven't modified it, but they don't have the sources.
Yet more reasons to get a lawyer's help.
Posted Jun 30, 2023 9:42 UTC (Fri)
by paulj (subscriber, #341)
[Link] (12 responses)
An entity disappearing is a "loophole" for the GPL 3 year offer as much as for the FOPL. To fix that would require a condition to deposit changes with some specified custodian entity/entities.
Further, it's not really a loophole to worry about. The companies who are trying to (effectively) proprietise copyleft software modifications, do so as part of building some other longer-term business - e.g. a support or consulting business, or cloud. There is for the support/consulting model an explicit leveraging of /future/ relationship status. Such an entity can not avail of a loophole that involves shutting itself down.
Generally, companies trying to restrict their modifications to copyleft software are invested in future revenue from the capital they have invested into making those modifications, and so that isn't really a loophole of use to them, AFAICS.
Posted Jun 30, 2023 10:06 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (11 responses)
That loophole doesn't exist for the GPL 3 year offer, because each entity in the chain is required to provide sources themselves; if Person A disappears, then Person B and Person C are still on the hook for the sources if they distribute a binary. regardless of its modification status.
And the reason it's a problem is that, per the terms of the licence as you've described them, neither Person B nor Person C have to distribute the modified source, even if they possess it, while Person A does have that obligation, but no longer exists for you to enforce against. Person B exists basically so that when you chase Person C for compliance, there's someone who can pass on the sources they got from Person A (but do not have to share) to a new Person D, who takes the place of Person A in the loophole. Rinse, wash, repeat - Person C never shuts down and never has the sources to the binary they pass on, and is running the long term business. Person B exists solely to put Person C in the position of always simply passing on an unmodified binary and never actually having the sources themselves. Person A gets replaced every time there's an attempt to enforce compliance, and the new Person A is seeded by Person B with the modified sources obtained by Person B from the previous Person A.
The result is that I have Person C, who exists long-term, and supports the business case, but who never even has the sources to the modified binary. Person A gets closed down whenever there's a chance that they'll be asked where the sources are, and Person B can honestly say that they're passing on an unmodified binary from Person A to Person C, who distributes it widely. The company that owns all of A, B and C has the sources, including modifications, but you have no practical way to get at those modifications, since the entity doing the modification (and hence with the obligation to publish) stops existing when you try to get the modified sources, and is replaced by a new entity in the shell game
This is why the GPL says that if you pass on a binary, you also acquire obligations to pass on the source code to the people you give the binary to - in the same scenario, Person C has an obligation to pass sources onto you, and thus the fact that Person A has vanished with the sources just puts Person C in a position where they can't distribute the binary at all (modified or not).
Posted Jun 30, 2023 10:40 UTC (Fri)
by paulj (subscriber, #341)
[Link] (10 responses)
So what you're describing is some nefarious distributor of copyleft software, C. C has customers who come along needing modifications to copyleft software.
C has somehow arranged some hidden party to do this modification work for them, via a series of never-ending shell-companies, A_1, ..., A_n. So for customer D_i of C, needing some modification, C somehow arranges for A_i to implement this modification and pass only the /binary/ on to C along with a source offer from A_i, to give to D_i. A_i is then legally collapsed.
How does C induce this hidden party to do this, without any commercial obligation? How does the source code, containing all the modifications to the copyleft software made by A_1, ..., A_i get passed on to A_{i+1}, legally?
I don't see how the GPL prevents this either. Either C availed of 3c (GPLv2), in which case there can be no commercial relationship between B and C or C and D_i, or else C has an obligation themselves to distribute the source - and it's C's problem if they don't have it.
Further, aren't courts well capable of looking through corporate structures and examining the controlling interests? If the same controlling interest is there in A, B and C, well...
Posted Jun 30, 2023 11:08 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (9 responses)
No, I said that in your description of how your licensing offer works, no source obligation falls on B or C. Under the GPLv2 (and v3), both B and C have obligations to provide source since they're providing a binary - and provision of a binary in the GPL is enough to trigger the obligation to provide source.
There is a commercial relationship between A_j, B and C. Only A_x does modifications, and thus, under the terms you've described, only A_x is obligated to publish source code. B gets a binary from A_x with matching source, and is thus able to seed A_x+1 with source when A_x is collapsed. C only gets a binary from B, which was built by A_x.
When a customer of C wants changes made, C relays this to A_m, A_m makes the changes, gives B source and binary. B gives C a binary, which C gives to the customer. Because, under your scheme (but not the GPL) C hasn't modified the sources (indeed, C doesn't have sources to modify), they don't have an obligation to publish or provide sources at all. Under the GPLv2, they'd have to use 3a or 3b, because it's commercial distribution.
And the courts need a reason to "pierce the corporate veil"; if I tried to play this scheme under GPLv2 terms, with C saying they can't provide sources as required by 3a or 3b because B didn't provide source, that's enough for the courts to look at the ownership relationship and deem B and C to be the "same entity" for the purposes of this litigation (and thus require B to disclose source to me directly); in contrast, if C is claiming to not have published sources because it's shipping an unmodified binary it got from B, and B is claiming not to have published sources because it's shipping an unmodified binary it got from A_z, neither B nor C has breached the licence terms, and thus there's no reason to go deeper. The fact that A_z no longer exists (but there's now an A_f filling the same place in the shell game) means that the trail ended with "A_z were obligated to publish sources for 3 years, and did for as long as they existed. A_z no longer exists, so you cannot get compensation from them for their breach, which in any case happened after they were wound up."
Posted Jun 30, 2023 11:48 UTC (Fri)
by paulj (subscriber, #341)
[Link] (8 responses)
The simple answer here is that the definition of "You" and "Your" (i.e. the licensee) in the FOPL would consider A, B, and C to all be one and the same, if they have or are part of the same controlling entity, be that by ownership, management direction, or contractual obligations. The license is granted to one and all, and the obligations extend to one and all the same, or to none.
Further, there is no exception in the FOPL for non-commercial distribution. If you distribute, you must ensure the recipient is informed as to how to get the source code "in a reasonable manner on or through a medium customarily used for software exchange." - while the distributor /could/ point the recipient to a convenient other party providing the source, the /obligation/ remains on the distributor. Your Modifications you must publicly distribute yourself though (and "Your" would consider A,B,C one and the same - so A dissolving doesn't absolve C, cause C has common owners and/or contracts in place with those holding the source).
Maybe the text can be made more robust, suggestions definitely welcome.
Posted Jun 30, 2023 12:49 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (7 responses)
This is one where I'd definitely want a lawyer involved - by my understanding of your definition, if I paid Red Hat to provide me software, then I could end up being "one and the same" with Red Hat because the contractual obligations make us "the same controlling entity".
If the requirement is simply that I must make sure that the source for the binary I am distributing is published in a suitable public location for a minimum of 3 years from the date on which I distribute the binary, regardless of whether I modified it or not, then that's simple - if, in my shell game, Person C tries to claim that they can't do that, then Person C is infringing, and that's the lever needed to have the court open up the entire shell game.
If you try to allow wiggle room for someone who distributes an unmodified binary to not also be on the hook for the source, you open up a loophole. If my obligations are the same whether it's unmodified or modified, but they're limited to "ensuring that the source is published for a period of time", then the loophole closes.
Posted Jun 30, 2023 13:11 UTC (Fri)
by paulj (subscriber, #341)
[Link] (6 responses)
If you distribute a work under the FOPL (whatever form), you must ensure the Source Code is made available too to recipients. Potentially you can refer to someone else's distribution of the same Source Code, so far as is reasonable - the obligation towards the recipients you've distributed to is on you though. If the Source Code you referred to was hosted by someone else, and they go away, you'd better have somewhere else to point to or made a copy. (Would be my reading). There is no explicit limitation on duration, it comes down to reasonableness.
The obligation to publicly make available Modifications that you Deploy (deployed to production, or distributed) explicitly extends to 24 months.
Posted Jun 30, 2023 14:02 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (5 responses)
Talking about "control" over Red Hat is a difficult one to pin down - if I pay Red Hat for support, is that sufficient to give me "control", given that I can use my subscription to direct Red Hat to work on a specific problem for me?
It gets more complex with a consultancy like Collabora, too - I can pay them to work on any OSS problem, pretty much.
Depending on "reasonableness" for duration is also dangerous; you run the risk that one court rules that it's unreasonable for you personally to have taken down your mirror of source code 25 years after you last distributed a binary, because you should reasonably have known that BigCo depended on that mirror to meet their compliance requirements, while a different court rules that it's unreasonable to expect BigCo to keep their mirror up for more than the minimum specified time after deploying to production, since they've deleted the service that used the binary.
Also note that your reading doesn't matter, as the granter of a licence; if a licence is unclear, then in many jurisdictions, the courts are supposed to interpret it in favour of the person relying on it, not you. You need the licence text to be clear, so that the court has only one interpretation to choose from
I would, personally, change it to say that if you distribute or Deploy a binary, you must ensure that the "corresponding Source Code" (to steal language from the GPLv2) is publicly available for a minimum of 24 months after the last distribution or the time when the binary is deleted from production. That sets a nice clear requirement for compliance, biases people towards longer distribution times not shorter ("I think we've removed the binary from production - let's keep the source up, just in case") and has no wiggle room in it that a shell game can play with.
Posted Jun 30, 2023 15:19 UTC (Fri)
by paulj (subscriber, #341)
[Link] (4 responses)
Posted Jun 30, 2023 15:20 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (3 responses)
I've lost the link to where you keep this licence - mind resending it, and I'll give MRs/issues as I see appropriate?
Posted Jun 30, 2023 16:05 UTC (Fri)
by paulj (subscriber, #341)
[Link] (2 responses)
Thanks for your comments, and same for comments by pizza and others.
Posted Jun 30, 2023 16:13 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
It this were to gain any traction, it would need to have some legal input and feedback. Have you considered reaching out to folks like Richard Fontana who has worked on https://github.com/copyleft-next/copyleft-next and submit it to the FSF and OSI for their review?
Posted Jul 3, 2023 12:21 UTC (Mon)
by paulj (subscriber, #341)
[Link]
Posted Jun 29, 2023 9:22 UTC (Thu)
by rschroev (subscriber, #4164)
[Link]
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
*compilation* counts as modification, because it's "creating a derivative work".
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
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?
AlmaLinux's response to Red Hat's policy change
[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
Wol
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change