I am working on the assembly instructions and support software; I am expecting the boards end of next week, so I should be able to start selling kits early February.
I've got the BOM done, and I am ordering parts I am low on so they arrive by the time the boards arrive
Set the SUID bit for the script associated with the power button, or whatever script you want. Have it be owned by a user capable of shutdown, or root if you want.
Make it read and execute by whatever user you are running as.
Once done, that script will have the owner permissions yet can be executed by an ordinary user.
Just make a program that monitors a GPIO bit and issues a shutdown when required. Run it as root from a start up from a normal daemon start script.
Question is what does it mean to monitor? I would imagine polling ten times per second or so would do and not eat too much CPU time. Make sure it runs as a high priority so that it never gets sidelined.
- The build manual is nine pages long right now - but once I add all the photos it will get a lot larger.
- I've figured out a simple serial protocol for controlling RoboPi from a Pi, I hope to have that running by Thursday.
- I am anxiously waiting for the production boards... tracking shows my package is now in LA, means I should get it Wednesday
- I'll also be receiving production "Pi Jumper"'s in this shipment (nice Pi GPIO breakout board, with both 3v3 and 5v I2C expansion)
I am soooo tempted to play with the latest Propeller 2 FPGA image, but I am making myself wait until after the manual and initial serial protocol are done.
From curiosity.... how do you connect the serial from the Pi and the serial from the Prop plug? Do you use something to isolate one from the other? In thinking about this I think it's necessary to isolate at least the TX lines on the two. Since the transmitter sets the idle state, one can't transmit while the other is connected but idle. I was considering diodes but the drop would be pretty rough. Do you just put in a switch?
The Raspberry Pi has a UART available on the GPIO headers.
That UART can be used to program the Propeller. Direct connection to Prop programming pins. No PropPlug required.
After programming that UART is used to chat to the running Propeller application.
All very simple.
He's providing a PropPlug connection as well though so I would assume some protection must be there in case the plug and the Raspberry UART are connected at the same time since he indicates that you can use either method. Maybe his plug is only for stand-alone development though.
- clean up the schematic (in progress)
- add a jpeg showing the top silk screen layer to the manual
- take photos of the steps involved in assembling RoboPi
- more textual descriptions of the various steps
- test the manual by building a board following the instructions
I am taking the time to make this manual as good as the original Morpheus build manual.
For software I need to:
- make a RoboPi diagnostic program (from the RoboProp diagnostic - basically remove the L298 tests)
- write the Pi side of the RoboPi control protocol
- write the Prop side of the RoboPi control protocol
- write some demos for "Pi controlling RoboPi" (port simple RoboProp demos to C on the Pi, using the control protocol)
Fortunately I am making a very simple protocol, so the software should not take much time.
He's providing a PropPlug connection as well though so I would assume some protection must be there in case the plug and the Raspberry UART are connected at the same time since he indicates that you can use either method. Maybe his plug is only for stand-alone development though.
Actually, if you program TX, RX and #17 on the Pi as inputs, you could use a PropPlug. Still, not recommended.
I am about to start building another RoboPi, following my instructions in the build manual - to make sure the instructions are correct and the best build sequence is the one used.
I'll be taking the pics for the manual as I build, I expect to release the build manual this weekend.
Most of you here on the forum are better off ordering the "Lite" kit without the Propeller, EEPROM and ADC - heck you probably have those parts already!
Progress report:
The manual is up to rev 0.60, and I have taken all of the shots of the build process today, as I built up a board according to my build instructions.
I tweaked the build order to make it easier to build, and I will be editing and adding the photos. I expect the manual will be complete in two or three days - however it is already detailed enough to build the board from. I've also started working on some demos and a diagnostic, I should be posting working code in two - three days, and some YouTube videos next weekend.
I will be upgrading to Heater's latest build of SimpleIDE this week as well.
I will be going to the post office tomorrow to ship some RoboPi's and EZasPi's that have been sold so far (thanks),
If you would like a RoboPi shipped to you tomorrow, PM me (or better yet, email me at mikronauts(at)gmail(dot)com
- your snail mail address
- email address you use for PayPal
- exactly what you would like to buy
As long as I get payment by 3pm tomorrow, I can ship your RoboPi tomorrow, which means you'd likely get the boards next week.
Example shipping rates to Continental US (not including Hawaii, Alaska, Puerto Rico)
(shipping normally takes 4 - 10 business days (usually 3 - 5 for major centers))
(1) one only RoboPi Lite Kit only - $8.00USD s/h + $24.95 for a total of $32.95 ... not insured, not trackable
(2) Any combination of my boards, up to $100USD in value, $16.50USD s/h INSURED, TRACKED shipping
That is enough for:
- two RoboPi Full Kits ($49.95 * 2) or
- four RoboPi Lite Kits ($24.95 * 4) or
- two RoboPi Lite Kits and four EzAsPi prototype boards ($2 * $24.95 + $12.95 * 4)
(3) Larger orders, non-continental US orders... email for shipping quote.
You get the idea
My next post office run will probably be Wednesday next week.
Technically if you distribute a Raspbian SD image you should be prepared to provide source code for all the GPL licensed programs on it.
Linking customers back to the Raspbian web site is not sufficient.
That's a shame because in my mind that would be a nice touch in that I'm not needing to go grab bits and pieces from various places to install the things needed to make useful projects. I suspect it's not a huge issue as the main requirement is SimpleIDE but before you do much useful on the Pi with any GPIO you're probably going to want somebody's library for that as well.
You are right. If memory serves, one can charge for the service of providing the source code. If so, when someone asks, I can provide the link to the raspbian source archive, and offer to fetch the sources for them, and burn them to dvd, charging hourly consulting rates for the service, plus shipping and handling. I think they would choose to go to the debian & raspbian source trees.
photomankc,
I need to look into it more. If it ends up not taking up too much time or hassle, I could do it, but would have to charge. It does seem to me that a lot of people would place a value on not spending a few hours downloading, image writing, updating, library fetching etc.
All,
Docs are coming along... I hope to release them Monday.
Should I start offering pre-configured SD cards for RoboPi?
Pre-loaded with SimpleIDE, serial console disabled, xrdp, RoboPi docs, libs, demos?
I was considering doing this before, but I was not sure if people would be willing to pay for it.
I think this idea has merit. Saves a lot of trawling, and users can run very quickly.
These days the price of bottom-end USB or SD storage, tends to be somewhat static, what you get for that money just quietly doubles every xx months.
That storage is now large enough that you can RUN code from the Flash Drives.
If you test apps for run-in-place where practical, that also helps confirm a simple copy-install work.
As I understand it you have to be prepared to provide the actual source used to build the binary you have delivered. Pointing people to some other web site is not sufficient. Who is to say that is the same stuff?
Holding source to ransom for consulting fees after having delivered the binary is certainly against the spirit of the GPL. The source is not Free in that situation. (Note capital F in "Free")
There is no "holding to ransom". I would not be generating the Raspbian or modifying the Rasbian binaries, I would be providing a service of pre-installing them on an SD card.
the Pi foundation is not adhering, as "Noobs" SD cards they sell do not include the source.
Interesting discussion, points to a major problem with the GPL. It makes it too onerous for small companies to distribute GPL systems.
Logically, pre-installing a given Raspbian release from a Raspbian installer, and pointing to the official Raspbian source repo's (which come to think of it, apt-get already points to) should be more than sufficient. If any source files were modified, including the modified source files should suffice.
As I understand it you have to be prepared to provide the actual source used to build the binary you have delivered. Pointing people to some other web site is not sufficient. Who is to say that is the same stuff?
Holding source to ransom for consulting fees after having delivered the binary is certainly against the spirit of the GPL. The source is not Free in that situation. (Note capital F in "Free")
No problem with distributing the binaries even if you were to ask huge media, packaging, consulting, support, whatever, fees to do so.
The "ransom" part is asking for money again to get the sources.
The sources do not need to be included in a binary distribution, only be available if asked for.
I do agree that logically this is a bit onerous and that in a case like this a link back to the upstream repo should be good enough.
One problem with this though is that after you have built an SD image and distributed it the Debian repos are advancing and up dating all the time. This means it's quite hard to get the exact sources that were used to build that image you are distributing.
There seems to be a bit of a legal technicality here. If I give you my GPLed programs and you pass them on to a third party as binaries saying that the source is available form me. Then you are trying to pass your obligations under the license on to me. That cannot be right because I cannot vouch that the binaries you are distributing are actually from the same code I gave you.
The "ransom" part is asking for money again to get the sources.
That is OK according to the GPL, and RMS himself. But there is actually a limit there, will come back to that. For GPL binaries you can charge as much as you wish, a billion dollars for example (GNU's example - see links below). Same with binaries plus source.If you provide only binaries, gratis or not, then (and only then) there's a special limit on how much you can charge for providing the sources too (if you choose the physical medium method: "[..], for a price no more than your reasonable cost of physically performing this conveying of source"
However, it is _also_ fine to simply provide a link to a 3party site: "[..]]the Corresponding Source may be on a different server (operated by you or a third party)" (in that case you don't get to charge extra for providing the link to the source though)
If I give you my GPLed programs and you pass them on to a third party as binaries saying that the source is available form me. Then you are trying to pass your obligations under the license on to me. That cannot be right because I cannot vouch that the binaries you are distributing are actually from the same code I gave you.
Correct, you're still under the obligation to provide the original source. You (er, Bill?) can keep pointing to a 3party server as long as that one actually contains the correct sources. If they become unavailable you (as the provider of the GPL binaries) have to follow up and come up with a new or updated link to the correct sources. The obligation itself cannot be passed on, but you can use 3party sources as long as they're actually there. Heater cannot and should not vouch for those sources being correct, that's still Bill's obligation - he can still point to your original sources though, it's just that it's not Heater's responsibility.
-Tor
(Edit - tried to untangle all the 'You' in there.. Heater is now the original GPL source provider, Bill built binaries and distributed them.)
Perhaps you are right and pointing back to Raspian and SimpleIDE upstream sources is OK if those are actually the correct sources.
That leaves a question: If I give you my six month old Raspian SD card with Simple IDE and whatever on it how do I point you to the exact same six month old versions of all the packages? Assuming I have done no updating in the mean time.
For things like SimpleIDE it's easy. I might know the git tag in the repo or the revision hash or whatever it is. Then I can tell you exactly what to fetch.
I have no idea how you do that for old versions of Debian/Raspian packages. I guess there must be a way.
Only one nit to pick... I would not be building the binaries.
Heater,
What if the "Noobies" SD the Pi Foundation has a six month old Raspbian?
Discussion:
Case 1: "Old School"
Customer wants to run an Application, that runs on a GPL'd OS.
Customer hires Vendor to install the OS, configure the computer, and install the Application, and make sure the Application works.
Vendor travels to customers site, downloads the OS binary installer, performs the service, and gets paid by the Customer.
This is a service, not distributing the OS.
Case 2: "Save travel time"
Customer was happy, told friend 1000 miles away.
Friend does not want to fly Vendor to his site.
Customer FedEx's the computer he wants the OS and Application installed on to the Vendor.
Vendor downloads the OS binary installer, performs the service, FedEx's the computer with installed OS and Application to Customer, and gets paid by the Customer.
Case 3: "Save on FedEx"
Friend tells his Buddy on another continent... who can't afford to fly the vendor in, indeed cannot afford to FedEx the computer to the Vendor for the installation service.
Customer asks Vendor to buy the boot drive (SD card) for his computer, and also asks the Vendor to use an in-house computer to do the installation of the OS and the Application, then FedEx the installed drive back to Buddy.
Vendor buys an SD card, downloads the OS binary installer, performs the service, FedEx's the SD card with installed OS and Application to Customer, and gets paid by the Customer.
Case 4: "Buddy tells the world, a lot of people want the pre-installed SD card"
Vendor wants to provide the service in such a way that it is affordable, without losing money doing so.
Customers pre-pay a reasonable price for the installed SD card.
To make it affordable, Vendor sets up a dedicated computer, and every time there is a release of the OS, downloads the installer, installs the OS, configures it, installs the Application. Vendor keeps the OS image around on his server, costs too much time to download the same image every time.
The Vendor then images the SD card to a server, and whenever a Customer orders a card, images the latest (image stored on the server) to the card.
Vendor mails the installed card to the Customer, who is happy at the much more affordable price (and cheap shipping compared to FedEx).
Summary
In NONE of the cases is the Vendor compiling the binaries from the source.
Case 1 & Case 2 are clearly outside the scope of the GPL license.
Case 3 is indistinguishable from Case 2, except the Vendor provides the SD card.
Case 4 is impossible to distinguish from Case 3 if the Vendor does the imaging of the SD card upon receipt of order from the customer.
Case 4 is possibly distinguishable from Case 3 if the Vendor images 100 SD cards before he receives the orders.
What does this tell us?
This usage case was not considered when the GPL was drafted.
Vendor is not responsible for the OS install image being changed, as Vendor did not compile that OS.
Specifics
Now in my specific case, I am considering case 4, as a service to those who do not want to download the installer, install Raspbian, configure it, install the Application.
Extremely narrowly viewed, I supposed one could consider it distributing the OS - but in reality it is a service.
Given that I would not be building the binaries, I don't think I'd have to do more than point to the repository of sources for the OS and SimpleIDE, arguably pointing out that apt-get can get the source of packages is sufficient.
Regarding "how can I be sure it is the same" - easy. Download the installer, install on a different card... md5 is your friend.
Regarding charging for retrieving the source, and burning a DVD for a customer - there is nothing in the GPL saying that I'd have to do it at a loss, so charging my normal charge-out rate is reasonable. There is absolutely no requirement that the vendor take a financial loss to provide the sources that the customer could get themselves.
Regarding the exact same version... GPL is all about keeping source code free, not about keeping every minor revision available after a new version is out.
About paying for the SD card... everyone could replicate the installation of the OS, SimpleIDE, etc. from my documentation, and anyone could provide that service.
About installing my application / docs / etc.... that would depend on the license I used for them (probably GPL)
----
Interesting discussion, but I won't have time to revisit it until at least tonight, maybe tomorrow morning.
----
Bringing back the topic to RoboPi
I'm continuing working on the manual. I will eventually have to re-take some shots as I decided to change the build order.
Comments
Latest SimpleIDE v0-45-9 is announced here:
http://forums.parallax.com/showthread.php/141469-SimpleIDE-for-Raspberry-Pi-Raspian?p=1237285&viewfull=1#post1237285
No load via UART yet, comming soon...
I am working on the assembly instructions and support software; I am expecting the boards end of next week, so I should be able to start selling kits early February.
I've got the BOM done, and I am ordering parts I am low on so they arrive by the time the boards arrive
I should be receiving them on Wednesday next week.
Production Pi Jumper boards are also arriving in the same shipment. I'd better get the BOM and pricing ready for Pi Jumper as well.
Set the SUID bit for the script associated with the power button, or whatever script you want. Have it be owned by a user capable of shutdown, or root if you want.
Make it read and execute by whatever user you are running as.
Once done, that script will have the owner permissions yet can be executed by an ordinary user.
No need for SUID.
Just make a program that monitors a GPIO bit and issues a shutdown when required. Run it as root from a start up from a normal daemon start script.
Question is what does it mean to monitor? I would imagine polling ten times per second or so would do and not eat too much CPU time. Make sure it runs as a high priority so that it never gets sidelined.
- The build manual is nine pages long right now - but once I add all the photos it will get a lot larger.
- I've figured out a simple serial protocol for controlling RoboPi from a Pi, I hope to have that running by Thursday.
- I am anxiously waiting for the production boards... tracking shows my package is now in LA, means I should get it Wednesday
- I'll also be receiving production "Pi Jumper"'s in this shipment (nice Pi GPIO breakout board, with both 3v3 and 5v I2C expansion)
I am soooo tempted to play with the latest Propeller 2 FPGA image, but I am making myself wait until after the manual and initial serial protocol are done.
Like wifey says - work first, play later.
From curiosity.... how do you connect the serial from the Pi and the serial from the Prop plug? Do you use something to isolate one from the other? In thinking about this I think it's necessary to isolate at least the TX lines on the two. Since the transmitter sets the idle state, one can't transmit while the other is connected but idle. I was considering diodes but the drop would be pretty rough. Do you just put in a switch?
That UART can be used to program the Propeller. Direct connection to Prop programming pins. No PropPlug required.
After programming that UART is used to chat to the running Propeller application.
All very simple.
What heater said
all:
Documentation is up to 11 pages now.
I still need to:
- clean up the schematic (in progress)
- add a jpeg showing the top silk screen layer to the manual
- take photos of the steps involved in assembling RoboPi
- more textual descriptions of the various steps
- test the manual by building a board following the instructions
I am taking the time to make this manual as good as the original Morpheus build manual.
For software I need to:
- make a RoboPi diagnostic program (from the RoboProp diagnostic - basically remove the L298 tests)
- write the Pi side of the RoboPi control protocol
- write the Prop side of the RoboPi control protocol
- write some demos for "Pi controlling RoboPi" (port simple RoboProp demos to C on the Pi, using the control protocol)
Fortunately I am making a very simple protocol, so the software should not take much time.
Developing on the Pi is more than fast enough; I have not even been tempted to also plug in a PropPlug.
Got it..... Do not connect both!
A Raspberry Pi makes a very good Prop Plug, for about the same price. With the added advantage that you don't even need a PC
I am about to start building another RoboPi, following my instructions in the build manual - to make sure the instructions are correct and the best build sequence is the one used.
I'll be taking the pics for the manual as I build, I expect to release the build manual this weekend.
See post #1 for details and pricing,
Most of you here on the forum are better off ordering the "Lite" kit without the Propeller, EEPROM and ADC - heck you probably have those parts already!
Progress report:
The manual is up to rev 0.60, and I have taken all of the shots of the build process today, as I built up a board according to my build instructions.
I tweaked the build order to make it easier to build, and I will be editing and adding the photos. I expect the manual will be complete in two or three days - however it is already detailed enough to build the board from. I've also started working on some demos and a diagnostic, I should be posting working code in two - three days, and some YouTube videos next weekend.
I will be upgrading to Heater's latest build of SimpleIDE this week as well.
If you would like a RoboPi shipped to you tomorrow, PM me (or better yet, email me at mikronauts(at)gmail(dot)com
- your snail mail address
- email address you use for PayPal
- exactly what you would like to buy
As long as I get payment by 3pm tomorrow, I can ship your RoboPi tomorrow, which means you'd likely get the boards next week.
Example shipping rates to Continental US (not including Hawaii, Alaska, Puerto Rico)
(shipping normally takes 4 - 10 business days (usually 3 - 5 for major centers))
(1) one only RoboPi Lite Kit only - $8.00USD s/h + $24.95 for a total of $32.95 ... not insured, not trackable
(2) Any combination of my boards, up to $100USD in value, $16.50USD s/h INSURED, TRACKED shipping
That is enough for:
- two RoboPi Full Kits ($49.95 * 2) or
- four RoboPi Lite Kits ($24.95 * 4) or
- two RoboPi Lite Kits and four EzAsPi prototype boards ($2 * $24.95 + $12.95 * 4)
(3) Larger orders, non-continental US orders... email for shipping quote.
You get the idea
My next post office run will probably be Wednesday next week.
Now I'll resume writing documentation...
Useful links:
http://www.mikronauts.com/raspberry-pi/robopi/
http://www.mikronauts.com/raspberry-pi/ezaspi/
http://www.mikronauts.com/raspberry-pi/ezaspi-b/
http://forums.parallax.com/showthread.php/153677-Wish-List?p=1240907&viewfull=1#post1240907
Thank you re/ RoboPi
Should I start offering pre-configured SD cards for RoboPi?
Pre-loaded with SimpleIDE, serial console disabled, xrdp, RoboPi docs, libs, demos?
I was considering doing this before, but I was not sure if people would be willing to pay for it.
I'll move this part of the discussion to my RoboPi thread so we don't clutter this one.
I'd appreciate your input.
Should I offer a 16GB "Raspbian - RoboPi" SD card pre-configured for Propeller / RoboPi development?
Linking customers back to the Raspbian web site is not sufficient.
I suspect you don't want to get into that.
You are right. If memory serves, one can charge for the service of providing the source code. If so, when someone asks, I can provide the link to the raspbian source archive, and offer to fetch the sources for them, and burn them to dvd, charging hourly consulting rates for the service, plus shipping and handling. I think they would choose to go to the debian & raspbian source trees.
photomankc,
I need to look into it more. If it ends up not taking up too much time or hassle, I could do it, but would have to charge. It does seem to me that a lot of people would place a value on not spending a few hours downloading, image writing, updating, library fetching etc.
All,
Docs are coming along... I hope to release them Monday.
I think this idea has merit. Saves a lot of trawling, and users can run very quickly.
These days the price of bottom-end USB or SD storage, tends to be somewhat static, what you get for that money just quietly doubles every xx months.
That storage is now large enough that you can RUN code from the Flash Drives.
If you test apps for run-in-place where practical, that also helps confirm a simple copy-install work.
I don't think that is right.
As I understand it you have to be prepared to provide the actual source used to build the binary you have delivered. Pointing people to some other web site is not sufficient. Who is to say that is the same stuff?
Holding source to ransom for consulting fees after having delivered the binary is certainly against the spirit of the GPL. The source is not Free in that situation. (Note capital F in "Free")
Frankly, under the strictest reading of
https://www.gnu.org/licenses/gpl.html#section6
the Pi foundation is not adhering, as "Noobs" SD cards they sell do not include the source.
Interesting discussion, points to a major problem with the GPL. It makes it too onerous for small companies to distribute GPL systems.
Logically, pre-installing a given Raspbian release from a Raspbian installer, and pointing to the official Raspbian source repo's (which come to think of it, apt-get already points to) should be more than sufficient. If any source files were modified, including the modified source files should suffice.
No problem with distributing the binaries even if you were to ask huge media, packaging, consulting, support, whatever, fees to do so.
The "ransom" part is asking for money again to get the sources.
The sources do not need to be included in a binary distribution, only be available if asked for.
I do agree that logically this is a bit onerous and that in a case like this a link back to the upstream repo should be good enough.
One problem with this though is that after you have built an SD image and distributed it the Debian repos are advancing and up dating all the time. This means it's quite hard to get the exact sources that were used to build that image you are distributing.
There seems to be a bit of a legal technicality here. If I give you my GPLed programs and you pass them on to a third party as binaries saying that the source is available form me. Then you are trying to pass your obligations under the license on to me. That cannot be right because I cannot vouch that the binaries you are distributing are actually from the same code I gave you.
However, it is _also_ fine to simply provide a link to a 3party site: "[..]]the Corresponding Source may be on a different server (operated by you or a third party)" (in that case you don't get to charge extra for providing the link to the source though)
More reading here: http://www.gnu.org/philosophy/selling.html
and section six of the GPL for the cost of source: http://www.gnu.org/licenses/gpl.html#section6
Correct, you're still under the obligation to provide the original source. You (er, Bill?) can keep pointing to a 3party server as long as that one actually contains the correct sources. If they become unavailable you (as the provider of the GPL binaries) have to follow up and come up with a new or updated link to the correct sources. The obligation itself cannot be passed on, but you can use 3party sources as long as they're actually there. Heater cannot and should not vouch for those sources being correct, that's still Bill's obligation - he can still point to your original sources though, it's just that it's not Heater's responsibility.
-Tor
(Edit - tried to untangle all the 'You' in there.. Heater is now the original GPL source provider, Bill built binaries and distributed them.)
Perhaps you are right and pointing back to Raspian and SimpleIDE upstream sources is OK if those are actually the correct sources.
That leaves a question: If I give you my six month old Raspian SD card with Simple IDE and whatever on it how do I point you to the exact same six month old versions of all the packages? Assuming I have done no updating in the mean time.
For things like SimpleIDE it's easy. I might know the git tag in the repo or the revision hash or whatever it is. Then I can tell you exactly what to fetch.
I have no idea how you do that for old versions of Debian/Raspian packages. I guess there must be a way.
Only one nit to pick... I would not be building the binaries.
Heater,
What if the "Noobies" SD the Pi Foundation has a six month old Raspbian?
Discussion:
Case 1: "Old School"
Customer wants to run an Application, that runs on a GPL'd OS.
Customer hires Vendor to install the OS, configure the computer, and install the Application, and make sure the Application works.
Vendor travels to customers site, downloads the OS binary installer, performs the service, and gets paid by the Customer.
This is a service, not distributing the OS.
Case 2: "Save travel time"
Customer was happy, told friend 1000 miles away.
Friend does not want to fly Vendor to his site.
Customer FedEx's the computer he wants the OS and Application installed on to the Vendor.
Vendor downloads the OS binary installer, performs the service, FedEx's the computer with installed OS and Application to Customer, and gets paid by the Customer.
Case 3: "Save on FedEx"
Friend tells his Buddy on another continent... who can't afford to fly the vendor in, indeed cannot afford to FedEx the computer to the Vendor for the installation service.
Customer asks Vendor to buy the boot drive (SD card) for his computer, and also asks the Vendor to use an in-house computer to do the installation of the OS and the Application, then FedEx the installed drive back to Buddy.
Vendor buys an SD card, downloads the OS binary installer, performs the service, FedEx's the SD card with installed OS and Application to Customer, and gets paid by the Customer.
Case 4: "Buddy tells the world, a lot of people want the pre-installed SD card"
Vendor wants to provide the service in such a way that it is affordable, without losing money doing so.
Customers pre-pay a reasonable price for the installed SD card.
To make it affordable, Vendor sets up a dedicated computer, and every time there is a release of the OS, downloads the installer, installs the OS, configures it, installs the Application. Vendor keeps the OS image around on his server, costs too much time to download the same image every time.
The Vendor then images the SD card to a server, and whenever a Customer orders a card, images the latest (image stored on the server) to the card.
Vendor mails the installed card to the Customer, who is happy at the much more affordable price (and cheap shipping compared to FedEx).
Summary
In NONE of the cases is the Vendor compiling the binaries from the source.
Case 1 & Case 2 are clearly outside the scope of the GPL license.
Case 3 is indistinguishable from Case 2, except the Vendor provides the SD card.
Case 4 is impossible to distinguish from Case 3 if the Vendor does the imaging of the SD card upon receipt of order from the customer.
Case 4 is possibly distinguishable from Case 3 if the Vendor images 100 SD cards before he receives the orders.
What does this tell us?
This usage case was not considered when the GPL was drafted.
Vendor is not responsible for the OS install image being changed, as Vendor did not compile that OS.
Specifics
Now in my specific case, I am considering case 4, as a service to those who do not want to download the installer, install Raspbian, configure it, install the Application.
Extremely narrowly viewed, I supposed one could consider it distributing the OS - but in reality it is a service.
Given that I would not be building the binaries, I don't think I'd have to do more than point to the repository of sources for the OS and SimpleIDE, arguably pointing out that apt-get can get the source of packages is sufficient.
Regarding "how can I be sure it is the same" - easy. Download the installer, install on a different card... md5 is your friend.
Regarding charging for retrieving the source, and burning a DVD for a customer - there is nothing in the GPL saying that I'd have to do it at a loss, so charging my normal charge-out rate is reasonable. There is absolutely no requirement that the vendor take a financial loss to provide the sources that the customer could get themselves.
Regarding the exact same version... GPL is all about keeping source code free, not about keeping every minor revision available after a new version is out.
About paying for the SD card... everyone could replicate the installation of the OS, SimpleIDE, etc. from my documentation, and anyone could provide that service.
About installing my application / docs / etc.... that would depend on the license I used for them (probably GPL)
----
Interesting discussion, but I won't have time to revisit it until at least tonight, maybe tomorrow morning.
----
Bringing back the topic to RoboPi
I'm continuing working on the manual. I will eventually have to re-take some shots as I decided to change the build order.
Here is the first assembly photo from the RoboPi build manual, showing how to easily solder the SOT-223 1117-3v3 voltage regulator:
(Click on the tumbnail to view a larger image)