2

Is there a variation of the GPL/BSD licences that states that you may use modify and distribute this code however you please but in such a fashion that should your distribution of the code compete with my distribution of the code some ways down the road that you will be open to merging our distributions together ?

Consider more vs. less, cat vs. dog or Libre vs. Open Office each set of packages provide similar functionality yet are direct competitors to one another. While the competition is good this creates a plethora of packages with similar implementations and features that users have to sift through before selecting one to become productive.

I was wondering if it were possible to license a package such that anyone can modify and extend it but not necessarily release it in direct competition to primary release. Should a competing release occur I would like to have the power to say "Hang on this is silly, Let's merge our efforts".

I appreciate that any two packages might have uniquely different architectures/strategies/structures for a particular problem and can see the benefit of such packages being in direct competition. When two packages are technically similar though merging them into one should be a no brainer and the way forwards, especially where the latter simply forked the former, added some features and released it in direct competition to the original.

Update (This was too long to respond with as a comment to @vonbrand):

@vonbrand commented that the freedom to extend and distribute a given source is a core part of Open Source software. I was just curious to know if there might be some means of converging the efforts of useful/successful modifications back into the the project in an effort to provide the "Best Possible" product versus having multiple branches where mine features X, his Y and hers Z. Users of the project cannot install/import X,Y and Z and are forced to go with one variant over another. That some variant Y or Z may supercede X is also fine provided the resulting project is better off for it in the end. Python's Esky project got abandoned by the original author due to competing clones and the frustration the maintainer experienced in having to compete against variants of their own package for example. Granted the freedoms permitted to the forks extend back to the original project and it could certainly incorporate these extentions back in but the maintainer of the project must then run around tracking down the forks and may loose the original audience due to the added noise. @amon points out that this is essentially the fault of the projects' stewardship but there might be some means of legally compelling all parties to stay true to the success of a project.

Carel
  • 123
  • 4
  • Some history of why Libre v Open happened with the office product may be helpful. https://www.crn.com/news/applications-os/227500950/openoffice-developers-split-from-oracle-create-own-organization.htm – ivanivan Jun 16 '19 at 13:59

1 Answers1

4

We have to distinguish between open source projects as a software artefact and open source projects as a social community.

  • It is perfectly possible to license open source software in a way so that an “upstream” project will be able to merge downstream modifications (to the degree that such modified software has been published). For example, copyleft licenses such as the GPL do exactly that. Note that no open source license requires private modifications to be published.

  • However, no open source license will let you control a community, such as by preventing community forks. You mention the OpenOffice vs LibreOffice split. This split happened precisely because the community was not confident in the new project leadership (Oracle). Because the software was open source, they were able to do their own thing. And the world has been much better for it.

If you are interested in such issues, it might be worth reading the OSI review process of the (rejected) Convertible Free Software License. That license tried to give Original Authors total control of the project. There was some interesting discussion about the value of forks (→ scroll to Relicensing and Maintainer–Community Dynamics in the January 2019 summary).

amon
  • 38,880
  • 1
  • 86
  • 113
  • My intention was to compel the persons extending a project to a single source of truth, from your argument I can see that such a clause might expose the project to mismanagement somewhere down the line. I do wonder if omitting Open/Libre Office from the examples would have swayed your answer otherwise though ? – Carel Jun 16 '19 at 21:54
  • 1
    @Carel: You can't ban forks altogether, but you may be able to use or repurpose the LPPL to at least force forks to use a different name and identify themselves as independent projects. The FSF considers it a free software license but with significant reservations, which you should also read before going down this path. – Kevin Jun 17 '19 at 02:18
  • @Carel, the right to fork is one of the basic rights of Open Source: Change what I got to adapt to my needs, no permissions asked. If you (original author) don't like my changes, but others do, too bad for your version. – vonbrand Jun 17 '19 at 13:04
  • @vonbrand my query was more to mitigate the release of modifications then it was to control any forks. I have since updated the question to elaborate upon this. – Carel Jun 17 '19 at 14:25
  • @Kevin thanks I had never read the LPPL before but it looks like it's in the spirit I was after. – Carel Jun 17 '19 at 14:27
  • 1
    @Carel, you could ask (like TeX does) that any derivative has to carry a different name. In any case, open source licenses generally ask to mark changes. But whatever you do, take pains to keep your stuff GPL-compatible. If not, you create an island of code that can't be used anywhere else. – vonbrand Jun 17 '19 at 15:12
  • 1
    @vonbrand that would be the last thing that I intend. I'll go over the LPPL, GPL and BSD licenses again before making a pick. The "update clause" is quite nice since it allows one to patch any erroneous restrictions later on. – Carel Jun 17 '19 at 15:35