Samalla kannalla ettei tuoda, oikeastaan kyllä hiukan eri perustein, niin kauan kuin siellä OSMin copyright-sivulla ei ole linkkiä MML:n lisenssiin, niin asia ei minusta ole epäselvä.
Tämä on minun nähdäkseni ylitulkintaa. Hahmotan tämän asian niin (mm. MML:n väen kanssa puhumisen perusteella), että MML:n tavoite lisenssillä on, että tieto alkuperästä ja lisensistä välittyy aineiston käyttäjille, eli idea ja pyrkimys on, että loppukäyttäjällekin tuo näkyisi.
Kuten aiemminkin hahmottelin, jos / kun OSM esittää verkkosivullaan maininnan siitä, että lähteenä on Maanmittauslaitos, ja linkin MML:n lisenssiin, tällöin homma olisi nähdäkseni MML-dataa OSM:ään syöttäjän kannalta kunnossa, syöttäjä noudattaisi lisenssin vaatimuksia, jos ajatellaan niin, että OSM:ään syöttäjä myöntää OSM-säätiölle oikeuden käyttää tuotostaan eli OSM-muokkausta.
Eihän lisenssi sisällä vaatimusta, että aineiston välittäjän pitää kertoa alkuperästä ja lisenssistä neljännelle, viidennelle, kuudennelle jne. - sitten sen sen kolmannen osapuolen vastuulla on kertoa neljännelle jnpp. Eli se, mitä OSMiin laitetulle aineistolle tapahtuu, on sitten OSMin asia, ei syöttäjän.
Mutta voihan mielenkiinnon vuoksi tarkastella asiaa myös OSMin kannalta, tai hiukan eri vinkkelistä. Jos katsotaan, että OSM on second party ja “third party” on kuka tahansa OSM-palvelun käyttäjä. Silloin on kyse siitä, onko OSM-säätiön sivuilla esitetty viittaus MML-lisenssiin ja MML-lisenssin ylläoleva vaatimus riittävä täyttämään tuon kriteerin, että OSM-säätiö on vaatinut kolmannelta osapuolelta vastaavan informaation eteenpäinlevittämistä. Miksei olisi? Niinhän nuo lisenssit yleensäkin toimivat, että käyttäjälle näytetään tekijänoikeus- ja lisenssiehdot, ja niitä sitten noudattakoon ne, jotka aineistoa käyttävät.
Mutta sinänsä tämä on vähän turhaa spekulointia, siitä mitä OSM tekee päättää OSM, sillähän se selviää mitä OSM tekee kun asian sinne vie.
Kiitos hyvistä pointtereista, kiinnostusta on, tosin tässäkin kyllä törmätään lisenssiasiaan, joka on aika ratkaiseva sen kannalta kuinka hyödyllisiä tuollaisen yhdistämisen tulokset ovat.
Minusta näyttää, että MML- ja OSM-lisenssit olisivat yhteensopivia, mutta eipä minun näkemykselläni asiaan ole kauheasti merkitystä, asia on kiinni lähinnä OSM-väestä, mahdollisesti myös MML:n tahdonilmauksista. Näyttää hyvinkin mahdolliselta, että OSMista huolehtiva väki saattaa katsoa, että MML-aineisto ei ole lisenssiltään yhteensopivaa.
Käytännön esimerkki: Sanotaan vaikka, että paketoitaisiin sovellus, jossa olisi kaavailemasi aineisto, Suomen tiestö MML-aineistosta plus nopeusrajoitukset OSM-aineistosta, ja sovelluspuolella kartan näyttö plus käyttäjälle varoitus siitä, kun ajetaan ylinopeutta tai lähellä sitä. Olisiko tällaisen paketin jako käyttäjille mahdollista?
Nähtävästi tuollainen OSM-nopeusrajoitukset plus MML-tiet -aineisto olisi ODbL:n termistössä tulkinnasta riippuen joko “Derivative Database”:
Jakelun kannalta on erittäin oleellinen ero siinä, kumpaan luokkaan paketti menisi. Produced Workin eteenpäinjakelukriteerit ovat lievemmät kuin Derivative Databasen. Pääperiaate on, että todetaan, että sisältää OSM-dataa ja miten OSM-data on lisensoitu.
Derivative Databasen jakelu taas edellyttää Share Alike -periaatetta:
Esim. kohta d. on aika selkeä: Derivative Databaseen ei saa lisätä dataa ODbL:n kanssa epäyhteensopivasta lähteestä.
Ymmärrän tämän niin, että jos tuollaisen OSM-nopeusrajoituksilla MML-tiet sisältävän sovelluksen katsottaisiin olevan “derivative database”, tai siis jos sovelluksen jakelussa katsottaisiin olevan kyse derivative databasen jakelusta, niin tätä derivative databasea ei olisi sallittua jaella.
Mikäli käy niin, että tulkinta on se, että MML- ja OSM-lisenssit eivät ole yhteensopivia, alan kiinnostua sellaisesta avoimen / vapaan datan karttahankkeesta, jossa yhteisö voi lisätä MML:n karttadatan täydennykseksi aineistoa, ja tätä yhteistulosta (MML-aineisto + käyttäjäyhteisön lisäykset) voi jaella eteenpäin.
Tätä ympäristöä ei siis vielä ole jos lisenssit eivät ole yhteensopivia. Tuollainen hanke siis pitäisi luoda, käytännössä tarkoittaisi MML-lisenssin kanssa yhteensopivan avoimen koodin lisenssin laatimista ja tietokannan + muokkausympäristön + mielellään myös rasterikarttapalvelun pystyttämistä sellaisilla tavoille että mukaan saataisiin riittävä määrä Suomen avoimen kartta-aineiston kehittämisestä kiinnostuneita.
Helppo uskoa että olet eri mieltä, mutta tosiasiassa juurikin tälläisten olemassa olevasta datasta välinpitämättömien importtaajien takia importeista ei kauheasti osmin puolella ensinnäkään tykätä (yksi painava syy muiden joukossa), ja niille on asetettu vaatimuksia jotka sinä olet varsin mallikkaasti ohittanut. …Ja se seuraava vika koko importissa, joka on todistetusti väärin tehty, on nyt sitten se ettet suostu palauttamaan aluetta aikaisempaan tilaan vaan selittelet että korjailut tehdään sotkun päälle. Tuollaisen lähestymistavan ongelma käytännössä on se ettei kukaan ei pysty varmistaamaan oletko itseasiassa korjannut kaikkea vai puhutko pelkästään tai vähintäänkin se vaatii muilta valtavasti työtä/säätämistä tehdä varmistusta, eli importtaaja päättää että hänen sotkujensa seuraksena muille tulee valtavasti lisävaivaa. Sotku pois vaan kaikkineen ja seuraava yritys niin ettei sotkuja synny ensinkään niin ei tarvitse alkaa sotkun päälle rakentamaan (kunhan lisenssijutut toki on ensin kunnossa). …Ilmeisesti et itse halua myöntää että virhe(!) on myös se sotku itse jota ei ensinnäkään pitäis olla niin että joutuu “korjailemaan” “virheitä”?
–
i.
ps. Ethän ota ylläolevaa henkilökohtaisesti, kyse on lähinnä importista joka on väärin toteutettu, eikä siitä että kuka sen on toteuttanut (ja minä pidän itseasiassa varsin odotettavana että tämä ei ole / tule olemaan ainoa tälläinen tapaus mml:n aineistoon liittyen kuten jo aiemmin totesinkin).
Sinänsä hauska esimerkki kun mukaan otetaan se OSM:n hyödyntäjän jälkeinen kaveri? Taitaapi OSM vaatia edelleen nimeään esille? Minusta mml ja osm vaativat lähinnä yhtä vahvaa attribuutiota ja sehän ei sovi osmin päässä.
Älkääs nyt päättäkö spekulointeja muuttumaan todeksi (jutuissa) - niin kauan kuin kukaan OSMin päässä ei ole sanonut ettei sovi, niin ei väitetä ettei sovi, eikös?
Eikös joku commonmap tms. koittanut alkaa virittelemään, mutta ei ole siitä välttämättä tullut mitään. Siellä ajatus oli importata mahdollisimman paljon ja sallia myös tavaran siirtäminen ihan “luvallisestikin” commonmap → mml koska SA vaatimukset poistettiin.
Tuossa kyseisessä nopeusrajoitus esimerkissä toteutus olisi aika ratkaisevana miten sitä tulkittaisiin. Jos nuo ovat edelleen erillisiä (matkustetaan nopeusrajoitetulla waylla osmin aineistossa mml:n reitittävä kartalla taustana) niin se olisi minusta selkestä collective db eikä derivative db. Nopeudet huomioiva reititys taas “aukkokohtien” yli mml:n kautta olisi jo selvästi derivativea.
MML:n aineistoon liittyvä “spekulointini” perustuu siihen erääseen täälläkin jo esitettyyn lainaukseen jossa oli mm. tälläisiä mainintoja: “don’t rely” ja “written permission”. Minusta on pikemminkin “spekulointia” se että onnistuuko joku jo huijaamaan osmin päätä vaikka kaikki ei ole vielä ihan kunnossa
Siis tekivätkö jotain ihan Suomen mml-tavaralla, vai puhutko nyt periaatteen tasolla? Minäkin muistan nähneeni mainintoja jostain fork-hankkeista liittyen OSMin lisenssimuutokseen, mutta silloin kyllä näytti, että noille tuskin tulisi kriittistä massaa. Mutta alueellisestihan tuo kyllä saattaisi toimia jos on kattava paikallisen laitoksen aineisto joka on OSMin kanssa epäyhteensopiva.
Tuossa esimerkissä lähdin tuosta JRA:n kuvauksesta, että jollain shapefile/OSM-työkaluilla yhdistettäisiin määreitä OSMista ja MML:stä, sen perusteella kyseessä olisi teknisesti yhdistetty kanta, ei siis kaksi erillistä (collective db). Ainakin jos shapefilejä / .osmeja/.pbf:iä jaeltaisiin, niin silloinhan tuo olisi selvästi derivative database.
En ODbL:stä nyt oikein varmasti hahmottanut oliko niin, että Derivative Databasen kriteerinä oli julkisuus (minusta näytti siltä). Tämän perusteella sitten jos privaatisti luo yhdistetyn kannan JRA:n mainitsemilla työkaluilla ja tekee siitä Produced Workin niin se kai on luvallista vaikka lisenssi ei olisikaan yhteensopiva, jos oikein hahmotan.
No, oli siellä toisaalta sekin maininta, että jos asia ei ole selvä, niin sitten tarvitaan written permission.
Lukaisin vielä sen Memorandum of Understanding -keskustelun jossa joltakulta OSM-kontribuuttorilta tuli aika jyrkkää vastustusta (“This sets a dangerous precedent that I strongly oppose it”), ja tuli siitä mieleen, että MoU:lle esitetyt tavoitteet saattaisivat täyttyä vaikka tähän malliin
laaditaan OSM copyright -sivulle sopiva muotoilu joka näyttää siltä, että se täyttää sekä MML:n että OSMin periaatteet & vaatimukset
lähestytään jotakuta sopivan tasoisessa asemassa olevaa MML:n henkilöä sähköpostitse ehdotuksella, että ajattelimme, että OSMiin pistettäisiin MML-aineistoa ja että OSMin copyright -sivulle pistettäisiin tällainen teksti lisenssilinkkeineen (MML:n lisenssiin), voitteko katsoa että tämä on teidän mielestä OK ja tehdä tarvittavat korjaukset
jos saadaan MML:ltä kuittaus että homma OK muotoilu näyttää hyvältä, lähestytään OSM-väkeä, että meillä on MML:ltä OK tällaiselle muotoilulle, sopiiko että lisäisitte tämän lisenssisivulle, niin voisimme sitten edetään koordinoitujen tuontien kanssa
jos OSM:ilta kuittaus että OK niin homma selvä; jos OSM vaatii jotain perusteellisempaa kirjallista, sitten ehkä jonkinlainen MoU, keskustelussahan myös todettiin, että OSM-säätiö on noita valtiollisten virastojen kanssa tehnyt, eli mitenkään poissuljettuhan tuokaan ei nähdäkseni ollut.
OSM-yhteisö on taas kerran tuottoisimmillaan silloin, kun tulkitaan lisenssejä. Lisään jotain soppaan itsekin.
Jos pilkkuja viilataan, niin uuteen ODbL:ään siirtymisen jälkeen OSM-lisenssi on tuskin yhteensopiva itsensä kanssa. OSM-OdbL -tietoja ei voisi imuroida OSM:iin, koska ODbL vaatii attribuutiota ja OSM:n käyttäjien lisäehdot vaativat niistä luopumista eikä OSM ainakaan takaa lähdeviitteiden säilymistä.
Johdettujen tietokantojen ja tuotettujen tuotteiden erottelu voi johtaa porsaanreikien hakemiseen. Esimerkkii:
Navigointiohjelman myyjällä on OSM-aineistot ladattavissa yhtenä Spatialite-tietokantana ja ei-vapaat aineistot toisena. Ohjelmiston ostajaa neuvotaan ajamaan skripti, joka suorittaa ei-vapaassa tietokannassa SQL-komennon “ATTACH DATABASE osm.sqlite AS OSM” ja sen jälkeen sekä ei-vapaan tietokannan että OSM-tietokannan taulut ovat navigointiohjelman käytettävissä ihan kuin ne olisivat yhtä ja samaa tietokantaa. Lopputulos on johdettu tietokanta viimeistään siinä vaiheessa, kun ajetaan toinen SQL-skripti joka yhdistelee kohteita ja tietoja OSM:in taulujen ja ei-vapaiden taulujen välillä. Silkkaa ODbL:ää siis, mutta ei-vapaan tietokannan käyttösopimus kieltää luovuttamisen kolmannelle osapuolelle (sitä paitsi se on kryptattu ja miinoitettu salaisilla tunnistetiedoilla ja vaikka mitä), ja ODbL taas laukeaa vasta kun:
a. Any Derivative Database that You Publicly Use must be only under the terms of:
Tekniikan puolesta tässä ei ole paljonkaan spekulointia, minulla alkaa olla karkea Quantum GIS -yhteensopiva malli koossa, tosin se ei tule käyttämään “attach database” -menetelmää vaan ihan erillisiä tietokantoja. Nekin voi yhdistää QGis:ssä sellaisella tavalla, jonka on OSM-listoilla katsottu muodostavan johdetun tietokannan, koska OSM-aineiston ja toisen aineiston kohteiden renderöinti ei tapahdu toisistaan riippumatta.
Taas on käyty hyvää keskustelua importin viemiseksi eteenpäin. Täällä saadun ja varsinkin yksityisviesteinä saadun tulenkatkuisen palautteen perusteella testituontini on koettanut teknisten asioiden lisäksi myös vallitsevaa asenneilmapiiriä MML.n aineiston tuontiin ylipäätänsä. En poista tuomaani aineistoa vielä, koska se on mm. HACY:n luettelemista kohdista keskeneräinen. Yritän korjata virheet ja samalla ottaa ylös kohtia, joita importtauksessa tulee huomioida vastaisuudessa(integrointi olemassaolevaan dataan on yksi suurimmista huomioista ja tulee varmasti olemaan yksi eniten aikaa vievistä työvaiheista tulevaisuudessa kun oikeaa importtia ryhdytään tekemään). Alueen palautus täysin entiselleen onnistuu tämän jälkeen vanhasta planet.osm tiedostosta mikäli näin halutaan.
Mitä enemmän noita kävin läpi niin sen jyrkemmin tuli mieleen, että vastaavissa importeissa ei kannata koskea pitkällä kepilläkään highway=* tageilla varustettuun kohteisiin ollenkaan. Ne on oletusarvoisesti parhaiten oikein openSTREETmap nimisessä kikkareessa. Jos jotain haluaa syöttää, niin keskittyy asioihin, mitä on hankala gps trace:sta saada oikein. Tai sitten keskittyy highway-tageihin kokonaan blankolla alueella. Tai täsmäkohteisiin, ei massaan.
Nyt en kyllä ymmärtänyt tuosta kahden kannan tapauksesta, että missä oli porsaanreikä - eikös kahdesta eri kannasta kartan piirtäminen ja kahden eri kannan toimittaminen ole ihan tarkoituksella sallittua toimintaa (collective databases), vaikka toisella kannalla olisikin rajattu lisenssi. Pointsi siinä, että jos OSM-kantaa parantaa, parannuksia ei saa jemmata vain omaan käyttöön, vaan parannukset pitää olla jaettavissa, mutta jos piirtelee riippumatonta dataa eri kannasta niin sitä eri kantaa saa sitten jaella myös samassa paketissa kuin OSM-kantaa. Ja ei kai tuossa ole tarpeen erikseen edellyttää käyttäjän manuaalisia toimia kantaan kytkeytymiseksi, vaan kaiketi tuossa samassa paketissa toimitetulle sovellukselle on ihan OK avata molemmat kannat.
Juu, elikkä toteutus taitaa lopulta olla sitä “korjaan niiltä kohdin mistä joku mainitsee” tasoa? Tämä on hirveän väärin! Minusta sinulla on vakavasti otettava ongelma toisen työn kunnioittamisen suhteen (et toki ole ainoa, monet importteihin hurahtaneet taitavat olla vähän sinnepäin kallellaan).
Tuo “asenneilmapiirikin” on ollut alusta asti täysin selvillä, ei sitä ole mitään tarvinnut koettaa. Jo alusta asti, mm. meetissä joka pidettiin ja muutenkin on ollut täysin selvää ettei olemassaolevan datan tuhoaminen, peruskartta import ja päälle korjailu (jos jaksetaan/viitsitään) ole oikea toimintatapa! Vai oletko eri mieltä? Jos olet niin mistä olet niin päätellyt? Miksi edelleenkin tuntuu että koitat ajaa kyseisen toimintatavan toimintamallia väkisin läpi vaikka ilmiselvää on ettei “yhteisö” ole lainkaan kanssasi samaa mieltä? Luulen että importti oli vaan helpointa toteuttaa noin “yksinkertaisella tavalla” joten valitsit sen että “sait jotain aikaan”. Minusta pelkkää vahinkoa, jonka hyötyjä on lähes mahdotonta rehellisesti sanottuna nähdä, kuten itsekin myönnät operaation haasteet liittyvät yhdistelyyn (ei siihen että osaa painaa deleteä ja uploadia). Kyllä jokainen sen tietää että kaiken olemassaolevan poistaminen on triviaalisti automatisoitava operaatio ja siihen importtaaminen helpohko homma, mutta koko toimitukset hyöty oikean importin suunnitteluun on IMHO täysin kuvitteellinen, ja tässä sillä kuvitteellisella hyödyllä nyt vaan koitetaan tuo operaatio “oikeuttaa”.
…Tai onko joku muu kenties sitä mieltä että pitäisi aloittaa “puhtaalta” peruskarttapyödältä? …nyt olisi aika kertoa mielipiteestään.
Onko noiden reverttien tekeminen sinulle niin ylivoimaisen hankalaa? Vaikeaa uskoa jos kerran importitkin olet saanut kasaa.
Entäs jonkun sillä välin keräämä maxspee, sillä ei liene väliä koska sinä et välitä? Sen voikin poistaa koska rapatessa roiskuu? Erittäin huolestuttavaa ja mietin jo varsin vakavissani esim. blockkien pyytämistä ettei vahinko entisestään suurene.
–
i.
Edit: huomasin vielä törkeämmän väitteen alueen palautusstrategiasta joka jäi ekalla lukemisella huomaamatta
No. postituslistalla on ollut lisenssejä tulkitsemassa äänekkäitä fundalisteja, joiden mielestä yhdistetty tietokanta ei ole enää “collective”, jos eri elementtejä käytetään yhdessä esimerkiksi niin, että ne vaikuttavat kadunnimien sijoitteluun karttaa piirrettäessä. Tai että png-kuva on ilman muuta tietokanta.
Mikäpäs siinä, jos tosiaan aloittaisi puhtaalta pöydältä peruskarttaan tai siis maastotietokantaan pohjautuvan karttapalvelun, minusta se olisi han hyvä tapa testailla MML-aineiston päälle rakentamista.
Tosin tällöin sitten pitäisi olla se puhdas pöytä. Yleensä ei pidetä ihmisten välisiin hyviin tapoihin kuuluvana, että puhdas pöytä saadaan käyttöön menemällä naapuriin ja viskomalla pöydällä oleva sisältö ikkunasta ulos. Tässä mielessä minusta aiempi luonnehdinta “uskalias” oli aika osuva :-), tosin tietysti muitakin sanoja voi jollekulle tulla mieleen.
Toisin sanoen edelleen olen sillä kannalla, että alkutilanteeseen palaaminen on paikallaan.
Kohta 2 voi olla hieman työläs, mutta ainakin lisäämiesi kohteiden poistamisen pitäisi olla helppoa id-numeroiden perusteella JOSMilla. Kerran kartoittelin pyöräily-GPS-jälkeä enkä huomannut, kun vahingossa painoin B:tä JOSMissa (kohdista pisteet tasavälein viivalle). Siinä meni yksi tie suoraksi ja monta polkua siksakiksi. Onnistuin palauttamaan solmut entiselleen hakemalla API-URLien avulla vanhan version tiestä, muokkaamalla *.osm-tiedostoa ja lähettämällä sen JOSMilla. Hieman sain tehdä käsityötä, sillä joku oli jo joitain pisteitä siirrellyt lähemmäksi oikeaa kohtaa, vaikka tie ehti olla rikki vain yhden tai kaksi vuorokautta.
Samaten kohta 4 saattaa olla hankala, jos OSM muuttuu paljon kohtien 3 ja 4 välillä. Mutta joka tapauksessa tuontia ja käsin tehtäviä korjauksia on hyvä harjoitella ja kokemukset sekä parhaat käytännöt raportoida wikiin.
Kokeiluja varten olisi ehkä järkevää perustaa puolijulkinen varjo-OSM tai vaikka useampia. Riippunee käyttötarkoituksesta, miten raskasta rautaa se vaatii. Jos ei tarvitse tiiliä vaan riittää tehdä vektorikarttoja vaikka OsmAndiin tai Garminille, ei tarvittane kuin vajaa gigatavu tallennustilaa. Nykyään finland.osm.pbf vie reilut sata megatavua.
En nyt oikein tavoita ajattelua, jonka mukaan PNG-kuva täyttäisi tuon esitetyn tietokantakriteerin. Onko ideana se, kuvaa voi systemaattisesti ja metodologisesti tarkastella esim. kuvankäsittelyn keinoin (tai vaikka neurologisin käsittelyprosessein optisilla esiprosessoinnilla ja sitä seuraavalla hermoverkkopohjaisella tietojenkäsittelyllä), ja lausua, että tuossa PNG:ssä näkyy kolme rakennusta ja kaksi tietä. Ja tämä tekisi kuvasta tietokannan, koska ihminen voi siinä nähdä rakennuksia ja teitä, tai kuvantunnistusohjelma voi tulkita kuvaa? Mutta oli miten oli, en myöskään hahmota, miksi olisi ongelma, jos PNG katsottaisiin tietokannaksi. Tai siis, joissakin harvoissa tapauksissa ongelmaa voisi varmaankin tulla.
En myöskään näe mitään ongelmaa ODbL:n suhteen siinä, että esim. navigaattorissa ruudulle karttaa piirrettäessä annettaisiin toisen, yhteensopimattomalla lisensillä lisensoidun tietokannan sisällön vaikuttaa siihen, miten OSM-tietokannan sisältö ruudulle piirretään, kun käytetään kahta erillistä tietokantaa. No, sitten jos navigaattorin kuvaa näytetään esim. TV-lähetyksessä lukuisille katsojille, tuon tiukan PNG-tulkinnan mukaan kai sitten navigaattorin kuvan näyttäminen saattaisi olla “tietokannan” jakamista. Varsin kaukaa haettua mielestäni kyllä.
Kokonaan toinen juttu on sitten se, jos toinen (OSM-lisenssin kanssa yhteensopimaton) tietokanta esiprosessoidaan OSM-aineistoa hyödyntäen ennen jakelua, silloinhan siitä hyvinkin saattaa tulla derivative database jolloin jakelu ei ole sallittua.
Rehellisesti sanottuna juurikin tuo kyseinen lainaus osoitti lähinnä vain sitä että kyseinen kirjoittaja ei tiennyt mistä puhui. On niitä esim. UK:ssakin viritetty erillismainintoja “avoimen datan” saamiseksi osmiin kun lisenssi ei ole ollut yhteensopiva, joten koko väite dangerous precedent:stä oli ihan tuulesta temmattu. Muutenkin koko legal keskustelu oli varsin hyödytön (lähinnä kait periaatteesta vastustajat äänessä), mutta se johtui ehkä osin siitä että siitä puuttui kokonaan linkki siihen varsinaiseen mml:n lisenssiin niin ei ne sitä kukaan tietty kaiva esiin. Hyödyllisin juttu oli juurikin sen UK(?) kaverin selitys mitä ne oli tehnyt, mutta valitettavast pääosin privana posikille joten me ei sitä edes olla nähty.
Musta niitä on jo lähestytty, se on niille suullisesti ok. Mutta ilmeisesti tuosta ei posikilla sitten ole mitään mailia tms. yksinkertaista kirjallista? Toki jos ne osmin päässä vastoin faq:ta suullisiin toisenkäden vakuutteluihin tyytyvät niin silloinhan asia olisi musta melko selvä pelkällä maininnan lisäyksellä.
