Issue 119168

Summary: Provide matching license in install set
Product: Installation Reporter: hdu <hdu>
Component: codeAssignee: hdu <hdu>
Status: CLOSED FIXED QA Contact:
Severity: Normal    
Priority: P3 CC: arielch, orw
Version: 3.4.0Flags: hdu: 3.4_release_blocker+
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: TASK Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
Patch to use LICENSE with no language none

Description hdu@apache.org 2012-04-02 13:09:15 UTC
Keeping the LICENSE and NOTICE files to conform to the requirements defined in http://www.apache.org/dev/release.html#distribute-other-artifacts should be automated, because the install set of Apache OpenOffice consists of many parts under different licenses which makes this task non-trivial:

By default only permissively licensed stuff is included (http://www.apache.org/legal/3party.html#category-a).

Running the configure step with the --enable-category-b option allows to extend Apache OpenOffice functionality using content provided under reciprocal licenses (http://www.apache.org/legal/3party.html#category-b).

It is also possible to extend the functionality by merely aggregating suitably licensed content such as galleries, dictionaries, etc.
Comment 1 hdu@apache.org 2012-04-02 19:10:22 UTC
Added the automated mechanism in the revisions 1308350 and 1308418.

Reassigning to orw who volunteered to update the LICENSE_category_b, NOTICE_category_b, LICENSE_aggregated and NOTICE_aggregated files.
Comment 2 Oliver-Rainer Wittmann 2012-04-03 09:20:30 UTC
updated LICENSE_category_b file and NOTICE_category_b file, rev. 1308772
Comment 3 Oliver-Rainer Wittmann 2012-04-03 11:30:48 UTC
updated LICENSE_aggregated file and NOTICE_aggregated file, rev. 1308824

issue back to Herbert (hdu) to finish work on "delivering" LICENSE and NOTICE in binary package
Comment 4 hdu@apache.org 2012-04-03 15:32:41 UTC
Delivering the LICENSE and the NOTICE files has been consolidated in revision 1308978.
Comment 5 Ariel Constenla-Haile 2012-04-05 18:41:42 UTC
Revision 1308978 breaks the build on Linux, when building the SDK and the language packs:

SDK:
ERROR: Could not find license file LICENSE_en-US (B)

Languge pack for language $LANG:
ERROR: Could not find license file LICENSE_$LANG (B)

Before that revision, targets created LICENSE_$LANG (just like in the README case)

SOURCELICENCES=$(foreach,i,$(SYSLICBASE) $(SYSLICDEST)$/$(i:b)_en-US$(i:e))

fallbacklicenses=$(foreach,i,{$(subst,$(defaultlangiso), $(alllangiso))} $(foreach,j,$(SYSLICBASE) $(SYSLICDEST)$/$(j:b)_$i$(j:e)))
Comment 6 hdu@apache.org 2012-04-06 06:09:12 UTC
It showed that the build system had too many different ways to handle the license files. It did not just copy them directly or with the many different "script particle" files in scp2 but it also sneaked them in via makefile-headers (like in solenv/inc/extension_pre.mk or solenv/inc/extension_post.mk) or via solenv's perl modules. Revisions>=1310178 now cover the build scenarios: product, sdext and swext ALv2 extensions, sdk, langpacks on the four major platforms win, mac, unx32 and unx64 for with-lang builds.
Comment 7 Ariel Constenla-Haile 2012-04-06 07:01:26 UTC
(In reply to comment #6)
> Revisions>=1310178
> now cover the build scenarios: product, sdext and swext ALv2 extensions, sdk,
> langpacks on the four major platforms win, mac, unx32 and unx64 for with-lang
> builds.

It is still not working on Linux:

installer::languagepack::select_language_items removes the LICENSE from $filesinproductlanguageresolvedarrayref
http://svn.apache.org/viewvc/incubator/ooo/trunk/main/solenv/bin/make_installer.pl?revision=1301475&view=markup#l1100


Then installer::epmfile::create_epm_header with $filesinproductlanguageresolvedarrayref without the LICENSE file
http://svn.apache.org/viewvc/incubator/ooo/trunk/main/solenv/bin/make_installer.pl?revision=1301475&view=markup#l1551

Besides, create_epm_header will try to find a $licensefilename = "LICENSE_$searchlanguage"
http://svn.apache.org/viewvc/incubator/ooo/trunk/main/solenv/bin/modules/installer/epmfile.pm?revision=1301475&view=markup#l399


Even if $licensefilename is set to "LICENSE", it will fail because the LICENSE is not in $filesinproductlanguageresolvedarrayref, and it won't be found
http://svn.apache.org/viewvc/incubator/ooo/trunk/main/solenv/bin/modules/installer/epmfile.pm?revision=1301475&view=markup#l493


-----------------------------------------------------------

That said, I'm not sure what's the proper fix here.
The license destination in the language pack is
destination=openoffice.org3/program/LICENSE

that is, the same as the already installed office; it does not make much sense to install the same license twice (besides I'm not sure if it will work at all: two different packages provide the same file... this may not work on Linux).
Comment 8 Ariel Constenla-Haile 2012-04-06 07:08:09 UTC
(In reply to comment #7)
> Then installer::epmfile::create_epm_header with
> $filesinproductlanguageresolvedarrayref without the LICENSE file

I modified trunk/main/instsetoo_native/util/makefile.mk by adding


.IF "$(VERBOSE)"=="TRUE"
VERBOSESWITCH=-verbose
.ELIF "$(VERBOSE)"=="FALSE"
VERBOSESWITCH=-quiet
.ENDIF

.IF "$(VERBOSE_INSTALLER)"=="TRUE"
VERBOSESWITCH+=-log
.ENDIF


Then export VERBOSE_INSTALLER=TRUE.
This will invoke make_installer.pl with -log, setting  $installer::globals::globallogging = 1

This way it generates files with the hashes content; then see how

trunk/main/instsetoo_native/unxlngx6/OpenOffice_languagepack/rpm/logging/$LANG/productfiles16b.log has no LICENSE file, and compare it to productifles13c.log.
Comment 9 hdu@apache.org 2012-04-06 08:09:37 UTC
The build worked for archive-packages. With the new rev 1310206 it now also works for epm-built packages. Yet another script in solenv had its own opinion... BTW: in the long enumeration of sneaky methods I mentioned earlier the custom scp actions and template scps were not even included.
Comment 10 Ariel Constenla-Haile 2012-04-06 08:09:37 UTC
Created attachment 77423 [details]
Patch to use LICENSE with no language

The SDK works once this dummy patch is applied.
(Assuming you only build with lang en-US. Building with other language will try to find a README_$lang, but the sdk is only build with en-US).
Comment 11 hdu@apache.org 2012-04-06 08:12:45 UTC
The build worked for type="archive" packages. With the new rev 1310206 it now also works for epm-built packages. The problem was that yet another script in solenv had its own opinion on where to get and where to put it... BTW: in the long enumeration of sneaky methods I mentioned earlier the custom scp actions and template scps were not even included.
Comment 12 hdu@apache.org 2012-04-06 08:29:06 UTC
Ah yes, the removal of the scp'ed license in select_language_items() is another perl that perfectly fits to other related mechanisms we discovered...

In the medium term getting rid of first removing it and then re-adding it somehow differently should be short-circuited. This would not only make more robust but could also simplify things considerably.