101–110 of 128 posts
Earlier quoted context omitted.
> rms is trying to make some topics (e.g., discussing if something could be used as a GPL loophole) taboo even for gnu-prog-discuss. Might not be a bad idea, since those discussions could be used after discovery as part of a trial.
If the problem is the discussion about loopholes, than why not just create a second mailing list about that topic and leave the other ones open?
Earlier quoted context omitted.
Agreed. It took a while for me to understand the idea that the free/open source difference is reasonably described as the difference between user freedoms and developer freedoms.
I like that distinction, but to be clear, the distinction isn't strictly an "either-or". It's pretty clear that "open source" is motivated by developer freedoms, but the fact that "free software" is motivated by user freedoms doesn't make it less about developer freedoms. In other words, if you subscribe to the four tenets of software freedom as they pertain to users, "free software" also provides as much freedom to…
I'm always surprised by the number of developers who enjoy the freedoms they are granted without thinking twice about taking the same freedoms away from their users.
For a time I too was the maintainer for GNU sed. Part of that time I was paid by the FSF for that work (this was a long time ago, when the FSF had a small staff working directly on the Hurd and GNU). When I started, GNU sed was very incompatible with the relatively new Posix standard for sed. When I finished, it was less incompatible. It was during this same time that I started work on a new regexp engine for sed but…
> He was sharp and I assume that, in spite of his age, he still is. Seriously? He's not 100, you know. Why wouldn't he be as sharp, or sharper, than ever?
Earlier quoted context omitted.
Just on your comment of legal support. One of his major complaints is that actually he is not getting the legal support he wants, and he thinks that he could do better by himself.
Is there a place where this complaint is posted? I know about the one time in regard to Werner Koch, and in which a legal problem arrived, and was subsequently fixed, but where FSF did not inform Koch about the fixing. To my understanding, that was a mistake in communication from FSF and was later resolved.
> "Once a developer assigns copyright, they are at the mercy of the assignee to enforce the copyright. In this particular case, one can speculate that the failure to pursue the violation was likely a shortage of human resources. As Richard noted, "We have staff for GPL enforcement, […] but there are so many violations that they can't take action on all.""
As the LWN article notes, statements like this are a huge distance between FSF in practice, and FSF's own reasoning behind assigning copyrights to it (http://www.gnu.org/licenses/why-assign.html).
When a project has assigned copyright to FSF, the project workers have no recourse when the copyright holder opts not to fulfill its part of the bargain.
> It is likely not possible to convince a diverse group such as the group of GNU maintainers to agree on coding standards for C++ ...bluntly asking: why? (In any closed-source C++ project, if someone writes a "style guide and coding standard" thing and the project manager supports it, people start writing "compliant" code, grunting or moaning at first but they do, and then it becomes part of "company culture" and peo…
Earlier quoted context omitted.
> You either have to compromise on users or on developers. Developers are users. > There are either strings attached as in GPL or there are not, as in BSD. From the way you're phrasing this, it's clear you miss the free software paradigm altogether. There are no strings attached. The ability for some users to limit other users' freedoms isn't one of the four freedoms.
Well, you not counting something I want to do with code as freedom does not make it less of a freedom. That, and also, that by limiting my ability to limit other users' freedom you are in fact limiting my own freedom: I may not use your code licensed that way. That's way I go with MIT, BSD, whatever, and leave GPL folks to play their hypocritical games with semantics, definitions and freedoms.
Nobody ever said that you had a right to infringe upon others' rights.
> leave GPL folks to play their hypocritical games with semantics, definitions and freedoms.
There's not one ounce of hypocrisy anywhere here. You may not like it, but to call "GPL folks" hypocritical is absolutely ridiculous.
Finally, it's remarkable that you managed to take a comment my comment, which was originally highlighting the similarities between the two schools of thought, and turning it into a jumping-off point for how one is clearly better than the other. Well-done!
Earlier quoted context omitted.
> You either have to compromise on users or on developers. Developers are users. > There are either strings attached as in GPL or there are not, as in BSD. From the way you're phrasing this, it's clear you miss the free software paradigm altogether. There are no strings attached. The ability for some users to limit other users' freedoms isn't one of the four freedoms.
Sigh. As a developer I have a problem to solve. GPL code comes with strings attach that LIMIT my ability to use it since the code I am writing does not have GPL compatible licensing. Thus it limits me as a developer. I don't miss the free software ideology - I just don't care about it. I care about the software I write and of what the users want, nothing more and nothing less.
So, you're saying that you want to choose a license for your code that infringes upon its users freedoms. That's not a problem with the GPL.
> I care about the software I write and of what the users want
Free software isn't about what users want. It's about what they deserve.
Rights are inalienable, so regardless of what users say or how they act, the rights are theirs, and neither you nor anybody else can infringe upon users' freedoms.
For a time I too was the maintainer for GNU sed. Part of that time I was paid by the FSF for that work (this was a long time ago, when the FSF had a small staff working directly on the Hurd and GNU). When I started, GNU sed was very incompatible with the relatively new Posix standard for sed. When I finished, it was less incompatible. It was during this same time that I started work on a new regexp engine for sed but…
> He was sharp and I assume that, in spite of his age, he still is. Seriously? He's not 100, you know. Why wouldn't he be as sharp, or sharper, than ever?
My view: sed does not need to be "extended" nor should it require much maintenance. At least, the BSD sed's I use have not needed much work. I recall Brian Kernighan mentioning how little maintenance awk has required over the years. As such, I fail to see why changing maintainers is newsworthy. Perhaps someone was looking for an excuse to state their opinions on other matters? I'll be honest I could not understand wh…
Just as an example of extending sed, I introduced "sed -i". Yes, it doesn't require much maintenance, but sometimes you can be surprised. I started maintaining GNU grep 3 years ago because it was in a really sorry state. Some parts were almost rewritten to make it faster and more correct.
If I really want to create temp files I can use ed or use sed with shell redirection. Were it for some reason a requirement, I can avoid temp files, at least for the substitution (s) command, as follows:
sed -a '"$1"';H;$!d;g;w'$2
where $1 is some sed s commands and $2 is a file
If GNU grep was in need of repair and you fixed it, then I thank you. But I'm not clear on how that justifies any "extensions" to GNU grep.
Maintenance, at least to me, means fixing things, not extending them and adding more complexity and things that can potentially break or create incompatibilities across different UNIX's.
Earlier quoted context omitted.
GNU might get you something roughly comparable to BSD/Solaris/etc, but without the Linux kernel there is really no technical reason to prefer GNU to BSD/Solaris/etc. Sure you could use Hurd instead of Linux, or Mach, or any other number of alternative kernels, but who actually does that? Mach is very popular, but only in all of the places that GNU definitely is not. (Clarification: I was explaining how Gnome may be f…
> "GNU might get you something roughly comparable to BSD/Solaris/etc, but without the Linux kernel there is really no technical reason to prefer GNU to BSD/Solaris/etc." This might make sense... except that it is popular to use GNU userlands on non-Linux systems, and that has always been the case. Hell, what do you think people were doing before Linux existed? So really it makes zero sense whatsoever. Gnome without a…