131–140 of 224 posts
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.
Earlier quoted context omitted.
Can someone ELI5 to me where the problem is because both perf and bfd seem to be GPL. Why would the former not be allowed to link to the latter?
Most GPL licenses permits their code to be redistributed as the same GPL version or any later version of the GPL, Linux releases as GPLv2 or later for example. Perf does not permit the license to be redistributed as anything except GPLv2, so it conflicts with GPLv3 code.
Linux doesn’t use “or later”. https://github.com/torvalds/linux/blob/master/COPYING:
The Linux Kernel is provided under:
SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
LICENSES/preferred/GPL-2.0
LICENSES/exceptions/Linux-syscall-note
Documentation/process/license-rules.rst
All contributions to the Linux Kernel are subject to this COPYING file.
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…
> carefully avoiding making the code too similar to what I happen to remember Is this really necessary? The GPL allows you to read and study the software. Is it really copyright infringement if you take your understanding and make your own program? Are people really forced to come up with convoluted new ways to solve the same problem just to avoid any similarity to existing work?
- Striking similarity, or what most of us think of as infringement, where there's literal copies of someone else's code in your own. This is what things like content ID systems try to detect.
- Access plus substantial similarity. This is where you've looked at someone else's code (source or disassembled, doesn't really matter); and then produced something that looks a lot like that code if you squint a little.
Substantial similarity does not have a hard-and-fast rule associated with it, it's usually something that juries or judges decide. It's basically the "yeah just change it a little so the teacher doesn't notice" meme, but in legal form. If you were to read another program's code, and then make another program that looked an awful lot like the first, then you'd be infringing. But this is bounded by other exceptions to and rules of copyright - notably, functionality itself can't be copyrighted, and copyright over interfaces is largely prescribed by various fair use decisions (so emulation and re-implementation is largely still OK even under this standard).
If you read GCC, and then write LLVM, that's not substantial similarity. That's a different, legally distinct compiler design. The FSF could sue the pants off Apple if merely reading GCC source meant any compiler you wrote was infringing.
If you read GCC, and then write a compiler with the same internal representation as GCC; a parser that's structured the same way as GCC; and optimization passes that are organized the same way as GCC's; then you're closer to infringing.
Your responsibility isn't to create an entirely novel program by any means necessary. It's just to avoid doing the software equivalent of tracing over someone else's drawing.
Earlier quoted context omitted.
Not really, or at least the license would be very unappealing. You'd need a method of determining revenue and then apportioning revenue amongst the many parts of a system. Then there's transfer pricing issues. Not to mention audit requirements. See also Hollywood accounting. One of the ways open source gets adoption is because using open source with an acceptable license is often much less hassle than paying for comm…
Yeah it's frustrating, i would never work on a open source project as i don't really get why companies can make money using something from the unpaid labour of someone else, and for our society that's acceptable
List and more references: https://github.com/LibreCybernetics/awesome-copyfarleft
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.
While so far FSF have behaved responsibly it makes perfect sense for the Linux developers to not place their trust in an external organization.
Oh no I hoped it was about speeding up perf record that is actually a big thorn on my side, one I wrote a specific tool for... Depending on the number of probes you use, perf record can induce large latency hits or reduced throughput. Batching/buffer disk writes solves the problem for me. But I had to redevelop a perf parser to record/compress smarter. And for network streaming (no touching the disk is even better...…
It'd be nice if perf record had a fundamentally faster way of working. I found a nice description of how it works in the README.md for cargo-trace: "perf relies on perf_event_open_sys to sample the stack. Every time a sample is taken, the entire stack is copied into user space. Stack unwinding is performed in user space as a post processing step. This wastes bandwidth and is a security concern as it may dump secrets like private keys."
cargo-trace is apparently dormant now, but I found it really interesting. It does the unwinding via eBPF instead, which should be quicker while recording, not generate as much (sensitive) data, and not require as much post-processing. (Symbolization would still happen in post-processing.)
> 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.
Kind of ironic that RMS campained against proprietary software to allow reuse of code. Now we have two islands of open source code ... .
As drran mentioned, I'm sure RMS would say the problem here is that Linux is licensed under v2 only. Linus of course would disagree.
Earlier quoted context omitted.
What is a good source to get an understanding of all the Licenses and their relation?
Here's a brief summary of major licenses: MIT, X11, BSD (2- or 3-clause), and more similar ones I can't name off the top of my head: these are the basic do-what-you-want license, the only requirements are things that every (good) license already has, such as standard limitation-of-warranty clauses and retention of copyright notice requirements. Apache (v2): This is the next stage up, which means that the text is leng…
IMO, the gist of the GPL boils down to:
> If you "distribute" a "derived work" of this code, you have to release your code as well (under the same terms.)
AGPL not only interprets "distribute" to mean "offer up as a service over the network", but it also interprets "derived work" the same way. This is why anyone who uses (say) MongoDB in a company basically has to pony up for the commercial license, lest they be required to open source huge parts of their company.
> 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.
I've often wondered why more linux distros don't provide a similar tool to build ZFS into the kernel for you.