- From: Marcos Caceres <marcosc@opera.com>
- Date: Fri, 6 Nov 2009 17:19:55 +0100
- To: SUZANNE Benoit RD-SIRP-ISS <benoit.suzanne@orange-ftgroup.com>
- Cc: public-webapps <public-webapps@w3.org>
- Message-ID: <b21a10670911060819n11872277tca17646ee38ea009@mail.gmail.com>
Hi Benoit, 2009/11/3 SUZANNE Benoit RD-SIRP-ISS <benoit.suzanne@orange-ftgroup.com> > All, > Reviewing the spec there is no access to the License attribute. Shouldn’t > it be added in the liste of the accessible attributes? > Thank you for raising this important issue. The reason we will not be including license as an attribute is that there are a number of legal issues and potential security vulnerabilities associated with making the license available as an interface. Some of the technical challenges are: 1. the license element can be a URI (which returns any content type - which could be a script). 2. the license element can be a file (which can be any content type). 3. the license element can be a text content of the license element. 4. The license element can be a mix of 1 OR 2 AND 3. I am not a lawyer, and the following are my personal opinions and should not be construed as having any legal weight whatsoever. WRT 1, as user, I am legally concerned with the implications of having a license that can change online without my consent. I'm not sure how the law deals with that, so we leave it up to UAs. Also, what happens if the license is unavailable upon request? Because of 4, there is a possibility that the online license and the license in the text content could contradict each other or invalidate each other. The above issues are only the tip of the iceberg. Implementers should take caution implementing this feature and should probably seek legal advice as to how best to proceed to protect consumers, developers, and themselves. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Received on Friday, 6 November 2009 16:20:29 UTC