Improve handling of EULA-protected builds with multiple EULA support

Registered by Georgy Redkozubov

Current per-build protection implementation is based on EULA.txt/OPEN-EULA.txt existence for determining whether to show or not the EULA and path containing either 'origen' or 'snowball' in the name for selecting license theme. We should improve that to allow per-file license and theme selection, blacklist old releases, possibly protect some downloads with login.

Proposed implementation of filename based EULA handling update is that EULA file "${artifactname}-EULA.txt.${vendor}" is placed along with artifact, where "vendor" is the vendor name to select proper license theme. If no special EULA file exists then EULA.txt/OPEN-EULA.txt is displayed.

Blueprint information

Данило Шеган
Georgy Redkozubov
Georgy Redkozubov
Series goal:
Accepted for trunk
Milestone target:
milestone icon 2012.04
Started by
David Zinman
Completed by
David Zinman

Related branches



[gesha, 2012-04-10] Problems rised during discussion with asac:
 - displaying proper EULA if more than one file to be protected with different EULAs exist in the same directory
 - select proper theme without path matching
 - no false positives when several EULA.txt exist
Future plans are to get a service to provide license protection based on different EULAs, logins, users email based statistic what was downloaded by whom.
[asac, Apr 12, 2012]: please clarify what blacklist of old releases means technically and from user experience. Put that info into the blueprint description i guess.
[asac, Apr 12, 2012]: please clarify and be explicit about what updating eula handling based on artifacts name or default EULA work item means
[asac, Apr 12, 2012]: It's not clear to me how this solves the discussed problem that we want to be able to have some hwpacks EULA protected and some NO-EULA in the same directory. What I proposed on the call was to use something like a file hwpackname.tar.gz--EULA.txt that is shipped alongside the bits to trigger EULA for individual files. I don't see this reflected. Might make sense to fork out a standalone blueprint just for that as this is what we really care short term. Ping me with questions :)
[asac, Apr 12, 2012]: proposal: lets split this up in: 1. per-file-EULA-publishing, 2. contact-data-collection-for-EULA-publishing, 3. open id protection of private hosting directories (this is probably something more like an IS ticket and might not need a blueprint on its own). Let's chat to be sure we catch all the requirements.
[asac, Apr 12, 2012]: in any case: all blueprints need proper acceptance criteria and headline :).
[dzin, Apr 17, 2012] retarget to 12.04
[dzin, Apr 19, 2012] Georgy, please communicate the status of this work.
[dzin, Apr 27, 2012] Postponed work item will be broken out into a new blueprint.

Headline: Click through license protection supports per-file EULA publishing to handle multiple artefacts that needs to be protected in the same directory.
Acceptance: EULA protected and open source artifacts co-exist in the same directory and proper EULA is displayed if needed for each protected downloadable item.


Work Items

Work items:
Blacklist all old directories: DONE
Update implementation of EULA/OPEN-EULA handling based on artifacts name or default EULA.txt/OPEN-EULA.txt: DONE
Update license theming based on artifact name: DONE
Play through and eliminate possible false positives with several EULAs: DONE
Fix https access issue: DONE
Update build scripts to generate per file EULA: POSTPONED

This blueprint contains Public information 
Everyone can see this information.