Keskustelu: Projektit: Software Development Template

Hei,

Olen itse tehnyt tällaisen projektin (Wiki-sivun osoite alla):

http://confluence.i4ware.fi/display/IOS/Software Development Template

Eli PHP- ja MySQL-pohjainen "sovelluskehtiysalusta", joka siis on mm. Liferayn kilpailija.

Käytetyt Frameworkit:
Zend Framework, Zion Framework, Ext JS, jQuery, TCPDF, PHPExcel, PHPWord ja PHPPowerPoint

Zion Frameworkillä olen tehnyt oikeustasot MVC:hen eli Model View Controlliin niin että MySQL-tietokannassa voidaan määritellä jokaiselle käyttäjärymälle eri oikeudet mitä käyttäjäryhmä näkee. Esim. voi piiloittaa jokin käyttöliittymäalueen näkymästä ryhmältä X ja että se näkyy vain ryhmälle Y. Samoin Zend Framework -funkotioita luokkien sisällä voidaan estää tai sallia käynnistymästä serveripuolella.

Wiki-sivun ositteesta löyttyy tämän projektin asennukseen tarvittava zip-paketti ja SQL-tiedosto tietokannan asennukseen.

Frameworkkien dokumentoinit taas lyötyy netistä julkisesti Googlettamalla.

Eli Red Hat, Inc. ja Canonical Ltd on tämän tiimoita hyväksynyt minun yrityksen i4ware Softwaren, Ubuntu Software Partner - ja Red Hat Technology Partner -ohjelmiin.

Eli tämä on GNU GPL, v. 3 -lisensoitu Open Source -tuote, jolla voi tehdä asiakkalle räätälöityjä projekteja kuten ERP, CRM, jne.

Ansaitalogiikka on siis tehdä projekteja asiakkaille tuntilaskutuksella.

Kaikki voi ladata tuotteen ja tehdä sillä asiakasprojekteja jos kiinnostaa.

Jos kiinnostaa päästä mukaan projektiin niin tässä alustavat ohjeet:
http://confluence.i4ware.fi/display/IOS/Partner Program

Haluaisitko kertoa mikä projekti wiki-sivun osoitteesta löytyy, mitä sillä tehdään?

Tuntuu, että olet jättänyt tärkeimmän asian viestistä kertomatta, mutta painotat siinä kaikkea muuta, mikä varmaankaan ei ole projektille tärkeää tietoa.

Lebe80 kirjoitti:

Haluaisitko kertoa mikä projekti wiki-sivun osoitteesta löytyy, mitä sillä tehdään?

Tuntuu, että olet jättänyt tärkeimmän asian viestistä kertomatta, mutta painotat siinä kaikkea muuta, mikä varmaankaan ei ole projektille tärkeää tietoa.

Ok. Korjaan ensimmästä postausta ASAP.

Ubuntu Software Partner -ohjelmaa ei enää ole joten siihen liittyvä sopimus on vanhentunut. Eli i4ware Software ei enää ole Canonical Ltd:n -partneri.

Tähän projektiin liittyvää tärkeää tietoa:
https://www.sencha.com/legal/GPL/
Yllä olevan linkin takana on linkki FAQ-sivuille GNU GPL, v. 3 -lisenssin tiimoilta.

Ja tämä kannattaa lukea myös: https://www.synopsys.com/blogs/software-security/saas-companies-open-source-risk/

PS: Selitä asiakkaalle jolle teet tällä tuotteella projektin, että tuote pitää jakaa julkisesti internetissä asennusohjeineen. Ettei asia tule yllätyksenä sille jälkeen päin, joka voi olla huono juttu. Älä siis vain laita sille pelkästään linkkiä GPL-lisenssiin.

Jos tekemänsä webbisoftan hostaa itse, niin sen lähdekoodia ei tarvitse julkaista backendin osalta.

The Alchemist kirjoitti:

Jos tekemänsä webbisoftan hostaa itse, niin sen lähdekoodia ei tarvitse julkaista backendin osalta.

Hyvä tietää.

Mutta entäs kun Model View Controllin ACL on tietokannassa määriteltävänä käyttäjäryhmäkohtaisesti frontendille, joka on tehty siis Ext JS 3.4.0:lla? Ja tämä sisältää myös koodin mahdollisesti JavaScriptin laittamista backend-koodeihin jotka ovat js pääteellä (muutettu kuitenkin php-koodiksi mutta frontendillä näkyvät js-koodina vaikka itse koodiin voi syöttää PHP:ta) mutta eivät näy kennellekkään ilman kirjautumista ja haluttua käyttäjäryhmää? Tai voi näkyä ilman kirjaantumista jos ne pakottaa ACL:llä eli Zion Frameworkillä julkisesti esillä oleviksi koodeiksi.

Ohjelmointikielellä ei ole mitään väliä.

Tarkoittaako tämä, että koko tehtyä ohjelmistoa ei tarvii jakaa väkisin netissä ladattavassa muodossa?

Mun mielestä erikoista että julkaiset softaa lisenssillä X etkä edes tiedä mitä ko. lisenssi sallii ja mitä ei salli.

Pääpiirteissään GPL-lisenssi vaatii, että kaikille sellaisille joille toimitetaan ohjelman binääri, täytyy toimittaa myös lähdekoodi, josta ko. binäärin voi kääntää.

Jos ohjelmaa käytetään tarjoamaan palavelua netissä, niin silloinhan yleensä ohjelman binääriä ei toimiteta käyttäjille ja näin ollen myöskään lähdekoodia ei tarvitse jakaa. Koska ainakin osa vapaan lähdekoodin puolestapuhujista on pitänyt tätä "porsaanreikänä", on luotu myös Affero GPL eli AGPL, joka vaatii lähdekoodin tarjoamista myös palvelun käyttäjille.

Erilaisia avoimen lähdekoodin lisenssejä löytyy toki muitakin kuin GPL ja AGPL.

Grez kirjoitti:

(25.11.2019 10:44:24): Mun mielestä erikoista että julkaiset softaa...

Ext JS:n valmistaja on mulle väittänyt, että minun täytyy jakaa tekemäni ohjelmistot julkisesti netissä.

Ext JS:n lisenssi oli alunperin LGPL tai maksa tuotteesta ja mainitsin silloiselle Ext JS LLC:lle asiasta, että lisenssi tuolla tavalla sallii sekä suljetunlähdekoodin että open source -tuotteiden tekemistä mm. Atlassian -tuotteeisiin kun taas GPL tai maksa tuotteesta sallii vain suljetunlähdekoodin tuotteiden tekemistä nähin eikä Open Source -tuotteiden. Tämän takia jos olin ees ainoa joka tästä Ext JS LLC:lle mainitsi sai ks. firman vaihtamaan lisensointia ja siitä tuli sitten hirveä sota internetissä. Varsinkin siitä, etteivät tajua omaa lisensointiaan ollekaan, jne. Niillä on nyt FLOSS-selvitys asiasta ja joutuivat maksammaan kuulema lakimiehille, etteivät ole heidän toidistamana rikkoneet mitään lakia.

Tällaisia kirjoituksia on netissä Ext JS:stä kasapäin: https://www.cnet.com/news/extjs-when-open-source-is-not-open-at-all/

No voihan siitä tietty saada jotain lohdutusta, että muutkaan ei ymmärrä käyttämiään lisenssejä.

Kuitenkin kertomasi seikka että ExtJS pääsi maksamaa lakimiehille ja vaihtamaan lisensointimallia kertoo minun mielestä lähinnä siitä että olisi järkevää ymmärtää käyttämänsä lisenssin sisältö eikä siitä että olisi ihan OK käyttää lisenssiä ymmärtämättä sitä.

walkout_ kirjoitti:

Ext JS:n lisenssi oli alunperin LGPL tai maksa tuotteesta ja mainitsin silloiselle Ext JS LLC:lle asiasta, että lisenssi tuolla tavalla sallii sekä suljetunlähdekoodin että open source -tuotteiden tekemistä mm. Atlassian -tuotteeisiin kun taas GPL tai maksa tuotteesta sallii vain suljetunlähdekoodin tuotteiden tekemistä nähin eikä Open Source -tuotteiden.

Tästä selityksestä ei kyllä ymmärrä yhtään mitään. Koodin copyrightien omistaja on sitä paitsi täysin vapaa valitsemaan lisenssissä aivan omilla ehdoillaan. Sekin on täysin sallittua, että sanoo käyttävänsä muunneltua GPL:ää, eli että lisenssi on pääosin GPL mutta sisältää joitakin muutoksia yksityiskohtiin. Ainoa lakitekninen ongelma voi muodostua siitä, että jossain asiayhteydessä on kuitenkin puhuttu ns. aidosta GPL-lisenssistä ilman mainintaa siitä, että kyse onkin GPL:ään pohjautuvasta eri lisenssistä.

Mutta ei tällöinkään automaattisesti rikota jotain lakia vaan jonkun GPL:ää puolustavan tahon pitäisi haastaa Ext JS:n tekijät oikeuteen, missä sitten olisi kyse yksityisestä riita-asiasta, jossa punnitaan, että onko jonkun oikeuksia rikottu.

Toinen hypoteettinen mahdollisuus on GPL-lisenssin tekstiin kohdistuvien tekijänoikeuksien loukkaaminen, mutta on vaikea kuvitella, että siitä saisi kallista riitaa aikaiseksi, sillä kyse on vain yhden tekstiosion poistamisesta.

The Alchemist kirjoitti:

(26.11.2019 03:27:48): ”– –” Tästä selityksestä ei kyllä ymmärrä yhtään...

Kukaan ei haastanut Ext JS LLC:tä oikeuteen vaan lisenssin muutos vain aiheutti Ext JS -yhteisössä vihaa. Eli yhteisö oli vihainen lisenssimuutoksesta vuonna 2008 ja sadoittain oli blogikirjoituksia ja kirjoituksia eri foorumeilla joissa Ext JS LLC:tä syytettiin vaikka mistä. Tuo lakimiehille maksaminen oli vain jonkin yhteisön jäsenenen väitös ja mitään todisteita ei ole pitääkö väitös paikkaansa.

Ja miksi ehdotin Ext JS LLC:lle lisenssin muutosta. No siksi, että olin ostanut heidän lisenssin ja halusin tehdä Atlassian -tuotteisiin plugineita ja estää sen, että joku voi tehdä ilmaisen Open Source -version joka syyö minulta taas rahaa kun on ilmainen kilpailija markkinoilla.

Eihän tuo noiden lisenssimuutos edes estä sitä että joku voisi tehdä ilmaisen open source version. Muutos LGPL:stä GPL:nhän lähinnä vaikuttaa siihen, ettei välttämättä pysty tekemään closed source versiota. Ja toki joku muukin voisi ostaa ExtJS lisenssin ja tehdä closed source kilpailijan.

Grez kirjoitti:

(26.11.2019 12:46:18): Eihän tuo noiden lisens­si­muutos edes estä...

Atalssianin tuotteet ovat suljettun lähdekoodin tuotteita johin voi tehdä plugineita ja mulla on ollut sellainen käsitys, että niihin saa tehdä plugineita vain lisenseillä BSD, MIT ja Apache Software License. Ainakin nuo ovat valmistajan suosituksia ja yhteisö ei varmaan tykkää GPL-lisenssitä koska siitä ei voi kopsta koodia maksuliseen pluginiin mm. Jiraan. Ja oli miten oli kukas nykyään enää haluaa tehdä ilmaisia plugineita Atlassian Marketplaceen? Ehkä ne jotka sen varjolla haluavat ja saavat Atlassian tuotteet ilmaiseksi vaikka ne maksaakin $10 / vuosi pikku yritykselle jolla on max 10 työn tekijää joten ei kovin suuri riski alkaa tehdä maksullisia tuotteita ks. sovelluskauppaan sillä riskillä että niitä ei sitten osta kukaan tai ostataan liian vähän.

Jos softa on julkaistu GPL:n alla, niin siihen saa tehdä plugareita vain GPL-lisenssillä; ei BSD-lisenssillä, ei Apache-lisenssillä eikä millään muullakaan. Sitten taas jos ostaa sen maksullisen version softasta, niin ei kuulosta todennäköiseltä, että myyjä pakottaisi julkaisemaan rahalla maksetut plugarit avoimena lähdekoodina.

Kyllä tässä ainoa ongelma on nyt sinun käsityksesi lisensoinnista ja siihen liittyvistä lakipykälistä.

The Alchemist kirjoitti:

(30.11.2019 13:32:25): Jos softa on julkaistu GPL:n alla, niin siihen...

Mulla on lisensit Ext JS:n kunoossa joten saan tehdä Cloused Source softia sillä.

Ymmärrät vähän väärin. Mun softat Atlassian tuottesiin ei ole koskaan julkaistu GPL-lisenssillä.

Ja miksi tämän topikin softakehitysalusta on julkaistu GPL-lisensillä on syy siihen se että on kopasattu GPL-lisensoitu iFrame-plugin Ext JS:n ja se oli dual-lisenstoiu myös ja mulla ei ollut rahaa ostaa sen lisenssiä silloin kun myyjä oli vielä olemassa.,

The Alchemist kirjoitti:

Jos softa on julkaistu GPL:n alla, niin siihen saa tehdä plugareita vain GPL-lisenssillä; ei BSD-lisenssillä, ei Apache-lisenssillä eikä millään muullakaan. Sitten taas jos ostaa sen maksullisen version softasta, niin ei kuulosta todennäköiseltä, että myyjä pakottaisi julkaisemaan rahalla maksetut plugarit avoimena lähdekoodina.

En kyllä näe mitä merkitystä varsinaisen softan lisenssimallilla on erillisiin plugareihin. Jos plugari itsessään on erikseen jaettava paketti (esimerkiksi dynaamisen linkityksen kautta toimiva itsenäinen kokonaisuus), ei sillä ole mitään tekemistä alkuperäisen softan lisenssimallin kanssa. Lisenssi koskee luonnollisesti vain sitä kokonaisuutta johon se on luotu. Mikään ei estä tekemästä vaikka MIT pohjaisia plugareita GPL:n alla julkaistuun kokonaisuuteen jos plugari on erillinen kokonaisuus. Jos taas plugarilla tarkoittaa sitä, että muokataan myös alkuperäistä kokonaisuutta (eli modataan sitä alkuperäistä kikkaretta joka GPL:n alla on tehty), pitää lisäystenkin olla GPL:llä lisenssoitu.

Pidetään nyt kuitenkin mielessä se, että lähtökohtaisesti kaikki GPL:n soveltamista koskevat tulkinnat ovat käsien heiluttelua, sillä konkreettisia ennakkotapauksia ei ole, koska asioita ei ole viety oikeuteen asti. Ja vaikka jossain maassa käytäisiinkin oikeutta, niin se ei ole suoraan sovellettavissa kyseisen valtion rajojen ulkopuolella.

Dynaamisen linkityksen periaate nojaa johonkin oikeustapaukseen vuodelta 1990, joka lähestulkoon edeltää koko GPL-lisenssin olemassaolon eikä sillä ole suoraa asiayhteyttä GPL-lisenssiin.

Esimerkiksi Wordpress- ja Drupal-yhteisöjen tulkinta on se, että Wordpressiin ja Drupaliin tehdyt moduulit on myös julkaistava GPL-lisenssillä. Jostain dynaamisesta linkityksestä horiseminen on vähän kontekstin ulkopuolella nyt.

Dynaamisella linkityksellä viittaan irrallisiin kokonaisuuksiin, jonka voi asentaa esimerkiksi paketinhallinnan kautta. Kokonaisuus joka ei muuta mitään alkuperäistä, vain laajentaa. Kun alkuperäiseen koodiin ei kosketa eikä mitään muuteta, plugarin saa lisenssoida miten tykkää. Esimerkiksi olemassaolevien, avoimien rajapintojen käyttäminen softasta ei pakota plugarin lisenssimallia softan lisenssiin vaikka olisikin gpl.

groovyb: GPL:n tulkinta on kyllä päinvastainen. Jos kirjasto A on jaettu GPL-lisenssillä ja ohjelma B käyttää sitä, myös B täytyy jakaa yhteensopivalla lisenssillä. Juuri tämän takia on erikseen LGPL, jossa on sallittu dynaaminen linkitys muillekin. Koodin kannalta plugin suhtautuu frameworkiin melkein kuin ohjelma kirjastoon, joten itse tulkitsisin lisenssiä tässä samalla logiikalla.

Metabolix kirjoitti:

Koodin kannalta plugin suhtautuu frameworkiin melkein kuin ohjelma kirjastoon, joten itse tulkitsisin lisenssiä tässä samalla logiikalla.

Riippuu varmaan aika paljon pluginin tekotyylistä. Jos ajatellaan vaikka historiallista tilannetta jossa Netscapeen sai tehtyä plugineita (Nestcape Plugin API / NPAPI:lla), ja muutkin selaimet sitten tukivat tuota samaa rajapintaa.

Olisi aika kohtuutonta ajatella että jos joku tekisi NPAPI:a tukevan GPL-lisensoidun selaimen, niin GPL:n virusvaikutus koskisi sitten kaikkia NPAPIa käyttäviä plugineita.

Voisi ajatella, että jos haluaa tehdä closed source pluginin johonkin GPL-tuotteeseen, niin riittää että on olemassa (tai tekee itse) myös closed source-yhteensopivalla lisenssillä oleva pluginia käyttävän ohjelma. Ilman tätäkin GPL-virusvaikutus noin päin on mielestäni* melko kyseenalainen.

* siis mikä tuntuisi loogiselta. En ole lakimies ja lakimieskään ei tyypillisesti voi antaa 100% varmaa tietoa mahdollisen oikeudenkäynnin lopputuloksesta.

groovyb kirjoitti:

Dynaamisella linkityksellä viittaan irrallisiin kokonaisuuksiin, jonka voi asentaa esimerkiksi paketinhallinnan kautta. Kokonaisuus joka ei muuta mitään alkuperäistä, vain laajentaa. Kun alkuperäiseen koodiin ei kosketa eikä mitään muuteta, plugarin saa lisenssoida miten tykkää.

Tämä on ihan sinun omaa tulkintaasi vailla mitään lakiteknistä pohjaa. Tällaisia foorumivinkkejä ei voi ottaa vakavasti, jos on oikeasti huolissaan lisensointikysymyksistä.

Niin kuin sanoin aiemmin, niin myös yleinen oletus dynaamisen linkityksen sallimisesta nojaa liki 30 vuotta vanhaan oikeustapaukseen, missä ei edes käsitelty dynaamista linkitystä vaan oikeutta muokata alkuperäisen ohjelman toimintaa ajonaikaisesti ulkoista sovellusta käyttämällä. Eli kyse ei edes ollut lähdekoodin käytöstä tai laajennoksista vaan binäärimuotoisen sovelluksen manipuloinnista.

Oikea dynaaminen linkitys voi ollakin vahvalla pohjalla (L)GPL-ongelmassa, sillä silloin kirjasto ja sitä käyttävä sovellus ovat "selvästi" erillisiä kokonaisuuksia, koska ne ovat erillisissä tiedostoissaan eikä niiden välillä voi olla jaettua ohjelmakoodia muuten kuin otsikkotiedostojen osalta. (Jenkkilässä tosin edelleen kiistellään siitä, voiko rajapinnan patentoida; voi ehkä liittyä tähänkin asiaan.)

Tässä täytyy muistaa se, että staattisen linkityksen katsotaan kuitenkin loukkaavan GPL-lisenssiä vaikkei se käytännön tasolla muuta yhtään mitään, koska ohjelma toimii ihan samalla tavalla kumpaa tahansa linkitystapaa käyttäessä.

Siksipä sinun onkin aika kyseenalaista alkaa yleistää php-plugarin olevan sama asia kuin dynaamisesti linkitetty ohjelmakirjasto mutta täysin eri asia kuin staattisesti linkitetty ohjelmakirjasto, kun php:n kontekstissa kumpaakaan linkitystapaa ei edes ole olemassa.

Edit: Täsmennetään vielä, että tässä keskustelussa on oikeastaan mukana kaksi eri asiaa:

1) Dynaaminen linkitys GPL-lisenssin puitteissa.
2) Dynaaminen linkitys LGPL-lisenssin puitteissa.

Kohta 2) on itsestäänselvä ja rajoittuu vain todelliseen dynaamiseen linkitykseen, sillä LGPL:n ehdoissa mainitaan eksplisiittisesti "object code form" ja otsikkotiedostojen käyttö. Eli tätä ei missään nimessä voi yleistää koskemaan kieliä, joissa dynaamista linkitystä saati otsikkotiedostoja ei käytetä.

GPL-lisenssin kohdalla olettama dynaamisesta linkityksestä perustuu taas tuohon yllä perkaamaani tapaukseen ja sanalliseen pyörittelyyn siitä, mitä tarkoittaa erillinen ohjelmakokonaisuus.

(Teoriassa on tosin mahdollista, että tyypittämätön php-koodi pluginissa ei viittaa ollenkaan alkuperäiseen ohjelmaan, jolloin voitaisiin yrittää verrata sitä dynaamiseen linkitykseen.)

GNU'n omassa GPL FAQ:ssa sanotaan, että millainen tahansa linkittäminen pakottaa ohjelmakirjastoa käyttävän sovelluksen myös GPL-lisenssin alle, mutta tämäkin on toki vain yhden tahon oma tulkinta eikä sen oikeellisuutta ole punnittu oikeudessa.

Lisäys:

Grez kirjoitti:

Metabolix kirjoitti:

Koodin kannalta plugin suhtautuu frameworkiin melkein kuin ohjelma kirjastoon, joten itse tulkitsisin lisenssiä tässä samalla logiikalla.

Riippuu varmaan aika paljon pluginin tekotyylistä. Jos ajatellaan vaikka historiallista tilannetta jossa Netscapeen sai tehtyä plugineita (Nestcape Plugin API / NPAPI:lla), ja muutkin selaimet sitten tukivat tuota samaa rajapintaa.

Olisi aika kohtuutonta ajatella että jos joku tekisi NPAPI:a tukevan GPL-lisensoidun selaimen, niin GPL:n virusvaikutus koskisi sitten kaikkia NPAPIa käyttäviä plugineita.

NPAPI:n tapauksessa asia on yksikäsitteinen, sillä NPAPI-standardin otsikkotiedostot on julkaistu useilla eri lisensseillä ja rajapinnan toteuttava plugari voi siten helposti olla suljettua lähdekoodia. Sillä ei ole mitään väliä, millaisin ehdoin NPAPI-kutsuja hyödyntävät ohjelmat on lisensoitu.

Ja vastuuhan menisi niin päin, että jos NPAPI-plugari on julkaistu vain GPL-lisenssillä, niin siitä riippuvainen sovellus joutuisi myös noudattamaan GPL-lisenssiä. Yleisesti ottaen kuitenkin NPAPI-plugari ei ole mikään riippuvuus vaan laajentava toiminto ja vastuu sen asentamisesta on loppukäyttäjän vastuulla, joten NPAPI-kirjaston ja kirjastoa käyttävän sovelluksen välille ei muodostu minkäänlaista laillista sidettä.

Muunlaisten plugareiden kohdalla laillinen side (termi oma keksimä) voi muodostua silloin, kun itse rajapinta ei ole NPAPI:n tapaan erillinen kokonaisuus vaan osa itse ohjelmistoa ja lisensoitu samoin ehdoin kuin ohjelmistokin.

The Alchemist kirjoitti:

Ja vastuuhan menisi niin päin, että jos NPAPI-plugari on julkaistu vain GPL-lisenssillä, niin siitä riippuvainen sovellus joutuisi myös noudattamaan GPL-lisenssiä.

Niin no Metabolix (jolle kommentoin) näytti olevan päinvastaista mieltä, josta syystä otinkin esimerkin jossa hänen näkemyksensä ei ainakaan toteudu ja totesin että tilanne varmaan riippuu paljonkin siltä mitä "plugin" milloinkin tarkoittaa.

En toisaalta ihan ymmärrä mikä on "plugarista riippuvainen sovellus", kun plugareiden idea lähtökohtaisesti on, että sovellus toimii ilmankin niitä. Jos koodaisin vaikka Photoshop-plugarin ja lisensoisin sen GPL:nä, niin en oleta että Photoshop muuttuisi GPL alaiseksi.

Minä en ymmärrä, miksi sinä aina tunnut jankkaavan aiheen vierestä. Loppukäyttäjän itse asentama Photoshop-plugari ei tietenkään pakota itse Photoshopin lisenssiä, sillä Adobe ei levitä Photoshopia paketoituna kyseisen plugarin kanssa. Sen sijaan Adobe omistaa sen rajapinnan, jonka kyseinen plugari pakostikin toteuttaa, eli plugarin tekijän tässä pitää noudattaa Adoben asettamia lisenssiehtoja.

Eiköhän näitä asioita jouduta aina arvioimaan case by case. Kysehän on siitä, käyttääkö kolmannen osapuolen tekemä ohjelmakoodi alkuperäisen ohjelman osia jollain tapaa. Tässä ei ole mitään muna vai kana -ongelmaa eli että pitääkö kirjasto lisensoida emo-ohjelman mukaan vai emo-ohjelma kirjaston mukaan, koska "derivatiivinen työ" määritetään sillä perusteella, kumpi oli ensin olemassa ja kumpi on aiemmin tehtyä koodia hyödyntävä osapuoli.

Wordpress- ja Drupal-plugareiden katsotaan olevan GPL:n alaista koodia, sillä laajennosta on mahdotonta toteuttaa kutsumatta funktioita, jotka on toteutettu Wordpressin/Drupalin ns. coressa. Ne eivät siis ole millään muotoa itsenäisiä komponentteja vaan niillä on suora riippuvuus plugaria käyttävään alustaan.

Tuostakin tulkinnasta voi varmasti olla eri mieltä jos ajatellaan, että plugari vain kutsuu jotain funktiota muttei sinällään ota kantaa siihen, missä tai miten kyseinen funktio on toteutettu, koska php:llä kirjoitettu laajennos ei erikseen lataile mitään tiedostoja (kuten c-kielinen ohjelma otsikkotiedostoja).

Eli jos minä toteutan "uuden Wordpressin", joka toteuttaa saman rajapinnan plugareille muttei käytä alkuperäisen Wordpressin koodia ollenkaan, niin silloin voidaan miettiä

1) onko minun sovellukseni jollain tapaa sidottu alkuperäisen Wordpressin lisenssiehtoihin tai "älylliseen omaisuuteen"?

2) kumoaako tämä sen tulkinnan, että php-plugarin lisensointi riippuu sille rajapinnan tarjoavan sovelluksen lisenssistä?

Näihin asioihin ei ole olemassa absoluuttista vastausta vaan ne pitäisi viedä oikeusistuimen käsiteltäväksi. Google vs. Oracle -tapaus javan rajapintoihin liittyen voi ensimmäistä kertaa tarjota konkreettisen esimerkin siitä, miten näitä asioita on tulkittava. Käsittely on edelleen kesken.

The Alchemist kirjoitti:

Minä en ymmärrä, miksi sinä aina tunnut jankkaavan aiheen vierestä.

Olisiko pata kattilaa soimaa efekti? Jos kerran olet samaa mieltä viestini kanssa, niin voit välttää helposti täältä päin tulevan jankkaamisen olemalla itse jankkaamatta siitä asiasta.

The Alchemist kirjoitti:

Eiköhän näitä asioita jouduta aina arvioimaan case by case.

Eli tämähän oli sen viestini pointti, johon lähdit jankkaamaan.

Grez kirjoitti:

The Alchemist kirjoitti:

Eiköhän näitä asioita jouduta aina arvioimaan case by case.

Eli tämähän oli sen viestini pointti, johon lähdit jankkaamaan.

Vitut minä mitään jankkasin vaan kirjoitin auki sinun vaillinaisen selityksesi.

edit: poistin loput, se on vain vanhan kierrätystä.

Grez kirjoitti:

Riippuu varmaan aika paljon pluginin tekotyylistä.

Totta, ajattelin tässä nyt vain sellaisia (CMS-)plugineja, joissa järjestelmä sisältää jonkin rajapinnan ja plugin käyttää sitä. Tietysti on paljon myös päinvastaisia tilanteita, kuten nyt tuo NPAPI.

Epitä tämä mitään, että tähän topikkiin on nyt tullut keskustelua.

Senchalta jo otettiin yhteyttä ja kaupattiin joko Hub-lisenssiä tai OEM-lisenssiä, jolloin minulla on lupa tehdä tällaisia juttuja Closed Source -lisenssillä sitten että voin antaa asiakkaille oikeuden tehdä lähdekoodilla mitä huvittaa ja julkaista se Closed Source -lisensillä siis tehdä lisenssimaksullisia softia joita asiakas saa itse muuttaa minun tekmällä softakehtiysalustalla/työkalulla.

Sencha, Inc. ei nyt uskonut projektiin koska pääsääntö on se, että minulla ei ole Ecosysteemiä tuotetekehityksessä ja eivät nyt myy mulle ainkaan vielä aiemmmin mainittua Hub-lisenssiä ja/tai OEM-lisenssiä.

Olen kuitenkin tehnyt jo rahaa tuottella melko paljonkin myyden tuotteella tehttäviä ohjelmistoprojekteja asiakkaille GNU GPL, v. 3 lisensssin ehdoin. Mutta tenkkapoo tuli siisnä, että Ext JS:n valmistaja Sencha, Inc. on väittänyt että minun pitää jaka kaikki tuotokseni ilmaiseksi netissä vaikka hostaisin kokonaan itse tuotteeni enkä olisi aiemmin jakanut lähdekoodia missään mutten kuin mikä on alkuperäinen ohjelmistokehitysalusta. Menin sanomaan asikkaille tästä Sencha, Inc:n väitöksestä jotain minkä takia kävi miten sitten kävi. Eli projektit keskeytettiin. Mutta voin taata että asiakkaat ovat senoneet etteivät syytä asiasta ketään ja vaadi mitään korvauksia yhtään keltään.

Lisenssiriidoissa voi ja saa olla mitä mieltä tahansa, koska lisenssiehtoja on harvoin puitu oikeudessa. Sinulla on yhtäläinen oikeus väittää olevasi eri mieltä. Senchan kaltaiset firmat ottavat aina, jopa tietäessään olevansa väärässä, sen kannan, että maksullinen lisenssi pitää hankkia elleivät mielivaltaiset kriteerit täyty.

Itsekin vetäydyin suosiolla eräästä projektimahdollisuudesta, koska open sourcena julkaiseminen ei ollut mahdollista ja kaupallinen lisenssi (valitsemiini työkaluihin) oli liian kallis yhtä ainoaa projektia varten. Valitettavasti joskus hinnoittelu on sellainen, että kulut kattaakseen pitäisi olla liukuhihnalta samoilla teknologioilla toteutettavia toimeksiantoja.

Ext JS:n lisensejä ei enää myydä pienempiä paketteja kuin 5 kehittäjän sellaisia joka toisi aikamoisen kuluerän ja sitä vuosimaksullista 1 kehittäjän lisenssiä ei minun kannata ostaa. Mutta olen saamassa ison perinnön isovanhemmilta, jotka kuoli joten minulla olisi kohta varaa tuohon 5 käehittäjän lisenssiin. Mutta jos ostan tuon 5 kehittäjän lisenssin niin se tulee ihan eri projektiin joka on aina ollut suljettu ohjelmisto, koska minulla on lisenssit Ext JS 2, 3, ja 4:seen. Tuote on Timesheet and Gantt Chart for Jira ja sillä nyt olen tehnyt 30000 USD rahaa, joten sijoiutukset eivät olle menneet vielä hukkaan vaikkakin tuon edellä mainitun rahan saantiin on mennyt nyt 8-vuotta aikaa ja se on pienempi kuin työttömyyskorvaus jos kerren näin monta vuotta on mennyt aikaa 30k USD saamiseen.

Projektilla on nyt julkinen Git:
https://github.com/i4ware-software/sdt