[cc-devel] License Chooser: partner url method vs REST API vs Licensechooser.js

[BjornW]

Hi guys,

I'm working with Tarmo on a WordPress plugin (License) to update it to
the current WordPress and Creative Commons standards. It uses the
partner url method with an iframe to select a license at this moment,
but this approach seems not to include all the metadata options of the
current chooser found on creativecommons.org. I also saw some docs on
the REST API, but these were not updated since beginning of 2011. Can
both methods still be used? Or are there plans to focus all energy into
one method of adding a licensechooser to a webapp? What's the role of
licensechooser.js in all of this?

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

[Maarten Zeinstra]

Has there been an answer to this yet?

Best,

Maarten
--

Post by BjornW
Hi guys,
I'm working with Tarmo on a WordPress plugin (License) to update it to
the current WordPress and Creative Commons standards. It uses the
partner url method with an iframe to select a license at this moment,
but this approach seems not to include all the metadata options of the
current chooser found on creativecommons.org. I also saw some docs on
the REST API, but these were not updated since beginning of 2011. Can
both methods still be used? Or are there plans to focus all energy into
one method of adding a licensechooser to a webapp? What's the role of
licensechooser.js in all of this?
grtz
BjornW
--
met vriendelijke groet,
Bjorn Wijers
* b u r o b j o r n .nl *
digitaal vakmanschap | digital craftsmanship
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
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

[BjornW]

Hi Maarten,

No, not as far as I know. For now I've decided to continue with the
partner url method for this plugin. Any news on (technical) changes with
regards to CC 4.0?

grtz
BjornW

Post by Maarten Zeinstra
Has there been an answer to this yet?
Best,
Maarten

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

Chiming into this a bit late... but I don't think there's good reason
to call out to a CC API for the WP plugin. Licenses change very
infrequently, there is no reason to introduce a dynamic call of any
kind at runtime just to populate the license options.

As for 4.0 changes, there are no infrastructure changes required by
4.0 per se, but I do think that (apropos the above as well) we need to
take a more critical look at all the stuff we host and shut down /
archive the pieces that are not widely used and are unmaintained.

Dan

Post by BjornW
Hi Maarten,
No, not as far as I know. For now I've decided to continue with the
partner url method for this plugin. Any news on (technical) changes with
regards to CC 4.0?
grtz
BjornW

Post by Maarten Zeinstra
Has there been an answer to this yet?
Best,
Maarten

--
met vriendelijke groet,
Bjorn Wijers
* b u r o b j o r n .nl *
digitaal vakmanschap | digital craftsmanship
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
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

[Tarmo Toikkanen]

I have to agree with Dan. We'll just use 4.0 licenses, and have all the information statically.

Although one extra bit: translations. We'd like to be able to localize license names and explanations, and I imagine translations will appear gradually, so we might need to load these dynamically - maybe have a button in the wp-admin side to "load translations for language X" or something like that.

Btw, when will 4.0 licenses be technically ready, as in, in the license chooser, and available online?
--
Tarmo Toikkanen
tarmo at iki.fi
http://tarmo.fi

Post by Dan Mills
Chiming into this a bit late... but I don't think there's good reason
to call out to a CC API for the WP plugin. Licenses change very
infrequently, there is no reason to introduce a dynamic call of any
kind at runtime just to populate the license options.
As for 4.0 changes, there are no infrastructure changes required by
4.0 per se, but I do think that (apropos the above as well) we need to
take a more critical look at all the stuff we host and shut down /
archive the pieces that are not widely used and are unmaintained.
Dan

Post by BjornW
Hi Maarten,
No, not as far as I know. For now I've decided to continue with the
partner url method for this plugin. Any news on (technical) changes with
regards to CC 4.0?
grtz
BjornW

Post by Maarten Zeinstra
Has there been an answer to this yet?
Best,
Maarten

--
met vriendelijke groet,
Bjorn Wijers
* b u r o b j o r n .nl *
digitaal vakmanschap | digital craftsmanship
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
_______________________________________________
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/20131022/efd0d8f7/attachment.html

[Diane Peters]

As for when the chooser will technically be ready, we have settled pretty
much on the integration plan but we're waiting to finish the legal code and
some important collateral (updated FAQs, etc.). The chooser and the new
deeds will go live at the same time we push the legal code live. We're
planning on updating affiliates and this list shortly with launch plans.

Diane

Post by Tarmo Toikkanen
I have to agree with Dan. We'll just use 4.0 licenses, and have all the
information statically.
Although one extra bit: translations. We'd like to be able to localize
license names and explanations, and I imagine translations will appear
gradually, so we might need to load these dynamically - maybe have a button
in the wp-admin side to "load translations for language X" or something
like that.
Btw, when will 4.0 licenses be technically ready, as in, in the license
chooser, and available online?
--
Tarmo Toikkanen
tarmo at iki.fi
http://tarmo.fi
Chiming into this a bit late... but I don't think there's good reason
to call out to a CC API for the WP plugin. Licenses change very
infrequently, there is no reason to introduce a dynamic call of any
kind at runtime just to populate the license options.
As for 4.0 changes, there are no infrastructure changes required by
4.0 per se, but I do think that (apropos the above as well) we need to
take a more critical look at all the stuff we host and shut down /
archive the pieces that are not widely used and are unmaintained.
Dan
Hi Maarten,
No, not as far as I know. For now I've decided to continue with the
partner url method for this plugin. Any news on (technical) changes with
regards to CC 4.0?
grtz
BjornW
Has there been an answer to this yet?
Best,
Maarten
--
met vriendelijke groet,
Bjorn Wijers
* b u r o b j o r n .nl *
digitaal vakmanschap | digital craftsmanship
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
_______________________________________________
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
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

--
Diane M. Peters, CC General Counsel
http://creativecommons.org/staff#dianepeters
diane at creativecommons.org <email%3Adiane at creativecommons.org>


______________________________________

Please note: the contents of this email are not intended to be legal
advice nor should they be relied upon as, or represented to be legal
advice.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/cc-devel/attachments/20131022/109b39e6/attachment.html

[BjornW]

@Dan/Tarmo: Well, it doesn't matter if we call the API or the partner
URL, both are a call to CC.org Although to be fair the API will probably
need a lot more back & forth going calls than just the - at this moment
- one call to the CC partner URL. Anyways, I'll stick with the partner
url for now.

As for translations: I've read about an extra parameter to include a
locale (the docs for the partner url use lang as parameter, but the API
uses locales. As far as I understood these are not necessarially the
same. Bug in docs?). If the locale does not exists will the partner url
fallback to a different language/locale?

@Diane: Looking forward to the launch plans, so we can 'add' (mostly
test) the updated licenses to our plugin as well.

Thanks,

grtz
BjornW

Post by Diane Peters
As for when the chooser will technically be ready, we have settled
pretty much on the integration plan but we're waiting to finish the
legal code and some important collateral (updated FAQs, etc.). The
chooser and the new deeds will go live at the same time we push the
legal code live. We're planning on updating affiliates and this list
shortly with launch plans.
Diane
On Mon, Oct 21, 2013 at 9:59 PM, Tarmo Toikkanen
I have to agree with Dan. We'll just use 4.0 licenses, and have
all the information statically.
Although one extra bit: translations. We'd like to be able to
localize license names and explanations, and I imagine
translations will appear gradually, so we might need to load these
dynamically - maybe have a button in the wp-admin side to "load
translations for language X" or something like that.
Btw, when will 4.0 licenses be technically ready, as in, in the
license chooser, and available online?
--
Tarmo Toikkanen
tarmo at iki.fi <mailto:tarmo at iki.fi>
http://tarmo.fi

Post by Dan Mills
Chiming into this a bit late... but I don't think there's good reason
to call out to a CC API for the WP plugin. Licenses change very
infrequently, there is no reason to introduce a dynamic call of any
kind at runtime just to populate the license options.
As for 4.0 changes, there are no infrastructure changes required by
4.0 per se, but I do think that (apropos the above as well) we need to
take a more critical look at all the stuff we host and shut down /
archive the pieces that are not widely used and are unmaintained.
Dan
On Mon, Oct 21, 2013 at 5:08 AM, BjornW <burobjorn at gmail.com

Post by BjornW
Hi Maarten,
No, not as far as I know. For now I've decided to continue with the
partner url method for this plugin. Any news on (technical) changes with
regards to CC 4.0?
grtz
BjornW

Post by Maarten Zeinstra
Has there been an answer to this yet?
Best,
Maarten

--
met vriendelijke groet,
Bjorn Wijers
* b u r o b j o r n .nl *
digitaal vakmanschap | digital craftsmanship
Van maandag t/m donderdag vanaf 10:00
Vrijdag is voor experimenteren en eigen projecten.
Postbus 14145
3508 SE Utrecht
The Netherlands
tel: [phone] <tel:%2B31%206%2049%2074%2078%2070>
http://www.burobjorn.nl
_______________________________________________
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

_______________________________________________
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
--
Diane M. Peters, CC General Counsel
http://creativecommons.org/staff#dianepeters
diane at creativecommons.org <mailto:email%3Adiane at creativecommons.org>
______________________________________
Please note: the contents of this email are not intended to be legal
advice nor should they be relied upon as, or represented to be legal
advice.
_______________________________________________
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]

I wasn't arguing for using one API over the other. I was arguing for
simply bundling that info into the plugin and making no API calls at
all during runtime. The licenses change so infrequently that the
dynamic approach doesn't make sense to me.

Maybe if we made the "API" a flat file, and you cached it on the
client for a very long time, it could be OK. But running a custom-made
python service to serve up static data is a waste of resources, IMO.

As for translations, the best scenario IMO is for you to check out our
i18n repository at build time. Next best thing would be for you to get
those strings translated together with the rest of your app.

Dan

Post by BjornW
@Dan/Tarmo: Well, it doesn't matter if we call the API or the partner
URL, both are a call to CC.org Although to be fair the API will probably
need a lot more back & forth going calls than just the - at this moment
- one call to the CC partner URL. Anyways, I'll stick with the partner
url for now.
As for translations: I've read about an extra parameter to include a
locale (the docs for the partner url use lang as parameter, but the API
uses locales. As far as I understood these are not necessarially the
same. Bug in docs?). If the locale does not exists will the partner url
fallback to a different language/locale?
@Diane: Looking forward to the launch plans, so we can 'add' (mostly
test) the updated licenses to our plugin as well.
Thanks,
grtz
BjornW

Post by Diane Peters
As for when the chooser will technically be ready, we have settled
pretty much on the integration plan but we're waiting to finish the
legal code and some important collateral (updated FAQs, etc.). The
chooser and the new deeds will go live at the same time we push the
legal code live. We're planning on updating affiliates and this list
shortly with launch plans.
Diane
On Mon, Oct 21, 2013 at 9:59 PM, Tarmo Toikkanen
I have to agree with Dan. We'll just use 4.0 licenses, and have
all the information statically.
Although one extra bit: translations. We'd like to be able to
localize license names and explanations, and I imagine
translations will appear gradually, so we might need to load these
dynamically - maybe have a button in the wp-admin side to "load
translations for language X" or something like that.
Btw, when will 4.0 licenses be technically ready, as in, in the
license chooser, and available online?
--
Tarmo Toikkanen
tarmo at iki.fi <mailto:tarmo at iki.fi>
http://tarmo.fi

Post by Dan Mills
Chiming into this a bit late... but I don't think there's good reason
to call out to a CC API for the WP plugin. Licenses change very
infrequently, there is no reason to introduce a dynamic call of any
kind at runtime just to populate the license options.
As for 4.0 changes, there are no infrastructure changes required by
4.0 per se, but I do think that (apropos the above as well) we need to
take a more critical look at all the stuff we host and shut down /
archive the pieces that are not widely used and are unmaintained.
Dan
On Mon, Oct 21, 2013 at 5:08 AM, BjornW <burobjorn at gmail.com

Post by BjornW
Hi Maarten,
No, not as far as I know. For now I've decided to continue with the
partner url method for this plugin. Any news on (technical) changes with
regards to CC 4.0?
grtz
BjornW

Post by Maarten Zeinstra
Has there been an answer to this yet?
Best,
Maarten

--
met vriendelijke groet,
Bjorn Wijers
* b u r o b j o r n .nl *
digitaal vakmanschap | digital craftsmanship
Van maandag t/m donderdag vanaf 10:00
Vrijdag is voor experimenteren en eigen projecten.
Postbus 14145
3508 SE Utrecht
The Netherlands
tel: [phone] <tel:%2B31%206%2049%2074%2078%2070>
http://www.burobjorn.nl
_______________________________________________
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

_______________________________________________
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
--
Diane M. Peters, CC General Counsel
http://creativecommons.org/staff#dianepeters
diane at creativecommons.org <mailto:email%3Adiane at creativecommons.org>
______________________________________
Please note: the contents of this email are not intended to be legal
advice nor should they be relied upon as, or represented to be legal
advice.
_______________________________________________
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
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
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

[Greg Grossmeier]

<quote name="Dan Mills" date="2013-10-22" time="12:04:58 -0700">

Post by Dan Mills
As for translations, the best scenario IMO is for you to check out our
i18n repository at build time. Next best thing would be for you to get
those strings translated together with the rest of your app.

Translations are official from CC, we probably don't want to encourage
third-parties to start translating the Deed text, unless we have had a
change of heart recently.

Greg

[Dan Mills]

The repository in question is controlled by us. We should not commit
anything (strings or otherwise) that we do not agree with.

Dan

Post by Greg Grossmeier
<quote name="Dan Mills" date="2013-10-22" time="12:04:58 -0700">

Post by Dan Mills
As for translations, the best scenario IMO is for you to check out our
i18n repository at build time. Next best thing would be for you to get
those strings translated together with the rest of your app.

Translations are official from CC, we probably don't want to encourage
third-parties to start translating the Deed text, unless we have had a
change of heart recently.
Greg
--
| 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

[BjornW]

Hi Dan,

Thanks for your explanation. I'm not sure the static approach is as easy
as it seems. If we would use your suggested static approach, how would
you deal with:

- New localizations or updates in localizations?
- New jurisdictions or countries adapting CC licenses?
- Typos / small mistakes etc. in license (issues that do not merit a new
version)

Basically the gist of my question is: How do I know, as a developer,
something has changed?

Using a dynamic API (incl partner url) keeping track of changes should
(hopefully) be done more or less automatic without having to build a new
version of the plugin (and hoping users would keep up-to-date with new
versions). Not to mention making sure it's using officially endorsed
changes :)
With static builds it's up to me keeping track of changes in licenses &
at this moment I'd not know how or where to look for this info.

So for now I'm leaning towards using a 'dynamic' API (incl partner url)
approach, because it makes it more manageable for me now & (hopefully)
in the future.

Please keep this in mind before shutting down any API service.

All the best,

grtz
BjornW

Post by Dan Mills
I wasn't arguing for using one API over the other. I was arguing for
simply bundling that info into the plugin and making no API calls at
all during runtime. The licenses change so infrequently that the
dynamic approach doesn't make sense to me.
Maybe if we made the "API" a flat file, and you cached it on the
client for a very long time, it could be OK. But running a custom-made
python service to serve up static data is a waste of resources, IMO.
As for translations, the best scenario IMO is for you to check out our
i18n repository at build time. Next best thing would be for you to get
those strings translated together with the rest of your app.
Dan

Post by BjornW
@Dan/Tarmo: Well, it doesn't matter if we call the API or the partner
URL, both are a call to CC.org Although to be fair the API will probably
need a lot more back & forth going calls than just the - at this moment
- one call to the CC partner URL. Anyways, I'll stick with the partner
url for now.
As for translations: I've read about an extra parameter to include a
locale (the docs for the partner url use lang as parameter, but the API
uses locales. As far as I understood these are not necessarially the
same. Bug in docs?). If the locale does not exists will the partner url
fallback to a different language/locale?
@Diane: Looking forward to the launch plans, so we can 'add' (mostly
test) the updated licenses to our plugin as well.
Thanks,
grtz
BjornW

Post by Diane Peters
As for when the chooser will technically be ready, we have settled
pretty much on the integration plan but we're waiting to finish the
legal code and some important collateral (updated FAQs, etc.). The
chooser and the new deeds will go live at the same time we push the
legal code live. We're planning on updating affiliates and this list
shortly with launch plans.
Diane
On Mon, Oct 21, 2013 at 9:59 PM, Tarmo Toikkanen
I have to agree with Dan. We'll just use 4.0 licenses, and have
all the information statically.
Although one extra bit: translations. We'd like to be able to
localize license names and explanations, and I imagine
translations will appear gradually, so we might need to load these
dynamically - maybe have a button in the wp-admin side to "load
translations for language X" or something like that.
Btw, when will 4.0 licenses be technically ready, as in, in the
license chooser, and available online?
--
Tarmo Toikkanen
tarmo at iki.fi <mailto:tarmo at iki.fi>
http://tarmo.fi

Post by Dan Mills
Chiming into this a bit late... but I don't think there's good reason
to call out to a CC API for the WP plugin. Licenses change very
infrequently, there is no reason to introduce a dynamic call of any
kind at runtime just to populate the license options.
As for 4.0 changes, there are no infrastructure changes required by
4.0 per se, but I do think that (apropos the above as well) we need to
take a more critical look at all the stuff we host and shut down /
archive the pieces that are not widely used and are unmaintained.
Dan
On Mon, Oct 21, 2013 at 5:08 AM, BjornW <burobjorn at gmail.com

Post by BjornW
Hi Maarten,
No, not as far as I know. For now I've decided to continue with the
partner url method for this plugin. Any news on (technical) changes with
regards to CC 4.0?
grtz
BjornW

Post by Maarten Zeinstra
Has there been an answer to this yet?
Best,
Maarten

--
met vriendelijke groet,
Bjorn Wijers
* b u r o b j o r n .nl *
digitaal vakmanschap | digital craftsmanship
Van maandag t/m donderdag vanaf 10:00
Vrijdag is voor experimenteren en eigen projecten.
Postbus 14145
3508 SE Utrecht
The Netherlands
tel: [phone] <tel:%2B31%206%2049%2074%2078%2070>
http://www.burobjorn.nl
_______________________________________________
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

_______________________________________________
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
--
Diane M. Peters, CC General Counsel
http://creativecommons.org/staff#dianepeters
diane at creativecommons.org <mailto:email%3Adiane at creativecommons.org>
______________________________________
Please note: the contents of this email are not intended to be legal
advice nor should they be relied upon as, or represented to be legal
advice.
_______________________________________________
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
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
_______________________________________________
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

[Jonas Öberg]

Hi Bjorn,

what would your ideal API look like? Maybe this is something that CC
doesn't need to provide but which can be built separately as a support for
other software developers?

A larger group of people could then keep it updated and in line with
official CC licenses, as well as opening up to supporting other licenses
using the same interface.

Sincerely,
Jonas

Post by BjornW
Hi Dan,
Thanks for your explanation. I'm not sure the static approach is as easy
as it seems. If we would use your suggested static approach, how would
- New localizations or updates in localizations?
- New jurisdictions or countries adapting CC licenses?
- Typos / small mistakes etc. in license (issues that do not merit a new
version)
Basically the gist of my question is: How do I know, as a developer,
something has changed?
Using a dynamic API (incl partner url) keeping track of changes should
(hopefully) be done more or less automatic without having to build a new
version of the plugin (and hoping users would keep up-to-date with new
versions). Not to mention making sure it's using officially endorsed
changes :)
With static builds it's up to me keeping track of changes in licenses &
at this moment I'd not know how or where to look for this info.
So for now I'm leaning towards using a 'dynamic' API (incl partner url)
approach, because it makes it more manageable for me now & (hopefully)
in the future.
Please keep this in mind before shutting down any API service.
All the best,
grtz
BjornW

Post by Dan Mills
I wasn't arguing for using one API over the other. I was arguing for
simply bundling that info into the plugin and making no API calls at
all during runtime. The licenses change so infrequently that the
dynamic approach doesn't make sense to me.
Maybe if we made the "API" a flat file, and you cached it on the
client for a very long time, it could be OK. But running a custom-made
python service to serve up static data is a waste of resources, IMO.
As for translations, the best scenario IMO is for you to check out our
i18n repository at build time. Next best thing would be for you to get
those strings translated together with the rest of your app.
Dan

Post by BjornW
@Dan/Tarmo: Well, it doesn't matter if we call the API or the partner
URL, both are a call to CC.org Although to be fair the API will probably
need a lot more back & forth going calls than just the - at this moment
- one call to the CC partner URL. Anyways, I'll stick with the partner
url for now.
As for translations: I've read about an extra parameter to include a
locale (the docs for the partner url use lang as parameter, but the API
uses locales. As far as I understood these are not necessarially the
same. Bug in docs?). If the locale does not exists will the partner url
fallback to a different language/locale?
@Diane: Looking forward to the launch plans, so we can 'add' (mostly
test) the updated licenses to our plugin as well.
Thanks,
grtz
BjornW

Post by Diane Peters
As for when the chooser will technically be ready, we have settled
pretty much on the integration plan but we're waiting to finish the
legal code and some important collateral (updated FAQs, etc.). The
chooser and the new deeds will go live at the same time we push the
legal code live. We're planning on updating affiliates and this list
shortly with launch plans.
Diane
On Mon, Oct 21, 2013 at 9:59 PM, Tarmo Toikkanen
I have to agree with Dan. We'll just use 4.0 licenses, and have
all the information statically.
Although one extra bit: translations. We'd like to be able to
localize license names and explanations, and I imagine
translations will appear gradually, so we might need to load these
dynamically - maybe have a button in the wp-admin side to "load
translations for language X" or something like that.
Btw, when will 4.0 licenses be technically ready, as in, in the
license chooser, and available online?
--
Tarmo Toikkanen
tarmo at iki.fi <mailto:tarmo at iki.fi>
http://tarmo.fi

Post by Dan Mills
Chiming into this a bit late... but I don't think there's good

reason

Post by Dan Mills

Post by BjornW

Post by Diane Peters

Post by Dan Mills
to call out to a CC API for the WP plugin. Licenses change very
infrequently, there is no reason to introduce a dynamic call of

any

Post by Dan Mills

Post by BjornW

Post by Diane Peters

Post by Dan Mills
kind at runtime just to populate the license options.
As for 4.0 changes, there are no infrastructure changes required

by

Post by Dan Mills

Post by BjornW

Post by Diane Peters

Post by Dan Mills
4.0 per se, but I do think that (apropos the above as well) we need to
take a more critical look at all the stuff we host and shut down /
archive the pieces that are not widely used and are unmaintained.
Dan
On Mon, Oct 21, 2013 at 5:08 AM, BjornW <burobjorn at gmail.com

Post by BjornW
Hi Maarten,
No, not as far as I know. For now I've decided to continue with

the

Post by Dan Mills

Post by BjornW

Post by Diane Peters

Post by Dan Mills

Post by BjornW
partner url method for this plugin. Any news on (technical)
changes with
regards to CC 4.0?
grtz
BjornW

Post by Maarten Zeinstra
Has there been an answer to this yet?
Best,
Maarten

--
met vriendelijke groet,
Bjorn Wijers
* b u r o b j o r n .nl *
digitaal vakmanschap | digital craftsmanship
Van maandag t/m donderdag vanaf 10:00
Vrijdag is voor experimenteren en eigen projecten.
Postbus 14145
3508 SE Utrecht
The Netherlands
tel: [phone] <tel:%2B31%206%2049%2074%2078%2070>
http://www.burobjorn.nl
_______________________________________________
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

_______________________________________________
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
--
Diane M. Peters, CC General Counsel
http://creativecommons.org/staff#dianepeters
diane at creativecommons.org <mailto:email%3Adiane at creativecommons.org>
______________________________________
Please note: the contents of this email are not intended to be legal
advice nor should they be relied upon as, or represented to be legal
advice.
_______________________________________________
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
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
_______________________________________________
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
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
_______________________________________________
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/20131022/885ab1c2/attachment.html

[BjornW]

Hi Jonas et all,

I've been thinking about your question about the 'ideal' API and frankly
I don't have a very good answer: it depends on what you want to do with
it. In the context of the CC licenses my preference for the API is to
make my life easier as a developer. Not having to worry about
translations or fixes in the licenses that is.

Seen from this perspective **and I'm just thinking out loud** maybe an
addition to the current API would be the possibility to get a complete
in-browser chooser which can be automatically added to a webapp and is
easily updated from the API. So basically you'll have the complete
chooser as-is available from the partner url including translations
which you can cache. Every X times it pings the CC server to see if
there is a newer version of the chooser, et voila. Basically it would be
something in the middle ground between statically adding everything and
keeping it fully dynamic.

Anyways, for now the plugin is using the partner url. After I have the
other functionality done I may add the static option as well.

grtz
BjornW

Post by Jonas Öberg
Hi Bjorn,
what would your ideal API look like? Maybe this is something that CC
doesn't need to provide but which can be built separately as a support
for other software developers?
A larger group of people could then keep it updated and in line with
official CC licenses, as well as opening up to supporting other
licenses using the same interface.
Sincerely,
Jonas
On 22 Oct 2013 21:43, "BjornW" <burobjorn at gmail.com
Hi Dan,
Thanks for your explanation. I'm not sure the static approach is as easy
as it seems. If we would use your suggested static approach, how would
- New localizations or updates in localizations?
- New jurisdictions or countries adapting CC licenses?
- Typos / small mistakes etc. in license (issues that do not merit a new
version)
Basically the gist of my question is: How do I know, as a developer,
something has changed?
Using a dynamic API (incl partner url) keeping track of changes should
(hopefully) be done more or less automatic without having to build a new
version of the plugin (and hoping users would keep up-to-date with new
versions). Not to mention making sure it's using officially endorsed
changes :)
With static builds it's up to me keeping track of changes in licenses &
at this moment I'd not know how or where to look for this info.
So for now I'm leaning towards using a 'dynamic' API (incl partner url)
approach, because it makes it more manageable for me now & (hopefully)
in the future.
Please keep this in mind before shutting down any API service.
All the best,
grtz
BjornW

Post by Dan Mills
I wasn't arguing for using one API over the other. I was arguing for
simply bundling that info into the plugin and making no API calls at
all during runtime. The licenses change so infrequently that the
dynamic approach doesn't make sense to me.
Maybe if we made the "API" a flat file, and you cached it on the
client for a very long time, it could be OK. But running a

custom-made

Post by Dan Mills
python service to serve up static data is a waste of resources, IMO.
As for translations, the best scenario IMO is for you to check

out our

Post by Dan Mills
i18n repository at build time. Next best thing would be for you

to get

Post by Dan Mills
those strings translated together with the rest of your app.
Dan
On Tue, Oct 22, 2013 at 11:48 AM, BjornW <burobjorn at gmail.com

Post by BjornW
@Dan/Tarmo: Well, it doesn't matter if we call the API or the

partner

Post by Dan Mills

Post by BjornW
URL, both are a call to CC.org Although to be fair the API will

probably

Post by Dan Mills

Post by BjornW
need a lot more back & forth going calls than just the - at

this moment

Post by Dan Mills

Post by BjornW
- one call to the CC partner URL. Anyways, I'll stick with the

partner

Post by Dan Mills

Post by BjornW
url for now.
As for translations: I've read about an extra parameter to

include a

Post by Dan Mills

Post by BjornW
locale (the docs for the partner url use lang as parameter, but

the API

Post by Dan Mills

Post by BjornW
uses locales. As far as I understood these are not

necessarially the

Post by Dan Mills

Post by BjornW
same. Bug in docs?). If the locale does not exists will the

partner url

Post by Dan Mills

Post by BjornW
fallback to a different language/locale?
@Diane: Looking forward to the launch plans, so we can 'add'

(mostly

Post by Dan Mills

Post by BjornW
test) the updated licenses to our plugin as well.
Thanks,
grtz
BjornW

Post by Diane Peters
As for when the chooser will technically be ready, we have settled
pretty much on the integration plan but we're waiting to

finish the

Post by Dan Mills

Post by BjornW

Post by Diane Peters
legal code and some important collateral (updated FAQs, etc.).

The

Post by Dan Mills

Post by BjornW

Post by Diane Peters
chooser and the new deeds will go live at the same time we

push the

Post by Dan Mills

Post by BjornW

Post by Diane Peters
legal code live. We're planning on updating affiliates and

this list

Post by Dan Mills

Post by BjornW

Post by Diane Peters
shortly with launch plans.
Diane
On Mon, Oct 21, 2013 at 9:59 PM, Tarmo Toikkanen
<tarmo.toikkanen at iki.fi <mailto:tarmo.toikkanen at iki.fi>

<mailto:tarmo.toikkanen at iki.fi <mailto:tarmo.toikkanen at iki.fi>>>

Post by Dan Mills

Post by BjornW

Post by Diane Peters
I have to agree with Dan. We'll just use 4.0 licenses, and

have

Post by Dan Mills

Post by BjornW

Post by Diane Peters
all the information statically.
Although one extra bit: translations. We'd like to be able to
localize license names and explanations, and I imagine
translations will appear gradually, so we might need to

load these

Post by Dan Mills

Post by BjornW

Post by Diane Peters
dynamically - maybe have a button in the wp-admin side to

"load

Post by Dan Mills

Post by BjornW

Post by Diane Peters
translations for language X" or something like that.
Btw, when will 4.0 licenses be technically ready, as in,

in the

Post by Dan Mills

Post by BjornW

Post by Diane Peters
license chooser, and available online?
--
Tarmo Toikkanen
tarmo at iki.fi <mailto:tarmo at iki.fi> <mailto:tarmo at iki.fi

<mailto:tarmo at iki.fi>>

Post by Dan Mills

Post by BjornW

Post by Diane Peters
http://tarmo.fi

Post by Dan Mills
Chiming into this a bit late... but I don't think there's

good reason

Post by Dan Mills

Post by BjornW

Post by Diane Peters

Post by Dan Mills
to call out to a CC API for the WP plugin. Licenses

change very

Post by Dan Mills

Post by BjornW

Post by Diane Peters

Post by Dan Mills
infrequently, there is no reason to introduce a dynamic

call of any

Post by Dan Mills

Post by BjornW

Post by Diane Peters

Post by Dan Mills
kind at runtime just to populate the license options.
As for 4.0 changes, there are no infrastructure changes

required by

Post by Dan Mills

Post by BjornW

Post by Diane Peters

Post by Dan Mills
4.0 per se, but I do think that (apropos the above as

well) we

Post by Dan Mills

Post by BjornW

Post by Diane Peters

Post by Dan Mills
need to
take a more critical look at all the stuff we host and

shut down /

Post by Dan Mills

Post by BjornW

Post by Diane Peters

Post by Dan Mills
archive the pieces that are not widely used and are

unmaintained.

Post by Dan Mills

Post by BjornW

Post by Diane Peters

Post by Dan Mills
Dan
On Mon, Oct 21, 2013 at 5:08 AM, BjornW

<burobjorn at gmail.com <mailto:burobjorn at gmail.com>

Post by Dan Mills

Post by BjornW

Post by Diane Peters

Post by Dan Mills
<mailto:burobjorn at gmail.com

Post by BjornW
Hi Maarten,
No, not as far as I know. For now I've decided to

continue with the

Post by Dan Mills

Post by BjornW

Post by Diane Peters

Post by Dan Mills

Post by BjornW
partner url method for this plugin. Any news on (technical)
changes with
regards to CC 4.0?
grtz
BjornW

Post by Maarten Zeinstra
Has there been an answer to this yet?
Best,
Maarten

--
met vriendelijke groet,
Bjorn Wijers
* b u r o b j o r n .nl *
digitaal vakmanschap | digital craftsmanship
Van maandag t/m donderdag vanaf 10:00
Vrijdag is voor experimenteren en eigen projecten.
Postbus 14145
3508 SE Utrecht
The Netherlands
tel: [phone]

<tel:%2B31%206%2049%2074%2078%2070>
<tel:%2B31%206%2049%2074%2078%2070>

Post by Dan Mills

Post by BjornW

Post by Diane Peters

Post by Dan Mills

Post by BjornW
http://www.burobjorn.nl
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org

<mailto:cc-devel at lists.ibiblio.org>
<mailto:cc-devel at lists.ibiblio.org
<mailto:cc-devel at lists.ibiblio.org>>

Post by Dan Mills

Post by BjornW

Post by Diane Peters

Post by Dan Mills

Post by BjornW
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>
<mailto:cc-devel at lists.ibiblio.org
<mailto:cc-devel at lists.ibiblio.org>>

Post by Dan Mills

Post by BjornW

Post by Diane Peters

Post by Dan Mills
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>
<mailto:cc-devel at lists.ibiblio.org
<mailto:cc-devel at lists.ibiblio.org>>

Post by Dan Mills

Post by BjornW

Post by Diane Peters
http://lists.ibiblio.org/mailman/listinfo/cc-devel
--
Diane M. Peters, CC General Counsel
http://creativecommons.org/staff#dianepeters
diane at creativecommons.org <mailto:diane at creativecommons.org>

<mailto:email%3Adiane at creativecommons.org
<mailto:email%253Adiane at creativecommons.org>>

Post by Dan Mills

Post by BjornW

Post by Diane Peters
______________________________________
Please note: the contents of this email are not intended to be

legal

Post by Dan Mills

Post by BjornW

Post by Diane Peters
advice nor should they be relied upon as, or represented to be

legal

Post by Dan Mills

Post by BjornW

Post by Diane Peters
advice.
_______________________________________________
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

--
met vriendelijke groet,
Bjorn Wijers
* b u r o b j o r n .nl *
digitaal vakmanschap | digital craftsmanship
Van maandag t/m donderdag vanaf 10:00
Vrijdag is voor experimenteren en eigen projecten.
Postbus 14145
3508 SE Utrecht
The Netherlands
tel: [phone] <tel:%2B31%206%2049%2074%2078%2070>
http://www.burobjorn.nl
_______________________________________________
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

--
met vriendelijke groet,
Bjorn Wijers
* b u r o b j o r n .nl *
digitaal vakmanschap | digital craftsmanship
Van maandag t/m donderdag vanaf 10:00
Vrijdag is voor experimenteren en eigen projecten.
Postbus 14145
3508 SE Utrecht
The Netherlands
tel: [phone] <tel:%2B31%206%2049%2074%2078%2070>
http://www.burobjorn.nl
_______________________________________________
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

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

I understand that it simplifies your life as the CC plugin developer.
However, it's not a good tradeoff: making all plugin instances to
communicate with services infrastructure at runtime in order to
retrieve data that changes in a timescale of years (even in bustling
times, it's months) is just not worth it.

However, as I said before - I can see a flat file approach as
workable, so long as it's simple to maintain and you cache it client
side.

Dan

Post by BjornW
Hi Dan,
Thanks for your explanation. I'm not sure the static approach is as easy
as it seems. If we would use your suggested static approach, how would
- New localizations or updates in localizations?
- New jurisdictions or countries adapting CC licenses?
- Typos / small mistakes etc. in license (issues that do not merit a new
version)
Basically the gist of my question is: How do I know, as a developer,
something has changed?
Using a dynamic API (incl partner url) keeping track of changes should
(hopefully) be done more or less automatic without having to build a new
version of the plugin (and hoping users would keep up-to-date with new
versions). Not to mention making sure it's using officially endorsed
changes :)
With static builds it's up to me keeping track of changes in licenses &
at this moment I'd not know how or where to look for this info.
So for now I'm leaning towards using a 'dynamic' API (incl partner url)
approach, because it makes it more manageable for me now & (hopefully)
in the future.
Please keep this in mind before shutting down any API service.
All the best,
grtz
BjornW

Post by Dan Mills
I wasn't arguing for using one API over the other. I was arguing for
simply bundling that info into the plugin and making no API calls at
all during runtime. The licenses change so infrequently that the
dynamic approach doesn't make sense to me.
Maybe if we made the "API" a flat file, and you cached it on the
client for a very long time, it could be OK. But running a custom-made
python service to serve up static data is a waste of resources, IMO.
As for translations, the best scenario IMO is for you to check out our
i18n repository at build time. Next best thing would be for you to get
those strings translated together with the rest of your app.
Dan

Post by BjornW
@Dan/Tarmo: Well, it doesn't matter if we call the API or the partner
URL, both are a call to CC.org Although to be fair the API will probably
need a lot more back & forth going calls than just the - at this moment
- one call to the CC partner URL. Anyways, I'll stick with the partner
url for now.
As for translations: I've read about an extra parameter to include a
locale (the docs for the partner url use lang as parameter, but the API
uses locales. As far as I understood these are not necessarially the
same. Bug in docs?). If the locale does not exists will the partner url
fallback to a different language/locale?
@Diane: Looking forward to the launch plans, so we can 'add' (mostly
test) the updated licenses to our plugin as well.
Thanks,
grtz
BjornW

Post by Diane Peters
As for when the chooser will technically be ready, we have settled
pretty much on the integration plan but we're waiting to finish the
legal code and some important collateral (updated FAQs, etc.). The
chooser and the new deeds will go live at the same time we push the
legal code live. We're planning on updating affiliates and this list
shortly with launch plans.
Diane
On Mon, Oct 21, 2013 at 9:59 PM, Tarmo Toikkanen
I have to agree with Dan. We'll just use 4.0 licenses, and have
all the information statically.
Although one extra bit: translations. We'd like to be able to
localize license names and explanations, and I imagine
translations will appear gradually, so we might need to load these
dynamically - maybe have a button in the wp-admin side to "load
translations for language X" or something like that.
Btw, when will 4.0 licenses be technically ready, as in, in the
license chooser, and available online?
--
Tarmo Toikkanen
tarmo at iki.fi <mailto:tarmo at iki.fi>
http://tarmo.fi

Post by Dan Mills
Chiming into this a bit late... but I don't think there's good reason
to call out to a CC API for the WP plugin. Licenses change very
infrequently, there is no reason to introduce a dynamic call of any
kind at runtime just to populate the license options.
As for 4.0 changes, there are no infrastructure changes required by
4.0 per se, but I do think that (apropos the above as well) we need to
take a more critical look at all the stuff we host and shut down /
archive the pieces that are not widely used and are unmaintained.
Dan
On Mon, Oct 21, 2013 at 5:08 AM, BjornW <burobjorn at gmail.com

Post by BjornW
Hi Maarten,
No, not as far as I know. For now I've decided to continue with the
partner url method for this plugin. Any news on (technical) changes with
regards to CC 4.0?
grtz
BjornW

Post by Maarten Zeinstra
Has there been an answer to this yet?
Best,
Maarten

--
met vriendelijke groet,
Bjorn Wijers
* b u r o b j o r n .nl *
digitaal vakmanschap | digital craftsmanship
Van maandag t/m donderdag vanaf 10:00
Vrijdag is voor experimenteren en eigen projecten.
Postbus 14145
3508 SE Utrecht
The Netherlands
tel: [phone] <tel:%2B31%206%2049%2074%2078%2070>
http://www.burobjorn.nl
_______________________________________________
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

_______________________________________________
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
--
Diane M. Peters, CC General Counsel
http://creativecommons.org/staff#dianepeters
diane at creativecommons.org <mailto:email%3Adiane at creativecommons.org>
______________________________________
Please note: the contents of this email are not intended to be legal
advice nor should they be relied upon as, or represented to be legal
advice.
_______________________________________________
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
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
_______________________________________________
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
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

[Kent Mewhort]

Bjorn, keep in mind as well that the DEED translations are much more
static and somewhat independent of the LEGAL ports. That is, for all
ports and versions, the localized deeds are available in all the
languages even when the legal texts are not When you link to a license,
you generally only point to the deed itself, so this process should be
transparent wrt to the ongoing process of affiliates releasing new ports
and license translations.

With that in mind, if you're going with a dropdown list of licenses, all
you should need are translations of the license titles, correct? You can
use the i18n files I have for my rails license chooser:
https://github.com/kmewhort/creative_commons_rails/blob/master/config/locales/cc_license_notices.yml.
Or, I don't know how this compares to the i18n files from the official
CC repos, but you should probably use the latter if they're available.

Kent

Post by BjornW
Hi Dan,
Thanks for your explanation. I'm not sure the static approach is as easy
as it seems. If we would use your suggested static approach, how would
- New localizations or updates in localizations?
- New jurisdictions or countries adapting CC licenses?
- Typos / small mistakes etc. in license (issues that do not merit a new
version)
Basically the gist of my question is: How do I know, as a developer,
something has changed?
Using a dynamic API (incl partner url) keeping track of changes should
(hopefully) be done more or less automatic without having to build a new
version of the plugin (and hoping users would keep up-to-date with new
versions). Not to mention making sure it's using officially endorsed
changes :)
With static builds it's up to me keeping track of changes in licenses &
at this moment I'd not know how or where to look for this info.
So for now I'm leaning towards using a 'dynamic' API (incl partner url)
approach, because it makes it more manageable for me now & (hopefully)
in the future.
Please keep this in mind before shutting down any API service.
All the best,
grtz
BjornW

Post by Dan Mills
I wasn't arguing for using one API over the other. I was arguing for
simply bundling that info into the plugin and making no API calls at
all during runtime. The licenses change so infrequently that the
dynamic approach doesn't make sense to me.
Maybe if we made the "API" a flat file, and you cached it on the
client for a very long time, it could be OK. But running a custom-made
python service to serve up static data is a waste of resources, IMO.
As for translations, the best scenario IMO is for you to check out our
i18n repository at build time. Next best thing would be for you to get
those strings translated together with the rest of your app.
Dan

Post by BjornW
@Dan/Tarmo: Well, it doesn't matter if we call the API or the partner
URL, both are a call to CC.org Although to be fair the API will probably
need a lot more back & forth going calls than just the - at this moment
- one call to the CC partner URL. Anyways, I'll stick with the partner
url for now.
As for translations: I've read about an extra parameter to include a
locale (the docs for the partner url use lang as parameter, but the API
uses locales. As far as I understood these are not necessarially the
same. Bug in docs?). If the locale does not exists will the partner url
fallback to a different language/locale?
@Diane: Looking forward to the launch plans, so we can 'add' (mostly
test) the updated licenses to our plugin as well.
Thanks,
grtz
BjornW

Post by Diane Peters
As for when the chooser will technically be ready, we have settled
pretty much on the integration plan but we're waiting to finish the
legal code and some important collateral (updated FAQs, etc.). The
chooser and the new deeds will go live at the same time we push the
legal code live. We're planning on updating affiliates and this list
shortly with launch plans.
Diane
On Mon, Oct 21, 2013 at 9:59 PM, Tarmo Toikkanen
I have to agree with Dan. We'll just use 4.0 licenses, and have
all the information statically.
Although one extra bit: translations. We'd like to be able to
localize license names and explanations, and I imagine
translations will appear gradually, so we might need to load these
dynamically - maybe have a button in the wp-admin side to "load
translations for language X" or something like that.
Btw, when will 4.0 licenses be technically ready, as in, in the
license chooser, and available online?
--
Tarmo Toikkanen
tarmo at iki.fi <mailto:tarmo at iki.fi>
http://tarmo.fi

Post by Dan Mills
Chiming into this a bit late... but I don't think there's good reason
to call out to a CC API for the WP plugin. Licenses change very
infrequently, there is no reason to introduce a dynamic call of any
kind at runtime just to populate the license options.
As for 4.0 changes, there are no infrastructure changes required by
4.0 per se, but I do think that (apropos the above as well) we need to
take a more critical look at all the stuff we host and shut down /
archive the pieces that are not widely used and are unmaintained.
Dan
On Mon, Oct 21, 2013 at 5:08 AM, BjornW <burobjorn at gmail.com

Post by BjornW
Hi Maarten,
No, not as far as I know. For now I've decided to continue with the
partner url method for this plugin. Any news on (technical) changes with
regards to CC 4.0?
grtz
BjornW

Post by Maarten Zeinstra
Has there been an answer to this yet?
Best,
Maarten

--
met vriendelijke groet,
Bjorn Wijers
* b u r o b j o r n .nl *
digitaal vakmanschap | digital craftsmanship
Van maandag t/m donderdag vanaf 10:00
Vrijdag is voor experimenteren en eigen projecten.
Postbus 14145
3508 SE Utrecht
The Netherlands
tel: [phone] <tel:%2B31%206%2049%2074%2078%2070>
http://www.burobjorn.nl
_______________________________________________
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

_______________________________________________
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
--
Diane M. Peters, CC General Counsel
http://creativecommons.org/staff#dianepeters
diane at creativecommons.org <mailto:email%3Adiane at creativecommons.org>
______________________________________
Please note: the contents of this email are not intended to be legal
advice nor should they be relied upon as, or represented to be legal
advice.
_______________________________________________
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
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
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

[BjornW]

Hi Kent et all,

Thanks for your suggestion. Your approach, and suggestions from Dan,
Mike et all of only translating the HTML/RDFA is indeed something very
doable and for this plugin probably a fine solution. For now I'm still
using the partner url, but I'm probably going to add (or replace the
partner url with) the static option after I'm done with the other features.

grtz
BjornW

Post by Kent Mewhort
Bjorn, keep in mind as well that the DEED translations are much more
static and somewhat independent of the LEGAL ports. That is, for all
ports and versions, the localized deeds are available in all the
languages even when the legal texts are not When you link to a license,
you generally only point to the deed itself, so this process should be
transparent wrt to the ongoing process of affiliates releasing new ports
and license translations.
With that in mind, if you're going with a dropdown list of licenses, all
you should need are translations of the license titles, correct? You can
https://github.com/kmewhort/creative_commons_rails/blob/master/config/locales/cc_license_notices.yml.
Or, I don't know how this compares to the i18n files from the official
CC repos, but you should probably use the latter if they're available.
Kent

Post by BjornW
Hi Dan,
Thanks for your explanation. I'm not sure the static approach is as easy
as it seems. If we would use your suggested static approach, how would
- New localizations or updates in localizations?
- New jurisdictions or countries adapting CC licenses?
- Typos / small mistakes etc. in license (issues that do not merit a new
version)
Basically the gist of my question is: How do I know, as a developer,
something has changed?
Using a dynamic API (incl partner url) keeping track of changes should
(hopefully) be done more or less automatic without having to build a new
version of the plugin (and hoping users would keep up-to-date with new
versions). Not to mention making sure it's using officially endorsed
changes :)
With static builds it's up to me keeping track of changes in licenses &
at this moment I'd not know how or where to look for this info.
So for now I'm leaning towards using a 'dynamic' API (incl partner url)
approach, because it makes it more manageable for me now & (hopefully)
in the future.
Please keep this in mind before shutting down any API service.
All the best,
grtz
BjornW

Post by Dan Mills
I wasn't arguing for using one API over the other. I was arguing for
simply bundling that info into the plugin and making no API calls at
all during runtime. The licenses change so infrequently that the
dynamic approach doesn't make sense to me.
Maybe if we made the "API" a flat file, and you cached it on the
client for a very long time, it could be OK. But running a custom-made
python service to serve up static data is a waste of resources, IMO.
As for translations, the best scenario IMO is for you to check out our
i18n repository at build time. Next best thing would be for you to get
those strings translated together with the rest of your app.
Dan

Post by BjornW
@Dan/Tarmo: Well, it doesn't matter if we call the API or the partner
URL, both are a call to CC.org Although to be fair the API will probably
need a lot more back & forth going calls than just the - at this moment
- one call to the CC partner URL. Anyways, I'll stick with the partner
url for now.
As for translations: I've read about an extra parameter to include a
locale (the docs for the partner url use lang as parameter, but the API
uses locales. As far as I understood these are not necessarially the
same. Bug in docs?). If the locale does not exists will the partner url
fallback to a different language/locale?
@Diane: Looking forward to the launch plans, so we can 'add' (mostly
test) the updated licenses to our plugin as well.
Thanks,
grtz
BjornW

Post by Diane Peters
As for when the chooser will technically be ready, we have settled
pretty much on the integration plan but we're waiting to finish the
legal code and some important collateral (updated FAQs, etc.). The
chooser and the new deeds will go live at the same time we push the
legal code live. We're planning on updating affiliates and this list
shortly with launch plans.
Diane
On Mon, Oct 21, 2013 at 9:59 PM, Tarmo Toikkanen
I have to agree with Dan. We'll just use 4.0 licenses, and have
all the information statically.
Although one extra bit: translations. We'd like to be able to
localize license names and explanations, and I imagine
translations will appear gradually, so we might need to load these
dynamically - maybe have a button in the wp-admin side to "load
translations for language X" or something like that.
Btw, when will 4.0 licenses be technically ready, as in, in the
license chooser, and available online?
--
Tarmo Toikkanen
tarmo at iki.fi <mailto:tarmo at iki.fi>
http://tarmo.fi

Post by Dan Mills
Chiming into this a bit late... but I don't think there's good reason
to call out to a CC API for the WP plugin. Licenses change very
infrequently, there is no reason to introduce a dynamic call of any
kind at runtime just to populate the license options.
As for 4.0 changes, there are no infrastructure changes required by
4.0 per se, but I do think that (apropos the above as well) we need to
take a more critical look at all the stuff we host and shut down /
archive the pieces that are not widely used and are unmaintained.
Dan
On Mon, Oct 21, 2013 at 5:08 AM, BjornW <burobjorn at gmail.com

Post by BjornW
Hi Maarten,
No, not as far as I know. For now I've decided to continue with the
partner url method for this plugin. Any news on (technical)
changes with
regards to CC 4.0?
grtz
BjornW

Post by Maarten Zeinstra
Has there been an answer to this yet?
Best,
Maarten

--
met vriendelijke groet,
Bjorn Wijers
* b u r o b j o r n .nl *
digitaal vakmanschap | digital craftsmanship
Van maandag t/m donderdag vanaf 10:00
Vrijdag is voor experimenteren en eigen projecten.
Postbus 14145
3508 SE Utrecht
The Netherlands
tel: [phone] <tel:%2B31%206%2049%2074%2078%2070>
http://www.burobjorn.nl
_______________________________________________
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

_______________________________________________
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
--
Diane M. Peters, CC General Counsel
http://creativecommons.org/staff#dianepeters
diane at creativecommons.org <mailto:email%3Adiane at creativecommons.org>
______________________________________
Please note: the contents of this email are not intended to be legal
advice nor should they be relied upon as, or represented to be legal
advice.
_______________________________________________
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
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
_______________________________________________
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

[Mike Linksvayer]

Post by Dan Mills
Chiming into this a bit late... but I don't think there's good reason
to call out to a CC API for the WP plugin. Licenses change very
infrequently, there is no reason to introduce a dynamic call of any
kind at runtime just to populate the license options.

FWIW, I totally agree with Dan.

Probably if I were doing it I'd list the pertinent licenses (I guess
7; CC0 and 6 4.0 licenses) and have an option to enter the URL and
title of another license if user wants something other than those. As
far as metadata, anything other than annotating the license link with
rel="license" is not worth it, unless you're also planning to
integrate with the WordPress media manager, which would be a bigger
job. This, or even fewer features, works for almost every major CC
integration.

The partner interface still works fairly well if you really want a Q&A
style "chooser". It, and the a bit later the CC API, were developed
when CC might've been developing a lot of different licenses (in a way
it did via porting of course...), making more navigation than a list
conceivably useful. The CC API was developed when it still seemed
non-web clients were important. May or may not have been a good choice
then, but certainly not now.

Yet another option that may not have been mentioned here is
http://wiki.creativecommons.org/LicenseChooser.js which seems to be
used by yet another old CC WordPress thing.

Mike