Création de logiciels dérivés à partir d'open source [fermé]

Question

Cette question a toujours été autour de ma tête.

Quelqu'un peut-il créer un nouveau produit basé sur un projet open source existant?

Dites que vous souhaitez créer un " serveur Web Apaxe " c’est essentiellement Apache avec quelques plugins supplémentaires (par exemple, support pour ASP ou quelque chose de similaire)

Est-ce possible?

Seriez-vous en mesure de créer un produit source fermé (gratuit ou sous licence)

Comme pour la GPL, il semble clair que ce n’est pas possible car la source doit être ouverte. Mais qu'en est-il de la licence Apache, de BSD et d'autres & "Pour les entreprises" & ";

Le prix (gratuit pour la majeure partie du projet), les corrections de bugs et le décompte avec l'équipe de développement principale sont-ils la seule chose qui empêche les autres de commercialiser ces produits OS?

Qu'en est-il: Khrome, un produit commercial basé sur Chrome avec support ActiveX (qui oserait faire une telle chose: P)

MODIFIER

Merci à vous tous pour vos réponses.

Encore une fois

Qu'est-ce qui empêche des produits similaires (clones) d'apparaître sur le marché?

:)

REMARQUE: je sais que nous ne sommes pas des avocats et que nous pourrions lire ici toutes les licences de logiciel libre http: //www.opensource. .org / licences .

Answer 1

Rien n'empêche les produits clones d'apparaître sur le marché. Regardez toutes les différentes distributions Linux, par exemple. Le projet X.org a été créé à partir de XFree86. Et ainsi de suite.

Cela arrive assez rarement, cependant, pour deux raisons:

• Le projet initial présente l'avantage d'être le premier au marché
• L'original est généralement distribué gratuitement

Donc, à moins que votre version ne soit nettement meilleure que la version d'origine, vous n'allez pas en tirer beaucoup d'avantages ni en tirer beaucoup d'argent. Si votre version est nettement meilleure, n'hésitez pas!

Du point de vue du développeur original, la puissance de la GPL réside dans le fait qu’elle force de tels clones à partager les améliorations apportées avec le reste du monde, afin de pouvoir les réintégrer dans l’original.

Answer 2

En général, ma lecture des licences est la suivante:

1. Vous pouvez créer un travail dérivé de tout projet basé sur l’une des licences les plus répandues (GPL, LGPL, Apache, MIT, BSD).
2. Vous pouvez facturer au moins la distribution & amp; emballage de votre travail dérivé.
3. En fonction de la licence, vous devrez peut-être également diffuser vos modifications sous forme de source et / ou inclure des notifications dans votre distribution.

Donc, pour répondre à votre question sur Apaxe: oui, vous pouvez le faire autant que je sache. Je pense que le serveur Oracle HTTPD est en fait dérivé d’Apache et qu’il n’est certainement pas gratuit!

Answer 3

Voici ma vue de 10 000 pieds de licences open source:

" Réel " Licences Open Source (par exemple: MIT, BSD, Apache je pense, etc.): Vous pouvez faire ce que vous voulez avec la licence de travaux dérivés. Il peut être fermé, ouvert, etc. La licence n'impose aucune restriction quant à la licence que vous accordez aux œuvres dérivées.

" Restreint " licences open source (par exemple: GPL, LGPL): Les travaux dérivés doivent inclure des restrictions de licence spécifiques; Par exemple, la GPL exige que les travaux dérivés soient au format GPL. Vos droits sont essentiellement limités aux œuvres dérivées.

La tarification des produits est distincte de l’un d’eux; aucun type ne limite la facturation des produits, bien que certaines licences imposent des restrictions sur les droits que vous pouvez conserver et / ou que vous devez transmettre aux destinataires de votre logiciel (c'est-à-dire: les licences & "Restricted &";).

J'espère que cela vous aidera.

Modifier: modifié par l'original " DRM " terme désignant les licences de type GPL en & "Restricted &"; certaines personnes associent des connotations négatives à DRM et / ou ne peuvent pas comprendre comment la GPL restreint vos droits pour les œuvres dérivées de manière presque identique à tout autre type de DRM (c.-à-d. contrôler ce que vous pouvez faire avec). Sérieusement, vous pouvez être un partisan de la FSF et continuer à défendre le concept selon lequel la GPL est plus restrictive que & "Real &"; licences open source. La question n'est pas de savoir quel type est correct ou non, mais de savoir quelle est la différence.

Answer 4

Red Hat (et la plupart des autres fournisseurs Linux) facturent le support, et non le logiciel - qui permet principalement aux entreprises de gagner de l'argent avec du code sous licence GPL.

Answer 5

Cela dépend vraiment de la licence utilisée par le projet open source.

Avertissement: je ne suis pas avocat. vous devriez toujours lire la licence pour plus de détails.

Si un projet est sous GPL, tout ce que vous en tirez doit également être publié sous GPL (ou une licence compatible, le cas échéant). Vous avez toujours le droit de facturer de l'argent pour cela, mais quiconque l'achète doit disposer de la source complète, et vous ne pouvez pas l'empêcher de le vendre ou de le donner gratuitement.

Si un projet est sous licence BSD, vous pouvez faire à peu près n'importe quoi avec ce dernier, y compris l'incorporer à un produit propriétaire à code source fermé. Il y a du code BSD dans Windows!

Les autres licences se situent quelque part entre les deux.

Answer 6

Regardez MyEclipse, c'est vraiment juste éclipse + plugins gratuits + plugins de myeclipse et ça coûte de l'argent.

Answer 7

  

Qu'est-ce qui empêche des produits similaires (clones) d'apparaître sur le marché?

Rien. La question réelle est la suivante: comment un produit cloné similaire peut-il devenir plus populaire que le produit original?

Quelques cas dans lesquels une personne peut cloner / créer un projet:

• Récupérer un projet open source mort et poursuivre son développement. Si le nouveau produit dérivé est mis à jour régulièrement et que le nombre de mises à jour par rapport à la version d'origine est supérieur, les utilisateurs commenceront à utiliser la nouvelle version. C’est l’un des gros avantages de l’open source - un bon logiciel n’a pas besoin de mourir, tout simplement parce que les développeurs originaux l’arrêtent de le développer, mais que d’autres peuvent continuer, là où ils sont restés. Voici un exemple de projet de ce type (que j’ai utilisé): le développement de Turck MMCache s'était éteint en 2003, donc eAccelerator l'a lancé et a poursuivi son développement en 2004. Je suis sûr qu'il y en a beaucoup d'autres exemples.

• Il existe un désaccord dans la communauté des développeurs concernant un projet open source, lequel se scinde en deux. C'est pourquoi il est préférable de rechercher une compréhension commune dans les projets open source, afin que la communauté ne soit pas scindée inutilement. Si un projet est divisé, les projets peuvent continuer à vivre s'ils parviennent à attirer suffisamment de développeurs et d'utilisateurs, mais sinon, ils risquent de mourir lentement. En règle générale, il convient d'éviter les scissions, car cela rend la communauté plus fragmentée et plus faible. Dans les présentations vidéo de Produire du logiciel Open Source (du bon matériel!), L’IIRC a mentionné un cas où le développeur original de certains projets voulaient prendre une direction complètement nouvelle dans le développement, mais la communauté des autres développeurs souhaitait conserver l’ancienne direction. Le résultat a été que le développeur d'origine a été exclu du projet. Il a donc créé une fourchette du projet, tandis que le reste de la communauté a poursuivi le développement du projet d'origine.

• Dérivé commercial fermé d'un projet open source publié sous licence (par exemple BSD). Le produit dérivé devrait être considérablement meilleur en fonctionnalités ou en support que le produit original. Sinon, les gens préféreront utiliser le produit original ouvert et gratuit.

Answer 8

N'est-ce pas essentiellement ce que fait Red Hat? Même s'ils ont Fedora, ils facturent de l'argent pour leur distribution Linux. Certes, ils ont écrit beaucoup de code pour cela, il est toujours basé sur du matériel open source.