- Symulator MaSzyna -

Symulator EU07 (i nie tylko) => Bieżące Symulatorowe => Wątek zaczęty przez: carmel4a w 10 Sierpnia 2017, 17:08:29

Tytuł: Dostępność do skryptów exportowych, problemy z licencją, itp.
Wiadomość wysłana przez: carmel4a w 10 Sierpnia 2017, 17:08:29
Temat rzeka ogólnie rzecz ujmując, ale trzeba to w końcu gdzieś przedyskutować.
W skrócie: Jaką licencje powinny mieć, według Was, właśnie powstające do programu Blender, jak i do programu 3D Max Studio, skrypty?
Chodzi o ograniczenie dostępu osobom, które potencjalnie chciałyby ukraść jakiś assset, mimo że i bez skryptów mogą to zrobić.

Zarysowanie problemu: Mamy słabą, źle napisaną licencje. "Chałupniczej" roboty - co jeszcze pograsza sprawę. Nie ma podziału na prawa autorskie do pliku wykonywalnego, assetów, technologii (fizyka, formaty plików). Mimo ewidentego nie otwartego charakteru assetów, specyfikacje mamy otwartą.

Z tego co rozumiem, dąży się do: w pełni otwartego kodu źródłowego i w pełni zamkniętych assetów - "by nam nie kradli".

Tu narodził się kolejny problem: zamknięte assety utrudniają pracę innym użytkownikom, a nie uniemożliwia kradzierzy. Mamy w pełni otwartą specyfikacje. (trzeba by pakować w format binarny z ukrytym, zamkniętym modułem w pliku wykonywalnym do dekompresji by uninąć części kradzierzy).

Trzeba to jakoś przedyskutować i ostatecznie rozwiązać ten problem.
Pomijam oczywistą kwestie, że nie możemy "tak poprostu" zmienić "licencji" (lub jej braku) już posiadanych assetów.
Zapraszam do dyskusji.

Tutaj będę edytował i pisał Wasze propozycje (bo wątek pewnie się rozrośnie).

1. @carmel4a Zakładając że status prawny kodu źródłowego jest jasny, aktualni i starzy programiści muszą ustalić licencję, następnie przypisać do siebie autorstwo. Nie róbmy kolejnej chałupniczej licencji. MIT, Apache - coś w tym stylu.
Ja swoje assety będę udostępniał pewnie na jakiejś odmianie CC, ale nie mogę Wam narzucać rozwiązania. Tu proszę o wypowiedź innych twórców. Jakie konkretnie prawa mają być chronione?
Skrypt do importu scenerii udostępnie na MIT, by nie robić problemu przyszłym pokoleniom. Problemem według @krzysiuup są skrypty do exportu t3d/e3d, ale to już prosiłbym o Jego wypowiedź. Zakończe tym, że według mnie nie ma sensu trzymać otwartej specyfikacji i zamkniętych assetów. Bo to nic nie da. Zamknięte skrypty utrudnią/uniemożliwią twórczość "młodym" userom.
Tytuł: Odp: Dostępność do skryptów exportowych, problemy z licencją, itp.
Wiadomość wysłana przez: Stele w 10 Sierpnia 2017, 17:50:04
Przez dekadę skrypty importy t3d/e3d miały ograniczoną dostępność. Formalnie tylko dla devsów, w praktyce dostawał je każdy, kto wyraził zainteresowanie. Zakładamy, że zanim ktoś będzie umiał dorobić coś do istniejącego modelu, pierwej wymodeluje tabliczkę na słupku samodzielnie, choćby dla zapoznania się z formatem t3d i skryptem eksportowym.
Nie słyszałem o przypadku nieuprawnionego użycia naszych assetów, z wyjątkiem td2, gdzie robili to i tak nasi byli deweloperzy/ Zresztą ich silnik chyba czyta nasz format.

Skoro coś działa, to po co zmieniać? Jestem jednak za napisaniem porządniejszej licencji.
Tytuł: Odp: Dostępność do skryptów exportowych, problemy z licencją, itp.
Wiadomość wysłana przez: matek123 w 10 Sierpnia 2017, 17:50:47
Zamknięte skrypty utrudnią/uniemożliwią twórczość "młodym" userom.
Na początek można sobie poeksperymentować z robieniem domku. Jak pokażą co potrafią i chcą coś zrobić z istniejącego modelu - droga wolna, może poprosić administrację o skrypt.

Skoro coś działa, to po co zmieniać? Jestem jednak za napisaniem porządniejszej licencji.
Też popieram. Wtedy jest szansa na zwiększenie puli modeli do pozyskania dla maszyny (niektórzy nie zgadzają się na użycie w maszynie ze względu na licencję). Dodatkowo nowa licencja jest wskazana dla modeli do których przyczyniają się przewoźnicy.