OKAPI already adds the following attribution notes:

http://i.imgur.com/q5CJie8.png

Please decide if you want your note to replace the current one, or you want to 
append your note to the current one, etc. Any change to this note will require 
new translations in all the languages.

Sry, I noticed OKAPI's disclaimer after opening this issue ... would have 
thought over it if I had seen it before.

I think we should replace it, including links to user profile, cache listing 
and cc-page, and add it small without date to log entries. English version "... 
as of YYYY-MM-DD" can be default for missing translations.

I have proposed this to the team - it also concerns our existing "XML 
Interface" - and will come back to you when it is decided. It turns out that 
not all implications of the datalicense have been considered upfront, we are 
learning the details now. Thanks for your support, we are very looking forward 
to starting up OKAPI. :-)

I think the current note will suffice until AFTER you have released OKAPI. We 
may still change it afterwards. Note, that other nodes may have other licences 
etc. so all of this has to be somewhat configurable (via your 
okapi_settings.php and mine okapi/settings.php).

Well, it MUST NOT be displayed before April 7, but the current note will not be 
sufficient from that date on - either OKAPI or the client applications must 
generate it then. This is because we were obliged by German law to email all 
users and prompt them to accept the new license, what we just did. And they 
accepted it including the clause that attribution of data downloaded from 
Opencaching.de must be in the form mentioned above.

Ok, I will tell what we have implemented in our "XML interface" and would like 
to have in OKAPI, too. I don't expect that you will jump and implement it - if 
you won't, we will have to live with the current solution or try to do the 
implementation ourselves (via a svn fork of the OKAPI repo of course, not in 
our code).

Default is that the disclaimer in this form is appended to all downloaded cache 
descriptions:

<p><em>© $USERNAME, www.opencaching.de, CC-BY-NC-ND, as of $DATE; all log 
entries © their authors</em></p>

... with the username linked to the user profile at opencaching.de, 
www.opencaching.de linked to the cache listing and cc-by-nc-nd linked to the 
license page (http://creativecommons.org/licenses/by-nc-nd/3.0/de/). All this 
is localized to language of the cache description, if possible, including the 
link to the license explanation (we have German, English, Italian and Spanish); 
otherwise in English. This should *replace* the current disclaimer added by 
OKAPI.

The client has the option to set a paramter "license=1", which will remove the 
disclaimer from the cache descriptions and instead deliver it in a dedicated 
'license' field without the <p><em> formatting, so that it can decide how and 
where it can be displayed best. This field is also available with log entries, 
which do not have a disclaimer appended otherwise. It is not important for us 
what happens to the OKAPI default disclaimer if the license option is set - it 
may be omitted or still be there.

So that's it.

[deleted comment]

I wouldn't like you to make a fork of OKAPI. Instead, please try to make the 
changes in the main repository, in a way that will work for all OC sites, as I 
did in the past.

I will implement this when you're ready to go online with OKAPI, okay? This is 
because I suspect you may change you mind a couple of times before you actually 
go for it... ;)

> I wouldn't like you to make a fork of OKAPI. Instead, please try to make the 
changes in the main repository, in a way that will work for all OC sites, as I 
did in the past.

Sure, that is what I meant.

We will switch to the new productive system (with PHP 5.3) on March 25 and go 
live with OKAPI on April 7.

This issue was closed by revision r602.

needs fixes

This issue was updated by revision r617.

This issue was closed by revision r618.

The mandantory form of attribution for OC.de turned out to be incompatible with 
OKAPI replication:

(from r617)
> > $owner['profile_url'], $owner['username'], $cache_url, $site_name, 
strftime('%x')
> This will make the replicate module rebuild the entire database every day. The
> attribution note is appended to every cache description. This way, the cache
> description changes every day.

I suggest to return the attribution note in a separate field 'attribution' 
instead of appending it to the description (without the <em></em>). This field 
will be included automatically if 'description', 'descriptions', 'hint', 
'hints', 'images', 'latest_logs', 'alt_wpts' or 'short_description(s)-TODO' are 
requested.

If the user does not explicitely request 'attribution', the OKAPI standard 
disclaimer will be appended to the descriptions. If 'attribution' is 
explicitely requested, the standard disclaimer is omitted. Documentation will 
state that the attribution field is not supported by all installations (and 
will what? if not present?), but if it is supported it is *mandantory* to 
display it / pass it on in the delivered or an equivalent form - see 
data-license-link - together with the cache description and/or cache images.

I would not like to make 'attribution' a default field because it generates so 
much data volume.

Is the date (%x) really necessary?

> If the user does not explicitely request 'attribution', the OKAPI standard 
> disclaimer will be appended to the descriptions. If 'attribution' is 
explicitely 
> requested, the standard disclaimer is omitted.

Fuck, this is not compatible with replication, too. OKAPI needs static 
description texts.

Also, you may require all applications to include your attribution note in your 
Terms of Use, without the need of including it in the data returned by OKAPI at 
all.

> Is the date (%x) really necessary?

Yes! 

> Also, you may require all applications to include your attribution note in  
> your Terms of Use, without the need of including it in the data returned by  
> OKAPI at all.

Sure, implicitely we already do that, but I already see us stuggling with lazy 
tool developers who didn't care. Ok, we can revoke their consumer keys in that 
case or say "it's not our problem" ... will cause additional stress.

I don't like any of the remaining options; will mull over it.

I was in error here:
> Fuck, this is not compatible with replication, too. OKAPI needs static 
description texts.

If 'attribution' field is included in the replication's logged cache fields, no 
disclaimer will be appended to the logged cache descriptions and it will work 
fine. It would be even finer if the default disclaimer is appended for 
replication. So here is a revision of my proposal from #15:

- A new field 'attribution' is introduced. Installations which do not support 
this will return null if explicitely requested. (If other nodes than oc.de 
decide to use it, too, it will need additional thought on how to configure & 
translate it.) The field is included in replication field list for 
installations which support it. The docs refer to data-license-link for more 
explanations on this field.

- If supported, the 'attribution' field will automatically be included if 
'description', 'descriptions', 'hint', 'hints', 'images', 'latest_logs' or 
'alt_wpts' is requested.

- A new boolean option-field 'exclude_attr_note' is introduced for oc.de. If 
this field is not set or false, the OKAPI standard disclaimer will be appended 
to the descriptions. If it is true, the standard disclaimer is omitted. This 
field is not in replication field list, so replication will include the 
standard disclaimer. The user is adviced that she MUST anyway include proper 
attribution with cache descriptions; see data-license-link.

I know, you don't like this because it adds complexity and additional 
installation-dependend switches to the OKAPI, and it may cause additional work 
if other nodes want to have it, too. But I think it will prevent future trouble 
for oc.de if we make it right now. I may do the implementation.

Yes, I don't like it... And I don't understand most of it. Maybe you could post 
some examples.

By examples I mean what gets returned on which request (in case of: 
caches/geocache, caches/formatters/gpx, replicate/fulldump, 
replicate/changelog).

GPX is another issue not only regarding OKAPI - thanks for pointing this out.

I will do a demonstration implementation, that is easier than explaining it 
"dry".

Goals:
1. Make all existing OKAPI clients immediately compatible to OC.de data license.
2. Make it as easy as possible for all OKAPI clients to comply with OC.de data 
license.
3. If possible, allow the clients to decide where and how they display the 
OC.de attribution note.

Consequences:
By default, OKAPI should automatically append the OC.de attribution note to 
cache descriptions whenever possible. If not possible (replication), it must be 
omitted. Users should be given the choice to exclude the note from cache 
descriptions and be provided with a ready-to-use note in a separate field.

Solution (proposal):

- Add an optional field 'attribution_note' to geocaches method; will contain 
the OC.de note or null for OCPL.

- Add a new boolean parameter 'attribution' to geocaches method which controls 
if the attribution note is appended to cache descriptions. Default is 'true'. 
If false, the 'attribution' field will be automatically included, and - only on 
OC.de - the note will NOT be appended to cache descriptions.

- Replication requests attribution=true if the node's attribution note is 
static, attribution=false if it is not static.

- GPX requests attribution=true.

I will commit my demonstration code to a feature branch. The changes to 
geocache, geocaches and gpx methods and the documentation engine are tested; 
the change to replication code ist just syntax-checked.

This issue was updated by revision r655.

This issue was updated by revision r657.

> If false, the 'attribution' field will be automatically included

should read: "the 'attribution_not' field ..."

This issue was updated by revision r658.

I will look into it as soon as I have some time.

I have rewritten most of your code and committed the changed to YOUR branch. 
Confirm that you're okay with them, then I will commit it to the trunk.

Note: I will be offline during the weekend.

This issue was updated by revision r667.

This issue was closed by revision r669.