Changing CentOS in mid-stream
Changing CentOS in mid-stream
Posted Dec 13, 2020 12:51 UTC (Sun) by johannbg (guest, #65743)In reply to: Changing CentOS in mid-stream by pbonzini
Parent article: Changing CentOS in mid-stream
Posted Dec 13, 2020 13:50 UTC (Sun)
by pbonzini (subscriber, #60935)
[Link] (44 responses)
For one, due to the sheer amount of patches in the RHEL kernel the process was starting not to scale. Every six months thousands and thousands of patches are applied. Just applying all the patches from an RPM would take several hours.
Second, no one in the CentOS community had even noticed that, for the ability for the community to rebuild was not affected at all. The whole thing came up when some Debian engineers went looking for kernel patches in RHEL6's 2.6.32 kernel to fix a bug. Well, they could have asked the upstream maintainer perhaps, since he worked for Red Hat: in the last couple years I have helped several times with backports for various processor erratas back to 3.14 or so.
Third, that's not obfuscation. There's countless open source projects that are developed within closed doors, with new releases consisting of code drops from a private repo to GitHub. Instead Red Hat is doing *all* development upstream first and providing the list of commits (99% of which apply with zero conflicts given how closely the RHEL8 kernel tracks upstream). Talk about double standards...
Posted Dec 14, 2020 7:37 UTC (Mon)
by nknight (subscriber, #71864)
[Link] (43 responses)
Posted Dec 14, 2020 13:52 UTC (Mon)
by pbonzini (subscriber, #60935)
[Link] (42 responses)
Posted Dec 14, 2020 22:13 UTC (Mon)
by paulj (subscriber, #341)
[Link] (33 responses)
Posted Dec 15, 2020 6:51 UTC (Tue)
by pbonzini (subscriber, #60935)
[Link] (32 responses)
1) that is nothing more than the definition of "source code", which is the actual term used by the GPL. Source code has a week known meaning in the industry that does not include the history.
2) the GPL also says that "for an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable" again with no reference to the history
3) "making modifications" does not require a git tree (ever done a shallow clone?). "Debugging", "identifying changes for the purpose of porting them to a different derivative", "collaborating with other people in the same organization" are not activities that the GPL talks about.
That said I am not sure how CentOS Stream will handle kernel changes. Maybe the git tree will be public after all, I don't know. The list of patches already is.
Posted Dec 15, 2020 7:57 UTC (Tue)
by nknight (subscriber, #71864)
[Link] (1 responses)
Posted Dec 15, 2020 10:03 UTC (Tue)
by pbonzini (subscriber, #60935)
[Link]
Posted Dec 15, 2020 9:17 UTC (Tue)
by paulj (subscriber, #341)
[Link] (29 responses)
"The source code for a work means the preferred form of the work for making modifications to it."
That is the literal licence text.
Is it /possible/ to make modifications without the information of what patches were applied to the stock linux kernel source? Of course! Just as it was /possible/ for people to make modifications to NVidia's obfuscated C X11 driver back in the day. Just as it is /possible/ to make modifications to the binary object code, either with a hex editor or by disassembling the code and editing the assembly code. These are all /possible/.
However, that's not the bar the licence sets. The licence sets the bar at "preferred" - precisely because Stallman anticipated that otherwise some would try work around the GPL with obfuscation.
You and your technical colleagues at RedHat clearly prefer using the git form, with the information of each 'modification' to the stock kernel code preserved, so as to make it easier to shuffle, update, re-order, drop, and work with all the changes. That is the preferred form.
The form you release has deliberately had that information stripped, so as to obfuscate it, and make it harder for others to work with.
Posted Dec 15, 2020 9:25 UTC (Tue)
by paulj (subscriber, #341)
[Link] (7 responses)
Your src.rpm form has the ability - indeed was /designed/ - to convey the original code and each change separately (the source and "patches") in a way that preserved this critical information. RedHat long created src.rpms of the kernel (from some other SCM I think) with the stock kernel code as the source, and the changes as patches. RedHat deliberately chose to collapse the source, and remove that information - critical to the preferred form for working with that code - to disadvantage others.
You could either publish the git, or (again) split out the source and each change as a patch in the src.rpm.
Posted Dec 15, 2020 11:10 UTC (Tue)
by paulj (subscriber, #341)
[Link] (6 responses)
Posted Dec 15, 2020 13:52 UTC (Tue)
by pbonzini (subscriber, #60935)
[Link] (5 responses)
Posted Dec 17, 2020 23:58 UTC (Thu)
by daniel (guest, #3181)
[Link] (4 responses)
Posted Dec 18, 2020 0:12 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (3 responses)
Who is going to determine what the "spirit" of the license is and how is that going to be enforced?
A license is a legal agreement. If something is not covered explicitly by the terms of the license that it is intended to cover, that is just a bug and should be fixed. Having clarity within the license is more effective than attempting to attach unspecified terms outside of it.
Posted Dec 18, 2020 1:11 UTC (Fri)
by pizza (subscriber, #46)
[Link] (1 responses)
And then that bug-fixed version of the license will get rejected by those intentionally taking advantage of the gray areas in the old license, while accusing its creators as being clueless zealots who are out of touch with what businesses need from "modern" software development.
Posted Dec 18, 2020 1:42 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link]
>And then that bug-fixed version of the license will get rejected by those >intentionally taking advantage of the gray areas in the old license
...Which is fine. Arguably this already happened with GPLv2 and GPLv3. The old and new versions have clear delineations and the choices are transparent to everyone as opposed to talking about the nebulous spirit of the license which really can mean anything from "The author of the license thinks this way" to "the project using the license thinks it should be interpreted this way" to "this person in LWN who is connected to neither wishes the license has this expanded interpretation although the plain reading of the license doesn't really say that". It is not the job of a software license to mandate healthy best practices around a community. If that was the case, even GNU wouldn't past that test given that bash git changelog has a lot of tarballs checked in directly on a routine basis.
Posted Dec 18, 2020 1:17 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
The musings/writings of (people within) the FSF is a good determinant of the GPL. If the wording of a licence is not clear a Judge has two options - to interpret it in favour of the defendant(s), or to interpret it in the light of explanatory text by the authors. Both are valid approaches.
And I think, in UK courts, Judges have been known to read Hansard and use the contents thereof to ignore the explicit black letter of the law on the basis that "MPs were misled when asked to vote on it".
Cheers,
Posted Dec 15, 2020 14:24 UTC (Tue)
by pizza (subscriber, #46)
[Link] (4 responses)
No, that clause was intended to ensure source code was supplied in an easily-machine-readable/modifiable form, as opposed to, say, delivered on reams of paper where it would first need to be OCR'd.
( https://lwn.net/Articles/431651/ )
Posted Dec 15, 2020 14:36 UTC (Tue)
by paulj (subscriber, #341)
[Link] (3 responses)
Note that today, git might be considered that medium. The source code on that medium defined as having to be in the "preferred form for making modifications".
Obfuscated source - i.e. sources with information removed (so as to frustrate others) - is not source code, as the GPL requires it.
Posted Dec 15, 2020 16:23 UTC (Tue)
by pizza (subscriber, #46)
[Link] (2 responses)
No, "medium" refers to something physical. Paper, tape, compact disc, or even the internet. How those bits are organized on that medium doesn't matter as long as that _medium_ is "machine readable" and "customarily used for software interchange".
(And yes, in the early days of the FSF/GNU, distributing software on machine-readable paper was very much still a thing!)
> Obfuscated source - i.e. sources with information removed (so as to frustrate others) - is not source code, as the GPL requires it.
But revision history is not source code, and the GPL covers *source code* only.
So yes, deliberate obfuscating the source code is a no-no, but how is distributing one big patch vs 100 smaller patches "obfuscating" the source code?
The GPL does not require revision control or any associated metadata with change history beyond "complete corresponding source code" is supplied for stuff distributed in binary form -- ie everything needed to recreate the distributed binaries. If you're distributing stuff purely in source code form, then you can supply the complete original work (modified or not), a random ten-line snippet, or anything in between, and deliver it etched into a slab of granite.
And while the GPL requires that any changed files "carry prominent notices stating you changed the files and the date of any change", note that applies at time of *distribution* -- it doesn't matter that I modified file1.c on 2020-11-20 and file 2.c on 2020-11-25, only that I publicly distributed my modified version of both on 2020-12-01, and a patch file clearly shows what was modified, and the "when" is "the timestamp of the patch file"
And before you say that a patch file doesn't satisfy that requirement, because it lies outside the files themselves, I should point out that revision control doesn't either, as that what/when change metadata is also not part of the actual files.
Posted Dec 15, 2020 16:50 UTC (Tue)
by paulj (subscriber, #341)
[Link] (1 responses)
I think it pretty obvious how collapsing and removing information about the constitution of code obfuscates it - be it by a compiler transforming C code into object code; or a RedHat src.rpm building system turning a series of commits in a git tree into one big blog of a patch.
The wording in the licence is "preferred form", and there is a simple test: Would the RedHat engineers prefer to work with the collapsed big-patch, or with the broken-out patches? The answer to that is obvious, given how RedHat engineers work.
Posted Dec 15, 2020 17:26 UTC (Tue)
by pizza (subscriber, #46)
[Link]
In other words, by virtue of their use of HTTP over the internet, Red Hat is using "a medium customarily used for software interchange" to distribute their complete corresponding source code.
> I think it pretty obvious how collapsing and removing information about the constitution of code obfuscates it - be it by a compiler transforming C code into object code; or a RedHat src.rpm building system turning a series of commits in a git tree into one big blog of a patch.
Please stop bringing up the red herring of distributing [partially] compiled sources, because (1) everyone agrees that is an explicit GPL violation, and (2) RH has never done that.
What's being "obfuscated" are the sequence and history of individual changes. The *source code* is the same either way.
Meanwhile, it's been nearly a decade since RH made this change -- see https://lwn.net/Articles/432012/ -- and nothing new has transpired since. You don't have to like what RH is doing. That's fine, a lot of others feel the same way (including our fine LWN editor). However, it is _not_ a GPL violation -- unless you are also arguing that most of what's available on gnu.org is violating the GPL as well. Say what you will about RH, but I trust that the FSF knows how follow their own license.
Posted Dec 15, 2020 20:28 UTC (Tue)
by madscientist (subscriber, #16861)
[Link] (15 responses)
It was not required that people publish their local RCS or SCCS repositories to comply with the GPL: they simply published source tarballs, same as appears now on the ftp.gnu.org site.
Even today I don't think the GNU project requires development of all its software to be performed in a publicly-accessible SCM, and if not to publish the contents of the SCM repository when making releases. Of course, it's moot these days because all GNU projects I'm aware of do it anyway, out of convenience.
Posted Dec 15, 2020 22:31 UTC (Tue)
by paulj (subscriber, #341)
[Link] (14 responses)
That aside, what is preferred can change over time. Things that were preferred in the 80s and 90s need not be (and are unlikely to be, in tech) preferred in the 2020's. And the GPL drafting seems to have been careful to explicitly specify the forms and technologies, no doubt to future-proof it.
Posted Dec 18, 2020 0:01 UTC (Fri)
by daniel (guest, #3181)
[Link] (13 responses)
Posted Dec 18, 2020 10:44 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (12 responses)
I'm not sure I agree with you, in the context of what the GPL is intended to enable.
While you would prefer the full revision history if you're trying to unpick why the distro did something, that's not something the GPL requires - only identification of the changes, and the ability for a recipient to make further changes. One big patch meets both of those requirements; you can clearly see what Red Hat got from upstream, and what changes Red Hat applied, and you can make further changes yourself.
Posted Dec 18, 2020 11:23 UTC (Fri)
by paulj (subscriber, #341)
[Link] (11 responses)
You're hitting a bug in some Free Software you're using, and you want to fix it. You go to the project's website. They have 'make dist' tarballs, and they have a git repository.
Which will you prefer to download, to make your modifications?
Posted Dec 18, 2020 11:28 UTC (Fri)
by paulj (subscriber, #341)
[Link] (9 responses)
You want to figure out which of their changes from stock is the problem. You might want to bisect through all the changes, to find the problem change, so you can fix it.
Which form would you prefer to start with?
Posted Dec 18, 2020 11:34 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (7 responses)
Now you've changed from what the GPL requires - it does not require the upstream to make it easy for me to identify which change is problematic, only that I can identify changes from the version my upstream received, and modify it.
If I want to fix-forward, then the version with stock kernel and all their changes is just fine - I don't need to know which change is problematic, I need to know what the bug is and fix it there. I only need to identify the problem change if I simply want to undo some of my upstream's changes but not all of them, and the GPL does not require upstream to make it easy for me to do that, as long as I can comfortably edit and rebuild the work as I received it.
Posted Dec 18, 2020 11:39 UTC (Fri)
by paulj (subscriber, #341)
[Link] (6 responses)
The GPL defines source code as "preferred form for modifications" - deliberately framed that way to remain general and be apply across technologies, and across time as tools and preferences change.
Asking questions about how developers work today, what they prefer to have in doing that work - within the confines of what the distributor has available - seems the correct way to me to figure out what "preferred form" should mean.
Posted Dec 18, 2020 11:45 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (5 responses)
If I am modifying the code, then I want the code as a whole on my filesystem - the output of `tar x` or similar. Revision control history is not something I need or usually want to make modifications to code.
You changed from making modifications to finding bugs introduced by modifications that my upstream made. In that situation, I'd like revision control history, as part of identifying the bug, not as part of modifying the code. Once I've identified the bug, I'll go back to the final form I was given and fix that.
Posted Dec 18, 2020 12:53 UTC (Fri)
by paulj (subscriber, #341)
[Link] (4 responses)
Flip it around: Say you're a distributor of other people's copyleft software. You have a git tree tracking changes.
Do you want to try dance on pins to argue that the workflow that is the easiest (and practical - given scaling) for you, is somehow not preferable for others, and acceptable within the licence, trying to justify nformation-striping you added to frustrate competitors?
Or do you just export that git tree (with whatever git filter), to make sure you accommodate others, and err on the side of staying clearly within the licence?
Posted Dec 18, 2020 13:21 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (3 responses)
But I use such a system, not to track the code, but to allow multiple people to work together on the code without conflicting. The VCS is a side-effect of that, used while I'm producing the work to allow several modifications to happen in parallel while providing me with a way to integrate them together into a final form that I release to my customers.
FWIW, when I worked somewhere that *did* distribute other people's copyleft software, every lawyer we dealt with said that the maximum the licence demanded was a tarball from my upstream, and a diff that could be applied with my changes to get to the modified version we shipped.
So, you can dance on pins trying to stretch the licence to require my development workflow to be shipped with my modified code, or you can stay clearly within the licence.
Posted Dec 18, 2020 15:40 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (2 responses)
And, as an aside while you're thinking about where stretching this goes, my preferred form for modification of code is downloaded to the filesystem of a fast machine with a decent 32" monitor attached and an editor set up to my preferences. I use that for every modification I make, including the ones I have that are in the upstream Linux kernel.
A VCS is entirely optional for modifying code, given a decent editor with good undo facilities and auto-commenting of lines. It makes it much, much easier to share my modifications with people, and to track what is the code I got from upstream versus what I've modified, but I do not use the VCS as part of actually modifying the code. In contrast, I do use the fast computer, the editor, and the monitor as part of actually modifying code - I've never made a kernel modification without a monitor and an editor of my choice.
Posted Dec 18, 2020 17:38 UTC (Fri)
by paulj (subscriber, #341)
[Link] (1 responses)
If monitors were specific to software source code, and you needed a very specific monitor unique to a code-base in order to modify it, and it was typical in software for proprietary vendors of code-base to sell such monitors along with source-code; and if someone created a copyleft licence that required all the tools to be passed along to those the redistributed the code to; then yes... maybe you could require people to supply monitors.
However, in this world, the hardware is usually general, and the general hardware is usually not supplied. So, that's a super-hypothetical world.
The GPLv3 does require the tools - other than general-purpose - to be supplied as part of the source code.
Posted Dec 18, 2020 17:57 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
But the VCS is also a general purpose tool, like a monitor, and when it comes to modifying code (e.g. to add support for a new printer type), I have no interest in what's in the VCS, whereas I do have a deep interest in having decent tools for actually making my changes. Indeed, if you give me the choice between my current monitor and a distribution tarball of the code, or a monitor half the area (a 22" or so) and full VCS history for a project I want to modify, I'll take the tarball and my current monitor every single time.
While I don't work at Red Hat, I suspect the same is true of their engineers too - full VCS history is nice, but good tools are far more important if you're modifying the code.
Posted Dec 18, 2020 12:16 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
And note that the ideal form for identifying their bug so I can fix it is not just the full revision history, but also full access to all the people involved in writing the changes so that I can talk to them about what they did, why they did it, and what the interactions with other changes are.
Taking your interpretation at face value, I could argue that because that's my preferred form of the code for fixing bugs, I have a right to your time if you distribute code to me (directly or indirectly). The GPL limits it to my preferred form for making modifications, and when I'm modifying code, I do that via a working copy and an editor, not via a VCS of some form.
Posted Dec 18, 2020 11:29 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
The `make dist` tarballs. That gets me something that's close to what I'm actually using to start from, and has handled a lot of the details of whatever build system the project uses already - so there's less work for me in getting to the point where I can build their code and run with it.
This changes if I want to contribute the fix back, but it's the desire to contribute that pushes me to the extra hassle of the git tree, not details of how I'd fix the problem.
Posted Dec 14, 2020 23:58 UTC (Mon)
by nknight (subscriber, #71864)
[Link] (7 responses)
Posted Dec 15, 2020 0:54 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
Posted Dec 15, 2020 8:04 UTC (Tue)
by nknight (subscriber, #71864)
[Link] (2 responses)
If Red Hat can't get their developers not to shove client names into commit messages (seriously? this would get you *immediately* escorted off the premises at many companies with sensitive clientele), well, just another reason not to trust them.
Posted Dec 15, 2020 10:01 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Dec 15, 2020 23:51 UTC (Tue)
by nknight (subscriber, #71864)
[Link]
A source tree of the Linux kernel of such importance is going to be seen by a *lot* of people over time, not all of whom are going to be vetted or trustworthy. If this were the concern, Red Hat would have much deeper problems.
Posted Dec 15, 2020 11:08 UTC (Tue)
by paulj (subscriber, #341)
[Link] (2 responses)
They'd have to remove that information, in whatever way.
Posted Dec 15, 2020 23:17 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Dec 18, 2020 0:04 UTC (Fri)
by daniel (guest, #3181)
[Link]
Posted Dec 13, 2020 14:15 UTC (Sun)
by pizza (subscriber, #46)
[Link] (36 responses)
Come on.
Oracle's sales strategy in this case could be best summed up as "We're selling Red Hat's stuff for cheaper than Red Hat sells it."
Which they could easily do because they were relying on Red Hat to perform all of the actual development/engineering work.
(Yes, Oracle's strategy is a bit more nuanced than this, but at the end of they day, they take RHEL, rebuild it, and sell support packages along with "value add" like better integration with Oracle's other offerings.)
Posted Dec 13, 2020 16:09 UTC (Sun)
by johannbg (guest, #65743)
[Link] (35 responses)
Anyway the big irony in Red Hat's management deciding to solve a broken sales strategy by obfuscation their source code and expecting that competing company would change its business practice ( Yeah like Larry "lawnmower" Ellis would suddenly grow a conscience ) as a result of that, is that Red Hat's entire business model is built around taking advantage of the openness of thousands of Free Software developers.
Does Red Hat contribute back to communities yes but does it contribute back in a reasonable proportion with the profit it makes profiting of the open source community and it's contributors well that is an material for an entire news article *wink* *wink* *nudge* *nudge*
Posted Dec 15, 2020 14:45 UTC (Tue)
by paulj (subscriber, #341)
[Link] (34 responses)
There are many companies at this, by various means. Some directly exploitative, taking free software of others and selling it with improvements they do not release back (or release only with great delay), and/or even with portions they will never release the code for. Others indirectly exploitative, by taking free software of others and profiting from it but - as you point at - largely not contributing back with support (employment, say) for those who supplied them with the software.
I think we need next-generation copyleft licences, to address this. Licenses that give users their freedom, but that also empower the actual authors of Free Software and shield the authors better from the parasitical tendencies of corporations - which the current GPL allows.
Posted Dec 15, 2020 17:52 UTC (Tue)
by mpr22 (subscriber, #60784)
[Link] (32 responses)
Those are violations of the GPL, and thus tortious (or even criminal) conduct for which the exploiter can be pursued by the copyright holder in a court of law.
(Yes, this is expensive. No, that expensiveness is not something that can be remedied by redrafting the licence on your software. Fixing that requires the assistance of legislators, not just lawyers.)
Posted Dec 15, 2020 19:09 UTC (Tue)
by paulj (subscriber, #341)
[Link] (31 responses)
There is at least one company who a) I know has improvements to software I have helped write; b) State they discharge their GPL obligations by giving the source to their customers with their binaries (i.e., they do not avail of the "offer to any 3rd party" clause in the GPL); d) Yet we never ever could get these improvements. I don't want to go into too much detail, but I strongly suspect side-contracts must be in place that penalise any of their customers if they publish or further distribute these changes to the GPL software.
Another example is the rise of large "cloud" companies, which are not in the business of distributing software. They are massive users of Free Software, and they often make fixes and improvements to that Free Software - but they are under no obligation to give those changes back, as they do not distribute. Some are good, and give back; others view these changes as a competitive advantage and are secretive even about what changes they made - never mind giving the changes back!
I would like a copyleft that completely barred private discharge of the source obligation to solve the first issue, and the second issue seems to me like it could only be fixed with some kind of clause requiring that modifications be made public, based on some reasonable condition to avoid requiring every speculative or dead-end change to have to be made public. E.g., perhaps require that any modifications that are put into use be made available publicly, always.
As for addressing expense, from talking to legal types, I think there may be non-legislative changes to licence text that could be made to make it easier to take action against violaters. E.g., in a number of jurisdictions one can only claim for demonstrable damages, so a licence that explicitly specified a monetary cost for use outwith the copyleft terms (e.g., X% of revenue of any controlling entity of the violator?) could make the licence easier to enforce. This could be done with a meta-licence, I guess - but it would be more universal and less hassle/confusing for developers if it was specified in the same licence.
Posted Dec 15, 2020 20:50 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (30 responses)
Note that their claim (b) - if true - IS a full and complete discharge of their responsibilities. The GPL does NOT entitle random 3rd parties (including other copyright holders) to request copies of other peoples' source.
It entitles CUSTOMERS to receive a copy of the source. If that copy is not provided when customers receive the binary it is *then* that the "random 3rd party" rule kicks in on the assumption that the original customer may have further distributed the binaries.
And you could well be right with your suspicions in (d), but I suspect that is a breach of neither the letter nor the spirit of the GPL :-(
Cheers,
Posted Dec 15, 2020 22:35 UTC (Tue)
by paulj (subscriber, #341)
[Link] (24 responses)
I think by banning wholly private discharge of the source code distribution obligation. I.e., I would want a licence that obliges the GPL licensee to make the source available to all, if to any, always.
Posted Dec 15, 2020 23:31 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (19 responses)
Which is COMPLETELY AGAINST the spirit of the GPL.
The whole point of the GPL is to protect *users* against an *abusive upstream*. You are said upstream. The GPL is there to protect your users *against you*. Sorry.
Cheers,
Posted Dec 16, 2020 0:05 UTC (Wed)
by paulj (subscriber, #341)
[Link] (18 responses)
The GPL does not exist to allow parasitic corporations to exploit Free Software developers, taking their code and making money of it with effectively-proprietary modifications to their customers, restricting the distribution of those modifications through side-contracts.
If you think those corporations need protecting, we're just going to have fundamentally disagree. And I think you're no friend of Free Software.
Posted Dec 16, 2020 0:26 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (17 responses)
You clearly don't understand what the Free Software Foundation thinks is "Free Software", nor what is the intent of the GPL.
The GPL has NEVER been a "friend of the software developer" - if that's what you want you need the BSD licence.
I repeat - that corporation is your *downstream* *user*. The GPL is there to protect *downstream*!
Cheers,
Posted Dec 16, 2020 10:32 UTC (Wed)
by paulj (subscriber, #341)
[Link] (16 responses)
I really do not care about the interests of such parasites, and I'd like to find a copyleft licence that discourages such parasites, to the benefit of the rest of the community.
And I don't see a problem with a copyleft licence protecting the interests of Free Software developers, as long as it still protects the freedom of users.
Posted Dec 16, 2020 11:57 UTC (Wed)
by pizza (subscriber, #46)
[Link] (13 responses)
As Wol pointed out, "parasitic corporations" are still "users", so what you are saying is that "I want some uses/users to have more rights/freedoms than others".
Posted Dec 16, 2020 12:16 UTC (Wed)
by paulj (subscriber, #341)
[Link] (12 responses)
The GPL already excludes users who want to keep modifications they distribute to others proprietary. The problem is that some corporates have found a way to /effectively/ keep their modifications proprietary, while (arguably) staying technically within the law - by placing their restrictions on /other/ users in side-contracts.
These users are already outside of the spirit of the GPL, as far as I'm concerned. They are taking freedoms away from others. I have no time or sympathy for them. I will be glad to see that loophole closed off in future copyleft licences.
Posted Dec 16, 2020 12:24 UTC (Wed)
by paulj (subscriber, #341)
[Link] (9 responses)
If you're a Free Software developer that things there should be /no/ restriction on freedoms for users, then go and use a BSD licence. You (and your users) won't get the benefits that copyleft can bring. And that's a subjective decision, and that's fine.
Posted Dec 16, 2020 16:41 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (8 responses)
You quite clearly have never bothered to read the GPL properly. The pre-amble states that yes, it does place obligations ON THE DEVELOPERS. The following is taken from clause 0 of the GPLv2
> Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.
While this does not explicitly cover the case of some one/thing who is both a downstream and an upstream, I think it is quite clear that the intent of this section (and of the rest of the licence) is to re-iterate the fact that downstream owes NO OBLIGATION WHATSOEVER to upstream. This is the - intentional - reversal of the normal state of affairs where downstream needs permission from upstream to do anything even as little as wiping its nose despite paying through its nose for the privilege...
That's why I said "if you want freedom FOR THE DEVELOPERS you need the BSD licence". The GPL frees your users from any obligation to you. If you don't like it, tough, that's what it is intended to achieve.
Cheers,
Posted Dec 16, 2020 17:13 UTC (Wed)
by paulj (subscriber, #341)
[Link] (7 responses)
The intent of the GPL is to ensure the downstream has all the rights its upstream received. That is, the downstream /must/ be free to be able to distribute the changes onward. And that includes back to the original source!
I.e. the original upstream can *also* be a further-downstream - the benefits of Free Software are intended to extend to the original developer, as much as to any other users. It's a two-way street (but the parasites want to skew that street to themselves). So you are just wrong that the upstream-and-downstream has no obligation to its upstream, for the whole idea of copyleft is that a downstream of that upstream-and-downstream ought to be able to supply the changes back to the original upstream, and hence make the original upstream a downstream of the upstream-and-downstream as well as an upstream.
Copyleft intended to guarantee that freedom for the "downstream", by imposing obligations on the "upstream-and-downstream" intermediary - which reduce the freedom of that "upstream-and-downstream" inter-mediary.
That some think they have a found a way to prevent their downstreams from exercising the rights that the original upstream - the copyright holder - wanted all downstreams to be able to exercise, is a problem that I would like to see fixed.
The BSD isn't useful here to the original upstream. The BSD licence has its uses, but this scenario isn't one of them.
Posted Dec 16, 2020 17:30 UTC (Wed)
by pizza (subscriber, #46)
[Link] (5 responses)
"ought to be able" is not the same as "must"
> That some think they have a found a way to prevent their downstreams from exercising the rights that the original upstream - the copyright holder - wanted all downstreams to be able to exercise, is a problem that I would like to see fixed.
For what it's worth, I agree with you. I just don't think this addressable/fixable from within the scope of a copyright license.
Ultimately this is a question of freedom of association -- "Sure, you're completely free to pass on these modified GPL sources; that's your right. But if you do that, I'll exercise my right to stop doing business with you."
Posted Dec 16, 2020 17:41 UTC (Wed)
by paulj (subscriber, #341)
[Link] (4 responses)
They should just not be able to use it to prevent others from exercising their copyleft rights to distribute. And that can be done easily by just making it a general requirement (with reasonable exceptions to address ability to do R&D in private, desert island residents and dissidents) to make source available, so that it ceases to be a tool to control others with.
In this day of a plethora of places that will host Free Software source for free, it's easy to make code available, and it's reasonable to generally require those who modify Free Software to do so.
Posted Dec 16, 2020 17:54 UTC (Wed)
by pizza (subscriber, #46)
[Link] (2 responses)
Private contracts are used to place far more onerous conditions on things far more basic and important than copyleft software; what makes software so special here?
For example, as part of my severance package from the last gig, there was an anti-disparagement clause. If I trashed-talked my former employer within a certain period of time, I'd have to return the money they paid me. I was free to say no, and trash my employer all I wanted, but instead I voluntarily entered into a contract that restricted my freedom of speech and used that money to pay off some debts.
Should this "Waiving my rights to X in exchange for certain considerations" sort of contract be made illegal? (if yes, why? If no, how X == free speech materially different from "X == redistribution of copyleft software"?)
Posted Dec 17, 2020 12:26 UTC (Thu)
by paulj (subscriber, #341)
[Link] (1 responses)
The copyright holder can't stop others exercising their freedom of association either.
The copyright holder can however require that the obligation to distribute modifications to the source be broader, such that others can not wield freedom of association as a weapon to restrict copyleft rights.
And if such parasitic companies don't like that, they're still perfectly free to not use that software. The authors are free to choose their licence for their software, and others are free to make their own decisions.
Posted Dec 17, 2020 13:20 UTC (Thu)
by pizza (subscriber, #46)
[Link]
Oh, yes it does; if I make use of or incorporate certain software in my last two jobs, I can be terminated on the spot.
> The copyright holder can't stop others exercising their freedom of association either.
Their attempts to create "ethical licenses" certainly do; under "field of use restrictions"
> The copyright holder can however require that the obligation to distribute modifications to the source be broader, such that others can not wield freedom of association as a weapon to restrict copyleft rights.
The actual "software" has no rights or permissions -- only "persons" do. I (or my employer), as a "person", have the permission granted by the software's author (ie the license) to redistribute that copyleft software. I can chose not to do so for any reason -- Because I don't like you. Because it's Tuesday. Because I promised my mother that I wouldn't. Because I signed a contract with my employer/supplier/whatever to not do so. And so forth.
What you are asking is for the license to unconditionally force/compel folks to redistribute the software to unrelated third parties. There are significant practical and legal problems with that. I'm not saying it's impossible, just that it's going to take a lot of care to draft, and the resulting license will probably see even less use than the AGPL -- Which is already considered so toxic that it's only significant use is as a deliberate poison pill.
Posted Dec 16, 2020 20:24 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
And you are showing your inability to follow a logical argument. If I rely on that company's software (never mind that some of it is your GPL software), I cannot afford for *them* to follow *their* right to freedom of association, and refuse to associate with me.
I have entered into a - supposedly mutual - beneficial arrangement with them, and neither of us wishes to jeopardise it. You are an outsider to that agreements, and by agreeing to the GPL you surrendered any rights you may have had. If you don't like it, it's your right to refuse to associate with the GPL.
It is a fundamental requirement of the free market, that people are not coerced into doing business with people they would rather avoid. This is what's wrong with modern "free market" capitalism, where the big players are free to buy, force out of business, or otherwise destroy their smaller competitors and force customers to do business with them. In this particular case, unfortunately that company does not want to do business with you, and their customers do not want to antagonise them.
YOU SAID the GPL requires you to pass on all the rights you received. But you are objecting to this company exercising those self-same rights that you received and passed on.
Cheers,
Posted Dec 16, 2020 19:21 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
And that includes the freedom NOT to distribute changes back to the original source.
You're arguing with your heart, not your head. And that way leads to disaster ... "The road to hell is paved with good intentions". You've already assumed (from no evidence whatsoever) that I am opposed to what you want. I'm not. Just like many other people here, my head tells me you can't have it. Doesn't mean I don't wish we could :-)
"Man proposes. Nature opposes". What you want is not achievable. Not without tying logic up in a granny knot and bashing it over the head with a rolling pin.
Cheers,
Posted Dec 16, 2020 16:27 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (1 responses)
So you want to discriminate between users - which is FORBIDDEN by the *concept* of copyleft. You won't - can't - find a copyleft licence that agrees with you. (Oh - and as I pointed out - the GPLv3 not only did not attempt to close that loophole, it quite deliberately opened it even wider!)
And those same users you have no sympathy for includes a LOT of hardware vendors - if you hadn't noticed, a lot of kernel developers feel similarly to you. The *problem* is that, as soon as you have the sort of licence *you* desire, the practical consequence will be that linux is sidelined and becomes completely irrelevant.
Sadly, sometimes practicality has to trump idealism, or the idealists will become irrelevant sighing winds in the desert :-(
Cheers,
Posted Dec 16, 2020 16:53 UTC (Wed)
by paulj (subscriber, #341)
[Link]
Some users think they've found a loophole, that is against the spirit of the GPL and copyleft. (And I completely disagree with you that the spirit of copyleft /intentionally/ allows for corporates to restrict re-distribution of modifications by their downstreams - that's absurd, the entire point of copyleft is to ensure the recipients get the right to distribute!).
I don't get your point about hardware vendors. If you mean the likes of graphics vendors with closed blobs, they may well be in direct violation of the GPL already - that's not the case I'm talking about.
I sense I'm down a rabbit hole with you.
Posted Dec 16, 2020 13:04 UTC (Wed)
by mpr22 (subscriber, #60784)
[Link] (1 responses)
Posted Dec 16, 2020 13:23 UTC (Wed)
by paulj (subscriber, #341)
[Link]
So I'd be happy to exempt natural persons from some obligations designed to tackle an issue that manifests itself mostly with corporations. If a reasonable balance of obligations and wording can be found that doesn't need to distinguish between natural persons and other bodies, that's fine too.
Posted Dec 16, 2020 1:08 UTC (Wed)
by pabs (subscriber, #43278)
[Link] (3 responses)
Posted Dec 16, 2020 1:31 UTC (Wed)
by bkuhn (subscriber, #58642)
[Link]
The issue of mandatory upstream distribution of source changes to copylefted software has been a hotly debated topic since I first got involved in copyleft licensing policy and drafting in the late 1990s. The two primary positions within this debate have been outlined well already in this thread. I think most copyleft theorists believe that modifiers (modulo the danger situations with dissidents that pabs identified) have a moral obligation to make generally useful improvements available to the general public. The problem, and this goes back to the points pabs raised, is how to draft policy that respects the privacy rights of some types of modifications while assuring that truly generally useful changes that the world deserves, morally speaking, can be codified into a copyleft license.
Much of this debate reminds me more recently of the so-called “Ethical License” initiatives. In those initiatives, its proponents argue that since there are immoral things done by companies with software (such as helping USA's ICE lock children up in cages) that the licenses are not ethical if they don't prevent that.
The flaw in the logic is the idea that every moral and social problem that relates to software can be fixed with its license. Having spent years enforcing copyleft licenses and drafting them, I've concluded that you have to be selective how you use the tool of copyleft. And, it's not that I'm just critical of new ideas: I'd argue that GPLv2§2(a) is a great example of a well-intentioned clause meaning to get to a good policy outcome that is just annoying to comply with in practice. We should all comply with it because it's required, but I would never include that clause or one like it again in a future copyleft license.
Similarly, when I hear people clamoring for features for copyleft licenses, I worry about future-proofing. It's hard to do. Anyway, I encourage anyone who wants to talk about real-world drafting of copyleft to join the copyleft-next project.
Posted Dec 16, 2020 10:38 UTC (Wed)
by paulj (subscriber, #341)
[Link] (1 responses)
The obligation to distribute generally could be to the greatest extent reasonable, subject to any external restrictions on distribution. So the desert island denizen, as long as they make available to anyone else on the island, would be fine.
The dissident can be protected by exempting any person (not corporation) from the obligation, where doing so would put lives at risk of oppression.
Posted Dec 16, 2020 13:05 UTC (Wed)
by mpr22 (subscriber, #60784)
[Link]
Posted Dec 16, 2020 0:20 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (4 responses)
Actually, version 3 of the GPL makes this intent even clearer - the wording of v2 effectively made the vendor *force* the source onto the user. Under v3, if the vendor merely makes the source *available* (by, for example, providing a download link) it stops the "random 3rd party" rule from kicking in.
In other words, if I point my users at a *private* *intranet* site, so long as they have access to said private site at the time I supply the binaries, then I can pull that source download site AT ANY TIME.
Cheers,
Posted Dec 25, 2020 19:12 UTC (Fri)
by sammythesnake (guest, #17693)
[Link] (3 responses)
Three years might be an interminable age or a blink of the eye depending on the circumstances, though.
Posted Dec 25, 2020 20:01 UTC (Fri)
by sfeam (subscriber, #2841)
[Link]
Posted Dec 27, 2020 1:13 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (1 responses)
In other words, you must comply with clause 6, but you can choose between (a) or (b) (or (c) or (d) or whatever).
Cheers,
Posted Dec 27, 2020 1:16 UTC (Sun)
by Wol (subscriber, #4433)
[Link]
Comply with (a) OR (b) OR (c) OR (d) OR (e).
Your choice - if you want to ignore 6(b) that's perfectly fine so long as you comply with one of the others.
Sheesh - talk about people not being able to understand plain simple English ... (or American :-)
Cheers,
Posted Dec 15, 2020 20:48 UTC (Tue)
by joib (subscriber, #8541)
[Link]
> There are many companies at this, by various means. Some directly exploitative, taking free software of others and selling it with improvements they do not release back (or release only with great delay), and/or even with portions they will never release the code for. Others indirectly exploitative, by taking free software of others and profiting from it but - as you point at - largely not contributing back with support (employment, say) for those who supplied them with the software.
There are, of course, licenses which provide monetary compensation to the developers, but those are called proprietary, not open source. The universe is, for better or worse, under no obligation to give money to you or me as a reward for writing free software.
> I think we need next-generation copyleft licences, to address this. Licenses that give users their freedom, but that also empower the actual authors of Free Software and shield the authors better from the parasitical tendencies of corporations - which the current GPL allows.
In a way, I completely agree with that. GPLv3 is in many ways fine, but doesn't go nearly far enough to protect e.g. against service providers. But it also seems to me a quixotic quest. GPLv3, modest improvement to GPLv2 as it was, already caused a schism in the GPL-using community, many of which explicitly chose to stay with GPLv2-only. Not to mention AGPL, which is regarded as outright poison by many. And a hypothetical GPLv4 which would close the "service provide loophole", would probably look like an even stronger version of AGPLv3. I think very few would jump on that train.
The other approach is maybe to take a step back and think about what we're actually trying to achieve, and whether there are other more fruitful avenues to get what we want. If we want devices that we own, and can tinker with, maybe pushing for Right to Repair type legislation, including the ability to boot our own code instead of the manufacturer signed one? And push for open specified protocols, so we can replace the original manufacturer black box software with our own?
But those are more legal or political changes. Getting out in the street protesting, lobbying etc. is certainly uncomfortable, but OTOH maybe the alternative idea of enacting social change by coding away in our basements was always an impossible dream anyway.
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Wol
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Wol
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Wol
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Wol
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Wol
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Wol
Changing CentOS in mid-stream
Wol
Changing CentOS in mid-stream
Wol
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Mandatory upstream distribution and its problems
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Wol
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Changing CentOS in mid-stream
Wol
Changing CentOS in mid-stream
Wol
Changing CentOS in mid-stream