OLPC needs to comply with the GPL

[gnu]

The GPL requires that a copy of the GPL license itself be provided to recipients of binaries, to notify them of their rights.

I don't have a modern build (just 542), but the only COPYING it has is in /usr/share/activities/Paint.activity/COPYING. Surely there should be a copy of it in a more global and prominent location -- and GUI end users should be notified of its existence. Debian puts such licenses in /usr/share/common-licenses/GPL, and puts a pointer in the text of /usr/share/doc/(program)/copyright to the shared copy. Fedora doesn't seem to have a similar convention.

(To be effective when shipping hundreds of thousands of units to non-English speakers, a translation of the license should be provided as well.)

In addition, a program that isn't the exact original source released by the author "must carry prominent notices stating that it is released under this License" (GPLv3 sec 5b; also in GPLv2). While a license notice at the top of each source file is "prominent" in source code, a nonexistent or hidden string in the binary can hardly be called "prominent", if it is never displayed to the user.

GPL binaries can only be legitimately copied by including a "written offer" to provide the source code (and, for GPLv3, any "Installation Information" needed to get past the DRM and actually install recompiled source code). OLPC does not provide such a written offer. (And even if one knows about the complex and arcane tools required to extract the source tree across the Internet, it's not obvious how to find the source code that matches a particular binary build. The *matching* source is required.)

Both the GPL2 "COPYING" and the GPL3 "COPYING" need to be provided in the binary, since different software that OLPC ships is licensed under each. Other software on the machine may require other licenses to be provided and documented.

Perhaps the Sugar GUI needs some kind of "About box" that provides a readily accessible way for end users to find out that they're running free software (not just Sugar, but all the stuff under the hood), that it came with a pile of rights, and how to exercise them.

[AlbertCahalan]

Correct. OLPC is currently not compliant with GPL 2. Actually this means the license is lost, but I'd be shocked if anybody wouldn't forgive past transgressions. You really do have just two options:

a. ship the source

b. ship a written offer

Stuff left on web sites won't do for GPLv2. See the GPL FAQ if this comes as a shock to anybody.

[gnu]

The ship.2 release includes only a single version of the COPYING license file (still in Paint.activity). Many components use other licenses, not included. Is this being fixed in update.1? The requirement to provide binary recipients with a copy of the license is completely independent of the requirement to provide source code.

[mako]

Yes. This is still something I plan to get done in the Update.1 time-frame. I have an RPM I will be uploading today or tomorrow with license information for software installed into the systme. It is small and contains no code changes so I expect there to be no issue including it in the build.

[mako]

Here's a little more information on what I'm planning.

• With the help of the RPM database, I've created a list of software installed on the system and which license it is under;
• I have gone off and retrieved every license currently being used;
• I am making a list of exceptions to common licenses and am storing these;

All of this data will be installed in the system, probably in /usr/share/licenses.

[mako]

I've created and upload an initial version of this package. It is currently waiting for approval into Update.1 and Joyride. See #5694.

[gnu]

I'm glad to see this proceeding toward resolution.

And this sort of don't-change-much fix seems essential since we're toward the end of a release cycle.

But wouldn't the right fix, for all subsequent releases, be to have our build process NOT throw away the license files that the Fedora RPM's are already careful to install? Otherwise, as the set of files in the base system evolves, and their licenses evolve, a custom license package will go out of date and require manual maintenance.

(If keeping the RPM licenses results in 77 copies of the same license file, a post-pass in pilgrim can replace the identical ones with hardlinks to each other, using their SHA1sums or MD5sums as an easy test of equality.)

[mako]

We discussed this option at some length a few weeks ago. It is my understanding that this is hard for a number of reasons. Most importantly, Fedora/Red Hat includes licenses as documentation for each RPM but does not have a standard location. Sometimes it is called GPL, sometimes COPYING, sometimes LICENSE, etc. Unlike Debian, where this is very consistent and mandated by policy, determining the license file is not easy (or we would have done that instead of this method).

Instead, Red Hat records license information in metadata. This *is* a standard for this and it makes automatically determining the license (including "or any later" language) easier than it is in Debian. That is where I got the data for moving forward the way I did.

What we need is for Red Hat to somehow mark license files. I'm happy to have this conversation but getting this fix through seems longer term at best. Perhaps Dennis Gilmore, who knows this area much better than I, can chime in.

[jg]

Seems like we should continue to improve the situation with time.

Unfortunately, I suspect we'll still end up with tons of (almost) duplicate license files, with trivial changes...

[gnu]

Mako, has your olpc-licenses package been integrated into update.1, or not? And does that sole action bring the release into compliance with GPL2, or not?

I don't think that modified versions of non-OLPC-owned GPL software are properly announcing their modified status.

And there is no progress on GUI visibility of copyright license terms on anything. How would an end user know that Sugar, or Pippy, is GPL-licensed, for example?

[mako]

The package has been incorporated into Update.1 with the exception and I believe that it addresses GPL (and other issues) compliance issues for RPM-packaged software in the builds. I'm happy to treat any remaining issues as bugs against the olpc-licenses package and/or against a particular license package if it's package lists the license information incorrectly.

The issue of activities packaged in .xo files is harder to track since there is not current a source package format we can require or a license field we can parse (there is progress toward both of these issues). Until we have a more general solution, this going to be handled on a Activity by Activity basis. I've got a list and am working with activity owners.

Perhaps at this point it might more sense to retitle this bug to make it clear that it pertains to RPM-based software, to close it, and to open a series of Activity specific bugs for the remaining packages that can be owned by the respective maintainers.

Does that sounds reasonable?

[walter]

Seems reasonable to me...

[ixo]

Confirmation that complete license information is in fact, included in the latest Update.1 release ?

[mako]

Yes. The license package was uploaded into Update.1

[gnu]

I object to the title change.

(1) Compliance with the GPL requires more than merely inserting COPYING files. Read the entire bug report, please. OLPC has modified numerous GPL'd programs but has not marked them as modified. OLPC's GPL'd programs do not display their license status in any way that the end user is likely to see it and thus be informed of the free-ness of the software. OLPC is shipping binary builds across the net (as "updates") yet not offering the matching source code. In fact, OLPC forcibly upgraded my XO laptop across the network to a new build without matching source -- without notice and without consent! OLPC is shipping 340,000 machines to Spanish speaking countries without providing a translation of the GPL license into Spanish so that the recipients will know their rights! This is the third time I have repeated this kind of stuff, in this bug report alone, yet nothing is done -- and meanwhile let's change the title to avoid letting people know that "OLPC needs to START complying with the GPL".

(2) If activity builds need checking for update.2, file that a separate bug. The basic GPL compliance bug is NOT resolved. Sugar itself is not GPL compliant, nor the underlying GNU/Linux stuff.

I continue to be shocked, shocked! that an FSF board member and major free software contributors are, five months after the initial complaint, still sweeping basic GPL violations under the rug.

[mako]

I have no interest in sweeping GPL compliance issues under the rug and I have absolutely no interest in doing anything that compromises users freedom. I am interested in filing actionable bugs and "OLPC needs to comply with the GPL, dammit" is not an example of that.

I addressed the first and major complaint you leveled in your initial bug report whose title discussed the lack of COPYING files in builds and retitled it to make it clear (to me) what remained to be done in regards to license inclusion in builds.

I understand what compliance with the GPL means and I understand that it is complicated enough that one "OLPC needs to comply" bug isn't very helpful. How about filing bugs that address the following issue:

* Spanish language GPL needs to be shipped with builds * "About" screen in Sugar needs to mention GPL and software freedom * Activities need to be audited for licensing information

To my knowledge, all G1G1 machines are distributed with written offers for source which is available for all releases from a consistent location. Source is going on school servers being shipped to countries.

I, and others, have and are continuing to put effort into this because we care about it deeply and agree with you that serious problems remain. Accusing me of trying to sweep this under the rug really isn't very constructive.

[mako]

I have created three new issues (#6928, #6929, and #6930) which are listed as blocking the resolution of this bug. These issues are the same three that I mentioned in my most recent response to gnu. I have kept gnu and myself CCed on each of this issues so we can follow up on the resolution of these. If there are other issues, we can file those as separate issues. I think having a list of actionable items will help us lead this issue toward resolution.

I am also transferring ownership of this issue to Dennis Gilmore since I am no longer working actively for OLPC and want to ensure that these are given high priority and handled as quickly as possible. I will stayed CCed on this bug and will follow up on it as I continue to have a very active interest in seeing this resolved fully.

[gnu]

How many years can OLPC ship binaries of GPL'd programs without complying with the GPL? How many releases? Will the upcoming release comply?

[cscott]

For the core build, I believe all issues have been addressed.

For activities, we will need to open separate bugs on each activity which is not in compliance. OLPC is only 'responsible' for the 'G1G1 activity set', since those are the only activities we ship.

[cscott]

I've added #8411 (all G1G1 activities must have Good Licenses) as a blocker. There's also #8413, which will ensure that we stay in compliance, and #8414, which should make it easier for content authors to assign an appropriate license.

[mstone]

I believe that this bug can be punted to the next release as soon as http://laptop.org/sources is updated for 8.2.0 and the results are checked. Correct?

[cscott]

gnu: how are we doing, in your view?

[gregorio]

I think we should roll this over to 9.1 to make sure we check it again.

Michael,

Can you make sure we post the source for 8.2 at the documented URL: http://wiki.laptop.org/go/Source_code

Once that is done we can set the mew milestone for this to 9.1.

Thanks,

Greg S

[hhardy]

Each copyright notice on the manual should include the © character to comply with the Berne convention.

http://en.wikipedia.org/wiki/Copyright_symbol

[gnu]

The Software Freedom Law Center has published an excellent guide to GPL compliance here:

http://www.softwarefreedom.org/resources/2008/compliance-guide.html

I strongly recommend that the key OLPC software maintainers and managers read it.

Because OLPC ships a variety of software under GPLv2-only, GPLv2-or-later, and GPLv3-or-later licenses, it has no easy path to compliance.

Also, OLPC's customers (country-specific education groups) also have obligations, because they often modify and redistribute GPL'd binaries that are provided by OLPC. Provision of source code by OLPC on the Internet does not satisfy the obligations of e.g. Project Ceibal, even if the code is unmodified by Ceibal.