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
This is probably obvious, but before linking to RedHat's severs, it would be nice to obtain permission from them. It's doubtful their bandwidth would be hit hard enough they'd care, but it somehow doesn't seem right to just take it without asking. It's not free. Since their distribution is being used in this product I can imagine them accomodating the request fairly easily -- there could even be useful mutual advertising involved.
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.
Here is how you do it to keep everybody happy.
1: Include the GPL itself with the documentation.
2: Include a link to your own FTP site with all the SRPMs piled high.
3: State within the warranty ( near the beginning, in bold letters ) that you don't cover modifications or recompilations of included software.
4: Include an offer to make such modifications for the user at a specific charge.
This complies with the GPL, makes your life simpler and makes the customer happy. Note that you should send the modified software ( whatever it is ) over to Sunsite so that it will be easily accessible even if your site is down ( All the really big archives mirror sunsite ).
--= Isn't it surprising how badly I spell ?
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.
External customers, then, are a bit more complex, as the GPL -does- apply to them. Here, though, the nature of Linux comes to your rescue. You are ONLY required to GPL changes to the kernel or changes to existing source code. Any drivers that you write as modules, along with any packages you write yourself, need not be GPL, and can be as closed as you want.
You're perfectly entitled to refer customers to Red Hat's site, or any other site, IMHO, The object of the GPL is that GPLed code is available. Who does the actual hosting of the site is, AFAICT, not relevent to the GPL.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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
From the GPL, just below section 3: "The source code for a work means the preferred form of the work for making modifications to it." This means you can't distribute a program disassembly and such as the source code.
I've discussed this with Stallman, and he claims that in his interpretation of section 3b of the GPL, merely providing a URL where the source can be downloaded is not sufficient to comply with the terms of the License. As implied by the words ``physically performing the source distribution'', this section requires an offer for a physical shipment (e.g. by snail mail) of a CD (or tape or some other machine-readable media) containing the source.
Stallman was going to change this in version 3 of the GPL (in fact, that would have been the major change); but he inquired as to what the facilities for Internet access were like in Europe, and since he found that they were not nearly as good as in North America, he decided that version 3 of the GPL would (probably) not change this.
So you must either ship a CD with each unit sold, or accompany it with a written offer to do so on demand. Having an FTP site is convenient, but it is neither necessary nor sufficient.
As for the meaning of ``commercial'' in section 3c, my interpretation is that it refers to your being commercial (not RedHat). (The ratio legis here is probably this: if an individual writes a small change to a GPL'ed program and offers to distribute the source, and some big company includes that program in a distribution that sells millions of copy, we don't want the individual to be overwhelmed by requests for source distribution if the company merely transmits the offer. This is my personal explanation, nothing more.)
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
This is what I'd do. You already planned to make the source available via FTP; this is a Good Thing. Now, you'll have to include a slip of paper with your products that states "To get the source code to this program, go to ftp://whatever.your.server.is and download via anonymous FTP" or whatever scheme you plan to use."
That should be enough. You do have to make the source freely available, but that should not be a problem at this point.
Cobalt Micro (the Qube guys) only have thier source available on thier FTP server. They don't include a CD, the source is not on the hard drive of the Qube already, and I certainly couldn't find reference to the source in thier docs. Also, while the source *is* available, I was told by tech support that recompiling could void my warrently.
So it seems clear that all you NEED to do is put the source on a public FTP server. You don't have to actually ship it with your product, and you don't have to actually the use of said code.
I don't know what the device is you're selling, so this may not really apply:
Why not let the customer have root and readily available source code? Just make it clear that customer modified software is not supported, and that if a device is returned "defective" because of customer modification, they will be CHARGED for the service (nothing unusual there, no warrantee covers user modifications). Set up the root account so that that disclaimer is repeated when they log in.
When a device is returned, run a CRC on the system software to detect such modifications.
There have been several occasions where I wish I had access to device firmware either to correct misfeatures or bugs (My DSS reciever for example has a couple of race conditions, including a lock-up. Interestingly, there is evidently a watchdog timer that resets after the lockup.)
Mot users do not care about source code. You guys are so geeked out, you think everyone wants source. Most people don't even know where to plug in a mouse.
Two years ago I didn't care about source code either. Now that I have some experience with what the availability of source code implies, I have a very different attitude.
A large scale change in perception will take time. But I think that it is going to happen.
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?
The whole matter of RPMs and even SRPMs are a real pain in the butt if you care about source code. I certainly wish that someone would release a Linux operating system where you could just do cd /usr/src and find everything where it belongs, and where you could say could Just Type Make (tm :-).
But I don't think it will happen. Vendors who make and sell Linux operating systems are, as you observe, selling them to non-programmers, people who don't care about source code. So we're hosed.
Fortunately, other solutions exist. :-)
You can certainly make money from supplying the software in the first place. Your client can always redistribute by himself, but many clients, especially corporate/industrial ones, won't want to because your software represents a significant business advantage to them.
Shipping the source is hugely incidental. Trivial. Not really worth mentioning.
--
--
There is no premature anti-fascism. -Ernest Hemingway
That is exactly what is happening and that is why Slashdot-style moderation does not work.
:)
I should write an essay on this.
Mot users do not care about source code. You guys are so geeked out, you think everyone wants source. Most people don't even know where to plug in a mouse
Lets see here, are all his users Mom and Pop types. Better yet, are his customers Mom and Pops or are they businesses. Sure, my mom doesn't care about the source. But if I was running a business, I would like to have access to the source, and be able to modify it. Am I a geek that likes to play with the code? Maybe, but if I was a manager, I would not want to be dependant on a single source for updates. If I don't like the vendor, or that vendor goes out of business, I would like to at least hire someone to take over. The point about GPL is not that you can access and modify the source. But you can always find someone who can.
That's the problem with Microsoft. If you buy their products, they are the only ones who can support you. I don't mean help you with using the product. But being able to change the product to suit your needs. If Microsoft decides to come out with another version of the product that no longer supports your application so you need to stay with the older product. Will you still get support for it? The idea of open/modifiable source is that I am not stuck with one option for who supports me. I can go anywhere.
If you were running the project, it would be history because you would be releasing your hard work to the public, and would be broke in no time, as no one would then be required to pay
If you need support, you need to pay. Software could be considered a product, or it can be considered a service. I like to think that software is a service. Who says that if I create an application, that I can rest on my laurels and sit and take from everyone without having to keep it up to date. Software is something that should be paid to create. Its hard today since we are stuck with the idea that software is a product. And it has been produced that way. If it started as a service, then it can be increased and advanced as a service. Like gcc.
Steven Rostedt
Steven Rostedt
-- Nevermind
Sendmail Pro has licensing restrictions, but you get the source. BSDI has licensing restrictions, but you get the source. And yes, the FSF has licensing restrictions, but you get the source. Historically, even expensive mainframes sometimes gave you the source if you bought the systems, but if so, this certainly had licensing restrictions. And think of how many times we've all seen the ominous words that "This is unpublished source code of AT&T" or words to that effect on the troff macro kits. That's obviously source, too.
Most users do not care about source code. You guys are so geeked out, you think everyone wants source.
Most people have never come into contact with murder laws. Perhaps we should just get rid of them?
Hamish
"Wise men talk because they have something to say; fools, because they have to say something" - Plato
How much of a pain in the add the license is. It is not protecting them, it is burdening them. It is not called the GPV for nothing. It has wormed its way in and infected his product. A truly free license would not have done that.
Comsider this:
I'm a developer. I want software to be free. I buy into a lot of what RMS, ESR, etc say. I know that in order for free software to propagate, it has to prove it's better than its proprietary counterparts. I therefore want to give free software an advantage: my work can only be included in other free software projects. I don't want to work for Microsoft for free. If Microsoft wants to use my code, they can pay me, but if Alan Cox wants to use my code for some drivers he's working on, he can feel free to do so. So, I go to hire a lawyer to draft me a license that outlines these terms, but wait! There's already a license I can use that suits my purpose: the GNU General Public License. Richard Stallman just saved me a bunch of lawyer's fees.
The BSD license is a good license, but it's ahead of its time. When all software is free, and the thought that it should be proprietary becomes generally absurd, the BSDL will be the perfect solution for everyone. However, not all software is free, and free software developers want to separate themselves from proprietary companies. These developers don't want to work for Company X for free, but they are willing to share their work with others like them. So they choose the GPL.
When all software is free (as in speech), I'll start writing BSD-licensed software. Until then, it's GPL for me.
--------
"I already have all the latest software."
Probably because the initial question was about Linux. If this was an automotive site and someone asked "How do I drop the transmission on my Chevy?" I would consider a response of "Buy a Ford." to be potential flamebait.
Note also that the post that created this thread was moderated up to 3 as Insightful.
I wish I had caught this thread earlier, for I have some important points to make...
Many have pointed out that you do not need to send a cd with each system, as long as you make the source code available on demand for three years.
Well, this is not as easy as it seems. Consider, for instance, that your company go bankrupt tomorrow. That's a nasty legal liability on your shoulders... What if you completely change your business focus? After all, things in the computer business change a lot. You'll be saddled with maintaining this source code and a formal channel to provide it on demand for three full years *after* you stopped selling the product.
Also, you have to remember that you'll need to keep control of the versions of the software you ship your product with. If you distribute three different revisions of the product in a single month, just for the sake of correcting three different bugs, that's three versions of the source code you'll have to keep for three years, and be able to identify which corresponds to what your client bought. Of course, you could ignore this and stay illegal and vulnerable to a class-action lawsuit. You don't want that, do you?
All in all... you should have gone BSD. No, this is not a flame bait, it's just my personal opinion. Based on the above.
(8-DCS)
If you include the source on CD, it shows good will and openness and pretty much avoids any risk that people will think you are trying to get around the GPL.
I wouldn't worry that people in large numbers recompile and alter your software; it's way too much work. For anything important, you should probably checksum the binaries on the deployed system and integrate checksum checks into your support structure (you can do this by hand or use the rpm system for it).
With GPL, if this situation arises, you must forget you ever wrote the GPL code and "reengineer" it for your commercial development, or have someone else reengineer it.
Incorrect. Any code you write is yours; you own the copyright, and you can use that code however you like. Once you publish under the GPL, the code you released is available to everyone else, and they are bound by the GPL. And if anyone contributes code, their code is unavailable to you for non-GPL use.
But your code is yours.
Given this and a few other points, it seems to me that GPL is a good license for hobby developers; BSD is the better license for professional programmers.
I disagree-- the GPL is for professional programmers, also. Here are the differences between the GPL and GSDL:
GPL: For people who want their code available to everyone, but don't want other people to use their code for proprietary (binary-only) purposes; has its roots in the political ideology that information is most efficient if everyone has equal access to it.
BSDL: For people who want their code available to everyone, but don't care if other people use their code in proprietary (binary-only) products. Politically agnostic.
Note that the licenses don't have anything to do with you, only what other people can do with your code. The BSDL is a noble license-- it assumes the best of human nature. The GPL is rather cynical, but for cynical folks like me, protects code from hijacking.
Some people see the GPL as forcing FSF morals on other people. However, this is logically flawed, as illustrated by the following sorite:
1. BSDL allows for binary-only distribution of BSDL-derived works.
2. Binary-only distributions do not include the source-- no source-code is available for use.
3. The GPL allows for free distribution of binaries.
So, from a BSDL standpoint, the GPL is as good as binary-only distributions. Actually, it's even better, because, though you can't mix GPL code into a BSDL product, you can look at the code for ideas on implementation, and for technical details that would otherwise remain hidden.
It's up to you which license you use. The GPL protects your investment by disallowing other people to hijack it; the BSD allows for maximum freedom for your code. Use the one that serves your purpose best.
Also, you might look at the Artistic license (Perl), or the NPL (Mozilla project) for other licensing ideas. I don't advocate creating a new license; use one that's there, and suits your purpose.
Microsoft is to software what Budweiser is to beer.
Your physical mailbox at home is full of CDROMs sent to you for free. Apparently it is economic to send CDROMs to non-computer people in the hope that they will use them. It is therefore undoubtedly the case that companies would line up around the block for a list of *developers* who have *asked* for a CDROM, ie professional computer people who purchase products, who have money, and who are guaranteed to actually use the CDROM they are sent as something other than a coaster.
You could make the process of asking for a copy of the sources very easy, just a matter of either filling out a form on the web, calling an 800 number, or sending a postcard. Maybe require $5 (using a credit card order form on the web) just as a proof of seriousness, or maybe not. Then you take this list, and you SELL it to a "freebie" computer magazine targetted at developers. Or to a computer catalog company. Or to a Linux software vendor. Or whatever. They send everyone their magazine or catalog or whatever, along with a CDROM containing (a) your sources (ie what the person actually asked for), plus (b) anything else they want to put on that disk, eg demo products, advertisements, a copy of their linux distribution, a copy of their catalog, whatever.
If you cannot find a dozen companies that would pay oodles for this privilege, then your company needs a new marketing dept.