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