Обмежте розмір кластера модулем із закритим кодом у програмі з відкритим кодом


10

Я працюю в академічному науково-дослідному інституті, сильно залежним від високоефективних обчислень. За 10 років ми розробили власний код Fortran, який дуже добре розглядається і може працювати на дуже великих кластерах. Для того, щоб ширша дослідницька спільнота отримала користь від коду, ми розглядаємо можливість зробити його відкритим кодом. Однак, оскільки наше фінансування сильно залежить від досліджень, які ми можемо виконати за допомогою коду, ми б наче стріляли в ногу.

Однією з ідей є обмеження кількості процесорів, на яких може працювати код, наприклад, максимум 1000 ЦП замість 100 000, які ми використовуємо. Таким чином глобальне дослідницьке співтовариство може отримати користь від коду, але ми матимемо перевагу в розмірі проблем, які ми можемо вирішити.

Чи можлива така особливість концептуально? І як можна було реалізувати таку функцію? По суті, ми хотіли б відкрити вихідний код повного коду, але обмежити паралелізацію (використовуючи MPI) фіксованою кількістю потоків MPI, наприклад, використовуючи модуль (із закритим кодом).


Що саме зробив би цей модуль із закритим кодом? Наскільки важко було б комусь повторно поповнити його?
svick

Відповіді:


16

Ви намагаєтеся дозволити дослідницькій спільноті виграти, надавши їм змогу робити те, що ви робите, не маючи змоги робити те, що ви робите. Це звучить так, ніби ви ще не зробили принципового вибору.

Такі програмні рішення, як у програмному забезпеченні з відкритим кодом, швидше за все, не працюватимуть: зрештою, код є відкритим кодом. Перше, що зроблять інші установи, - це вирвати біт із закритим джерелом, замінити його бітом з відкритим кодом без такого обмеження, і тоді всі користуватимуться цим.

Там може бути компроміс можливо: чи не з відкритим вихідним кодом програмного забезпечення, але ліцензії продають. Установи з ліцензіями також отримують право читати та змінювати код, але не поширювати його. Стягування щорічно. Таким чином, ви можете, можливо, компенсувати втрати у фінансуванні, взявши частину їх.

Інший варіант - випустити старішу версію, яку ви постійно оновлюєте, але завжди відстаєте на деяку кількість років. Однак, спільнота з відкритим кодом може взяти участь у проекті та розробити нові функції швидше, ніж ви (а може і ні; більшість людей завищують інтерес інших до свого програмного забезпечення).

Або просто відпустіть його та скористайтеся роботою, яку виконують інші. Ви завжди будете найкращими фахівцями з програмного забезпечення.


4

Це реально неможливо зробити.

Ідея відкритого джерела полягає в тому, що джерело є відкритим , іншими словами, люди матимуть доступ до нього. З Вікіпедії :

У виробництві та розробці відкритий код як модель розробки сприяє універсальному доступу через безкоштовну ліцензію до дизайну продукту або креслення, а також універсального перерозподілу цього дизайну чи креслення, включаючи подальші вдосконалення його будь-ким.

Забезпечивши універсальний доступ до дизайну або креслення, навіть якщо випущена версія обмежена лише 1000 ядрами, було б досить легко просто змінити це число на 100000 чи щось.


Ось кілька варіантів того, що можна зробити замість цього:

  • Подумайте про випуск коду під ліцензією, яка обмежує користувачів вашого коду
  • Випустіть бібліотеку API із закритим джерелом, яка дозволяє іншим дослідникам отримати вашу функціональність, не маючи доступу до самого коду.

Правильно. Якщо ви вкладете код там, щоб сказати "перевірити кількість процесорів і не використовувати належним чином більше X з них", будь-хто інший може прочесати ваш відкритий код, зняти цю перевірку та перекомпілювати.

4

Ви можете зробити дуже мало, щоб обмежити те, що зроблять інші зі своїм вихідним кодом. Вони можуть зробити ще один модуль з нуля, який може розблокувати можливості багатопроцесорної обробки або навіть покращити його: це коштуватиме часу та досвіду, але якщо для них це важливо, вони це зроблять.

З десятьма роками ви все ще маєте можливість використовувати свій досвід та знання коду, щоб продовжувати робити найкращі дослідження, навіть якщо ви надаєте іншим вихідний код, який дозволяє їм повторити ваші експерименти. У ваших фінансуючих може бути навіть більше причин звернутися до вас, оскільки ваш вплив на дослідження може бути більшим, якщо ви лідери проекту з відкритим кодом, який використовується в декількох університетах.

Замість відкритого коду ви можете спробувати обмежити інших юридично, опублікувавши своє джерело, але встановивши власні обмеження на ліцензію на джерело. Я можу придумати кілька проектів, які зробили це: Ghostscript, AT&T Unix, Microsoft .NET і Xerox PARC Smalltalk-80. Хоча вони зрештою вийшли повністю з відкритим кодом, я вважаю, що є й інші, менш відомі, які все ще встановлюють обмеження щодо використання вихідним кодом ліцензіатів. Звичайно, якщо публікація вашого джерела означатиме, що ті, хто менше дотримується закону, можуть порушити умови, це повинно перешкоджати сумлінним академічним дослідникам від використання вашого коду на суперкомп'ютерах настільки потужним, як і ваш.



@musiKk У 2002 році вилка Rotor в ядрі .NET почала використовуватись як " власний спільний джерело" , але набагато останнім часом великі частини комерційного джерела були опубліковані під ліцензійною ліцензією , а потім, у версії 4.6, повністю відкритим кодом . Я не усвідомлював, наскільки складно домовленість Microsoft про обмін джерелами .
квітня

1
Ти справді змусив моє серце стрибнути. Я думав, що я викопав відповідь 13 років. Не забувайте, що SO була запущена в 2008 році ... Тоді досить справедливо.
musiKk
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.