<_whitenotifier-4>
[scopehal-docs] azonenberg c9d2156 - Fixed formatting of copy-pasteable code listings to be properly copy-pasteable on both PDF and HTML formats. Fixes #87.
<_whitenotifier-4>
[scopehal-docs] azonenberg closed issue #87: Documentation: Ubuntu and Debian HTML pages have double line breaks so apt-get install x \ ... (next line) is treated as a new command, which fails - https://github.com/ngscopeclient/scopehal-docs/issues/87
<_whitenotifier-4>
[scopehal-apps] azonenberg caef0e0 - Updated to latest scopehal-docs
<azonenberg>
aaand with that, we're down to a single digit number of tickets blocking the v0.1 release
<azonenberg>
(plus cutting a final version of the docs talking about installing packages etc, and reformatting the website to have "latest" and v0.1 release docs, etc - but that will all come later)
<_whitenotifier-4>
[scopehal] azonenberg 319b2ce - ACRMS: Fixed bug where AC RMS measurement would sometimes truncate the last sample in the GPU implementation
<azonenberg>
miek: so it looks like the GPIB driver we have now depends on linux-gpib which is GPLv2 only
<azonenberg>
Thoughts on how to proceed? We can't ship a release that links to GPL code
<azonenberg>
It's currently an optional build time component
<azonenberg>
I suppose we can make it be off by default and then add a separate ENABLE_GPL cmake flag
<azonenberg>
since the vast majority of users probably won't be using gpib hardware and those that are can always compile themselves
<azonenberg>
but a long term solution is needed
<d1b2>
<josHua> is there a reason you cannot ship a GPL-covered binary?
<d1b2>
<josHua> (are there proprietary components that conflict?)
<d1b2>
<azonenberg> Project policy, for the most part. We want to be compatible with third party proprietary plugins etc
<d1b2>
<azonenberg> None currently exist but we want to allow it
<d1b2>
<azonenberg> And that is not going to change
<d1b2>
<azonenberg> The goal is to become an industry standard T&M API and that means being compatible with blobs
<d1b2>
<josHua> hmm are plugins dynamically loaded? if so, you are good on GPL components (a user can certainly dynamically load a proprietary plugin into a GPL-covered app of their own)
<d1b2>
<azonenberg> Plugins are dynamic, yes. But still, per project policy, we do not use GPL dependencies
<d1b2>
<josHua> and if not, it does not matter, because you are not going to ship a binary that has both a proprietary blob and a GPL component yet
<d1b2>
<azonenberg> Not sure how this slipped through the cracks
<d1b2>
<josHua> it is a fair policy, though I guess my point is it may not need to be an emergency blocking 1.0
<d1b2>
<azonenberg> We want to support use cases like a scope vendor shipping ngscopeclient plus a proprietary driver as an on device UI, etc
<d1b2>
<josHua> right
<d1b2>
<azonenberg> I would rather disable gpib support than ship a GPL release
<d1b2>
<azonenberg> We can easily do that and ship v0.1 without gpib enabled
<d1b2>
<azonenberg> then users can turn it on manually if they are ok with their local copy being GPL
<d1b2>
<josHua> reasonable
<d1b2>
<azonenberg> I suppose one possibility would be to refactor the gpib driver into a separate repo that builds as a plugin
<d1b2>
<azonenberg> similar to how gstreamer splits up plugins by license compatibility etc
<d1b2>
<josHua> which would also be good as an example of how to write a plugin in a separate repo
<d1b2>
<azonenberg> I've thought about modularizing scopehal to have scope drivers move to a plugin library etc too and keep the core library simple
<d1b2>
<azonenberg> So this is not implausible
<d1b2>
<josHua> it would also be nice to reduce the link size when developing only on a scope driver
<d1b2>
<azonenberg> Yeah I'm picturing an eventual structure where scopehal is just base classes and core math blocks a lot of other stuff uses like "get average value of waveform"
<d1b2>
<azonenberg> then we have either one plugin for all drivers or even one per vendor or something
<d1b2>
<azonenberg> and then perhaps filter graph blocks done similarly, idk
<d1b2>
<azonenberg> anyway, i think that's the cleanest solution
<azonenberg>
Made a scopehal-plugins-gpl repo skeleton and will work on migrating stuff over
<azonenberg>
There's no proprietary linking exception, so basically if you are running a closed source fork of ngscopeclient or including blob plugins you can't also use that plugin technically
<_whitenotifier-4>
[scopehal-docs] azonenberg 14f8855 - Removed references to linux-gpib from getting started section. Added note to scopehal-plugins-gpl under the transports section.