8

Say I have a personal software project that I would like to be Open-Source. 100% of the source code for my version of that project is available online for everyone (e.g. on GitHub). I'd the like to grant/impose the following freedoms/restrictions:

  1. Anyone is free to use my project, modify it, redistribute it (all the freedoms that GNU licenses usually grant).
  2. If someone modifies my source code and redistributes it, they have to make my source code and their changes publicly available.
  3. If someone links to a (potentially proprietary) dependency in their modified version of my project and distributes it, they HAVE to make the modification that links to the dependency publicly available, BUT they do NOT have to distribute the dependency AND they do NOT have make the source code for the dependency public.
  4. If someone incorporates my project or their own modified version of it in a larger work (i.e. simply add to my project/their modified version of it), as long as they comply with the conditions listed above, they can license their larger work however they want.

Example of point 4: someone modifies my work to fit their needs, publishes the entire source code of the modified version of my project, uses this modified version in a larger, proprietary, work and notifies the user about using the modified version of my work).

What license should I choose in order to achieve this?

Improve this question
3
  • 3
    When you say "make xyz publicly available", do you mean a) 'publish so that everybody in this world can see it' or b) 'make available to the recipients of that redistributed software/code' ?
    – Martin_in_AUT
    Sep 8 at 13:31
  • I mean b), but people usually do a) if it's an open source project because it's both more effective and easier
    – Nicolas Dumitru
    Sep 8 at 13:42
  • 2
    LGPL is close to what you need. Have you looked at it before asking your question? Which part(s) of LGPL do you not like?
    – Martin_in_AUT
    Sep 8 at 13:50

1 Answer 1

Reset to default
13

Lets go over your licensing points one by one and see what restrictions they put on your choice for a license.

Number 1 (Anyone can make changes and distribute them) suggests that you want an open-source license. That makes the question on-topic here, but does not otherwise limit your choice among the open-source licenses.

Number 2 (My code must remain open-source) points towards a copyleft license. The GNU licenses are popular examples, but there are others as well.y

Number 4 (Ability to use in larger, proprietary, project) indicates that you want a weak copyleft license. It is primarily your code and the changes to it that you want to keep open. This removes the GPL and AGPL licenses from the list of possibilities.

Number 3 (Ability to use a proprietary dependency) is where it becomes more difficult to give a recommendation. That also depends on where exactly the dividing line lies between "a modification to link to the dependency" and the dependency itself. Also, do you want to allow someone to write a proprietary replacement and change your (open-source) code to only be a wrapper around the proprietary code, or do you want to limit the proprietary dependencies that they can only hook into a defined part of the system (like a plug-in).

The two licenses that I would recommend for your consideration are

  • MPL 2.0: A file-based copyleft license. This means that the copyleft aspect of the license extends only to the code that was explicitly marked as subject to the license. It is possible to add extra files to a project under a different, potentially proprietary, license.

    This license meets all your requirements, if you don't mind that parts of the code linking a third-party proprietary dependency could be added through non-MPL files.

  • LGPL 3.0: A weak copyleft license. This license does not actually meet condition 3, but there are ways to incorporate that and it is a very well-known license.

    The way to support condition 3 in the LGPL is through a mechanism called "additional permissions": Next to the statements that the code is under the LGPL license, you add a paragraph stating what people are allowed to do that would not be normally allowed under the LGPL license. This could be used, for example, to allow linking with proprietary dependencies that make use of a plug-in mechanism that you provide.

The LGPL+permissions option is more suitable if there is a fairly narrow use-case for proprietary dependencies that you want to allow and you can clearly articulate that in a "additional permission" paragraph.

If you want to allow proprietary dependencies in a broader way, then the MPL would be the better choice.

Improve this answer
6
  • 1
    Great breakdown of the licenses! I think I'd like to limit the proprietary dependencies to only plug-ins/libraries, as turning my code into a wrapper for a proprietary replacement seems like it's not only undermining my code and closing it down, but also sort of masquerading as my code. I'll have to think this through. Could you please clarify what you mean by narrow -> broad proprietary dependency usage and the implications?
    – Nicolas Dumitru
    Sep 8 at 15:19
  • @NicolasDumitru, what I mean with narrow vs broad here is basically how many and how strict the limitations are on where proprietary dependencies should be allowed in your view. Only linking via a predefined plug-in interface would be narrow, allowing someone to also extend the plug-in interface would be a bit broader, allowing proprietary dependencies "everywhere" would be really broad.
    – Bart van Ingen Schenau
    Sep 8 at 15:27
  • How can licenses limit this in such a granular manner? What license corresponds to which level? MPL would probably be on the "broad" end of the spectrum, right?
    – Nicolas Dumitru
    Sep 8 at 15:50
  • @NicolasDumitru, MPL is indeed on the broad side. The plain LGPL forbids it completely and with additional permissions you can get as specific as you want, even down to named packages (you can link to A and B, but no others).
    – Bart van Ingen Schenau
    Sep 8 at 19:17
  • 1
    Bart, thanks for helping me out. Your breakdown was awesome, but I just realized that this problem is initially more complex than I thought, as I'd like my source code to also be compatible with most open-source licenses. I fell like all this licensing stuff can very easily backfire and may hinder progress just as much as it protects the copyright holders.
    – Nicolas Dumitru
    Sep 10 at 13:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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