Hi John,

У нед, 26. 08 2012. у 17:15 -0600, John Rigby пише:

Probably related or same issue. On the old site I was able to download hwpacks with for example:

wget -q -k --no-cookies --header 'Cookie: redirectlicensephp=200' http://oldsnapshots.linaro.org/precise/hwpacks/lt-snowball/latest/hwpack_lin...

This no longer works and I get the license acceptance page instead.

We have provided a script which can download stuff for you in lp:linaro-license-protection (license_protected_file_downloader inside tests/ directory - should be moved to scripts/ though).

This has been present for a while now, and has been a recommended way to download binaries from snapshots.l.o. (Or, if you are doing this from a static IP, we've got support for allowing that through if it's an automated service [we do that for eg. validation.linaro.org].)

We will look into providing a nicer API, but until we do, any interface we've got is going to be unstable and internal.

I know Friday is not the perfect timing, but that's why we are still keeping the oldsnapshots.l.o to ensure we can quickly go back if needed.

We'll make sure to avoid deployments this late in the cycle, and I hope this to be a one-off that's more of an exception than a standard.

Cheers, Danilo

Hello,

On Mon, 27 Aug 2012 19:21:22 +0200 Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:

[]

...

We have provided a script which can download stuff for you in lp:linaro-license-protection (license_protected_file_downloader inside tests/ directory - should be moved to scripts/ though).

This has been present for a while now, and has been a recommended way to download binaries from snapshots.l.o. (Or, if you are doing this from a static IP, we've got support for allowing that through if it's an automated service [we do that for eg. validation.linaro.org].)

We will look into providing a nicer API, but until we do, any interface we've got is going to be unstable and internal.

IMHO this is utter lunacy, is there any oversight on how we do this?

If we offer both the "protected", click through, EULA, downloads and the tools to download them without seeing any license then I cannot see how this is any more legally fine than just ignoring the whole damn mess.

That was my original concern during initial implementation of EULA protection in December. Over time, we came to conclusion (?, I wish I saw more general discussion and approval by stakeholders) that doing something like:

./download-linaro --accept-license <url>

, where --accept-license is mandatory, should have equivalent meaning to willfully clicking a button on a page. For extra "safety", we can also make HTTP param/cookie sent in this case be explicitly named like "accept_license=yes". I guess that gets as good as it can to allow some automation while clearly communicating other's party license acceptance.

The stuff we are doing here feels like DRM but it is even more insane as we are the senders and recipients and we _still_ cannot get it right!

Recipients can be anyone, and well, that's what our members (corporations) (and their lawyers) want...

Maybe it's time to write an RFC on the "eula compliance" bit, get a new HTTP header defined, offer a patch for wget and couple of other tools and not reinvent the download tools over and over.

Frustrated ZK

PS: In Linaro we _wrote_ code that generates, displays, enforces, avoids and side-steps licenses. We have scripts that send magic cookies. We have tools that click or type "I ACCEPT". I wonder how much time was wasted on this, instead of, say, writing better kernel code, or LAVA, or whatever...

W dniu 29.08.2012 09:58, Danilo Šegan pisze:

У пон, 27. 08 2012. у 19:21 +0200, Zygmunt Krynicki пише:

...

If we offer both the "protected", click through, EULA, downloads and the tools to download them without seeing any license then I cannot see how this is any more legally fine than just ignoring the whole damn mess.

The scripts have an explicit "yes, I agree to the license" step in them. We are making it even more explicit very soon now (that's why it's in "tests" until we make it even "stronger" and have it display the license unconditionally and prompt the user before the download begins).

Those "scripts" will not solve the problem that people have. The problem will remain, that there is an interactive step in an otherwise batch processing. I cannot expect linaro's automation pipeline to fall apart because of this requirement so I can only predict that such "improved" scripts will continue to exist.

For whitelisting, our general approach is to simply have a hard-coded list of IPs internal to Linaro that can access downloads without any license restrictions, and if a Linaro box has a static IP, we'd gladly add any of them to the whitelist.

White-listing is not a good solution. In lava we had two code paths, one that would use white-listing and another that would attempt to 'accept' the license. In practice the second code path is better as it makes the program more robust (as it behaves the same whatever IP you have) and easier as there is less code to maintain.

None of the user facing code we provide can download anything without the explicit license acceptance. FWIW, that's why linaro-fetch-image cannot download protected images still: we haven't provided the license acceptance functionality.

This is not true. In lava, we have at least two such copies of code. One that downloads any image without prompt and another that combines images and auto-accepts the interactive license. This was essential for automation.

I cannot determine if there are any other similar pieces of code available but I cannot imagine only we had that problem.

I still believe that there is a need for a good general purpose _technical_ solution that would scale beyond linaro and would allow batch processing without jumping through burning hoops.

Best regards ZK