Read more about the OSI Board.

Read the Beyond-Licensing email archives for more details about the project.

Meeting Notes

• Beyond licensing: meant to explore open source just beyond the scope of licensing - what is the raison d'etre of the OSI beyond keeping a list of licenses
• A license is not enough to create a successful community & project, but these things are not as well defined as e.g. The Open Source Definition
• Open standards requirements are a good addition to the purview of the OSI
• Branding is important for open source projects, see recent post from Shane Curcuru on Beyond Licensing list
  • Company leadership who is disconnected from marketing dept understanding of open source and who co-opt open source brands / branding (e.g. Hadoop)
  • People want to work on projects because of the "brand" - reputation, credibility, etc.
  • Not every project needs to get to the point of needing "branding" but if you wait to long then your brand can have been coopted by businesses, etc.
  • Foundations exist to hold marks and allows for use of them in a sane way, e.g. differently than a trademarked name of a 'project' which is owned by a VC funded company
  • Company involvement can skew the perception of your project before you are aware it is happening
• Open source needs marketing & marketing education! ^^
  • OSI can provide education and basic models for trademark usage or amplify signal of modern trademark guidelines & FOSS Marks project
  • Guide on what to worry about and when in your lifecycle for branding for projects so you don't burn cycles or get co-opted
  • 80% of trademark enforcement can be done with no cash outlay, just by sending a letter - can OSI provide templates for these polite letters?
• Governance models
  • Copyright aggregation - this can be dangerous if any one entity exercises too much control over code base copyright
  • How do we organize our open source project
• Social responsibility of the open source movement / organizations within it
  • Are codes of conduct something we should talk about as a best practice?
  • Free software and policy, e.g. bill introduced in New York City Council advocating government prefer FOSS in procurement - cuts costs, use local contractors vs. big vendors, set target for amount of open source being used, software produced by government should be released as open source
• How to tell if a particular project is "good" to engage with / contribute to
• How do we engage authentically with open source communities when we're a business using/creating open source software
• OSI has capacity and neutrality to compile and index this kind of best practices content, the question is where to start - we want to be the 'reference desk'
  • Would there be a peer review process for this content?
  • What is the approval process for a particular document / syllabus / piece of work?
    • Could be the committer model to avoid endless debate
• Employee and employer relationship around open source stuff - employment contracts, expectations of time to spend contributing, copyright assignment in work for hire situations, etc.
• Sustainability of working on open source as an independent developer
• Dealing with large and old companies trying to figure out how to use and deal with open source software and change agency within their organization
  • documenting the journey of these long existing companies to open source, e.g. Airbus determining the only way to support software in their aircraft, which can be in service 50-80 years, requires open source
• Case study approach for business models of open source
• Newer projects didn't really care about licenses in the first place - look at GitHub 3-4 years ago, now GitHub is recommending a license as you spin up project
•