Equitable Open Source

From P2P Foundation
Jump to: navigation, search

= aims to attribute an Equitable Open Source (EOS) label based on a common charter


"While more and more companies are adopting free and open source software -whether as a keyword, a commodity or a business strategy- their influence on open source projects has been steadily growing.

This is not bad as such since this resulted in many more companies contributing to the FOSS ecosystem. However this also resulted in a situation where the balance of power has somewhat shifted from community-centric to commercial-induced interests.

And since commercial interests don't always correspond (why would they?) to the spirit and the principles of free and open source software, there is a need to balance more equitably commercial and community interests through new initiatives.

The Equitable Open Source (EOS) is one such initiative, aiming at defining a label attached to companies producing software applications. Since many -including industry analysts- predict that in just a few years most commercially-produced software will encompass substantial pieces (hopefully entire projects) of free and open source software, it makes sense to focus first on large companies which business is to produce software and which influence is the greatest. This of course, doesn't preclude rewarding smaller companies for the quality and/or the novelty of their interaction with the free and open source software community.

Now such initiative cannot work without the active participation of FOSS developers or it will just turn into another marketing buzz that sooner or later will be exploited by somebody: Nature dislikes vacuum.

We need to start somewhere so I you want to participate in jump starting things, hopefully before OSCON, drop me an email [email protected] and we will start from there. (http://blog.milkingthegnu.org/2008/05/call-for-equitable-open-source.html)


"Some key issues to take into account:

  • Patent policies (how many patents, what's your policy, bonus when using no-patent licenses)
  • Open source access effectiveness (how hard is it to find the source, to compile or to run it)
  • Open source licenses (no proliferation: bonus points if your licenses are among the top 5)
  • Ratio between open source and proprietary code (what do you sell?)
  • Ratio between paid and non-paid open source in the code
  • Recruiting practices (e.g. more than 50% of one project key contributors is not good)
  • Level of control of open source projects (trademarks, licenses etc.)
  • Relationship with other open source companies and their EOS (e.g. if your business and contractual relationships are mostly with high EOS companies it should reflect on you)