I'd guess polshaw wants to sell/distribute an appliance containing proprietary software (hence the reluctance to use a GPLv3 licensed component), not just install it on his own device.
No religious objection. The problem for me with GPLv3 is that it is not compatible with (privately) signed code. If it is possible to run unsigned code on my appliance then my proprietary code would not be secure, putting the entire business in jeopardy. If you can square this circle then I'd love to use it.
I'd be interested to see a list of shipping appliances (meaning not open hardware platforms) with GPLv3 if you know of any.
>No religious objection. The problem for me with GPLv3 is that it is not compatible with (privately) signed code. If it is possible to run unsigned code on my appliance then my proprietary code would not be secure, putting the entire business in jeopardy. If you can square this circle then I'd love to use it.
Your code is still under the full protection of the law. And no signing mechanism will prevent a competitor from simply dumping the flash and reading your code off there, if they really want to - if anything this is probably easier than running their own code on the system. So I don't see what using the GPLv3 changes.
If you're really paranoid, how about running samba in a chroot/jail/etc. where it has access to the data files it needs to serve/store, but not your code? (Your code can operate on the same data from outside the chroot). As long as you make it possible for the user to upgrade samba (which should be fine - you don't care what code runs inside this chroot, because it only has access to the same files the user could access via samba anyway, so the samba that runs in the chroot doesn't have to be signed) you're compliant with the GPL but haven't exposed the rest of your system.
If it is a straight rip-off then the law should protect (at least in the west), but if it were just used (for learning or adapting from) then it could be exceedingly hard to prove or even know about. I suppose what I would be most worried about is if it were leaked such that anyone could use it on any platform without paying. Who would buy an apple TV if you could run it off your raspberry pi? (I know the analogy doesn't quite work-- aTV is decent value as hardware-- but as a start up I will have higher costs so higher prices).
>flash dump
This is why you encrypt the private data on your flash :) Decryption codes can be stored in the processor (it's been a while since I looked at the system- I'll have to look again, but it seemed solid). So that means they'd have to either de-solder the RAM while somehow keeping it freezing cold too, or use an electron microscope or something on the CPU. If they are that capable then I'm sure they could just rewrite the code themselves without my 'help'. I'm not sure how much security compilation would offer, and if the details of that matter, that's something I should look into further. But the above seems pretty solid AFAICT.
>samba in a chroot/jail/etc
Thanks! This is a great idea. IIRC it is possible to break out of a chroot, but (IIRC again) not BSD jails.. so that could be a great option down the line if I am able to use BSD. It adds a fair amount of complexity legally (although it seems sound at first thought) and technically though (can they be hacked?), so perhaps one for later.
By "signed" do you mean a DRM-locked down platform ? There's no problem with signed code, there is a problem with trying to claim ownership of a device that the customer owns :-).
There are many appliances shipping with GPLv3 Samba, Netgear, Drobo, IOmega, Synology, just off the top of my head.
Of course none of these are trying to control what the customer does with the appliance.
If you want to control what customers do with their own hardware, write your own SMB3 server. Good luck with that..
Well thanks for replying I suppose. The reality is that the alternative is that customers get no SMB server, and will have to use other file interfaces. The appliances you mention.. well you didn't actually mention any specifically.. but going by the brands it sounds like you are referring to NAS boxes, in which case they are selling only hardware-- they have no valuable software of their own to protect, 99% just linux+samba, maybe they wrote a trivial control-panel backend. Show me a device that has a competitive advantage from its own software that uses GPLv3 code. 'Signed code only' does not have to mean customers aren't free with the hardware (I'd be quite happy to help wipe the device so they can do whatever they want), it just means potential competitors aren't free to steal my code and waste the investment of xyz man hours that went into that. As a consequence, those that mean no malice will lose freedom with my mix of software on the hardware they own, but they can remain free with their own software on the purchased hardware (as above. Except for GPLv3).
There are several cloud filesystem gateway appliances that contain considerable proprietary code on the appliance, and use Samba GPLv3 software to provide gateway services from SMB clients into the cloud.
I'm not at liberty to name them as I am the NAS boxes as most of them are not forthcoming about their use of Samba to anyone but their customers (to whom they provide replaceable source code of course), whereas the NAS vendors are well known users of GPLv3 Samba.
You seem to be under the impression that avoiding GPLv3 code prevents competitors from buying our box and rendering it down to components, including your precious software, and figuring out any trade secrets you may have.
This is a strange and incorrect impression.
If you genuinely want to use Samba in your proprietary appliance, email me (I'm easy to find). I help companies do this every day as part of my job.
You won't be able to use Samba outside of the terms of GPLv3 of course, but most companies not requiring DRM seem to be perfectly comfortable with that.
