Anthropic bierze na cel klonowanie gier przez Claude, pozostawiając dozwolone tworzenie oryginalnych gier

Anthropic dodał instrukcje przeciwko klonowaniu gier przez Claude, jednocześnie wyraźnie pozostawiając oryginalne gry i projekty gatunkowe wśród zamierzonych zastosowań narzędzia. Zmiana dotyczy Claude Code działającego na Opus 5.5, zgodnie z wyjaśnieniami firmy. Wyznacza granicę między pomaganiem komuś w tworzeniu gry a pomaganiem mu w odtworzeniu konkretnego wydania stworzonego przez kogoś innego.

To rozróżnienie ma znaczenie, ponieważ deweloperzy mierzą się ze sprzecznymi presjami. Potrzebują publicznych prezentacji, by przyciągać graczy, lecz te prezentacje jednocześnie wystawiają ich pracę na potencjalnych naśladowców. ReVamp od Digital Sun ilustruje ten dylemat, a reakcja Valve pokazuje, że ograniczenia wewnątrz narzędzia AI rozwiązują tylko część problemu.

Kluczowe pytanie brzmi, czy Anthropic potrafi zniechęcać do kopiowania bez zakłócania legalnego tworzenia gier. Zadeklarowane ograniczenie określa stanowisko firmy. Nie oznacza jednak niezawodnego egzekwowania, trafnych ocen własności ani ochrony przed osobami korzystającymi z innych narzędzi.

Co Anthropic zmienił w kwestii klonowania gier przez Claude

Anthropic zmienił instrukcje Claude Code, lecz publicznie dostępne dowody nie potwierdzają, że odtwarzanie gier stało się technicznie niemożliwe.

Materiał Engadget opisuje ograniczenie odtwarzania gier i potwierdza, że oryginalne projekty nadal są dozwolone.

Bardziej szczegółowe wyjaśnienie pochodzi od Addy’ego Osmaniego, członka zespołu technicznego Anthropic. Według Game Developer Anthropic skierował redakcję do jego oświadczenia potwierdzającego dodanie dwóch zdań do promptów Claude Code na Opus 5.5. Prompt to instrukcja przekazywana modelowi, aby kierować jego odpowiedziami.

Według relacji nowe brzmienie zezwala na oryginalne gry, gry gatunkowe oraz projekty wykorzystujące projekty i zasoby użytkownika. Zakazuje odtwarzania konkretnej istniejącej gry, w tym wersji przedstawianych pod inną nazwą. Game Developer podał to potwierdzenie 30 października, po relacji użytkownika o zmianie około 27 października.

Te szczegóły znacząco zawężają tę historię. Potwierdzone działanie dotyczy instrukcji dla konkretnego środowiska programistycznego i modelu. Nie należy automatycznie traktować go jako twierdzenia o każdym produkcie Claude, każdym modelu ani każdym żądaniu dotyczącym istniejącego oprogramowania.

Postanowienie dotyczące zmiany nazwy ujawnia też zamierzony cel. Skopiowany projekt nie staje się oryginalny tylko dlatego, że zmienia się jego tytuł. Anthropic sygnalizuje, że liczy się żądany rezultat, a nie etykieta do niego dołączona.

Tworzy to praktyczne rozróżnienie między możliwościami a dozwoleniem. Model może zachować wiedzę przydatną w programowaniu gier, otrzymując jednocześnie instrukcje zabraniające wykorzystywania jej do określonych żądań. Zachowanie odmowne nie dowodzi zatem samo w sobie, że podstawowa zdolność programistyczna zniknęła.

Dostępne oświadczenie pozostawia też przestrzeń na korektę. Według relacji publikacji Osmani zaprosił deweloperów do zgłaszania odmów dotyczących ich własnej pracy, odnosząc się do ograniczenia Claude Code.

To zaproszenie jest istotne, ponieważ ograniczenie zawiera pozytywną obietnicę. Oryginalne tworzenie ma pozostać dostępne. Odmowa dotycząca autoryzowanego projektu zasługuje więc na analizę w świetle deklarowanego przez firmę zakresu.

Dla czytelników śledzących ograniczenia dotyczące gier w Claude, uzasadniony wniosek jest konkretny: Anthropic wprowadził granicę zachowania przeciwko odtwarzaniu określonych gier. To, czy granica ta działa konsekwentnie, pozostaje otwartym pytaniem produktowym.

To także inne twierdzenie niż stwierdzenie, że gry generowane przez AI są zakazane. Wyjaśnienie Anthropic zachowuje możliwość ich tworzenia, gdy projekt podąża w oryginalnym kierunku. Trudność zaczyna się tam, gdzie szerokie konwencje gatunkowe nakładają się na rozpoznawalne indywidualne projekty.

Publiczne dema stawiają niezależne studia w trudnej sytuacji

Natychmiastowa presja spada na deweloperów, którzy muszą pokazywać niedokończone gry, zanim będą mogli sprzedawać gotowe.

Digital Sun dostarcza konkretnego przykładu. 19 października Game Developer poinformował, że studio Moonlighter ograniczyło plany publicznych testów ReVamp. Studio wskazało obawy, że ktoś mógłby odtworzyć i opublikować konkurencyjną wersję przed jego własną premierą.

Alternatywą były bardziej ograniczone testy za pośrednictwem społeczności Discord, rozpoczynające się 29 października. Takie rozwiązanie zachowało dostęp do opinii, ograniczając jednocześnie skalę publicznej dystrybucji. Decyzja studia dotycząca testów ReVamp dokumentuje zmianę strategii wydawniczej, a nie jedynie hipotetyczny lęk.

To rozróżnienie jest ważne. Studio nie potrzebuje dowodu, że ktoś skopiował jego grę, aby niepewność wpłynęła na jego decyzje. Jeśli postrzegane ryzyko stanie się wystarczająco duże, zespół może zmienić sposób prezentowania swojej pracy.

Publiczne testy służą jednocześnie kilku celom. Deweloperzy mogą obserwować niezrozumienie, odkrywać problemy techniczne i znajdować graczy, którzy rozumieją zamierzone doświadczenie. Ograniczony test zmienia to, kto uczestniczy i jak szeroko to doświadczenie krąży.

Koszt jest więc szerszy niż brakująca możliwość pobrania. Mniejsza ekspozycja może utrudnić nieznanemu projektowi zbudowanie odbiorców. Ogranicza również liczbę osób, które mogą rozmawiać o grze i ją polecać.

Tworzy to nierówne obciążenie. Oryginalny deweloper musi zdecydować, ile ujawnić, podczas gdy naśladowca może czekać, aż pojawi się coś obiecującego. Nawet nieudana imitacja może pochłonąć uwagę, którą pierwotny zespół miał nadzieję zdobyć.

Nie dowodzi to, że każda podobna gra jest kopią. Wyjaśnia natomiast, dlaczego zagrożenie konkretnym odtworzeniem zmienia kalkulację dotyczącą wczesnego dostępu. Obawa koncentruje się na rozpoznawalnej pracy stającej się materiałem wyjściowym dla kogoś innego.

Interwencja Anthropic dotyczy jednej drogi prowadzącej do tego problemu. Jeśli Claude odrzuci bezpośrednie żądanie odtworzenia, zwiększa to trudność przed powstaniem konkurencyjnego projektu. Interwencja następuje wcześniej niż skarga do sklepu po publikacji.

Decyzja studia dotyczy jednak całego środowiska wydawniczego. Ograniczenie w Claude nie może samodzielnie zagwarantować, jak zachowa się inne oprogramowanie ani jak sklep będzie obsługiwał zgłoszenia.

Najmocniejszy dowód poprawy pochodziłby zatem z zachowania deweloperów. Studia, które zaczęłyby czuć się swobodnie z szerszymi testami, sugerowałyby, że ich ocena zagrożenia się zmieniła. Sama nowa instrukcja nie może potwierdzić takiego rezultatu.

Na razie przykład ReVamp pokazuje, dlaczego stawka wykracza poza to, czy chatbot odpowie na prompt. Problem sięga budowania publiczności, harmonogramów testów oraz zakresu niedokończonej pracy, którą deweloperzy czują się komfortowo udostępniać.

Oryginalne gry pozostają dozwolone, ale granica wymaga interpretacji

Stanowisko Anthropic zachowuje pomoc przy oryginalnym projektowaniu, prosząc jednocześnie Claude o rozpoznawanie sytuacji, w których żądanie dotyczy konkretnej gry stworzonej przez kogoś innego.

To rozróżnienie brzmi jasno na swoich krańcach. Żądanie odtworzenia nazwanego wydania różni się od żądania wdrożenia niezależnie zaprojektowanego projektu. Pomiędzy tymi krańcami deweloperzy korzystają z odniesień, znanych mechanik i utrwalonego języka gatunków.

Wyobraźmy sobie hipotetycznego projektanta tworzącego grę farmerską z oryginalnym światem, systemem progresji i grafiką. Opisanie jej jako gry farmerskiej daje asystentowi programistycznemu użyteczny kontekst. Etykieta gatunku nie wskazuje konkretnego tytułu do odtworzenia.

Inne hipotetyczne żądanie prosi o rozpoznawalną oprawę i progresję innej gry, przy zmianie jedynie nazw i kolorów. To żądanie testuje ograniczenie opisane przez Anthropic. Nazwanie rezultatu oryginalnym nie rozwiązałoby podstawowej obawy.

Trudne przypadki dotyczą częściowych podobieństw. Deweloper może poprosić o interakcję z ekwipunkiem, zachowanie kamery lub mechanikę walki kojarzoną z istniejącym wydaniem. Asystent musi interpretować żądany zakres, nie traktując każdego odniesienia jako żądania odtworzenia.

Nie ma tu publicznych podstaw, by twierdzić, że Anthropic rozwiązał ten problem interpretacyjny. Jego oświadczenie opisuje zamierzone zachowanie. Nie przedstawia opublikowanej oceny pokazującej, jak często odpowiednią odpowiedź otrzymują żądania z pogranicza.

Wsparcie Claude dla oryginalnych gier byłoby łatwiejsze do oceny, gdyby Anthropic opublikował przykłady zaakceptowanych i odrzuconych projektów. Przykłady pomogłyby deweloperom zrozumieć, czy odmowa dotyczy zasobów, całego projektu czy żądanego wdrożenia.

Ma to znaczenie komercyjne, ponieważ asystent programistyczny działa wewnątrz trwającego projektu. Deweloperzy muszą wiedzieć, czy jego zachowanie pozostanie przewidywalne w miarę rozwoju projektu. Niejasne granice mogą przerywać pracę, nawet gdy samo ograniczenie ma rozsądny cel.

Szerzej pojęta branża oferuje również użyteczne porównanie. Dyrektor Epic, Marcus Wassmer, opisał wykorzystywanie Claude i Codex do wspierania prac nad Unreal Engine, frameworkiem używanym do tworzenia gier. Według doniesień dotyczących rozwoju silnika wspomaganego przez AI, jego relacja obejmuje pomoc przy uporczywych błędach i monitorowaniu stabilności.

Są to deklaracje firmy, a nie niezależne pomiary skuteczności tych narzędzi. Mimo to ilustrują kategorię autoryzowanego rozwoju, różniącą się od odtwarzania ukończonej gry stworzonej przez kogoś innego.

Porównanie umieszcza tworzenie gier z Claude w szerszym procesie tworzenia oprogramowania. Pomoc programistyczna może obejmować utrzymanie, testowanie i wdrażanie własnych decyzji zespołu. Ocena tych zastosowań wyłącznie przez pryzmat kontrowersji wokół klonowania pominęłaby rozróżnienie, które sam Anthropic stara się zachować.

Dla zespołów wyraźniejsze rejestry projektu pomagają wyjaśnić to rozróżnienie. Decyzje projektowe, pochodzenie zasobów i uprawnienia zapewniają kontekst, gdy narzędzie kwestionuje żądanie. Pomagają również ludzkim recenzentom zrozumieć rozwój projektu.

Przeszukiwalna baza wiedzy inżynieryjnej może utrzymywać ten kontekst dostępny w dokumentach technicznych. Takie zapisy wspierają weryfikację; nie gwarantują, że zautomatyzowany asystent zaakceptuje zadanie.

Wyzwanie produktowe pozostaje kwestią interpretacji. Claude musi rozpoznawać żądanie odtworzenia, nadal pomagając przy legalnym rozwoju, który je otacza. Zbyt szeroka odmowa podważyłaby pozwolenie, które Anthropic deklaruje zachować.

Zgłaszane odmowy ujawniają ryzyko blokowania legalnej pracy

Zabezpieczenie potrzebuje dowodów zarówno na kopiowanie, któremu zapobiega, jak i na autoryzowaną pracę, którą zakłóca.

Tom’s Hardware opisał skargi użytkowników twierdzących, że Claude odmawiał przy zwyczajnym tworzeniu gier i powiązanych zadaniach technicznych. Materiał odsyłał do zgłoszeń problemów dotyczących trwających projektów, mechanik i prac nad bezpieczeństwem.

Relacje te rodzą istotną obawę, lecz wymagają ostrożnego przypisania. Publiczna skarga opisuje doświadczenie użytkownika i jego rozumienie odmowy. Niekoniecznie ujawnia, która wewnętrzna instrukcja spowodowała odpowiedź.

To rozróżnienie staje się szczególnie ważne, gdy nakłada się kilka rodzajów ograniczeń. Odmowa podczas tworzenia gry może dotyczyć zasady odtwarzania, odrębnego zabezpieczenia lub sposobu, w jaki model zinterpretował prośbę. Sam moment jej wystąpienia nie pozwala ustalić przyczyny.

Relacja publikacji o zgłaszanych odmowach podczas prac deweloperskich potwierdza zatem skargi wymagające zbadania. Nie ustala jednak mierzalnego wskaźnika błędów dla nowej instrukcji dotyczącej gier.

W tym miejscu kompromis staje się kwestią operacyjną. Fałszywy pozytyw, czyli nieprawidłowo zablokowana uzasadniona prośba, tworzy dodatkową pracę dla dewelopera. Zespół musi doprecyzować zadanie, zebrać kontekst lub zwrócić się o pomoc, zanim będzie mógł kontynuować.

Zbyt pobłażliwa odpowiedź tworzy inny problem. Jeśli bezpośrednia prośba o odtworzenie gry zostanie spełniona mimo instrukcji, polityka zapewnia mniejszą ochronę, niż zamierzano. Oba rezultaty mają znaczenie przy ocenie, czy ta granica jest użyteczna.

Rzetelna ocena porównywałaby wyniki dla jasno opisanych zadań. Oryginalne projekty powinny nadal otrzymywać wsparcie, podczas gdy prośby o odtworzenie konkretnego wydania powinny podlegać deklarowanemu ograniczeniu. Niejednoznaczne przypadki wymagają wystarczającego wyjaśnienia, by recenzent mógł zrozumieć decyzję.

Własność utrudnia taką ocenę. Model nie dysponuje automatycznie wiarygodnymi dowodami na to, kto jest właścicielem każdego projektu lub zasobu. Pewne twierdzenie użytkownika i faktyczne upoważnienie mogą wyglądać podobnie w rozmowie.

Ta niepewność nie sprawia, że każda odmowa jest uzasadniona. Oznacza, że Anthropic potrzebuje wykonalnego procesu korygowania błędów obok samego ograniczenia. Deweloperzy potrzebują sposobu na rozwiązanie pomyłek bez wielokrotnego przedstawiania tej samej historii projektu.

Niepewność wpływa także na twierdzenia dotyczące inżynierii wstecznej, czyli analizy istniejącego oprogramowania w celu zrozumienia jego działania. Potwierdzona instrukcja dotycząca gier nie dowodzi, że każde takie zadanie podlega powszechnemu zakazowi.

Szerokie wnioski zaciemniałyby rzeczywiste dowody. Firma potwierdziła instrukcję skoncentrowaną na odtwarzaniu, a użytkownicy zgłaszali szersze odmowy. Powiązanie każdej zgłoszonej odmowy z tą instrukcją wymaga dodatkowych informacji.

Dla czytelników oceniających ograniczenia Claude dotyczące gier najważniejsze pytanie dotyczy zatem powtarzalności. Czy uzasadniony projekt może być konsekwentnie realizowany po zrozumieniu jego kontekstu? Czy recenzenci mogą odtworzyć zgłoszony problem i ustalić jego przyczynę?

Dopóki takie dowody nie istnieją, ani ogólne uspokajanie, ani ogólne ogłoszenie, że tworzenie gier jest zepsute, nie mają mocnego oparcia. Dostępne informacje uzasadniają analizę wdrożenia, przy jednoczesnym uznaniu deklarowanego przez Anthropic zezwolenia na oryginalną pracę.

Valve mierzy się z tym samym problemem na innym etapie

Ograniczenie w kodowaniu dotyczy produkcji, podczas gdy sklep musi zdecydować, co dzieje się, gdy konkurencyjna gra trafia do graczy.

Stanowisko Valve ilustruje tę różnicę. Podczas wydarzenia dla deweloperów w Korei Południowej przedstawiciele firmy odpowiadali na pytania dotyczące imitacji wspieranej przez AI. Według relacji Game Developer Valve podkreślało zaufanie społeczności i wyróżnienie się, a nie ograniczenia narzędzi deweloperskich.

Opisana reakcja Steam na klonowanie pokazuje, dlaczego zmiana Anthropic nie może samodzielnie rozstrzygnąć problemu. Asystent programistyczny i sklep podejmują decyzje na różnych etapach drogi gry na rynek.

Dostawca modelu może odmówić pomocy w realizacji prośby. Sklep może ocenić zgłoszony produkt i skargi z nim związane. Żadna z tych decyzji nie dostarcza automatycznie informacji potrzebnych drugiej stronie.

To rozdzielenie ma znaczenie w dyskusji o odpowiedzialności. Odmowa w Claude nie przesądza, co stworzy inne narzędzie. Podobnie pojawienie się gry w sklepie nie dowodzi, że jej proces tworzenia respektował pracę innego twórcy.

Główne napięcie nadal dotyczy kreatywnej pomocy kontra konkretna imitacja. Znaczenie Valve wynika z radzenia sobie z dalszymi konsekwencjami tego napięcia. Jego podejście nie powinno przekształcać tej historii w prosty spór między firmami o zasadniczo odmiennych rolach.

Dla deweloperów lojalność społeczności może zapewniać pewną ochronę. Gracze, którzy rozpoznają pracę zespołu, mają kontekst, którego sama oferta w sklepie nie może dostarczyć. Mogą odróżnić historię projektu od nowo pojawiającej się alternatywy.

Budowanie takiego rozpoznania wymaga jednak widoczności. Studio nie może łatwo budować zaufania wokół pracy, której obawia się pokazać. To ponownie prowadzi do problemu publicznych demonstracji: ochrona i widoczność mogą działać w przeciwnych kierunkach.

Złożoność produktu także nie odpowiada na każdą obawę. Deweloper może celowo tworzyć niewielkie, skoncentrowane doświadczenie. Znaczenie tej pracy nie zależy od tego, jak łatwe komuś innemu wydaje się jej odtworzenie.

Te obserwacje wyjaśniają, dlaczego instrukcja w Claude ma ograniczony zasięg. Może wyrażać granicę Anthropic i potencjalnie zniechęcać do określonych próśb. Nie może jednak decydować o tym, jak odbiorcy odkrywają gry ani jak rozwijają się spory po publikacji.

Kwestia konkurencji również pozostaje węższa, niż sugerują niektóre komentarze. Publicznie dostępne dowody nie ustanawiają, że konkurencyjni asystenci programistyczni egzekwują równoważne zasady lub oferują identyczne wyjątki. Rzetelne porównanie wymagałoby aktualnej dokumentacji i odtwarzalnych testów.

Deweloperzy oceniający alternatywy powinni zatem porównywać zachowanie na autoryzowanych projektach, które rozumieją. Różnice w odmowach mają znaczenie obok jakości kodu, wyjaśnień i możliwości kontynuowania pracy po doprecyzowaniu.

Użyteczny rezultat połączyłby kilka etapów: jaśniejsze działanie narzędzi, zrozumiałe procesy weryfikacji oraz wiarygodne rozpatrywanie skarg po premierze. Żadnego z tych etapów nie można wywnioskować z istnienia innego.

Anthropic podjęło działania na etapie prośby. To, czy zmieni to doświadczenia twórców oryginalnych projektów, zależy od tego, co wydarzy się później w pozostałej części procesu tworzenia i dystrybucji.

Na co zwracać uwagę po aktualizacji Claude

Kolejne dowody powinny pokazać, jak ta granica działa w praktyce, jak korygowane są błędy oraz czy deweloperzy zmieniają decyzje dotyczące premier.

Pierwszym sygnałem będzie bardziej przejrzysta dokumentacja produktu lub przykłady od Anthropic. Deweloperzy potrzebują konkretnych rozróżnień między dopuszczalnymi odniesieniami a prośbami odtwarzającymi konkretną grę. Opublikowane przykłady ułatwiłyby ocenę deklarowanej granicy.

Najbardziej użyteczne przykłady dotyczyłyby rzeczywistej niejednoznaczności. Wyraźnie oryginalny projekt i oczywiste odtworzenie wyznaczają skrajne przypadki. Częściowe mechaniki, odziedziczony kod i starsze projekty należące do użytkownika sprawdzają interpretację pomiędzy nimi.

Jeśli Anthropic wyjaśni te przypadki, wzmocni to pogląd, że ograniczenie może współistnieć z przewidywalnym procesem tworzenia. Utrzymująca się niepewność osłabiłaby ten pogląd, nawet gdyby podstawowa polityka pozostała bez zmian.

Drugim sygnałem będzie sposób rozpatrywania zgłoszonych błędów. Warto obserwować publiczne rozwiązania problemów, które wyjaśniają, dlaczego uzasadniona praca została zatrzymana i co ją przywróciło. Zamknięta skarga bez zrozumiałego rezultatu dostarcza ograniczonych dowodów.

Powtarzalne wyniki miałyby większe znaczenie niż odosobnione historie sukcesu. Jeśli deweloperzy mogą opisać autoryzowane zadanie i konsekwentnie je ukończyć, wsparcie Claude dla oryginalnych gier staje się bardziej wiarygodne. Uporczywe, niewyjaśnione odmowy podważałyby to zaufanie.

To także miejsce, w którym tworzenie gier z Claude wymaga oceny wykraczającej poza początkową odpowiedź. Narzędzie może zaakceptować pierwszą prośbę dotyczącą projektu, a później przerwać powiązaną pracę. Dla zespołów polegających na nim liczy się konsekwencja w całym projekcie.

Trzecim sygnałem jest zachowanie deweloperów wokół publicznego testowania. Warto obserwować, czy studia poszerzają dostęp do demonstracji, nadal korzystają z ograniczonych społeczności, czy wyjaśniają nowe zabezpieczenia wpływające na ich decyzje. Te wybory pokazują, jak zespoły oceniają ogólne ryzyko.

Powrót do szerszych testów nie dowodziłby, że zmianę spowodowało Anthropic. Polityka sklepów, reakcje społeczności i indywidualne okoliczności również kształtują strategię wydawniczą. Przypisanie przyczyny wymagałoby więcej dowodów niż zbieżnych dat.

Mimo to decyzje te stanowią konkretny rezultat, który warto śledzić. Obawą stojącą za tą debatą jest to, że oryginalni twórcy czują presję, by ujawniać mniej. Dowody, że mogą oni z większą pewnością dzielić się swoją pracą, bezpośrednio odniosłyby się do tej obawy.

Argument za podejściem Anthropic staje się silniejszy, jeśli prośby o kopiowanie napotykają opór, a jednocześnie uzasadnione projekty pozostają użyteczne. Słabnie, jeśli ograniczenia przede wszystkim zakłócają pracę autoryzowanych deweloperów lub pozostawiają docelowe zachowanie bez zmian.

Żadnego z tych rezultatów nie należy zakładać na podstawie samego ogłoszenia. Klonowanie gier w Claude ma teraz wyraźną granicę w opisanej konfiguracji programistycznej. Konsekwencje zależą od tego, jak dokładnie działa ta granica i jak reaguje otaczający ją rynek.

Zanim zinterpretujesz kolejną odmowę jako całkowity zakaz, porównaj prośbę z deklarowanym przez Anthropic rozróżnieniem między oryginalnym tworzeniem a konkretnym odtwarzaniem. Zachowaj wystarczający kontekst projektu, aby wyjaśnić własne projekty, zasoby i uprawnienia. Jeśli uzasadniona praca zostanie zatrzymana, zapisz zadanie i odpowiedź, aby problem mógł zostać zbadany. Śledź konkretne korekty obok zgłoszeń o blokowanym kopiowaniu i obserwuj, czy studia odzyskują zaufanie do publicznego testowania. Te obserwacje ujawnią więcej niż skuteczna odmowa lub odosobniona skarga. Pytanie, które warto zachować na przyszłość, jest praktyczne: czy nowa granica pomaga oryginalnym twórcom nadal tworzyć i udostępniać swoją pracę?