[cc-devel] Legal code and technical implementation: your input wanted

[Kat Walsh]

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

[Maarten Zeinstra]

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
--

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.
*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
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
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
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/cc-devel/attachments/20130418/09a69a0f/attachment-0001.html

[BjornW]

I agree with Maarten. If it ain't broke don't fix it.

grtz
BjornW

Post by Maarten Zeinstra
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 <http://www.kennisland.nl> | t [phone] | m
*
*
*
*
*
On Apr 18, 2013, at 24:57 , Kat Walsh <kat at creativecommons.org

Post by Kat Walsh
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
<http://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
*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
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
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
cc-devel at lists.ibiblio.org <mailto:cc-devel at lists.ibiblio.org>
http://lists.ibiblio.org/mailman/listinfo/cc-devel

_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

--
met vriendelijke groet,
Bjorn Wijers

* b u r o b j o r n .nl *
digitaal vakmanschap | digital craftsmanship

Werkdagen:
Van maandag t/m donderdag vanaf 10:00
Vrijdag is voor experimenteren en eigen projecten.

Postbus 14145
3508 SE Utrecht
The Netherlands

tel: [phone]
http://www.burobjorn.nl

[Dan Mills]

Hi Bjorn & Maarten,

I think you're missing a key point that Kat is making: the legal team is looking to change the pages that the licenses are on, to add translation links. I also know that they are thinking about ways of including the licenses inside the deeds, which would also require some changes to the license pages.

So the point is not "what do you think of Markdown" in a vacuum, it's: what format can we store that contains only the absolute minimum to be considered to be part of the licenses, so that we can build tooling to style it appropriately depending on the context.

We could obviously write tooling that takes the current HTML and transforms it, but such tooling would need to be highly content-aware: it would need to know which parts of the HTML file it can remove or change, and which ones it cannot. We likely can't eliminate that completely regardless of the format, but we should try to minimize it.

Markdown seems pretty close to the minimal format that lets us express what we need. We could also continue to use HTML, but we'd need to use a minimal subset--not what we use now (which includes images, scripts, links not part of the license, etc).

Post by Maarten Zeinstra
1. Both markdown and HTML (HyperText Markup Language) are markup
languages, it seems silly to convert one markup language into another.

This is not a criteria for choosing a format to use.

Post by Maarten Zeinstra
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

It does, but the alternative is an HTML->HTML transformation, which is arguably more complex because HTML is so expressive. We could make it work if we enforced a very limited subset of HTML as the input, though.

Post by Maarten Zeinstra
3. Markdown is not a standard and we cannot rely on it to stay the same, HTML is.

This is not actually true, the history of HTML is littered with examples:

http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28Non-standard_HTML%29#Deprecated_HTML_elements

But you're right that Markdown is not currently led by any large standards body. I think there are two mitigating factors:

(a) The primary uses for these files will be:

- to be transformed for general consumption, and
- to serve as an archive.

The first is internal to CC only, the second requires at most that the file be readable at some point in the future without our help. In other words, we do not need every client (browser) to natively understand the format.

(b) Markdown is so incredibly simple, it's hard to imagine a future where someone will be unable to read it:

http://etherpad.creativecommons.org/p/markdown-example

Post by Maarten Zeinstra
4. Markdown basically is short hand for HTML, again why would we use it?

Simplicity, and as a forcing function to get us to stop putting in extraneous content in our licenses.

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/cc-devel/attachments/20130418/12d80791/attachment.html

[Nathan Kinkade]

All of the CC licenses validate as XHTML 1.0 Transitional. There are
a lot of really great XML parsers out there for manipulating such
documents. It would be trivial for us to clean up the HTML in the 4.0
licenses to more minimal, using better nesting of id and classes so we
can use more accurate CSS selectors, and javascript can more reliably
navigate the DOM. I have already started this when I put together the
Draft 3 of the 4.0 licenses by giving a unique ID to each section and
subsection:

http://mirrors.creativecommons.org/drafts/by-sa_4.0d3.html#s3a1B

Nathan

Post by Dan Mills
Hi Bjorn & Maarten,
I think you're missing a key point that Kat is making: the legal team is
looking to change the pages that the licenses are on, to add translation
links. I also know that they are thinking about ways of including the
licenses inside the deeds, which would also require some changes to the
license pages.
So the point is not "what do you think of Markdown" in a vacuum, it's: what
format can we store that contains only the absolute minimum to be
considered to be part of the licenses, so that we can build tooling to style
it appropriately depending on the context.
We could obviously write tooling that takes the current HTML and transforms
it, but such tooling would need to be highly content-aware: it would need to
know which parts of the HTML file it can remove or change, and which ones it
cannot. We likely can't eliminate that completely regardless of the format,
but we should try to minimize it.
Markdown seems pretty close to the minimal format that lets us express what
we need. We could also continue to use HTML, but we'd need to use a minimal
subset--not what we use now (which includes images, scripts, links not part
of the license, etc).
1. Both markdown and HTML (HyperText Markup Language) are markup
languages, it seems silly to convert one markup language into another.
This is not a criteria for choosing a format to use.
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
It does, but the alternative is an HTML->HTML transformation, which is
arguably more complex because HTML is so expressive. We could make it work
if we enforced a very limited subset of HTML as the input, though.
3. Markdown is not a standard and we cannot rely on it to stay the same, HTML is.
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28Non-standard_HTML%29#Deprecated_HTML_elements
But you're right that Markdown is not currently led by any large standards
- to be transformed for general consumption, and
- to serve as an archive.
The first is internal to CC only, the second requires at most that the file
be readable at some point in the future without our help. In other words, we
do not need every client (browser) to natively understand the format.
(b) Markdown is so incredibly simple, it's hard to imagine a future where
http://etherpad.creativecommons.org/p/markdown-example
4. Markdown basically is short hand for HTML, again why would we use it?
Simplicity, and as a forcing function to get us to stop putting in
extraneous content in our licenses.
Dan
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

[Dan Mills]

Hi,

The licenses still contain too much information which is not actually part of the licenses. Just open that link, view source, and behold.

Of course we could parse it, but how would you decide what you can remove and what is part of the license? We need to minimize the amount of code that has such decisions embedded in it.

Dan

All of the CC licenses validate as XHTML 1.0 Transitional. There are
a lot of really great XML parsers out there for manipulating such
documents. It would be trivial for us to clean up the HTML in the 4.0
licenses to more minimal, using better nesting of id and classes so we
can use more accurate CSS selectors, and javascript can more reliably
navigate the DOM. I have already started this when I put together the
Draft 3 of the 4.0 licenses by giving a unique ID to each section and
http://mirrors.creativecommons.org/drafts/by-sa_4.0d3.html#s3a1B
Nathan

Post by Dan Mills
Hi Bjorn & Maarten,
I think you're missing a key point that Kat is making: the legal team is
looking to change the pages that the licenses are on, to add translation
links. I also know that they are thinking about ways of including the
licenses inside the deeds, which would also require some changes to the
license pages.
So the point is not "what do you think of Markdown" in a vacuum, it's: what
format can we store that contains only the absolute minimum to be
considered to be part of the licenses, so that we can build tooling to style
it appropriately depending on the context.
We could obviously write tooling that takes the current HTML and transforms
it, but such tooling would need to be highly content-aware: it would need to
know which parts of the HTML file it can remove or change, and which ones it
cannot. We likely can't eliminate that completely regardless of the format,
but we should try to minimize it.
Markdown seems pretty close to the minimal format that lets us express what
we need. We could also continue to use HTML, but we'd need to use a minimal
subset--not what we use now (which includes images, scripts, links not part
of the license, etc).
1. Both markdown and HTML (HyperText Markup Language) are markup
languages, it seems silly to convert one markup language into another.
This is not a criteria for choosing a format to use.
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
It does, but the alternative is an HTML->HTML transformation, which is
arguably more complex because HTML is so expressive. We could make it work
if we enforced a very limited subset of HTML as the input, though.
3. Markdown is not a standard and we cannot rely on it to stay the same, HTML is.
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28Non-standard_HTML%29#Deprecated_HTML_elements
But you're right that Markdown is not currently led by any large standards
- to be transformed for general consumption, and
- to serve as an archive.
The first is internal to CC only, the second requires at most that the file
be readable at some point in the future without our help. In other words, we
do not need every client (browser) to natively understand the format.
(b) Markdown is so incredibly simple, it's hard to imagine a future where
http://etherpad.creativecommons.org/p/markdown-example
4. Markdown basically is short hand for HTML, again why would we use it?
Simplicity, and as a forcing function to get us to stop putting in
extraneous content in our licenses.
Dan
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org (mailto:cc-devel at lists.ibiblio.org)
http://lists.ibiblio.org/mailman/listinfo/cc-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/cc-devel/attachments/20130418/ed4b9371/attachment.html

[Greg Grossmeier]

I guess the miscommunication here is:
what tooling will you build that needs to use something other than HTML
to display the license?

What use-case do you have in mind, Dan?

Greg

<quote name="Dan Mills" date="2013-04-18" time="10:50:26 -0700">

Post by Dan Mills
Hi,
The licenses still contain too much information which is not actually part of the licenses. Just open that link, view source, and behold.
Of course we could parse it, but how would you decide what you can remove and what is part of the license? We need to minimize the amount of code that has such decisions embedded in it.
Dan

All of the CC licenses validate as XHTML 1.0 Transitional. There are
a lot of really great XML parsers out there for manipulating such
documents. It would be trivial for us to clean up the HTML in the 4.0
licenses to more minimal, using better nesting of id and classes so we
can use more accurate CSS selectors, and javascript can more reliably
navigate the DOM. I have already started this when I put together the
Draft 3 of the 4.0 licenses by giving a unique ID to each section and
http://mirrors.creativecommons.org/drafts/by-sa_4.0d3.html#s3a1B
Nathan

Post by Dan Mills
Hi Bjorn & Maarten,
I think you're missing a key point that Kat is making: the legal team is
looking to change the pages that the licenses are on, to add translation
links. I also know that they are thinking about ways of including the
licenses inside the deeds, which would also require some changes to the
license pages.
So the point is not "what do you think of Markdown" in a vacuum, it's: what
format can we store that contains only the absolute minimum to be
considered to be part of the licenses, so that we can build tooling to style
it appropriately depending on the context.
We could obviously write tooling that takes the current HTML and transforms
it, but such tooling would need to be highly content-aware: it would need to
know which parts of the HTML file it can remove or change, and which ones it
cannot. We likely can't eliminate that completely regardless of the format,
but we should try to minimize it.
Markdown seems pretty close to the minimal format that lets us express what
we need. We could also continue to use HTML, but we'd need to use a minimal
subset--not what we use now (which includes images, scripts, links not part
of the license, etc).
1. Both markdown and HTML (HyperText Markup Language) are markup
languages, it seems silly to convert one markup language into another.
This is not a criteria for choosing a format to use.
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
It does, but the alternative is an HTML->HTML transformation, which is
arguably more complex because HTML is so expressive. We could make it work
if we enforced a very limited subset of HTML as the input, though.
3. Markdown is not a standard and we cannot rely on it to stay the same, HTML is.
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28Non-standard_HTML%29#Deprecated_HTML_elements
But you're right that Markdown is not currently led by any large standards
- to be transformed for general consumption, and
- to serve as an archive.
The first is internal to CC only, the second requires at most that the file
be readable at some point in the future without our help. In other words, we
do not need every client (browser) to natively understand the format.
(b) Markdown is so incredibly simple, it's hard to imagine a future where
http://etherpad.creativecommons.org/p/markdown-example
4. Markdown basically is short hand for HTML, again why would we use it?
Simplicity, and as a forcing function to get us to stop putting in
extraneous content in our licenses.
Dan
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org (mailto:cc-devel at lists.ibiblio.org)
http://lists.ibiblio.org/mailman/listinfo/cc-devel

_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

[Maarten Zeinstra]

Hi Greg,

I just drafted the same email to Dan:

"You are making me curious. Could you give a either a mockup or a schematic of how you envision this then?

Also it appears that most of us oppose this from a technical point of view whereas you are saying that there are reason from legal that are important here as well. Could you explain those view in a way that I can understand them?"

Cheers,

Maarten
--

Post by Greg Grossmeier
what tooling will you build that needs to use something other than HTML
to display the license?
What use-case do you have in mind, Dan?
Greg
<quote name="Dan Mills" date="2013-04-18" time="10:50:26 -0700">

Post by Dan Mills
Hi,
The licenses still contain too much information which is not actually part of the licenses. Just open that link, view source, and behold.
Of course we could parse it, but how would you decide what you can remove and what is part of the license? We need to minimize the amount of code that has such decisions embedded in it.
Dan

All of the CC licenses validate as XHTML 1.0 Transitional. There are
a lot of really great XML parsers out there for manipulating such
documents. It would be trivial for us to clean up the HTML in the 4.0
licenses to more minimal, using better nesting of id and classes so we
can use more accurate CSS selectors, and javascript can more reliably
navigate the DOM. I have already started this when I put together the
Draft 3 of the 4.0 licenses by giving a unique ID to each section and
http://mirrors.creativecommons.org/drafts/by-sa_4.0d3.html#s3a1B
Nathan

Post by Dan Mills
Hi Bjorn & Maarten,
I think you're missing a key point that Kat is making: the legal team is
looking to change the pages that the licenses are on, to add translation
links. I also know that they are thinking about ways of including the
licenses inside the deeds, which would also require some changes to the
license pages.
So the point is not "what do you think of Markdown" in a vacuum, it's: what
format can we store that contains only the absolute minimum to be
considered to be part of the licenses, so that we can build tooling to style
it appropriately depending on the context.
We could obviously write tooling that takes the current HTML and transforms
it, but such tooling would need to be highly content-aware: it would need to
know which parts of the HTML file it can remove or change, and which ones it
cannot. We likely can't eliminate that completely regardless of the format,
but we should try to minimize it.
Markdown seems pretty close to the minimal format that lets us express what
we need. We could also continue to use HTML, but we'd need to use a minimal
subset--not what we use now (which includes images, scripts, links not part
of the license, etc).
1. Both markdown and HTML (HyperText Markup Language) are markup
languages, it seems silly to convert one markup language into another.
This is not a criteria for choosing a format to use.
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
It does, but the alternative is an HTML->HTML transformation, which is
arguably more complex because HTML is so expressive. We could make it work
if we enforced a very limited subset of HTML as the input, though.
3. Markdown is not a standard and we cannot rely on it to stay the same, HTML is.
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28Non-standard_HTML%29#Deprecated_HTML_elements
But you're right that Markdown is not currently led by any large standards
- to be transformed for general consumption, and
- to serve as an archive.
The first is internal to CC only, the second requires at most that the file
be readable at some point in the future without our help. In other words, we
do not need every client (browser) to natively understand the format.
(b) Markdown is so incredibly simple, it's hard to imagine a future where
http://etherpad.creativecommons.org/p/markdown-example
4. Markdown basically is short hand for HTML, again why would we use it?
Simplicity, and as a forcing function to get us to stop putting in
extraneous content in our licenses.
Dan
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org (mailto:cc-devel at lists.ibiblio.org)
http://lists.ibiblio.org/mailman/listinfo/cc-devel

_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| http://grossmeier.net A18D 1138 8E47 FAC8 1C7D |
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

[Dan Mills]

No, end users would use HTML when used in a web context, of course. But consider the two use-cases I mentioned:

* Adding translation links at the bottom of the legal code page.
* Embedding the legal code into the deed in some manner.

Both are HTML for the end user, but *different HTML*.

So again, the point is that we need:

1) a *minimal* format to express the licenses themselves, and nothing more.
2) some tooling to take those licenses and format them as needed depending on context.

And although we could write that tooling today with the HTML as-is, I would *much* rather write tools that know less about the license content.

Dan

Post by Greg Grossmeier
what tooling will you build that needs to use something other than HTML
to display the license?
What use-case do you have in mind, Dan?
Greg
<quote name="Dan Mills" date="2013-04-18" time="10:50:26 -0700">

Post by Dan Mills
Hi,
The licenses still contain too much information which is not actually part of the licenses. Just open that link, view source, and behold.
Of course we could parse it, but how would you decide what you can remove and what is part of the license? We need to minimize the amount of code that has such decisions embedded in it.
Dan

All of the CC licenses validate as XHTML 1.0 Transitional. There are
a lot of really great XML parsers out there for manipulating such
documents. It would be trivial for us to clean up the HTML in the 4.0
licenses to more minimal, using better nesting of id and classes so we
can use more accurate CSS selectors, and javascript can more reliably
navigate the DOM. I have already started this when I put together the
Draft 3 of the 4.0 licenses by giving a unique ID to each section and
http://mirrors.creativecommons.org/drafts/by-sa_4.0d3.html#s3a1B
Nathan

Post by Dan Mills
Hi Bjorn & Maarten,
I think you're missing a key point that Kat is making: the legal team is
looking to change the pages that the licenses are on, to add translation
links. I also know that they are thinking about ways of including the
licenses inside the deeds, which would also require some changes to the
license pages.
So the point is not "what do you think of Markdown" in a vacuum, it's: what
format can we store that contains only the absolute minimum to be
considered to be part of the licenses, so that we can build tooling to style
it appropriately depending on the context.
We could obviously write tooling that takes the current HTML and transforms
it, but such tooling would need to be highly content-aware: it would need to
know which parts of the HTML file it can remove or change, and which ones it
cannot. We likely can't eliminate that completely regardless of the format,
but we should try to minimize it.
Markdown seems pretty close to the minimal format that lets us express what
we need. We could also continue to use HTML, but we'd need to use a minimal
subset--not what we use now (which includes images, scripts, links not part
of the license, etc).
1. Both markdown and HTML (HyperText Markup Language) are markup
languages, it seems silly to convert one markup language into another.
This is not a criteria for choosing a format to use.
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
It does, but the alternative is an HTML->HTML transformation, which is
arguably more complex because HTML is so expressive. We could make it work
if we enforced a very limited subset of HTML as the input, though.
3. Markdown is not a standard and we cannot rely on it to stay the
same, HTML is.
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28Non-standard_HTML%29#Deprecated_HTML_elements
But you're right that Markdown is not currently led by any large standards
- to be transformed for general consumption, and
- to serve as an archive.
The first is internal to CC only, the second requires at most that the file
be readable at some point in the future without our help. In other words, we
do not need every client (browser) to natively understand the format.
(b) Markdown is so incredibly simple, it's hard to imagine a future where
http://etherpad.creativecommons.org/p/markdown-example
4. Markdown basically is short hand for HTML, again why would we use it?
Simplicity, and as a forcing function to get us to stop putting in
extraneous content in our licenses.
Dan
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org (mailto:cc-devel at lists.ibiblio.org)
http://lists.ibiblio.org/mailman/listinfo/cc-devel

_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org (mailto:cc-devel at lists.ibiblio.org)
http://lists.ibiblio.org/mailman/listinfo/cc-devel

--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| http://grossmeier.net A18D 1138 8E47 FAC8 1C7D |
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org (mailto:cc-devel at lists.ibiblio.org)
http://lists.ibiblio.org/mailman/listinfo/cc-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/cc-devel/attachments/20130418/d6e6d9b0/attachment.html

[Maarten Zeinstra]

But really that is just silly.

What legal is requesting is a way to get to the 'real' legal code, but actually they are asking for a simple representation of that code. As I see it they want something like a 'print-version' of the legal code. That would still mean that there is markup in some way.

I would have one basic html document, slightly different than Kinkades example (I would stack css classes), and have two pages. One for web viewing and another completely dressed down for print.

I think given the option of a print version or a markdown version the legal-team will probably choose the former.
--

Post by Dan Mills
* Adding translation links at the bottom of the legal code page.
* Embedding the legal code into the deed in some manner.
Both are HTML for the end user, but *different HTML*.
1) a *minimal* format to express the licenses themselves, and nothing more.
2) some tooling to take those licenses and format them as needed depending on context.
And although we could write that tooling today with the HTML as-is, I would *much* rather write tools that know less about the license content.
Dan

Post by Greg Grossmeier
what tooling will you build that needs to use something other than HTML
to display the license?
What use-case do you have in mind, Dan?
Greg
<quote name="Dan Mills" date="2013-04-18" time="10:50:26 -0700">

Post by Dan Mills
Hi,
The licenses still contain too much information which is not actually part of the licenses. Just open that link, view source, and behold.
Of course we could parse it, but how would you decide what you can remove and what is part of the license? We need to minimize the amount of code that has such decisions embedded in it.
Dan

All of the CC licenses validate as XHTML 1.0 Transitional. There are
a lot of really great XML parsers out there for manipulating such
documents. It would be trivial for us to clean up the HTML in the 4.0
licenses to more minimal, using better nesting of id and classes so we
can use more accurate CSS selectors, and javascript can more reliably
navigate the DOM. I have already started this when I put together the
Draft 3 of the 4.0 licenses by giving a unique ID to each section and
http://mirrors.creativecommons.org/drafts/by-sa_4.0d3.html#s3a1B
Nathan

Post by Dan Mills
Hi Bjorn & Maarten,
I think you're missing a key point that Kat is making: the legal team is
looking to change the pages that the licenses are on, to add translation
links. I also know that they are thinking about ways of including the
licenses inside the deeds, which would also require some changes to the
license pages.
So the point is not "what do you think of Markdown" in a vacuum, it's: what
format can we store that contains only the absolute minimum to be
considered to be part of the licenses, so that we can build tooling to style
it appropriately depending on the context.
We could obviously write tooling that takes the current HTML and transforms
it, but such tooling would need to be highly content-aware: it would need to
know which parts of the HTML file it can remove or change, and which ones it
cannot. We likely can't eliminate that completely regardless of the format,
but we should try to minimize it.
Markdown seems pretty close to the minimal format that lets us express what
we need. We could also continue to use HTML, but we'd need to use a minimal
subset--not what we use now (which includes images, scripts, links not part
of the license, etc).
1. Both markdown and HTML (HyperText Markup Language) are markup
languages, it seems silly to convert one markup language into another.
This is not a criteria for choosing a format to use.
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
It does, but the alternative is an HTML->HTML transformation, which is
arguably more complex because HTML is so expressive. We could make it work
if we enforced a very limited subset of HTML as the input, though.
3. Markdown is not a standard and we cannot rely on it to stay the same, HTML is.
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28Non-standard_HTML%29#Deprecated_HTML_elements
But you're right that Markdown is not currently led by any large standards
- to be transformed for general consumption, and
- to serve as an archive.
The first is internal to CC only, the second requires at most that the file
be readable at some point in the future without our help. In other words, we
do not need every client (browser) to natively understand the format.
(b) Markdown is so incredibly simple, it's hard to imagine a future where
http://etherpad.creativecommons.org/p/markdown-example
4. Markdown basically is short hand for HTML, again why would we use it?
Simplicity, and as a forcing function to get us to stop putting in
extraneous content in our licenses.
Dan
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org (mailto:cc-devel at lists.ibiblio.org)
http://lists.ibiblio.org/mailman/listinfo/cc-devel

_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| http://grossmeier.net A18D 1138 8E47 FAC8 1C7D |
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/cc-devel/attachments/20130418/5b9f91ac/attachment-0001.html

[Maarten Zeinstra]

Hi Dan,

Ok, I see that you mean a bit more now, but can't we do it the other way around?

Embed the license pages as they are proposed by us into a more rich page? However I would never ever endorse a view where the URI of the licenses are used for other purposes than just showing the best ways to read the licenses on the web.
--

Post by Maarten Zeinstra
But really that is just silly.
What legal is requesting is a way to get to the 'real' legal code, but actually they are asking for a simple representation of that code. As I see it they want something like a 'print-version' of the legal code. That would still mean that there is markup in some way.
I would have one basic html document, slightly different than Kinkades example (I would stack css classes), and have two pages. One for web viewing and another completely dressed down for print.
I think given the option of a print version or a markdown version the legal-team will probably choose the former.
--

Post by Dan Mills
* Adding translation links at the bottom of the legal code page.
* Embedding the legal code into the deed in some manner.
Both are HTML for the end user, but *different HTML*.
1) a *minimal* format to express the licenses themselves, and nothing more.
2) some tooling to take those licenses and format them as needed depending on context.
And although we could write that tooling today with the HTML as-is, I would *much* rather write tools that know less about the license content.
Dan

Post by Greg Grossmeier
what tooling will you build that needs to use something other than HTML
to display the license?
What use-case do you have in mind, Dan?
Greg
<quote name="Dan Mills" date="2013-04-18" time="10:50:26 -0700">

Post by Dan Mills
Hi,
The licenses still contain too much information which is not actually part of the licenses. Just open that link, view source, and behold.
Of course we could parse it, but how would you decide what you can remove and what is part of the license? We need to minimize the amount of code that has such decisions embedded in it.
Dan

All of the CC licenses validate as XHTML 1.0 Transitional. There are
a lot of really great XML parsers out there for manipulating such
documents. It would be trivial for us to clean up the HTML in the 4.0
licenses to more minimal, using better nesting of id and classes so we
can use more accurate CSS selectors, and javascript can more reliably
navigate the DOM. I have already started this when I put together the
Draft 3 of the 4.0 licenses by giving a unique ID to each section and
http://mirrors.creativecommons.org/drafts/by-sa_4.0d3.html#s3a1B
Nathan

Post by Dan Mills
Hi Bjorn & Maarten,
I think you're missing a key point that Kat is making: the legal team is
looking to change the pages that the licenses are on, to add translation
links. I also know that they are thinking about ways of including the
licenses inside the deeds, which would also require some changes to the
license pages.
So the point is not "what do you think of Markdown" in a vacuum, it's: what
format can we store that contains only the absolute minimum to be
considered to be part of the licenses, so that we can build tooling to style
it appropriately depending on the context.
We could obviously write tooling that takes the current HTML and transforms
it, but such tooling would need to be highly content-aware: it would need to
know which parts of the HTML file it can remove or change, and which ones it
cannot. We likely can't eliminate that completely regardless of the format,
but we should try to minimize it.
Markdown seems pretty close to the minimal format that lets us express what
we need. We could also continue to use HTML, but we'd need to use a minimal
subset--not what we use now (which includes images, scripts, links not part
of the license, etc).
1. Both markdown and HTML (HyperText Markup Language) are markup
languages, it seems silly to convert one markup language into another.
This is not a criteria for choosing a format to use.
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
It does, but the alternative is an HTML->HTML transformation, which is
arguably more complex because HTML is so expressive. We could make it work
if we enforced a very limited subset of HTML as the input, though.
3. Markdown is not a standard and we cannot rely on it to stay the same, HTML is.
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28Non-standard_HTML%29#Deprecated_HTML_elements
But you're right that Markdown is not currently led by any large standards
- to be transformed for general consumption, and
- to serve as an archive.
The first is internal to CC only, the second requires at most that the file
be readable at some point in the future without our help. In other words, we
do not need every client (browser) to natively understand the format.
(b) Markdown is so incredibly simple, it's hard to imagine a future where
http://etherpad.creativecommons.org/p/markdown-example
4. Markdown basically is short hand for HTML, again why would we use it?
Simplicity, and as a forcing function to get us to stop putting in
extraneous content in our licenses.
Dan
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org (mailto:cc-devel at lists.ibiblio.org)
http://lists.ibiblio.org/mailman/listinfo/cc-devel

_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| http://grossmeier.net A18D 1138 8E47 FAC8 1C7D |
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/cc-devel/attachments/20130418/95b322f5/attachment-0001.html

[Dan Mills]

This is not actually about Markdown.

This is about having a minimal document that we transform into the page the user sees, by adding styling, headers, errata, links to translations, or whatever the legal team wants to add. Markdown is just one example of a format that would make that easy.

I completely agree that there should be some immutable version of the license, the discussion is about what that should look like.

Dan

Post by Maarten Zeinstra
But really that is just silly.
What legal is requesting is a way to get to the 'real' legal code, but actually they are asking for a simple representation of that code. As I see it they want something like a 'print-version' of the legal code. That would still mean that there is markup in some way.
I would have one basic html document, slightly different than Kinkades example (I would stack css classes), and have two pages. One for web viewing and another completely dressed down for print.
I think given the option of a print version or a markdown version the legal-team will probably choose the former.
--
Kennisland

Post by Dan Mills
* Adding translation links at the bottom of the legal code page.
* Embedding the legal code into the deed in some manner.
Both are HTML for the end user, but *different HTML*.
1) a *minimal* format to express the licenses themselves, and nothing more.
2) some tooling to take those licenses and format them as needed depending on context.
And although we could write that tooling today with the HTML as-is, I would *much* rather write tools that know less about the license content.
Dan

Post by Greg Grossmeier
what tooling will you build that needs to use something other than HTML
to display the license?
What use-case do you have in mind, Dan?
Greg
<quote name="Dan Mills" date="2013-04-18" time="10:50:26 -0700">

Post by Dan Mills
Hi,
The licenses still contain too much information which is not actually part of the licenses. Just open that link, view source, and behold.
Of course we could parse it, but how would you decide what you can remove and what is part of the license? We need to minimize the amount of code that has such decisions embedded in it.
Dan

All of the CC licenses validate as XHTML 1.0 Transitional. There are
a lot of really great XML parsers out there for manipulating such
documents. It would be trivial for us to clean up the HTML in the 4.0
licenses to more minimal, using better nesting of id and classes so we
can use more accurate CSS selectors, and javascript can more reliably
navigate the DOM. I have already started this when I put together the
Draft 3 of the 4.0 licenses by giving a unique ID to each section and
http://mirrors.creativecommons.org/drafts/by-sa_4.0d3.html#s3a1B
Nathan

Post by Dan Mills
Hi Bjorn & Maarten,
I think you're missing a key point that Kat is making: the legal team is
looking to change the pages that the licenses are on, to add translation
links. I also know that they are thinking about ways of including the
licenses inside the deeds, which would also require some changes to the
license pages.
So the point is not "what do you think of Markdown" in a vacuum, it's: what
format can we store that contains only the absolute minimum to be
considered to be part of the licenses, so that we can build tooling to style
it appropriately depending on the context.
We could obviously write tooling that takes the current HTML and transforms
it, but such tooling would need to be highly content-aware: it would need to
know which parts of the HTML file it can remove or change, and which ones it
cannot. We likely can't eliminate that completely regardless of the format,
but we should try to minimize it.
Markdown seems pretty close to the minimal format that lets us express what
we need. We could also continue to use HTML, but we'd need to use a minimal
subset--not what we use now (which includes images, scripts, links not part
of the license, etc).
1. Both markdown and HTML (HyperText Markup Language) are markup
languages, it seems silly to convert one markup language into another.
This is not a criteria for choosing a format to use.
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
It does, but the alternative is an HTML->HTML transformation, which is
arguably more complex because HTML is so expressive. We could make it work
if we enforced a very limited subset of HTML as the input, though.
3. Markdown is not a standard and we cannot rely on it to stay the
same, HTML is.
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28Non-standard_HTML%29#Deprecated_HTML_elements
But you're right that Markdown is not currently led by any large standards
- to be transformed for general consumption, and
- to serve as an archive.
The first is internal to CC only, the second requires at most that the file
be readable at some point in the future without our help. In other words, we
do not need every client (browser) to natively understand the format.
(b) Markdown is so incredibly simple, it's hard to imagine a future where
http://etherpad.creativecommons.org/p/markdown-example
4. Markdown basically is short hand for HTML, again why would we use it?
Simplicity, and as a forcing function to get us to stop putting in
extraneous content in our licenses.
Dan
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org (mailto:cc-devel at lists.ibiblio.org) (mailto:cc-devel at lists.ibiblio.org)
http://lists.ibiblio.org/mailman/listinfo/cc-devel

_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org (mailto:cc-devel at lists.ibiblio.org)
http://lists.ibiblio.org/mailman/listinfo/cc-devel

--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| http://grossmeier.net (http://grossmeier.net/) A18D 1138 8E47 FAC8 1C7D |
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org (mailto:cc-devel at lists.ibiblio.org)
http://lists.ibiblio.org/mailman/listinfo/cc-devel

_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org (mailto:cc-devel at lists.ibiblio.org)
http://lists.ibiblio.org/mailman/listinfo/cc-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/cc-devel/attachments/20130418/d553515f/attachment-0001.html

[Dan Mills]

Can you explain a bit more what you mean? Not sure I get how it's different from what I'm suggesting.

Dan

Post by Dan Mills
This is not actually about Markdown.
This is about having a minimal document that we transform into the page the user sees, by adding styling, headers, errata, links to translations, or whatever the legal team wants to add. Markdown is just one example of a format that would make that easy.
I completely agree that there should be some immutable version of the license, the discussion is about what that should look like.
Dan

Post by Maarten Zeinstra
But really that is just silly.
What legal is requesting is a way to get to the 'real' legal code, but actually they are asking for a simple representation of that code. As I see it they want something like a 'print-version' of the legal code. That would still mean that there is markup in some way.
I would have one basic html document, slightly different than Kinkades example (I would stack css classes), and have two pages. One for web viewing and another completely dressed down for print.
I think given the option of a print version or a markdown version the legal-team will probably choose the former.
--
Kennisland

Post by Dan Mills
* Adding translation links at the bottom of the legal code page.
* Embedding the legal code into the deed in some manner.
Both are HTML for the end user, but *different HTML*.
1) a *minimal* format to express the licenses themselves, and nothing more.
2) some tooling to take those licenses and format them as needed depending on context.
And although we could write that tooling today with the HTML as-is, I would *much* rather write tools that know less about the license content.
Dan

Post by Greg Grossmeier
what tooling will you build that needs to use something other than HTML
to display the license?
What use-case do you have in mind, Dan?
Greg
<quote name="Dan Mills" date="2013-04-18" time="10:50:26 -0700">

Post by Dan Mills
Hi,
The licenses still contain too much information which is not actually part of the licenses. Just open that link, view source, and behold.
Of course we could parse it, but how would you decide what you can remove and what is part of the license? We need to minimize the amount of code that has such decisions embedded in it.
Dan

All of the CC licenses validate as XHTML 1.0 Transitional. There are
a lot of really great XML parsers out there for manipulating such
documents. It would be trivial for us to clean up the HTML in the 4.0
licenses to more minimal, using better nesting of id and classes so we
can use more accurate CSS selectors, and javascript can more reliably
navigate the DOM. I have already started this when I put together the
Draft 3 of the 4.0 licenses by giving a unique ID to each section and
http://mirrors.creativecommons.org/drafts/by-sa_4.0d3.html#s3a1B
Nathan

Post by Dan Mills
Hi Bjorn & Maarten,
I think you're missing a key point that Kat is making: the legal team is
looking to change the pages that the licenses are on, to add translation
links. I also know that they are thinking about ways of including the
licenses inside the deeds, which would also require some changes to the
license pages.
So the point is not "what do you think of Markdown" in a vacuum, it's: what
format can we store that contains only the absolute minimum to be
considered to be part of the licenses, so that we can build tooling to style
it appropriately depending on the context.
We could obviously write tooling that takes the current HTML and transforms
it, but such tooling would need to be highly content-aware: it would need to
know which parts of the HTML file it can remove or change, and which ones it
cannot. We likely can't eliminate that completely regardless of the format,
but we should try to minimize it.
Markdown seems pretty close to the minimal format that lets us express what
we need. We could also continue to use HTML, but we'd need to use a minimal
subset--not what we use now (which includes images, scripts, links not part
of the license, etc).
1. Both markdown and HTML (HyperText Markup Language) are markup
languages, it seems silly to convert one markup language into another.
This is not a criteria for choosing a format to use.
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
It does, but the alternative is an HTML->HTML transformation, which is
arguably more complex because HTML is so expressive. We could make it work
if we enforced a very limited subset of HTML as the input, though.
3. Markdown is not a standard and we cannot rely on it to stay the
same, HTML is.
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28Non-standard_HTML%29#Deprecated_HTML_elements
But you're right that Markdown is not currently led by any large standards
- to be transformed for general consumption, and
- to serve as an archive.
The first is internal to CC only, the second requires at most that the file
be readable at some point in the future without our help. In other words, we
do not need every client (browser) to natively understand the format.
(b) Markdown is so incredibly simple, it's hard to imagine a future where
http://etherpad.creativecommons.org/p/markdown-example
4. Markdown basically is short hand for HTML, again why would we use it?
Simplicity, and as a forcing function to get us to stop putting in
extraneous content in our licenses.
Dan
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org (mailto:cc-devel at lists.ibiblio.org) (mailto:cc-devel at lists.ibiblio.org)
http://lists.ibiblio.org/mailman/listinfo/cc-devel

_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org (mailto:cc-devel at lists.ibiblio.org)
http://lists.ibiblio.org/mailman/listinfo/cc-devel

--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| http://grossmeier.net (http://grossmeier.net/) A18D 1138 8E47 FAC8 1C7D |
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org (mailto:cc-devel at lists.ibiblio.org)
http://lists.ibiblio.org/mailman/listinfo/cc-devel

_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org (mailto:cc-devel at lists.ibiblio.org)
http://lists.ibiblio.org/mailman/listinfo/cc-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/cc-devel/attachments/20130418/0ae39919/attachment-0001.html

[Maarten Zeinstra]

I think we're almost there.

Let's say we have one HTML document that contains the license. It is mark with css classes and anchors. Now webtechnology can be created and or exists to embed that document. What I am getting at is that something like

http://creativecommons.org/licenses/by-nc-nd/3.0/legalcode

should consist of only one document with css designed for print, mobile devices, and regular screens, in may include js for errata

But let's only have one document! Let's not have it marked up in one markup language and presented in another, let's have one document. That's all I am saying.

Now if you want to add functionality, do not do it on the legalcode page. For example if you want to create a product say:

http://creativecommons.org/licenses/by-nc-nd/3.0/explained

You should use javascript or similar tech. to fetch the legalcode page and work from that to add functionality.
--

Post by Dan Mills
Can you explain a bit more what you mean? Not sure I get how it's different from what I'm suggesting.
Dan

Post by Dan Mills
This is not actually about Markdown.
This is about having a minimal document that we transform into the page the user sees, by adding styling, headers, errata, links to translations, or whatever the legal team wants to add. Markdown is just one example of a format that would make that easy.
I completely agree that there should be some immutable version of the license, the discussion is about what that should look like.
Dan

Post by Maarten Zeinstra
But really that is just silly.
What legal is requesting is a way to get to the 'real' legal code, but actually they are asking for a simple representation of that code. As I see it they want something like a 'print-version' of the legal code. That would still mean that there is markup in some way.
I would have one basic html document, slightly different than Kinkades example (I would stack css classes), and have two pages. One for web viewing and another completely dressed down for print.
I think given the option of a print version or a markdown version the legal-team will probably choose the former.
--

Post by Dan Mills
* Adding translation links at the bottom of the legal code page.
* Embedding the legal code into the deed in some manner.
Both are HTML for the end user, but *different HTML*.
1) a *minimal* format to express the licenses themselves, and nothing more.
2) some tooling to take those licenses and format them as needed depending on context.
And although we could write that tooling today with the HTML as-is, I would *much* rather write tools that know less about the license content.
Dan

Post by Greg Grossmeier
what tooling will you build that needs to use something other than HTML
to display the license?
What use-case do you have in mind, Dan?
Greg
<quote name="Dan Mills" date="2013-04-18" time="10:50:26 -0700">

Post by Dan Mills
Hi,
The licenses still contain too much information which is not actually part of the licenses. Just open that link, view source, and behold.
Of course we could parse it, but how would you decide what you can remove and what is part of the license? We need to minimize the amount of code that has such decisions embedded in it.
Dan

All of the CC licenses validate as XHTML 1.0 Transitional. There are
a lot of really great XML parsers out there for manipulating such
documents. It would be trivial for us to clean up the HTML in the 4.0
licenses to more minimal, using better nesting of id and classes so we
can use more accurate CSS selectors, and javascript can more reliably
navigate the DOM. I have already started this when I put together the
Draft 3 of the 4.0 licenses by giving a unique ID to each section and
http://mirrors.creativecommons.org/drafts/by-sa_4.0d3.html#s3a1B
Nathan

Post by Dan Mills
Hi Bjorn & Maarten,
I think you're missing a key point that Kat is making: the legal team is
looking to change the pages that the licenses are on, to add translation
links. I also know that they are thinking about ways of including the
licenses inside the deeds, which would also require some changes to the
license pages.
So the point is not "what do you think of Markdown" in a vacuum, it's: what
format can we store that contains only the absolute minimum to be
considered to be part of the licenses, so that we can build tooling to style
it appropriately depending on the context.
We could obviously write tooling that takes the current HTML and transforms
it, but such tooling would need to be highly content-aware: it would need to
know which parts of the HTML file it can remove or change, and which ones it
cannot. We likely can't eliminate that completely regardless of the format,
but we should try to minimize it.
Markdown seems pretty close to the minimal format that lets us express what
we need. We could also continue to use HTML, but we'd need to use a minimal
subset--not what we use now (which includes images, scripts, links not part
of the license, etc).
1. Both markdown and HTML (HyperText Markup Language) are markup
languages, it seems silly to convert one markup language into another.
This is not a criteria for choosing a format to use.
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
It does, but the alternative is an HTML->HTML transformation, which is
arguably more complex because HTML is so expressive. We could make it work
if we enforced a very limited subset of HTML as the input, though.
3. Markdown is not a standard and we cannot rely on it to stay the
same, HTML is.
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28Non-standard_HTML%29#Deprecated_HTML_elements
But you're right that Markdown is not currently led by any large standards
- to be transformed for general consumption, and
- to serve as an archive.
The first is internal to CC only, the second requires at most that the file
be readable at some point in the future without our help. In other words, we
do not need every client (browser) to natively understand the format.
(b) Markdown is so incredibly simple, it's hard to imagine a future where
http://etherpad.creativecommons.org/p/markdown-example
4. Markdown basically is short hand for HTML, again why would we use it?
Simplicity, and as a forcing function to get us to stop putting in
extraneous content in our licenses.
Dan
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org (mailto:cc-devel at lists.ibiblio.org)
http://lists.ibiblio.org/mailman/listinfo/cc-devel

_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| http://grossmeier.net A18D 1138 8E47 FAC8 1C7D |
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/cc-devel/attachments/20130418/75e270b4/attachment-0001.html

[Dan Mills]

I'm not sure that would work, unless you are suggesting that /legalcode be the bare-bones version and we generally link to /explained instead. If so, skip to the bottom of my reply :)

The problem is that the license, when prepared for human consumption, benefits from changes in its surroundings. For example:

(1) user visits the deed. It might be required for the legal code to be included there in some form (such as an expanding widget, for example). This is what I'm hearing from the legal team - it's not 100% clear yet, but a possibility. In such a setting, the legal code would need to

- not contain the big header
- not include the "back to deed" link at the bottom
- not include links to translations being proposed for the legalcode page (the deed already has locale links)

(2) user visits the legal code page. It makes sense to have the above, plus potentially other tools for e.g. viewing errata changes in-context.

Maybe what you meant is something like:

deed: links to /explained (not /legalcode).
/explained: web readable version generated from /legalcode
/legalcode: hand-edited bare-bones document with no JS or stylesheets.

If so, that's closer to what I proposed, except that it changes what /legalcode is today somewhat. I think we should have the URLs serve the purpose they serve today, just invert how they are generated:

deed: links to /legalcode (as it does today)
/legalcode: generated from /legalcode-plain
/legalcode-plain: hand-edited bare-bones document with no JS or stylesheets.

Dan

Post by Maarten Zeinstra
I think we're almost there.
Let's say we have one HTML document that contains the license. It is mark with css classes and anchors. Now webtechnology can be created and or exists to embed that document. What I am getting at is that something like
http://creativecommons.org/licenses/by-nc-nd/3.0/legalcode
should consist of only one document with css designed for print, mobile devices, and regular screens, in may include js for errata
But let's only have one document! Let's not have it marked up in one markup language and presented in another, let's have one document. That's all I am saying.
http://creativecommons.org/licenses/by-nc-nd/3.0/explained
You should use javascript or similar tech. to fetch the legalcode page and work from that to add functionality.
--
Kennisland

Post by Dan Mills
Can you explain a bit more what you mean? Not sure I get how it's different from what I'm suggesting.
Dan

Post by Dan Mills
This is not actually about Markdown.
This is about having a minimal document that we transform into the page the user sees, by adding styling, headers, errata, links to translations, or whatever the legal team wants to add. Markdown is just one example of a format that would make that easy.
I completely agree that there should be some immutable version of the license, the discussion is about what that should look like.
Dan

Post by Maarten Zeinstra
But really that is just silly.
What legal is requesting is a way to get to the 'real' legal code, but actually they are asking for a simple representation of that code. As I see it they want something like a 'print-version' of the legal code. That would still mean that there is markup in some way.
I would have one basic html document, slightly different than Kinkades example (I would stack css classes), and have two pages. One for web viewing and another completely dressed down for print.
I think given the option of a print version or a markdown version the legal-team will probably choose the former.
--
Kennisland

Post by Dan Mills
* Adding translation links at the bottom of the legal code page.
* Embedding the legal code into the deed in some manner.
Both are HTML for the end user, but *different HTML*.
1) a *minimal* format to express the licenses themselves, and nothing more.
2) some tooling to take those licenses and format them as needed depending on context.
And although we could write that tooling today with the HTML as-is, I would *much* rather write tools that know less about the license content.
Dan

Post by Greg Grossmeier
what tooling will you build that needs to use something other than HTML
to display the license?
What use-case do you have in mind, Dan?
Greg
<quote name="Dan Mills" date="2013-04-18" time="10:50:26 -0700">

Post by Dan Mills
Hi,
The licenses still contain too much information which is not actually part of the licenses. Just open that link, view source, and behold.
Of course we could parse it, but how would you decide what you can remove and what is part of the license? We need to minimize the amount of code that has such decisions embedded in it.
Dan

All of the CC licenses validate as XHTML 1.0 Transitional. There are
a lot of really great XML parsers out there for manipulating such
documents. It would be trivial for us to clean up the HTML in the 4.0
licenses to more minimal, using better nesting of id and classes so we
can use more accurate CSS selectors, and javascript can more reliably
navigate the DOM. I have already started this when I put together the
Draft 3 of the 4.0 licenses by giving a unique ID to each section and
http://mirrors.creativecommons.org/drafts/by-sa_4.0d3.html#s3a1B
Nathan

Post by Dan Mills
Hi Bjorn & Maarten,
I think you're missing a key point that Kat is making: the legal team is
looking to change the pages that the licenses are on, to add translation
links. I also know that they are thinking about ways of including the
licenses inside the deeds, which would also require some changes to the
license pages.
So the point is not "what do you think of Markdown" in a vacuum, it's: what
format can we store that contains only the absolute minimum to be
considered to be part of the licenses, so that we can build tooling to style
it appropriately depending on the context.
We could obviously write tooling that takes the current HTML and transforms
it, but such tooling would need to be highly content-aware: it would need to
know which parts of the HTML file it can remove or change, and which ones it
cannot. We likely can't eliminate that completely regardless of the format,
but we should try to minimize it.
Markdown seems pretty close to the minimal format that lets us express what
we need. We could also continue to use HTML, but we'd need to use a minimal
subset--not what we use now (which includes images, scripts, links not part
of the license, etc).
1. Both markdown and HTML (HyperText Markup Language) are markup
languages, it seems silly to convert one markup language into another.
This is not a criteria for choosing a format to use.
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
It does, but the alternative is an HTML->HTML transformation, which is
arguably more complex because HTML is so expressive. We could make it work
if we enforced a very limited subset of HTML as the input, though.
3. Markdown is not a standard and we cannot rely on it to stay the
same, HTML is.
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28Non-standard_HTML%29#Deprecated_HTML_elements
But you're right that Markdown is not currently led by any large standards
- to be transformed for general consumption, and
- to serve as an archive.
The first is internal to CC only, the second requires at most that the file
be readable at some point in the future without our help. In other words, we
do not need every client (browser) to natively understand the format.
(b) Markdown is so incredibly simple, it's hard to imagine a future where
http://etherpad.creativecommons.org/p/markdown-example
4. Markdown basically is short hand for HTML, again why would we use it?
Simplicity, and as a forcing function to get us to stop putting in
extraneous content in our licenses.
Dan
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org (mailto:cc-devel at lists.ibiblio.org) (mailto:cc-devel at lists.ibiblio.org)
http://lists.ibiblio.org/mailman/listinfo/cc-devel

_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org (mailto:cc-devel at lists.ibiblio.org)
http://lists.ibiblio.org/mailman/listinfo/cc-devel

--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| http://grossmeier.net (http://grossmeier.net/) A18D 1138 8E47 FAC8 1C7D |
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org (mailto:cc-devel at lists.ibiblio.org)
http://lists.ibiblio.org/mailman/listinfo/cc-devel

_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org (mailto:cc-devel at lists.ibiblio.org)
http://lists.ibiblio.org/mailman/listinfo/cc-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/cc-devel/attachments/20130418/2acb8f6b/attachment-0001.html

[Diane Peters]

Jumping in here on the legal team piece, please see inline.

Post by Nathan Yergler
<snip>
(1) user visits the deed. It might be required for the legal code to be
included there in some form (such as an expanding widget, for example).
This is what I'm hearing from the legal team - it's not 100% clear yet, but
a possibility. In such a setting, the legal code would need to
- not contain the big header
- not include the "back to deed" link at the bottom
- not include links to translations being proposed for the legalcode page
(the deed already has locale links)

What Dan's alluding to here is a possibility I mentioned to him when
discussing 4.0. Specifically, a few affiliates (maybe one or two) have in
the past asked that the deed be reproduced at the top of the legal code.
Dan's reaction back was, if it's determined there is a decision taken in
the 4.0 process to locate the deed and legal code in closer, immediate
proximity for some reason, then there exists the other possibility of
having the legal code appear in a scroll box (or other) on the deed rather
than the reverse.

This is not yet a discussion framed for comment with the affiliates, I'm
trying to follow up with those couple of affiliates who have petitioned for
this change in the past first. It's not at all certain it will progress,
just so you're aware.

Thanks for the good discussion. We'll progress the "what do we need/desire
from a legal perspective to remain unchanged" on the affiliate list.

Diane

Diane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/cc-devel/attachments/20130418/f7033285/attachment.html

[Maarten Zeinstra]

Hi Diane,

I'm neutral about being able to embed the legal code into another document, like a scroll box on the deed page.

What I am heavily opposing here is adding an extra layer of formatting to the legal code. Commonplace HTML is fine for the purpose you are referring to here. If you choose for MarkDown or HTML, either way you will need to develop a parser that converts that format to another format. However if you choose MarkDown you will need to write two parsers, for HTML only one: MarkDown to HTML and MarkDown to embeddeable text, or only HTML to embeddeable text. I would choose the latter as it is the way with the most standardisation and least development time. Developers that CC at the moment doesn't have.

I do have to remark that this is an unusual process of requesting feedback. It seems that you have intended functionality in mind, choose a way of implementing that functionality and are requesting feedback only on the implementation, leaving the intended functionality out of the discussion. A more structural way to go about this it so ask us for ways to implement intended functionality and not comment on the consequences of a flawed implementation. That would give a far more constructive discussion and leaves room for creativity.

Best,

Maarten
--

Post by Diane Peters
Jumping in here on the legal team piece, please see inline.
<snip>
(1) user visits the deed. It might be required for the legal code to be included there in some form (such as an expanding widget, for example). This is what I'm hearing from the legal team - it's not 100% clear yet, but a possibility. In such a setting, the legal code would need to
- not contain the big header
- not include the "back to deed" link at the bottom
- not include links to translations being proposed for the legalcode page (the deed already has locale links)
What Dan's alluding to here is a possibility I mentioned to him when discussing 4.0. Specifically, a few affiliates (maybe one or two) have in the past asked that the deed be reproduced at the top of the legal code. Dan's reaction back was, if it's determined there is a decision taken in the 4.0 process to locate the deed and legal code in closer, immediate proximity for some reason, then there exists the other possibility of having the legal code appear in a scroll box (or other) on the deed rather than the reverse.
This is not yet a discussion framed for comment with the affiliates, I'm trying to follow up with those couple of affiliates who have petitioned for this change in the past first. It's not at all certain it will progress, just so you're aware.
Thanks for the good discussion. We'll progress the "what do we need/desire from a legal perspective to remain unchanged" on the affiliate list.
Diane
Diane

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/cc-devel/attachments/20130422/654e1f17/attachment.html

[Kat Walsh]

Post by Maarten Zeinstra
I do have to remark that this is an unusual process of requesting feedback.
It seems that you have intended functionality in mind, choose a way of
implementing that functionality and are requesting feedback only on the
implementation, leaving the intended functionality out of the discussion. A
more structural way to go about this it so ask us for ways to implement
intended functionality and not comment on the consequences of a flawed
implementation. That would give a far more constructive discussion and
leaves room for creativity.

One thing I should say, that I don't think the initial message made
clear, is that this was meant to be understood as simply one proposal
to start discussion about the problem it was trying to solve, not a
finished product; I'm happy to see its presentation didn't prevent
questioning of the assumptions it was making where that was justified.

(Within Legal, we don't have strong opinions on the details of any
particular implementation--it's mostly about ensuring that whatever
does get used is suitable for the various purposes it needs to be used
for, not all of which we're going to be aware of without asking a
cross-section of communities.)

Cheers,
Kat

Post by Maarten Zeinstra
Best,
Maarten
--
Kennisland
Jumping in here on the legal team piece, please see inline.

Post by Nathan Yergler
<snip>
(1) user visits the deed. It might be required for the legal code to be
included there in some form (such as an expanding widget, for example). This
is what I'm hearing from the legal team - it's not 100% clear yet, but a
possibility. In such a setting, the legal code would need to
- not contain the big header
- not include the "back to deed" link at the bottom
- not include links to translations being proposed for the legalcode page
(the deed already has locale links)

What Dan's alluding to here is a possibility I mentioned to him when
discussing 4.0. Specifically, a few affiliates (maybe one or two) have in
the past asked that the deed be reproduced at the top of the legal code.
Dan's reaction back was, if it's determined there is a decision taken in the
4.0 process to locate the deed and legal code in closer, immediate proximity
for some reason, then there exists the other possibility of having the legal
code appear in a scroll box (or other) on the deed rather than the reverse.
This is not yet a discussion framed for comment with the affiliates, I'm
trying to follow up with those couple of affiliates who have petitioned for
this change in the past first. It's not at all certain it will progress,
just so you're aware.
Thanks for the good discussion. We'll progress the "what do we need/desire
from a legal perspective to remain unchanged" on the affiliate list.
Diane
Diane
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

--
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.

[Kat Walsh]

Coming back to this thread to respond to a few hanging points after
splitting off part of the discussion onto the affiliate list. For
those of you who aren't on that list, the question about which parts
of the current page make up part of the legal code was given in more
detail there, in preparation for a more public post about it; we
should have really asked this question separately to begin with.

Post by Maarten Zeinstra
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.
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.

This was actually a 2-part question that should have been entirely
split, into asking about what people consider to be "part of the
license" and the actual implementation of maintaining and displaying
it. You're right that the latter part should have been asked of this
community first--sorry for muddling the issue.

-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.

[Mike Linksvayer]

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.

I may have suggested something like this long ago, but I'd probably
stick to HTML as the canonical version now. That canonical HTML should
be as minimal as possible, just including enough structure and
annotation to make it possible for external CSS and Javascript to make
look pretty and dynamically add further annotation in a variety of
contexts, and for plain text to be generated without manual post
processing.

Mike

[yangzi2008]

2013-04-19







????Mike Linksvayer <ml at gondwanaland.com>
?????2013-04-19 00:32
???Re: [cc-devel] Legal code and technical implementation: your input wanted
????"Kat Walsh"<kat at creativecommons.org>
???"cc-devel at lists.ibiblio.org"<cc-devel at lists.ibiblio.org>

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.

I may have suggested something like this long ago, but I'd probably
stick to HTML as the canonical version now. That canonical HTML should
be as minimal as possible, just including enough structure and
annotation to make it possible for external CSS and Javascript to make
look pretty and dynamically add further annotation in a variety of
contexts, and for plain text to be generated without manual post
processing.

Mike
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/cc-devel/attachments/20130419/3295208c/attachment.html

[Nathan Yergler]

Post by Mike Linksvayer

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.

I may have suggested something like this long ago, but I'd probably
stick to HTML as the canonical version now. That canonical HTML should
be as minimal as possible, just including enough structure and
annotation to make it possible for external CSS and Javascript to make
look pretty and dynamically add further annotation in a variety of
contexts, and for plain text to be generated without manual post
processing.

While you could continue to use javascript, etc for injecting that
sort of customization, I think the burden for creating and maintaining
that sort of code is greater than that for a script that takes a
template document and runs in the actual content.

Regardless of the markup format for the "immutable" document, I think
my primary concern is making it easy for a software agent to "follow
its nose" from the license URI to the immutable legalcode. (I
*thought* there was follow-your-nose markup from the deed to the
legalcode, but I don't see it now, so maybe I'm mis-remembering.)
Figuring out what the right predicate is shouldn't be super difficult,
and would fit in the existing ecosystem.

For what it's worth, we added support for "stripped down" legalcode in
2010 (I think). For example,
http://creativecommons.org/licenses/by-sa/3.0/legalcode-plain. That
file is generated from the static HTML, and having
markdown/restructured text/something less expressive would have made
life a little easier.

NRY

Post by Mike Linksvayer
Mike
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

[Dan Mills]

Post by Nathan Yergler

Post by Mike Linksvayer

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.

I may have suggested something like this long ago, but I'd probably
stick to HTML as the canonical version now. That canonical HTML should
be as minimal as possible, just including enough structure and
annotation to make it possible for external CSS and Javascript to make
look pretty and dynamically add further annotation in a variety of
contexts, and for plain text to be generated without manual post
processing.

While you could continue to use javascript, etc for injecting that
sort of customization, I think the burden for creating and maintaining
that sort of code is greater than that for a script that takes a
template document and runs in the actual content.

I very much agree. Client-side JS absolutely has its place, and I have no problems with using it (heavily, if needed), but it's not some sort of escape hatch for modifying pages without modifying the page that is served up. That's just obfuscation, and it's harder to maintain.

Post by Nathan Yergler
Regardless of the markup format for the "immutable" document, I think
my primary concern is making it easy for a software agent to "follow
its nose" from the license URI to the immutable legalcode. (I
*thought* there was follow-your-nose markup from the deed to the
legalcode, but I don't see it now, so maybe I'm mis-remembering.)
Figuring out what the right predicate is shouldn't be super difficult,
and would fit in the existing ecosystem.

Were you thinking of a link? "The license on this page was generated from [link]" ?

Post by Nathan Yergler
For what it's worth, we added support for "stripped down" legalcode in
2010 (I think). For example,
http://creativecommons.org/licenses/by-sa/3.0/legalcode-plain. That
file is generated from the static HTML, and having
markdown/restructured text/something less expressive would have made
life a little easier.

Hah.

Yeah, so that plain format could be close to being acceptable as a *source* if we really want to use HTML (modulo the stylesheet and JS tags).

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/cc-devel/attachments/20130418/d71f7132/attachment.html

[Maarten Zeinstra]

Well actually ideally it would exactly the same document, but with different css and no js, right?

Cheers,

Maarten
--

Post by Dan Mills

Post by Nathan Yergler

Post by Mike Linksvayer

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.

I may have suggested something like this long ago, but I'd probably
stick to HTML as the canonical version now. That canonical HTML should
be as minimal as possible, just including enough structure and
annotation to make it possible for external CSS and Javascript to make
look pretty and dynamically add further annotation in a variety of
contexts, and for plain text to be generated without manual post
processing.

While you could continue to use javascript, etc for injecting that
sort of customization, I think the burden for creating and maintaining
that sort of code is greater than that for a script that takes a
template document and runs in the actual content.

I very much agree. Client-side JS absolutely has its place, and I have no problems with using it (heavily, if needed), but it's not some sort of escape hatch for modifying pages without modifying the page that is served up. That's just obfuscation, and it's harder to maintain.

Post by Nathan Yergler
Regardless of the markup format for the "immutable" document, I think
my primary concern is making it easy for a software agent to "follow
its nose" from the license URI to the immutable legalcode. (I
*thought* there was follow-your-nose markup from the deed to the
legalcode, but I don't see it now, so maybe I'm mis-remembering.)
Figuring out what the right predicate is shouldn't be super difficult,
and would fit in the existing ecosystem.

Were you thinking of a link? "The license on this page was generated from [link]" ?

Post by Nathan Yergler
For what it's worth, we added support for "stripped down" legalcode in
2010 (I think). For example,
http://creativecommons.org/licenses/by-sa/3.0/legalcode-plain. That
file is generated from the static HTML, and having
markdown/restructured text/something less expressive would have made
life a little easier.

Hah.
Yeah, so that plain format could be close to being acceptable as a *source* if we really want to use HTML (modulo the stylesheet and JS tags).
Dan
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/cc-devel/attachments/20130418/b8cfb183/attachment-0001.html

[Dan Mills]

Not necessarily, see the two examples I gave Greg. And there are others which we aren't interested in today, but we should know are possible in the future. For example:

http://www.gnu.org/licenses/gpl.html

That page has a ton of stuff that is not part of the GPL itself.

Again - that's not what we want to do at this time, but it's conceivable that at some point we might.

Dan

Post by Maarten Zeinstra
Well actually ideally it would exactly the same document, but with different css and no js, right?
Cheers,
Maarten
--
Kennisland

Post by Dan Mills

Post by Nathan Yergler

Post by Mike Linksvayer

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.

I may have suggested something like this long ago, but I'd probably
stick to HTML as the canonical version now. That canonical HTML should
be as minimal as possible, just including enough structure and
annotation to make it possible for external CSS and Javascript to make
look pretty and dynamically add further annotation in a variety of
contexts, and for plain text to be generated without manual post
processing.

While you could continue to use javascript, etc for injecting that
sort of customization, I think the burden for creating and maintaining
that sort of code is greater than that for a script that takes a
template document and runs in the actual content.

I very much agree. Client-side JS absolutely has its place, and I have no problems with using it (heavily, if needed), but it's not some sort of escape hatch for modifying pages without modifying the page that is served up. That's just obfuscation, and it's harder to maintain.

Post by Nathan Yergler
Regardless of the markup format for the "immutable" document, I think
my primary concern is making it easy for a software agent to "follow
its nose" from the license URI to the immutable legalcode. (I
*thought* there was follow-your-nose markup from the deed to the
legalcode, but I don't see it now, so maybe I'm mis-remembering.)
Figuring out what the right predicate is shouldn't be super difficult,
and would fit in the existing ecosystem.

Were you thinking of a link? "The license on this page was generated from [link]" ?

Post by Nathan Yergler
For what it's worth, we added support for "stripped down" legalcode in
2010 (I think). For example,
http://creativecommons.org/licenses/by-sa/3.0/legalcode-plain. That
file is generated from the static HTML, and having
markdown/restructured text/something less expressive would have made
life a little easier.

Hah.
Yeah, so that plain format could be close to being acceptable as a *source* if we really want to use HTML (modulo the stylesheet and JS tags).
Dan _______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org (mailto:cc-devel at lists.ibiblio.org)
http://lists.ibiblio.org/mailman/listinfo/cc-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/cc-devel/attachments/20130418/a4cf2861/attachment-0001.html

[Nathan Yergler]

On Thu, Apr 18, 2013 at 11:01 AM, Dan Mills <dan at creativecommons.org> wrote:
<snip>

Post by Nathan Yergler
Regardless of the markup format for the "immutable" document, I think
my primary concern is making it easy for a software agent to "follow
its nose" from the license URI to the immutable legalcode. (I
*thought* there was follow-your-nose markup from the deed to the
legalcode, but I don't see it now, so maybe I'm mis-remembering.)
Figuring out what the right predicate is shouldn't be super difficult,
and would fit in the existing ecosystem.
Were you thinking of a link? "The license on this page was generated from [link]" ?

Yes, but more specifically a machine-readable annotated anchor tag, or
link tag in head. Something that software could use to unambiguously
arrive at the immutable source. My thinking is that we give people the
deed as the canonical URI of the license (great!). It should then be
possible to write software that retrieves the immutable document and
compares it to some reference, so you can confirm that the copy you
received (or looked at last week) hasn't changed.

Post by Nathan Yergler
For what it's worth, we added support for "stripped down" legalcode in
2010 (I think). For example,
http://creativecommons.org/licenses/by-sa/3.0/legalcode-plain. That
file is generated from the static HTML, and having
markdown/restructured text/something less expressive would have made
life a little easier.
Hah.
Yeah, so that plain format could be close to being acceptable as a *source*
if we really want to use HTML (modulo the stylesheet and JS tags).

Hilariously, though, it's generated from the existing legalcode HTML
(Inception!) --
http://code.creativecommons.org/viewgit/cc.engine.git/tree/cc/engine/licenses/views.py#n183

NRY

Post by Nathan Yergler
Dan

[Greg Grossmeier]

<quote name="Kat Walsh" date="2013-04-18" time="00:57:57 +0200">

Post by Kat Walsh
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.

I really don't have much to add to Maarten and Mike's comments here,
honestly.

I like the idea of a plaintext-like base from which everything is
generated, but the only non-HTML markup that would probably be
standardized enough and not proprietary and/or stupid is something like
XML (wait, I did say not stupid....). ;-)

And if we're doing XML, might as well do HTML.

So yeah, barebones HTML, with all basic formatting included (bolding,
section numbering, etc) but with all styling in css/js as appropriate,
where that stuff can change as needed. I guess we trust CC enough to not
use CSS to hide certain parts of the license text ;-)

Also, a reminder as it relates to this topic: the annotation tool and
anchor tags are going to be a part of 4.0, right?

Annotation tool for marking errata and the anchor tags so I can like to
a specific section of the license, eg 4(b).

Greg