Hi Kat, We've talked about this issue briefly in London. I am glad to see that what you told me then is reflected in the request for comments, I did understand you correctly.
However that also means that I keep to my initial conclusions. This is definitely not a good idea. I've put my thoughts down below, so we can break down the discussion into its subparts 1. Both markdown and HTML (HyperText Markup Language) are markup languages, it seems silly to convert one markup language into another. 2. Adding markdown to the infrastructure creates extra dependancies on a conversion between markdown and HTML, one that will probably takes more skill and time than doing these licenses immediately in html 3. Markdown is not a standard and we cannot rely on it to stay the same, HTML is. 4. Markdown basically is short hand for HTML, again why would we use it? Finally I've expected the cc-developers list to be consulted first before the affiliates were consulted. I think the members on this list are the more tech savvy and have experience in implementing various technologies. This seems like a very top-down idea with possible good intention but with a general lack of understanding the consequences of a decision like this. As a sidenote, is CC really willing to invest tech time into fixing something that is not broken instead of working on actual requests like adding more metadata-languages and working on the 40 or so unread bug reports? @Greg, Jonas, Bjorn: what are your ideas on this? Best, Maarten -- Kennisland | www.kennisland.nl | t +31205756720 | m +31643053919 | @mzeinstra On Apr 18, 2013, at 24:57 , Kat Walsh <[email protected]> wrote: > Greetings! I think this is my first time posting to this list, so as a brief > introduction for those who haven't seen me flooding their inboxes yet, I've > been working in the CC legal team since last June. One of the things I'm > focusing on is the legal impact of CC's tech projects, so you're likely to > see more from me in the future. > > As we are preparing for the publication of 4.0, there are a few > implementation details that we would like your feedback on. The rest of this > message was also posted to the affiliates, and some of the questions and > descriptions are directed primarily toward them; however, your input both as > a development community and as people aware of how CC's tools are being used > would be really valuable on some of these questions. > > ---- > > The first part of this message describes an idea we're considering about > changing the way the legal code is maintained, and asking how (if it all) it > would affect you. In the second part, we want to know which parts of the > published licenses you expect never to change after publication. > > CC has promised that once the legal code of a license has been published, it > will never change, and this is a practice we will continue with 4.0. Doing > this allows people to rely on a single version, without having to monitor for > changes that may affect their understanding of the license. > > Currently, when a license is published, the official version is the HTML file > as published on creativecommons.org. For example, for BY-SA-3.0 Unported, the > official version is located at > http://creativecommons.org/licenses/by-sa/3.0/legalcode. We are considering > an idea to separate the legal code from the non-legal code elements of the > web page more cleanly, and have the part that is the legal code itself be in > a separate file that will never change, while the HTML version may change > elements (such as page navigation) that are not actually part of the legal > code. > > If we were to do this, the legal code would be maintained in a separate file > from the HTML, in a format that maintained all of the essential information. > For example, formatting such as bold or italic text that has legal > significance, section headings, etc., would all be considered essential and > part of the legal code itself. This legal code file would likely be > maintained using Markdown[1], or something similar to it. > > The web page with the licenses would be generated from this legal code file, > by converting it to HTML and adding non-legal code formatting, text, and > navigational elements. However, since the legal code file would not have to > be touched, it would be impossible to accidentally make a change to the legal > code itself by changing other elements of the page. > > Ultimately, the experience of almost all users of the license would be > exactly the same: they would see a CC license applied to a work, and click > through to a page that looks exactly like the current page. The experience > for affiliates would differ. During the translation process, affiliates and > translation teams would be editing the legal code in its new format, rather > than an HTML file. (The markup would probably be simple, but it would still > be different.) CC HQ would also be editing and commenting on these files. > Additionally, informed license users who wished to rely on the unchanging > legal code would be able to find it and know that it would always remain > stable. > > In general, CC doesn't want to disrupt existing processes without reasons > that justify that change, and we'd like to hear whether this would be true > for you. Some pros and cons we've identified: > > *provides a unchanging file containing all of the essential elements of the > legal code > *makes a clean separation between the actual legal code and the way it is > displayed > *adds some complexity to the development process > *introduces some changes to the editing and translation processes, including > a different format for the legal code > > Questions we'd like feedback on: > 1. Do you think this would be worthwhile? > 2. Would it make translation and editing more difficult for you and your > teams? > > The second part of this, which is important for us whether or not we pursue > the first proposal, is that we would like some input on what, exactly, must > stay the same, and what may change. For example, it should be clear that the > actual text contained in the license is part of the legal code, and therefore > it must be kept exactly as is. It should also be uncontroversial that the > navigational elements on the page (directing viewers back to the deed, for > example) are not part of the legal code, and may be changed. > > However, we would like to start thinking about elements that are less > certain--and in particular, we want to be able to say for certain what is > part of the legal code and what is not, and we need to settle that question > in collaboration with you, as community expectations around our commitment > not to change the legal code are extremely important. (For example, is it > allowable to add navigation boxes to legal code pages that link to other > translations of that legal code? As translations of CC0 are progressing, this > is not a purely theoretical question!) > > Do you already have expectations about what is part of the legal code and > cannot change, and what is not? Which elements do you think should be able to > change, and which should not? > > We really appreciate your input on these questions. > > Thanks, > Kat > > -- > Kat Walsh, Counsel, Creative Commons > IM/IRC/@/etc: mindspillage * phone: please email first > Help us support the commons: https://creativecommons.net/donate/ > CC does not and cannot give legal advice. If you need legal advice, please > consult your attorney. > _______________________________________________ > cc-devel mailing list > [email protected] > http://lists.ibiblio.org/mailman/listinfo/cc-devel
_______________________________________________ cc-devel mailing list [email protected] http://lists.ibiblio.org/mailman/listinfo/cc-devel
