Thank you so much for asking this question in the public forum.
I’d love to get feedback from the community on the suitability of our current license with respect to use cases like this one, as well as any questions about licensing provisions that aren’t well understood or licensing requirements that you would like to see.
For now, I’ll answer the questions above, but if there’s interest I can create a separate discussion topic to provide more context on the adoption of the license, as well as our initial intent and vision for future collaboration. Topics that could be discussed might include:
- How we decided on adopting the Eclipse Public License v1.0
- Our understanding of what is allowed / disallowed by this license
- Open discussions re: tranisition to a different open-source license
- Our vision for collaborating with developers and implementers
- Upgrading to EPLv2.0
Please note that I Am Not A Lawyer (IANAL) so please do your own research regarding the EPL license.
Could you please provide me with information regarding the licensing terms that govern rebranding OpenBoxes software for commercial use?
The simple answer is yes. Software licensed under the Eclipse Public License (EPL) can be rebranded or white-labeled.
We provide mechanisms for white-labeling through configuration i.e. logos, colors, custom URLs, etc. The one configuration that does not work reliably yet is the request context path (/openboxes). We started to work on that in 0.9.x but it took a backseat to other essentials during the 0.9.x migration project.
Additionally, I would like to know if there are any specific guidelines or restrictions to be aware of when using OpenBoxes in a commercial capacity.
There are some conditions to keep in mind related to attribution, modification, and prorietary code. You can find the details in the license itself …
… but here’s a general summary of the rules, based on my understanding (reminder: IANAL).
Attribution
The EPL requires that the original copyright notices and disclaimers remain intact. While you can rebrand the software, you must retain credit to the original authors where required.
Modifications
If you modify the software and distribute those changes, you must make the source code for the modifications available under the EPL. The base software must remain under the EPL license.
Proprietary Code
You can create and distribute proprietary code alongside EPL-licensed software, as long as it doesn’t modify the EPL-licensed code itself.
Conclusion
A commercial entity, using or distributing OpenBoxes, has considerable flexibility under the EPLv10. However, to definitively conclude whether a particular use case falls under the licensing provisions will likely require a lawyer (familiar with open-source licenses) to take a more in-depth look at your roadmap.
If you do plan to modify the code or build proprietary features, we’d be happy to consult with you on ways to make OpenBoxes more extensible so that your changes fall under the EPLv10 license.