141–150 of 224 posts
> Michał Sidor suggests building against libbfd, something that the Debian maintainers don’t want to do. "don't want to" isn't quite correct - they can't . Perf is licensed under the GPLv2, libbfd under the GPLv3. The licenses are incompatible, which makes the combination unredistributable - which is what Debian would be doing with it. Debian is legally not allowed to do this.
Earlier quoted context omitted.
It was always clear that gnu would create newer versions of the GPL and start releasing under it. The blame is pretty clearly on the people who editted the license text to be GPL2 only.
I think it's acceptable to not want an organisation to be able to relicense your software under arbitrary terms, which the GPL does allow the FSF to do. The GPL 3 is a pretty benign improvement on the GPL 2 (though I know Linus objects to the Tivo clause). I don't think anyone who was happy with their software being used under the terms of GPL 2 would be unhappy with it being used under the terms of the GPL 3 additio…
Earlier quoted context omitted.
Two? Are the AGPL licenses compatible? How about GPL licenses with exceptions for some APIs as used by OpenJDK?
The AGPL licenses are explicitly compatible with the GPL ones. FWIW, this issue is essentially entirely caused by Linus, who refuses to use or accept GPL3.
That's a bit disingenuous. Linus has said no to the GPLv3, yes, but his reasons for doing so have merit.
It is a tough feeling to see someone else's design for a library that would be literally perfect for my needs, but I'm unable to use it because of the license, so I have to spend weeks implementing my own inferior version while carefully avoiding making the code too similar to what I happen to remember. I'm past believing that I'm smart enough to always be able to come up with/reimplement a competent enough solution…
Rather than thinking about how to re-implement a thing that doesn't exist, I think about how to implement the tool I actually need. What I end up with may be less general, but it's actual functionality is often simpler and easier for me to grok/remember.
reading/parsing dwarf data, on the other hand, is likely to be slow. not totally sure, but maybe i/o could be sped up by mmap'ing in the dwarf data and maybe part of the parsing could be cached?
fun story, i once solved a similar performance regression in a machine learning context, where calling code would serialize an entire model and pass it to inference code, which would then deserialize it all, make one inference, and then tear it all down. if online/streaming is not required, a huge speedup can come from just batching the work.
Earlier quoted context omitted.
It was always clear that gnu would create newer versions of the GPL and start releasing under it. The blame is pretty clearly on the people who editted the license text to be GPL2 only.
I think it's acceptable to not want an organisation to be able to relicense your software under arbitrary terms, which the GPL does allow the FSF to do. The GPL 3 is a pretty benign improvement on the GPL 2 (though I know Linus objects to the Tivo clause). I don't think anyone who was happy with their software being used under the terms of GPL 2 would be unhappy with it being used under the terms of the GPL 3 additio…
Yet another case of GPL virality causing more issues than it solves. E: Downvoters, have you read the article? The program started a new process for each address lookup instead of using a library because that library is GPL. Shall we have a discussion?
IMO it's not "GPL virality" that is at the root of the issue here. The authors' decision to license theis works this way causes the problem. You can still ask both libraries' authors for relicensing their work in a less restricted / more compatible way. If they don't want to do that, then being authors and owning their copyrights, that's their right to do. That's nothing I would blame on the GPL. I mean we should be…
But this is an example of the ugly side of open source licensing. A lot of people don't have strong feelings about ensuring the distribution terms of their code, and just don't care how it's used. And in those cases, it can be annoying to have e.g. opensource.org insist that GPLv3 is the best option.
Edit: To be more specific, I mean that this problem could be avoided if both softwares were released under a public-domain-equivelent license. But of course, that will never happen.
Earlier quoted context omitted.
While so far FSF have behaved responsibly it makes perfect sense for the Linux developers to not place their trust in an external organization.
The code was always going to be possible to use under GPL2, even if it said GPL2+. It's not really placing their trust with anyone since they wouldn't lose anything. It's more of a flag waving op to keep corporate interest -- corporate are notoriously disinterested in GPL3 projects, so Linux devs basically said "ok let's not let anyone fork as GPL3 and make significant work we can't benefit from". Then Linux stays re…
Earlier quoted context omitted.
You might as well blame GNU for updating from GPLv2+ to GPLv3+, creating the problem in the first place. Since, realistically, neither Linux nor GNU will budge, maybe the practical solution would be to look into integrating with the equivalent library in the LLVM ecosystem (assuming it exists).
It was always clear that gnu would create newer versions of the GPL and start releasing under it. The blame is pretty clearly on the people who editted the license text to be GPL2 only.
>The blame is pretty clearly on the people who editted the license text to be GPL2 only.
They edited the licence, yes, but the FSF explicitly wants you to do this to make your intention clear(1). When you licence software under the GPLv2 (or 3, etc) you have a choice of 'GPLv2 only' or 'GPLv2, or any later version', however since the licence text only states 'Version 2' with the old short labels being just 'GPL-2.0' there's some ambiguity on whether you mean GPL-2.0-only or GPL-2.0-or-later.
The default assumption should always be v2-only, however as (at the time) the FSF were still recommending the short label of GPL-2.0 and the issue of using v2-only or v2-or-later wasn't really an issue you had a lot of v2 licenced software and patches using the default unedited licence with the FSF short label of GPL-2.0 and this is purely the fault of the FSF. It wasn't until the GPLv3 came around which some people didn't like (notably the Linux kernel, which is probably why perf is v2-only) that you got people editing their licences to make the intention clear, although for many projects they had no choice in the matter as changing to v2-or-later would require permission from every copyright holder that had contributed code to that project, again this is partially the fault of the FSF for not having enough foresight or making the choice of -only or -or-later more explicit and clear.
P.S. if you already know the history and context here this post probably seems a little patronising and I apologise for that.
(1) https://www.gnu.org/licenses/identify-licenses-clearly.html
I would like to see a more general approach to solving the problem of "short lived processes are expensive". There needs to be a way to dynamically link a binary into your own address space, and call it's logic repeatedly, without incurring all the process startup overhead all the time. Pretty much, have all command line utilities be linkable like a library.