OpenWrt Forum Archive

Topic: Releasing binaries of GPL software

The content of this topic has been archived on 9 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

First let me say that overall the OpenWRT project (and related projects) are pretty good about respecting the GPL. The reason for this post is more a reminder prompted by several violations I have run in to at other sites. I just wanted to remind everyone that when you compile and release binaries from GPL source code you have certain responsibilities with respect to ensuring the receiver of the binary also has easy access to the source. They have to be able to easily recreate the binaries from source that you are responsible for providing.  I have run into many instances lately of GPL violations at several sites, including one very large and well known vendor who should know better (I have been in discussion with their web master for the last couple of weeks trying to get this corrected, nicely).

It saddens me that people disregard this responsibility. It is precisely because of the GPL that we are even able to have this OpenWRT project at all. It is because of the GPL that we are able to customize our routers like we are. Please, take the extra 5 minutes and document anything you may have changed in a package and provide your Makefiles etc so the next guy/gal can take your changes and build upon them. To me there is little difference between providing a commercial proprietary application for download (warez) and a customized binary only release of a GPL program. You are breaking the license that the author placed on their software in both cases.

Ok, enough preaching because I know that even I may not be fully in compliant with the binaries I release but I think I am. If anyone sees anything wrong with how I am releasing my custom binaries let me know and I will correct it. I have created a lot of RPMS from softtware licensed under the GPL but I also offer the SRPM (something the vendor I mentioned earlier did not do for something). I have created an ipkg of net-snmp. net-snmp is licensed under the BSD license so I don't really *have* to release it's source code but I have treated it just as if it were a GPL package. If net-snmp were GPL instead of BSD I think I would be in compliance. Here are the netsnmp packages I am referring to.

Someone point out if there would be GPL violations here (again, pretend this is a GPL based package):
http://voidmain.is-a-geek.net/files/ipkg/
Source here:
http://voidmain.is-a-geek.net/files/ipkg/source/

The reason I ask is I was thinking about putting out some Kismet ipkgs and Kismet *is* GPL and I want to take care in complying with the license.

Some things I see overlooked and worth taking a loot at:
http://www.gnu.org/licenses/gpl-faq.htm … ndedBinary
http://www.gnu.org/licenses/gpl-faq.htm … erentSites

And this one will make you think twice. It's one that I don't know if I am prepared to handle should I get a lot of requests (which I doubt will ever happen):
http://www.gnu.org/licenses/gpl-faq.htm … OnInternet

At any rate, I just wanted to post a reminder. Most people know about the GPL and appreciate what it gives us and that we respect the licenses like I do but for those who are new to all of this... Considering the OpenWRT project doesn't release firmware images it's pretty hard to not to be in compliance with the license. I think this is good practice. Thanks for doing it this way! Again, this is not a scolding to anyone here, it's more of a "please don't get into the bad habits that a lot of other sites seem to be getting in". Thanks!

I think this a very appropriate reminder.  Thanks.

As to this concern:

And this one will make you think twice. It's one that I don't know if I am prepared to handle should I get a lot of requests (which I doubt will ever happen):
http://www.gnu.org/licenses/gpl-faq.htm … OnInternet

I believe it only applies if you distribute via binary only + offer.  If you make binaries and source available from the same place, this doesn't apply.

I hope that is correct, and I would *think* that should be good enough. I mean if I only offer the binaries from a download then I should also be able to provide the source from the same place (not be required to snail mail it if asked).

On a side note, I noticed you took down your thttpd-php package:
http://davidoffdotnet.net/openwrt/ipkg/MISSING_PKGS

I only noticed because someone asked me about where I got the one I am running:
http://voidmain.is-a-geek.net/forums/vi … php?t=1137

First let me say that your packages didn't even cross my mind when I posted the original message in this thread. smile Having said that, I just checked the license for both thttpd and for PHP, neither of which is GPL. Correct me if I am wrong but it would appear that both packages allow for distribution in binary form without the source. I would like to know how you read it.

Having said that I still think it is a good idea to pass along the source with any packages even if not required by license. Just makes life easier for the rest of us who like to tinker. Another thing that has to be considered are what licenses any libraries use that may be statically linked in and possibly even dynamically linked in. Treating all code as if it were GPL should be the safest way.

Thanks!

PHP is distributed under both the GPL and the PHP License i.e. you have to comply with both. 

I'm not entirely clear on the GPL's stance on distribution of unmodified binaries, however, paragraph 3 reads:

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 . . .

The fact that it says object code must be distributed under the terms of Sections 1 and 2 leads me to believe you still must make available source.

In any event, my PHP packages are slightly modified (two lines changed to be exact) so I think I am required to post source under any reading.  My new harddrive is arriving today, so I hope to have the packages back up by tomorrow at the latest (more likely, tonight).

On a separate note, though I'm also not entirely clear on this, I think that even for unmodified binary distribution you are required to distributed copies of the license.  I would suggest package maintainers do this.

As an example, in my lwhp packages, I included the relevant licenses (GPL and PHP) in the folder /usr/licenses/lwhp. 

I'm open to a better suggestion for locations, but I think it might make sense to agree on a standard for openWRT packages.

That all sounds about right. Most binary RPMs of GPL softare also include the GPL license file. On Red Hat systems this usually is placed in the /usr/share/doc/<pkgname>. Which brings up a good point, If this is in fact true then we need to start including a copy of the GPL in our binary packages as well. I'll have to do some more digging on this.

You need to be able to produce the source for any GPL program whether modified or not if you pass along the binaries. If someone gets a binary from you and asks for the source then you need to be able to produce the source for them that will generate the binary that you gave them. At least that's the way I have always understood it.

If someone gets a binary from you and asks for the source then you need to be able to produce the source for them that will generate the binary that you gave them. At least that's the way I have always understood it.

Just a minor note -- I think the condition is that you must either (a) offer to produce the source by mail or (b) make source available in the same place as the binary.

The point being, if you only offer to produce, any production is not enough, it has to be by mail (see http://www.gnu.org/licenses/gpl-faq.htm … nInternet).  On the other hand, you need not make an offer at all, if you distribute source and binary at the same spot.

I'll stop talking now  smile

including the licence with the pkg is a waste of good diskspace...

Maybe we could create an ipkg with all relevant licences in them, or an ipkg per license ?

and have the install say something like "this pkg covered by the GPL,
"ipkg install gpl" and "more /usr/licenses/gpl" to read the gpl

?

including the licence with the pkg is a waste of good diskspace...

problem is, i think it might be required by the GPL.

You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you . . .give any other recipients of the Program a copy of this License along with the Program.

As noted above, Section 3 incorporates this requirement for binary distribution as well.

As to your second suggestion.  I'm not sure that works either.  See, http://www.gnu.org/licenses/gpl-faq.htm … stIInclude.

One thing I wonder, though, is if it would be OK to have a post-install script that checked for a copy of the GPL and, if that copy was present on the WRT, just made a symlink to it, and, if not, copied the whole thing over.

That way a user could install a copy of the GPL at, say, /usr/GPL, and if that copy was there the installer would not install multiple copies.

As always, I'm anxious to hear if people disagree with my GPL interpretations.  I certainly agree with cnf that the more space saved the better.

I think the key is that the GPL must be "distributed" with the package. It doesn't necessarily have to be installed. As long as the user is aware of what license the package falls under it can be up to them if they want it actually installed on their system. You are right, disk space is precious on an embedded system and users probably wouldn't normally want to install the license file, but they do need to be aware of it.

I can think of a couple possible solutions neither of which I have any idea whether it would satisfy the GPL.

1) Include the GPL somewhere other than the "data.tar.gz" file included in the ipkg.
2) Include a file parallel to the binary/source in your download directory that has the exact same name as the package but with a *.license extension.
3) Update the functionality of the ipkg command to give the user the option to install the LICENSE file, or just print it to the screen at install time.

I think the control file and Packages file should at least list the license which the package is licensed under (and a link to the license), which would be nice if that were enough. These are more or less just "brain storming out loud" examples. Any more thoughts?

Anyone know if any other embedded systems have found a good solution to this problem?  How about the community that created ipkg in the first place?

For software licensed under the GPL, why don't we all include the (same) licence in our packages with the same name.  I suggest /usr/GPL-V2.  The description in the control file should say that the software is licensed under the licence installed as /usr/GPL-V2. No need for post-install scripts or symlinks.  There would be a minimum of wasted space (unless lots of different licences are used).

For source, I am not so sure.  If there are no source changes at all, is it acceptable just to reference the original source distribution point?  What happens if that becomes unavailable? If that is acceptable then, if the differences are small, it might be easiest just to add a new file (e.g. patches.tar.gz) into the ipkg.  If the differences are large, it would be best to separately make the sources available.  In either case, the description in the control file would explain where to find them.

Graham

Should be safe to have one copy of the GPL, and have the distro have a checksum for the valid GPL, verify the one it sees and if it is correct print it...  or it could pull down the GPL, compare it to the one in place and if they are the same link instead of creating new copy.  The requirement is to ensure the user KNOWS the GPL, not necessarily to have the code as part of the installed package, so long as it can be ensured that the correct license can be viewed.

Sam

I'm a licensing newbie so this may be a very elementary question

The company I work for is trying to leverage the openwrt software, but we have a small problem. We are also under NDA with another company and we are linking openwrt with their stuff. I was thinking that we would create an pkg for it and have this package be an addon. We can make any other additions to openwrt public, but we cannot reveal the intellectual property that we dont own.

What license would this fall under? Can we keep that part propietary because we are under NDA?

It depends on what you mean by "linking with OpenWRT". OpenWRT is not a library that you can link to. If the programs you are distributing do not include any GPL code or are directly linked to any GPL library then you can put it under any license you choose (well, as long as it's ok with the other non-GPL parties). You first need to find out if you are including any GPL code or linking to any GPL licensed libraries. You then should read all of the FAQ questions at www.gnu.org and if you still have questions, send them a note and ask them. They have promptly responded to every one of my questions.

Here are the licenses with links to the FAQs that actually answer a lot of questions you might have:

http://www.gnu.org/licenses/licenses.html

"Linking" was probably not the right word. The package would run on openWRT and would be a compiled C/C++ program. It will not be using any of the libraries under the GPL license.

I will check out the website which you mentioned. Thanks for your help.

If you don't link to any GPL libraries or include any GPL code then you have no obligation to distribute your source with your software, unless you just want to be a nice guy and make the rest of us happy. But no, you can license your code however you want.

I want to be a nice guy - the only problem is the NDA.

All our other code is going to be open-source (I dont know what license yet).

And although the router is for our vertical market, I dont see why I cant offer a plain openwrt router for anyone who wants to buy it...that could be an attractive point for openwrt smile

The discussion might have continued from here.