Slashdot Mirror
On the GPL and Releasing Source Code
wally@smug continues: "We'd like to avoid having to ship a CD-ROM of source code with each product, so using a web site is the best solution for us. Obviously, for GPL programs that we have modified, we are going to have to release the source code on our website. That is pretty much clear.
The tricky part comes to the distribution of the source for everything else on the unit.
If we used (for example) Red Hat Linux, it is my understanding that we can not just link to the source on the Red Hat website, as Red Hat is a "commercial" distribution. Is this correct? (What exactly constitutes "commercial" under the GPL anyway?)
Or is section 3. (c) of the GPL talking about us being commercial, and not the original distribution? Of so, is our distribution "commercial" or not? (We are really selling the hardware unit and our own custom software that drives it, and not the distribution...)
How about if we just obtained each program/item from their original source on the web, and not from a distribution? Can we then just use hyperlinks to the source?
Ideas and comments would be greatly appreciated. "
I figure there will be a lot of future Linux-based solutions that will follow a similar model and, rather than being a computer that you control, will be more of a turnkey product that you buy and use (while the vendor is responsible for things like maintenance and administration). So for setups like this, source distribution becomes a bit of a problem (and a considerable nuisance to the vendor). What are ways such vendors can distribute such products yet still remain compliant to the GPL?
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
So you can use section 3b instead of 3c if you for instance have an ftp or web site up at least three years from the release date containing the source code.
after all, the gpl doesn't really take say, embedded applications, where the end-user might not be able to modify the code in any significant way, into account. Is that a violation? I don't know---and I don't think anyone at the FSF has thought about it much. Incidentally, source code CD-ROMS for a nominal fee are probably the best approach in the scenario I've understood here.
... the hardware and software are set up for a specific set of tasks, and users fiddling with the software setup would be a bad thing (and a potentially huge source of returns of "faulty" products). So users will not have an account or root password given to them (as it's not required to use the product).
Others have pointed out the ways you can distribute the source without using a source cd, so I won't bother that one. One of your other problems seemed to be that you were afraid that easy access to the source would encourage clients to tamper with the setup, and then complain that your product stopped working right. You are apparently shipping to a set of clients who are not overly concerned that they will not have root access. Are these people that will be inclined to muck about with the software on these boxes? Even if they did, couldn't you legalese something to the effect of "screwing with the box voids your warranty"?
Communication is only possible between equals
The GPL doesn't require you to do so. As long as the source is available.
Obviously, for GPL programs that we have modified, we are going to have to release the source code on our website. That is pretty much clear.
No, it isn't. As long as the source is available to anyone who asks for it, you're in the clear. For example, cheapbytes ( www.cheapbytes.com ) sell Linux CDs that contain binaries only. However, you can also purchase the source CD for $2-. If you have a CD burner, you can just burn and ship the source for anyone who asks for it, and charge a modest fee.
If we used (for example) Red Hat Linux, it is my understanding that we can not just link to the source on the Red Hat website, as Red Hat is a "commercial" distribution. Is this correct?
No, it's not at all correct. The problem is that it is woefully insufficient because you are not distributing it. The fact that someone else has the source on a public ftp site doesn't exhonerate you from your obligation to make the source available.
Section 3c is discussing a situation where Joe user gets a binary-only CD from, say Cheapbytes. He wants to loan it to his friend for copying. 3c says he's allowed to do that. This doesn't really apply to you, because you are distributing it commercially. It's not fair for you to expect Redhat to provide ftp services for your commercial venture. However, it would also be unfair to require Joe user to order the source from Cheapbytes (just in case his friend wanted it two years later), or to require Joe User to set up an ftp service.
If you already have an ftp/webserver, you could use that. Otherwise, you could just ship a "written offer" as outlined in the GPL, and burn/ship a CD for anyone who wants one ( probably almost noone, judging by the nature of the product )
Cheers,
I think the delivery of sources and the conditions
of the provided warranty are separate issues.
The warranty conditions could state that
bug reports are only accepted if the bug
can be reproduced on an unmodified product.
Steffen
I know it's probably a bit late, but if you'd have chosen FreeBSD, the license would have allowed you to withhold source code as much as you wish. A lot of other "Appliance" companies are doing just this, for instance http://www.whistle.com/ and the GNATbox firewall (forgot URL).
Good luck, anyway!
Provide binary/source or binary only with the product, make the source available upon request, and (and this is the important bit) CHARGE source code SUPPORT.
;)
if someone "breaks" it by messing with the source code, then charge them the appropriate fees for support, by the hour.
doesn't seem like a problem to me.. in the documentation state something along the lines of "we will provide free support only for binaries supplied with this product. support for user-compiled binaries is available upon request, at additional cost" or similar. or just state that you straight out don't support user compiled binaries (depends if you want to make money out of it).
this works with redhat.
im sure if you try to recompile your redhat distro with the supplied source CD, and ring up redhat saying something to the effect of "whats a makefile? how do i configure it???" they will not provide that sort of support for free
the whole idea about making money out of open source is charging for *consulting*, but not the actual product.
just me..
smash
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
I don't really see the problem in releasing the source anyway. Here's why:
Anyone who changes the source will more than likely know exactly what they are doing, and certainly not need any support. Put on a disclaimer if you like, but my guess is that the number of people wanting to modify and recompile your drivers will be in single figures.
But hey, you might get lucky. Suppose some technical guru spots a deep bug that she can fix, or sees a way to optimize the code to make it leaner, faster and more stable, or maybe finds a cool way to interface with other hardware that you never dreamed of. And the great thing about the GPL then is that you get these enhancements back to incorporate into your next release!
Basically, GPL is great for drivers and hardware support. You shouldn't waste any energy trying to obfuscate access to the source, since this will only throw away most of the considerable benefits that the GPL can bring.
Why? Upgrades.
If you upgrade the Linux you ship, you have to have another copy of the source available. Everybody has to be able to access their source code. Doing this on a Web site can be annoying and expensive. By shipping the CD, you don't have to keep holding onto the code yourself. Most other solutions require you to keep a copy of today's Linux fifty years down the line.
If you really don't want to give everybody a disk, remember to version your Linux and other open code. Hand the customer a notice saying "This contains FredCo Open Source Distribution v1.0. Please contact FredCo at 800-555-5555 to purchase a source distribution of this software at a nominal fee, plus shipping and handling". Then, just have a couple of master disks (never just one) of FredCo OSD v1.0, and have a CD-burner around to copy these for customers. Upgrade your software? Cut a new set of master CDs, and rev the version number.
This may be cheaper in terms of materials, but you still have to have some business process in place for handling source requests.
--The basis of all love is respect
If you're rally serious about shipping a product, then your company must have legal counsel, right? You've dealt with contracts and leases and other legal documents in the past, right? Presumably it would be your lawyer's job to read and interpret the GPL and give your company competent LEGAL ADVICE about the licensing issues involved.
Please remember that Slashdot does not carry malpractice insurance and any advice you get from Slashdot readers (myself included) should be highly suspect, since most of us ARE NOT LAWYERS.
/peter
Well, the flip side of that is that is't really hard to resist bumping down what we disagree with.
I have a theory. I bet that within any group there are a few fanatics. And that the bigger the group the more the absolute number of fanatics.
And I believe that a fanatic is more apt to bump down something he disagrees with than to bump up something he agrees with. Why? Because the negative affect sticks in his craw--affects him--more than the positive one does.
If this is all true, and there are more pro-Linux folks than pro-BSD folks, then you would expect to see more anti-Linux statements zapped than you would see anti-BSD statements zapped. Right? Is this happening?
That is exactly what is happening and that is why Slashdot-style moderation does not work.
:)
I should write an essay on this.