Firma X zaslala předžalobní výzvu vývojáři projektu Nitter (Wikipedia), open-source alternativního frontendu k sociální síti X (ex-Twitter), a provozovatelům instancí jako XCancel, které umožňovaly číst příspěvky bez přihlášení, reklam a javascriptu. Údajně se dopouštějí „sběru dat“. Zdrojový kód Nitteru vývojář archivoval. Vývoj již dříve přerušil v roce 2024 po tehdejším omezení API X. X je dceřiná společnost SpaceXAI Elona Muska, provozující mj. kontroverzního chatbota Grok.
Bylo vydáno Ubuntu 26.04.1 LTS, tj. první opravné vydání Ubuntu 26.04 LTS s kódovým názvem Resolute Raccoon. Přehled novinek a oprav na Discourse.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) vydal Zprávu o stavu kybernetické bezpečnosti ČR za rok 2025 (pdf). Incidentů ubylo, sofistikovanost útočníků roste.
Open source softwarový stack AMD ROCm (Wikipedie) pro vývoj AI a HPC na GPU od AMD byl vydán v nové major verzi 10.0. S ROCm.AI. Přehled novinek v aktualizované dokumentaci.
Finanční skupina Partners se stala minulou neděli obětí kybernetického útoku, při kterém se útočníci dostali k některým osobním údajům klientů. Společnost o tom informovala ve čtvrtek. Ujišťuje, že peníze klientů nejsou v ohrožení. „Kybernetický útok zasáhl část IT infrastruktury naší společnosti. Ihned po zjištění útoku jsme s pomocí externích bezpečnostních odborníků začali intenzivně pracovat na minimalizaci škod. Útočníci se
… více »Americká technologická společnost Meta Platforms se dohodla, že zaplatí až zhruba 18 miliard dolarů (asi 373 miliard Kč) za mimosoudní urovnání sporu o závislosti dětí na sociálních sítích a provede významné změny pro jejich používání mladistvými. Téměř tři desítky států USA firmu v roce 2023 obvinily z toho, že sítě Facebook a Instagram vědomě navrhla tak, aby u dětí vyvolávaly závislost, a zatajovala tyto dopady před veřejností. Firma se
… více »Byl publikován aktuální přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Blíží se vydání podporující čipy M3. Vývojáře lze podpořit na GitHub Sponsors a Open Collective.
Kancelářský balík LibreOffice byl vydán ve verzi 26.8. Mimo jiné vylepšuje typografii a kompatibilitu s formáty MS Office, více v poznámkách k vydání.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 26.8. Přehled novinek v poznámkách k vydání.
Byla vydána nová verze 23.1.0, tj. první stabilní verze z nové řady 23.1.x, překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, LLD, Extra Clang Tools, Libc++, Polly a Flang.
ak by si svoj projekt nevydal ako open source len ťažko môžeš začleňovať open source projekty iných do toho svôjho
Tohle záleží na spíše licenci.
ad 1) Jasně, může si to opravit pro sebe (jak psal Leoš), ale vývojář ten zaslaný patch stejně tak jako tak musí zkontrolovat.
Staci, aby se ten projekt prestal rozvijet a pokud v nem nevidis budoucnost, musis investovat do migrace na jiny projektV mnoha pripadech to neni problem - pokud je jasne dany smysl programu (ktery se v case moc nemeni), program je uz v dostatecne finalni fazi, tak program neni treba dal rozvijet a staci pouze upravovat nalezene bugy, coz zvladne kdekdo. Naopak, pokud program dobre splnuje me pozadavky, tak jsem vetsinou radsi, kdyz uz se moc nerozviji, nebot casto takyvy rozvoj me uz nic neprinasi (program splnuje dalsi a dalsi pozadavky, ktere ale ja nekladu) a prinasi komplikace (rust nabubrenosti, zmeny, mensi stabilita).
Pokud něco uvolním jako OpenSource, kdokoliv to může z principu věci okopírovat a vydávat za své dílo.Pozor, to teda ne. Korektní přiznání autorství je nutnost a ani nejliberálnější opensource licence z tohoto požadavku neslevují.
Mnohdy je rychlejší napsat požadovanou funkcionalitu sám, než se prodírat cizím patchem (který se obvykle nedrží nastolené štábní kultury)V takovym pripade bych bez kompromisu zavrel editor a poslal autorovi, at si to hezky opravi... Takze prodirani kodem bez pozadovane stabni kultury by se nekonalo
Ja jsem v podstate jeste zadny kod jako F/OSS neuvolnil, i kdyz se mam na disku nekolik nastroju, o kterych si uz dlouho rikam, ze tohle urcite jednou udelam jako F/OSS
Ono to zni jednoduse, ale nejaky cas to chce... projet veskere zdrojaky a ujistit se, ze kazda trida a metoda je dobre anglicky okomentovana, udelat web/wiki, naplnit daty, napsat tutorialy a v neposledni rade se taky trochu starat o vyvoj a byt aktivni na mailing listech/forech. Moc nerad bych delal F/OSS tak, ze to nekde hodim na net a posluzte si... rad bych kdyz uz, tak si za tim trochu stal. A na to nemam zatim cas
A duvody? Kdyz uvolnim framework ci nejaky nastroj, muzu na tom jen vydelat -- peer review, nejaky dobry kod, sance ziskat spolupracovniky se znalosti mych nastroju (coz se jinak dela dost tezko...), publicita (kvalitne rozjetej F/OSS projekt je lepsi reklama nez tisic kecu...)
Priklanim se k tomu, co napsal pan Kvasnicka a rekl bych, ze to co on vyzdvihuje jako (+) neni v 99 % pripadu vyvazeno tim, co ztracite. Tedy jestli minite open source ve smyslu gpl apod.Jde o to dobre vychytat tu hranici co otevrit a co ne, aby ta ztrata nebyla. Udelat kompletni vlajkovy produkt jako open source je pro freelancera bez firmy a sirsiho portfolia v zadech ekonomicky relativne beze smyslu. Ale udelat jako open source treba jen par nastroju a frameworku, tam bych nemluvil o "ztrate". Sice obsahuji nejake moje know how, ale ne takove, ktere by tvorilo efektivni konkurenceschopnost. Napr. tvurci frameworku Djano by vam taky nedali komplet zdrojaky svych zpravodajskych portalu, ale kdyz otevreli Django, jen jim to prospelo (IMHO).
Ja prodavam vlastni software vzdy se source ale zakaznik s tim muze neco delat jen tehdy, kdyz bych odmitl dalsi spolupraci. Pak smi muj cod vzit a delat s tim co chce. To hodnoti zakaznici jako pozitivni a protoze to je dnes bezne, ani to nemohu delat jinak.Ja nedavam zdrojak rovnou, ale do smlouvy klauzuli, ze predam zdrojak a vse potrebne, pokud nebudu schopen zajistit kontinuitu dila (min. v ramci sjednane sluzby). Ale i na zdrojacich rovnou k dilu bych byl ochoten se za urcitych podminek domluvit.
Zaslaný patch musí někdo zkontrolovat. Mnohdy je rychlejší napsat požadovanou funkcionalitu sám, než se prodírat cizím patchem (který se obvykle nedrží nastolené štábní kultury). Tohle považuji za největší nevýhodu tohoto stylu vývoje softu.E? Jednak muzu vesele ignorovat patche od jinych ve svem stromu, jednak je programatorskou zhuverilosti neprovadet code review pred zaclenenim patche do stromu, at je vyvoje open source nebo closed source (pokud se nejedna o one-man-show, samozrejme).
Proto je obvykle lepší, když uživatel zašle požadavek na funkci a vývojový tým, který zná kód daleko lépe, než kdokoliv cizí, ji na přání uživatele napíše. Tohle je v podstatě opak předchozího. Buď se zvýší režie na kontrolu patchů, nebo se zvýší režie na komunikaci mezi vývojáři a komunitou.Napise nebo nenapise. A kdyz nenapise, pozadavek konci ve stoupe.
Dále je to omezená kontrola nad produktem. Pokud něco uvolním jako OpenSource, kdokoliv to může z principu věci okopírovat a vydávat za své dílo. Proti čemuž se jen těžko bojuje.Autorsky zakon plati pro open i closed source. Nezavisle na tom, zda je kod uzavreny ci neni, privlastnit se da oboji, jen v tom druhem pripade je to trosku narocnejsi. A na otazku, co pro me znamena Open Source, je tato odpoved: a) moznost spoluprace s jinymi, nemam prece patent na rozum (nejlepsi prispevatele jsou "cistici" kodu, kteri vezmou stavajici prasacky napsany kod a vypuliruji ho) b) zdroj vzdelani (ano, za zivot jsem nastudoval funkcnost mnoha ruznych kodu a naucil se mnoha vecim z nich) c) zvyseni vazby s hlavnimi uzivateli (uz se mi nekolikrat stalo, ze pri problemu v Solarisu velky zakaznik poukazal na moznosti implementaci zmen v OpenSolarisu a obcas jsme se dopracovali vzajemnou komunikaci k zajimavym vysledkum)
No dobře, ale k tomu nepotřebuješ zdrojáky, stačí dobře dokumentované API těch sdílených knihoven.
popř. si ji můžu upravit podle svých potřeb.Hmm... Jasně, no. Assemblerem to půjde i u closed-source, ale to myslím není ono.
A vzhledem k tomu, že nepíšu (doufejme) jako prase, tak výše popisované problémy (opatřit komentáři v angličtině, upravit "ke zveřejnění" atd.) u mne odpadají a zveřejnění SW je otázkou pár minut, popř. hodin.Napsal jsem projet veskere zdrojaky a ujistit se, ze kazda trida a metoda je dobre anglicky okomentovana. To neznamena, ze jsem prase, ale ze proste chci mit jistotu. Komentuju veskere sve kody, kazdou metodu a tridu, ale kdyz dopredu neplanuju, ze to jednou bude jako open source, nejsem si pak zpetne 100% jisty -- coz je myslim pochopitelne. Takze to je otazkou hodin a brzdil bych s temi silnymi vyrazy
@param a podobne.... Takze tak
Takže neptej se "Co mi přinese, když program uvolním jako open source?", ale spíše "Co se stane, když nikdo nebude dělat open source." Jinak ti to samozřejmě nepřinese žádné výhody.I uvolneni programu jako open source muze neprimo vest k materialnim vyhodam a neni na tom vubec nic spatneho. Nekdy muze byt dusledkem otevreni kodu i vetsi materialni zisk, nez jaky by teoreticky byl, kdyby SW zustal uzavrent. IMHO je dost projektu, ktere kdyby autori neotevreli, tak zdechnou, protoze by nebyli schopni se dostat pres relativne vysoky vstupni prah na ten dany segment trhu. Kdyz SW ale otevreli, znacne ten prah snizili (samotny SW byl bezplatny, takze se o to lide vice zajimali) a casem kolem toho SW vybudovali support masinerii, ktera jim prinasi nemale penize...
Tiskni
Sdílej: