bcaa7f3a8bbc
Joined 9 years ago
Joined 9 years ago
I think it's a reasonable position to take. Reducing the scope of fair use to strengthen copyleft is a double-edged sword, as it simultaneously makes copyright laws more restrictive, such a ruling can potentially be used by proprietary software vendors against the FOSS community in various ways. It's an issue that requires careful considerations.
[0] https://www.fsf.org/blogs/licensing/fsf-funded-call-for-whit...
Previously he also claimed "the freenode network is its own sovereign state", So I'm pretty sure he's just trolling here.
As the author later pointed out: it's not a new idea, FreeBSD has been doing it for decades. Nevertheless, I agree it deserves broader uses.
> Where Did We Go Wrong? TRANSFORMERS were essential elements of EVERY balanced interface 50 years ago ... High noise rejection was taken for granted but very few engineers understood why it worked. Differential amplifiers, cheap and simple, began replacing audio transformers by 1970. Equipment specs promised high CMRR, but noise problems in real-world systems became more widespread than ever before ...Reputation of balanced interfaces began to tarnish and “pin 1” problems also started to appear!
> Why Transformers are Better. Typical “active” input stage common-mode impedances are 5 kΩ to 50 kΩ at 60 Hz. Widely used SSM-2141 IC loses 25 dB of CMRR with a source imbalance of only 1 Ω. Typical transformer input common-mode impedances are about 50 MΩ @ 60 Hz. Makes them 1,000 times more tolerant of source imbalances – full CMRR with any real-world source.
> CMRR and Testing. Noise rejection in a real interface depends on how driver, cable, and receiver interact. Traditional CMRR measurements ignore the effects of driver and cable impedances! Like most such tests, the previous IEC version “tweaked” driver impedances to zero imbalance. IEC recognized in 1999 that the results of this test did not correlate to performance in real systems... My realistic method became “IEC Standard 60268-3, Sound System Equipment - Part 3: Amplifiers” in 2000. The latest generation Audio Precision analyzers, APx520/521/525/526, support this CMRR test!
[0] https://www.aes-media.org/sections/pnw/pnwrecaps/2005/whitlo...
> One of the big claims for many audiophile op amps is lower noise. The chip manufactures make a big deal about it and audiophiles, not surprisingly, have jumped on the bandwagon. But, in reality, it’s often the Johnson Noise that limits the noise performance of a headphone amp, not the op amps. Johnson Noise is, literally, self generated noise that’s present in any resistor. The larger the resistor value, the more noise you get. Many DIY headphone amp designs have the volume control at the input to the gain stage. And it’s, at the lowest, usually 10,000 ohms. By comparison the O2 has 274 ohms in series with the input. That’s a huge difference in Johnson Noise. The way volume controls work, the noise is typically worst at half volume where you have 5000 ohms in series with the source and 5000 ohms to ground. So, at typical volume settings, you get a fair amount of Johnson Noise from the volume control that’s amplified by whatever gain your amp has. That noise typically exceeds the op amp’s internal noise. If you put the volume control after the gain stage its Johnson Noise is no longer amplified. And, as a bonus, the volume control at lower settings now attenuates noise from the gain stage. For more, see O2 Circuit Description and Circuit Design.
> To put these numbers in perspective, referenced to the old 400 mV they’re –105.3 dBr and –108.2 dBr. On the exact same test, at half volume, the Mini3 had nearly 11 dB more noise and measured –94.5 and –97.5 dB. Noise of –113 dB below 1 volt is under 3 microvolts.
[0] https://spectrum.ieee.org/tech-history/silicon-revolution/nw...
[1] https://nwavguy.blogspot.com/2011/07/o2-headphone-amp.html
[0] https://descanso.jpl.nasa.gov/monograph/series10/Reid_DESCAN...
Also, if anyone has a high quality photo of the Philips PM5544 video signal generator, please upload it to Wikipedia. This machine is an important artifact of popular culture, yet photos of the signal generator itself is uncommon on the web (and many people mistakenly believed the PM5544 is just a test card, not a signal generator), but so far there's no high-quality photo under a free license. (Or leave a comment if you have the actual machine, I'd pay $1000 for that. If I ever get the machine, I'll take a photo and upload it, and write a blog post about how the circles and lines are drawn by the analog circuitry). Finally, manuals, manuals and manuals: I'm willing to buy any documents about the Philips PM5544 (or any notable signal generators) to get them digitized. Currently the only document on the web is an issue of Philips Electronic Measuring and Microwave Notes [0] that only briefly mentions a tiny bit of its inner working.
[0] https://frank.pocnet.net/other/sos/Philips_PM5544_PM3400_Pub...
This is exactly what I was thinking about. If Copilot is fair use, it means that all proprietary source code, as long as they're publicly available to read, will be free to use as training materials for a hypothetical free and open source machine learning project, which I think would be a good thing. An example is a proprietary program released under a restrictive "source available" license, you can read it but not reuse it under any circumstances (and I believe these projects are already included in Copilot's training data). This is why I said fair use can be a good thing and a ruling to reduce the scope of fair use can potentially be used by proprietary software vendors against the FOSS community.
It would be even better if training from all forms of available proprietary binary code can be fair use, too. It may allow the creation of powerful static binary analysis or code generation tools by learning from essentially all free-to-download proprietary software without copyright restrictions. However, the situation of proprietary binary code is more complicated here. Reverse engineering proprietary binary code is explicitly permitted by the US copyright laws, but the "no reverse engineering" clause in EULA overrides it, and this can be a bad thing. It makes FOSS's fair use right meaningless, meanwhile giving proprietary software vendors a free pass to ignore FOSS licenses.
Thus the outcome is unclear, it may go either way, this is why I said such an issue requires careful considerations.