Developer discussion for Creative Commons technology and tools

[Nathan Kinkade <nkinkade AT creativecommons.org>]

Diane is on this list and can weight in if necessary, but I believe
that it was lately established (at least informally so) that such
changes would be acceptable, since it only modifies the underlying
markup and not the actual license in any way.

Nathan

On Mon, Jun 24, 2013 at 2:51 PM, Maarten Zeinstra <mz AT kl.nl> wrote:
> Thanks Nathan K for clarifying that.
>
> On Nathan Y's remark on changes to the legalcode-pages. I don't think that 
> making them more secure (i.e. more accessible for people who browse the web 
> certain ways) would change anything in the legal code. We shouldn't confuse 
> significant changes to the actual texts or appearance to the these document 
> to keeping up to date with technology. We are actually changing the 
> appearance of these pages by not changing them, as they won't load properly 
> on user's browser with more strict security guidelines..
>
> I would be we wholly in favour of refactoring all ~750 legalcode pages if 
> that would mean that they would be accessible over more secure connections. 
> Don't get me wrong, I believe we should never change the actual wording or 
> layout of these documents but in 20 years these documents need still be 
> visible to the common browser and protocols at that time. If we can now 
> identify a trend of more https (or spdy) traffic than I think we should 
> enable and add those protocols to these pages.
>
> @Dan, as this will be under your supervision in a couple of weeks, what are 
> your thoughts?
>
> Cheers,
>
> Maarten
>
> --
> Kennisland | www.kennisland.nl | t +31205756720 | m +31643053919 | 
> @mzeinstra
>
>
>
>
> On Jun 24, 2013, at 19:04 , Nathan Kinkade <nkinkade AT creativecommons.org> 
> wrote:
>
>> On Mon, Jun 24, 2013 at 11:58 AM, Maarten Zeinstra <mz AT kl.nl> wrote:
>>> Refactor all links from a form like
>>>
>>> http://www.creat..
>>>
>>> to
>>>
>>> //www.creat…
>>>
>>> I don't know if that notation is backward compatible with most browsers
>>> though.
>>
>> It is.  We use it protocol-relative URLs in a number of places already.
>>
>> Nathan
>