0

I'm not talking about code here but rather about protocol documentation. If I develop an open protocol and release the documentation for it, how can I release the documentation in a way that:

  1. Prohibits the release of proprietary/closed-source implementations
  2. Requires all modifications and extensions to the protocol to be released under the same license (with the same restrictions on implementations and modifications)

I see that there is a risk that, while my (or someone else's) code may always remain open source, the protocols used may be adopted and extended by proprietary competitors.

  • 1
    By making your project commercial friendly and willing to consider extending/improving your library, you will increase the chances that your project will be used and any additions will be shared rather than kept closed. – sambler Feb 10 '18 at 2:35
  • @sambler If you use a commercial-friendly license then companies can take the project, add proprietary extensions, and then sell their proprietary version until "everyone needs it" and the original open-source version has fallen behind and can't keep up. – Micheal Johnson Feb 10 '18 at 12:24
  • May be you are worrying to much. Proprietary systems like Microsoft's are only used because of legacy support. Or in the case of Apple, as a status symbol (stag horns). On the other hand the web that has become very successful is now having Digital Restrictive Management. – ctrl-alt-delor Feb 23 '18 at 0:27
  • @ctrl-alt-delor So if I develop an open protocol for something along with a reference application, what's to stop Microsoft (or another large company with commercial interests) from taking my open protocol and application (which were specifically designed and intended to be open) and extending it substantially, marketing it as their own product, and getting users to rely on the proprietary extensions that they've added (effectively making the protocol no longer open)? – Micheal Johnson Feb 23 '18 at 17:57
  • So are you worried about proprietary implementations, or incompatible implementations, or incompatible proprietary implementations? – ctrl-alt-delor Feb 23 '18 at 18:54
2

You can't.

Implementations of a protocol are not considered derived works of the protocol description under copyright law, so the copyright license on the protocol description has no influence at all on the copyrights of the implementations.

The closest you can get to your first point is if you have a patent on (a part of) the technology needed to implement the protocol. Then you could probably require an open-source implementation as part of the patent license that you grant.

And as the copyright license on your protocol can't force how the implementations are licensed, you also can't force such a requirement on derived protocols or extensions that might even be considered completely separate works under copyright law.

| improve this answer | |
  • Can't a license extend beyond copyright law? For example a lot of proprietary licenses impose restrictions on what situations the software can be used in (non-commercial, educational, etc.) or for what purposes (one game I had allowed simultaneous use on up to two computers only for network play) and as far as I'm aware these are legally valid and binding. So could a license not say "you can only use this protocol documentation for open-source implementations"? – Micheal Johnson Feb 10 '18 at 12:35
  • I must say that I found the patent part amusing, when patents are often used to restrict open-source implementations rather than enforce them. Although this would cost money on the part of the original developer. – Micheal Johnson Feb 10 '18 at 12:36
  • @Micheal such restrictions are typically part of a EULA, which is not a copyright license but closer to a contract. You can put any restrictions you want in a contract. – Bart van Ingen Schenau Feb 11 '18 at 6:04
  • Isn't an open-source license still an EULA? Can an EULA not accompany protocol documentation? – Micheal Johnson Feb 11 '18 at 18:55
0

The Creative Commons license has several options that allow you to customise the terms for your documentation.

NoDerivatives — If you remix, transform, or build upon the material, you may not distribute the modified material.

NonCommercial — You may not use the material for commercial purposes.

ShareAlike — If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original.

| improve this answer | |
  • 2
    This won't help with a proprietary implementation of an open protocol though. – curiousdannii Feb 10 '18 at 4:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.