Les Mikesell wrote: > Andrew Haley wrote: >>>> Err, one library according to you, was unfree in the sense that >>>> you weren't allowed to change it in any way; to enhance it, or to >>>> fix bugs. >>> That's not an accurate description, although it did have a >>> restriction on distributing modified versions. I could, of >>> course, change my own copy and submit bug fixes and enhancements >>> to the author for incorporation - or make the source modifications >>> available separately from the package. The restriction was more >>> about preventing broken versions from being distributed than >>> enhancements. >> Sure, but it had that effect, didn't it? If you're not allowed to >> distribute modified versions without someone else's consent, it's >> not free (as in freedom) software. > It's not free the way the GPL redefines the word to mean restricted, > but it doesn't interfere with your freedom to distribute your > changes as patches, leaving it clear that it is something different > from the original author's work that he supports. I think my meaning was clear. It's not free because you can't distribute modified versions. And no matter how much you try to define it away, this basic fact will not change. Yes, you can supply it with a bunch of patches, but you can't do the obvious thing and check it in to a public source code control system and work on it there, since that would mean sharing a modified version. You can't distribute a modified version as part of, for example, a Linux distro. It's not free in any sense, except free-as-in-beer. > In more modern licenses, I'd prefer the ones where you are permitted > to modify independently and distribute the forked copy if you change > the package name, Well, yes. Obviously. > but it is only in odd circumstances that it even matters or that > there is any effective difference. Even in GPL circles I think most > people agree that the best process is to coordinate modifications > into a single revision tree instead of forking wildly. Sure, but that's a matter of free choice. That's what freedom means: you can either fork the software yourself, or you can contribute to the trunk. The choice is up to *you*. And anyone to whom you give the software has that same choice, and you can't take that freedom away from them. >>> There is the argument that if the author/maintainer stops >>> updating, the package can die. >> >> Quite. And, indeed, that's the inevitable consequence. > > It's not at all inevitable since the copyright holder can transfer > control at any time or might already be a foundation that will outlast > any possible use for the product. Sure, or they might not choose to do so. You could say the same about any software supplied under a restrictive licence. > But, in technology everyone is better > off when an old package does die and is replaced by something new and > improved, and the harm of the GPL is that it's 'work as a whole' > requirement makes it difficult or impossible for these replacements to > happen at the component level when the currently best component isn't > encumbered by the GPL. Eh? This makes no sense. It's certainly not justified by this example, anyway. Andrew. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
