Difference between revisions of "Talk:License"

Latest revision as of 15:33, 26 June 2011

Which Open Source License applies to LEAF in general and Bering-uClibc 4.x in particular? As per my mail to the leaf-devel mailing list 2011-05-13 and kp's reply it is not completely clear. Davidmbrooke 14:49, 15 May 2011 (UTC)

My Proposal:

1) Let's wait another week, and if none responds/disagree, we add the "Creative Commons Attribution-ShareAlike License" for the wiki.

2) I read the busybox license and think we need to choose GPL2:

To summarize: every version of BusyBox may be distributed under the terms of GPL version 2. New versions (after 1.2.2), as a whole, may only be distributed under GPLv2, not under other versions of the GPL. Older versions of BusyBox might (or might not) be distributable under other versions of the GPL. If you want to use a GPL version other than 2, you should start with one of the old versions such as release 1.2.2 or svn 16112, and do your own homework to identify and remove any code that can't be licensed under the GPL version you want to use. New development is all GPLv2.

I have no objections to choose GPLv2, and shurely I don't want to make any homework :) --Kapeka 17:27, 25 May 2011 (UTC)

I agree on both counts. My conclusion from reviewing the (much) earlier email discussion is that the LEAF project has chosen GPL v2 already, it's just that we're not very explicit about stating that.

Not all of the software included in a LEAF distribution will necessarily use the GPL v2 license, so we still need to check each package and ensure we comply with the license terms and any attribution or similar requirements.

Davidmbrooke 09:28, 26 May 2011 (UTC)

Main Page is now tagged with the CC BY-SA license text, logo and link. We can override that with a specific statement on any other page if we need to.

Davidmbrooke 18:19, 1 June 2011 (UTC)

Many of the component parts of Bering-uClibc 4.x are released under the GNU General Public License, version 2, most notably:

• The Linux kernel
• Shorewall
• BusyBox

This license requires that any "derivative works" be licensed under a "compatible license". Since we make changes (i.e. apply patches) to these we are creating "derivative works" and must therefore comply with the requirements of the GPL. In practice, this almost certainly means that Bering-uClibc 4.x must be released under either GPL v2 or GPL v3.

A particular requirement of the GPL is the need to make source code available by the same mechanism(s) that we make binary code available. We meet this requirement by providing a .tar.gz file containing all of the source code in the same download folder as the disk Image files.

The SourceForge.net Terms and Conditions of Use require that code posted to SourceForge.net be "compliant with the Open Source Initiative ("OSI")'s Open Source Definition (http://www.opensource.org/docs/osd) or certified as an "OSI-Approved License" (http://opensource.org/licenses)."

Best practice for developers is to include a line in every Package's .help file, preferably just after the "Requires:" entry (if any), to clarify which license applies to that particular Package. For example, if GPL v2 applies:

License: GNU General Public License, version 2 (see http://www.gnu.org/licenses/gpl-2.0.html)

Some licenses require that the full text of the license is included in every distribution (for example the OpenLDAP Public License). One way to comply with this requirement would be to ship a file called package.license in the same way that we ship package.help.

If we were to do that, a possible implementation would be to have each buildtool.cfg include an entry like:

License = GPL-2.0

and to modify buildpacket.pl to process that entry and copy a file called e.g. tools/license/GPL-2.0 to package.license.

There is a set of standard license "Identifiers" (like "GPL-2.0") at http://www.spdx.org/licenses/
Davidmbrooke 12:44, 11 June 2011 (UTC)

David, I thought a bit further about the idea adding a "License" line to buildtool.cfg.

With shipping the license text with every package we end up in having them multiple times in our ram-based fs.

A suggestion is to package all necessary licenses in an extra package, which can be installed by default, but can be removed is RAM is an issue.

And instead the license line in buildtool.cfg a recommendation would be to add "License: xx" at the beginning of the help text. That way it can be identified by the help command. --Kapeka 17:28, 12 June 2011 (UTC)

Well, yes, my approach is simple but space-hungry. I have already started adding a "License:" line to the help text of any Package I touch (see e.g. radius) but we need the full text to fully satisfy some licenses.

Maybe a hybrid approach - e.g. create file package.license as a symbolic link to one of a standard set of license text files installed via an optional package (licenses.lrp perhaps). What do you think? Davidmbrooke 18:46, 12 June 2011 (UTC)

thx for editing help :)

The hybrid sounds like a good solution.

--Kapeka 19:20, 12 June 2011 (UTC)

I've committed a skeleton package with/for licenses. I suggest to create a Trac ticket, where we outline the remaining work (symbolic link, changes needed in buildpacket.pl and packages that need to be reviewed for licenses etc.). --Kapeka 18:59, 20 June 2011 (UTC)

I have made some adjustments to license.lrp - hope you don't mind :-) I have also implemented the symbolic linking logic in buildpacket.pl and added a small number of "License = XYZ" lines to buildtool.cfg files. A Trac ticket is a good idea. I will create one now (done - #56). Davidmbrooke 14:56, 26 June 2011 (UTC)