Consider a more permissive licence than AGPLv3.

[Matthew-Jennings]

Hi @SimonBiggs and others,

I think we should seriously consider abandoning the AGPLv3 license applied to pymedphys in favour of a more permissive license. If not MIT, then perhaps LGPL (which I've seen recommended for libraries) or 3- or 4-clause BSD. We can explore options.

The strong copyleft nature of AGPLv3 - that any derivative work must be released under the same license and that the source must be released alongside the derivative work - is a very strong disincentive to contribute, for at least three reasons:

1. IP conflicts on either contributed or derivative work
2. The added workflow burden of compliance (which makes no sense for a library)
3. Limited commercialisation options for derivative works
   • note that "modifications" and "covered" works seem to be very broadly defined, whereas "aggregate" works seem very narrowly defined.

To elaborate:

• For contributors: EDIT: upon reflection, these are problems with open-source in general, not necessarily AGPLv3.

  • Most of our expected contributors will be employed medical physicists. Both we as maintainers and they as contributors would prefer the ability to make contributions in the natural course of their employment. However, most (all?) institutions have at least partial claim to any IP that their employees produce. By default, an employee may not have the legal right to make open-source contributions during work-hours. Even after-hours contributions are murky if they in any way leverage assets provided by the employer.
  • Some medical physicists, especially those employed by smaller, private institutions, might be able to negotiate terms to make open-source contributions. But this is at the discretion of their employers/IP decision-makers, with any "no"s subtracting from our pool of potentially high-quality contributors. Moreover, many physicists are employed in large, highly-bureaucratic institutions where IP negotiation, although not impossible, is difficult. I'd also suggest that cumbersome, drawn-out negotiations are unlikely to be undertaken without the promise of (financial) reward.

• For library users:

  • My interpretation is that developers who create larger works that use even small pieces of pymedphys must make the entire source codebase of their larger work freely available. EDIT: it's only to those to whom they distribute the code. It is possible that in some cases, the "aggregate" definition will hold, but as I outlined above, the definition seems rather narrow in scope. This is a severe restriction for a library. The points I made above for contributors apply here as well: users may not have the legal right to propagate the AGPLv3 license and so cannot use the pymedphys library for larger works (which could even be so obscure and specific as to be unsuitable for inclusion into pymedphys). This is surely a majority of potential users.
  • Moreover, even if they do have the legal right, the cost of compliance could be high. There are precise manners in which source code must be made available under AGPLv3, consitutiing yet another disincentive to even use pymedphys.

As I understand it, the major reasons for having AGPLv3 are that it prevents others from simply packaging up pymedphys and reselling it under a closed offering without properly acknowledging original work (although I think this still remains illegal under other licenses) or expanding the free/open-source codebase. But I personally find neither of these points particularly compelling:

• If people see fit to package up pymedphys and resell it as a closed version, let them! If they've only provided a non-free version of something that's already freely available, it won't take hold anyway. If they've provided a suite superior enough (e.g. with enough added convenience/functionality) for people to pay for it, they've genuinely added value and should have the option of being compensated for it. Both cases will almost certainly promote the visibility of pymedphys. Plus, I genuinely have faith that most people aren't complete asses and would largely attribute credit where it's due. And I'm still pretty sure this is a legal requirement for alternative licenses anyway. If someone is willing to breach copyright for the other licenses, they are willing to breach any added terms in AGPLv3. So we might have a license that limits contributors and user numbers without achieving what it's designed to achieve anyway...
• The second point is merely ideology: that more code should be available open-source, and AGPLv3 legally enforces it for any derivative works. I really think this is a mistake. So what if heaps of derivations exist that are closed? I suspect there will be anyway, due to the difficulty of enforcing this particular term. Plus, we may ironically have fewer open-source contributions due to the restrictive nature. The restriction might achieve the opposite of what it intends.

Also note that QATrack+, pylinac and pydicom are all under the MIT license. Even dicompyler-core, although not the standard MIT licence, has a similarly unrestrictive license. I think we should have strong cause to deviate from this apparent consensus.

Sure, plenty of other projects have AGPLv3, but they are not medical physics projects that are largely contributed to by medical physicists employed under almost certainly stricter IP arrangements than the typical software developer. I'm not sure how many parallels we can draw between pymedphy and more general open-source projects. Even then, plenty of high quality open source projects have less restrictive licenses (like GitLab, Electron, Atom, AngularJS...)

Note that most of the above constitutes my (read: a non-lawyer's) interpretation of the situation. I'm certainly open to correction, but I do think I have the general gist.

On a personal note, I am genuinely concerned about my ability to make contributions going forward. Initial conversations in this regard are not looking good. I actually have to navigate IP for two large, bureaucratic institutions: my hospital AND my university...

[Matthew-Jennings]

Consider the following scenarios:
A: pymedphys is under the AGPLv3 licence
B: pymedphys is under the MIT license

I am developing a new automated patient-specific QA process that is highly tailored to my centre. It involves a 3D dose comparison between the primary TPS and a secondary TPS. I would like to use the pymedphys gamma tool for this. I am in an institution where I cannot share the larger work I am undertaking.

Scenario A:
I cannot use the pymedphys gamma, since I cannot legally share the larger work to which it would contribute (and, indeed, may not want to). I write my own gamma or seek an alternative. I dismiss pymedphys going forward, since its a library that I cannot legally use.

Scenario B:
In the "worst" case, I use pymedphys gamma but do not share anything else I've developed. Whilst this doesn't follow the preferred open-source philosophy, it is still a net benefit to pymedphys. If pymedphys gamma works well enough, I won't seek alternatives. I don't dismiss it, since I'm allowed to use it. I remember pymedphys going forward and perhaps use other pieces of it later. Perhaps I find something of particular interest to which I'd like to make a contribution in my own time. More importantly, if I stick to pymedphys gamma for my larger work, I'm invested in its performance. I will write to you to tell you of bugs, suggest features, etc. Maybe I'll even fix bugs myself, in my own time, on the open-source version.

Can you see how even closed-source use of pymedphys is beneficial? I think AGPLV3 all but removes this as a possibility. Overall, my opinion is that pymedphys' visibility/reputation will grow much faster, since more people can use it.

[SimonBiggs]

I haven't read what you have written in full, but on a partial read (will come back in a bit), there may be a misunderstanding of the AGPL. Scenario A does not apply to your initial outline.

I am developing a new automated patient-specific QA process that is highly tailored to my centre. It involves a 3D dose comparison between the primary TPS and a secondary TPS. I would like to use the pymedphys gamma tool for this. I am in an institution where I cannot share the larger work I am undertaking.

The clauses of the AGPL only apply when you distribute the work in whatever form it results in, only the people you distribute the code to need to also have access to the source code. If you cannot ever share your work, then that's fine, you can legally use pymedphys and you don't have to share it in either source code or binary form.

If you distribute it to you colleagues the AGPL does come into effect, but it only comes in effect with respect to the very people who you share it with. Only your colleagues would need to also have access to the source code. It usually isn't an issue to tell your colleagues where the source code is located.

See my following note:

https://github.com/SimonBiggs/scriptedforms#a-note-about-the-code-sharing-license-requirement

[Matthew-Jennings]

Okay, but even if that's true, my point would hold if I altered my last comment to be the following:

I am developing a new automated patient-specific QA process that is highly tailored to my centre. It involves a 3D dose comparison between the primary TPS and a secondary TPS. I would like to use the pymedphys gamma tool for this. I am in an institution where I cannot share the larger work I am undertaking for free. But sharing it in the form of a binary file as a commercialisation option is permitted (indeed encouraged).

Scenario A:
I cannot use the pymedphys gamma, since I cannot legally share the larger work to which it would contribute (and, indeed, may not want to). I write my own gamma or seek an alternative. I dismiss pymedphys going forward, since its a library that I cannot legally use.

Scenario B:
In the "worst" case, I use pymedphys gamma but do not share anything else I've developed. Whilst this doesn't follow the preferred open-source philosophy, it is still a net benefit to pymedphys. If pymedphys gamma works well enough, I won't seek alternatives. I don't dismiss it, since I'm allowed to use it. I attribute credit to pymedphys for the portions of it I used, promoting its visibility I remember pymedphys going forward and perhaps use other pieces of it later. Perhaps I find something of particular interest to which I'd like to make a contribution in my own time. More importantly, if I stick to pymedphys gamma for my larger work, I'm invested in its performance. I will write to you to tell you of bugs, suggest features, etc. Maybe I'll even fix bugs myself, in my own time, on the open-source version.

Can you see how even closed-source use of pymedphys is beneficial? I think AGPLV3 all but removes this as a possibility. Overall, my opinion is that pymedphys' visibility/reputation will grow much faster, since more people can use it.

[SimonBiggs]

Not too much of a chance to discuss right now, but a significant issue is the closed source sold option always being the "Professional Version". Always being the version that can feel free to take all improvements within the open source version, and never have to return anything back. Meaning that no matter what the Open Source version does, it will always be second rate, and can never actually be the best on the market. And in the end it dies in the water, and no one looks at it. Everyone forgets the open source code that was the original product, only the closed source option ends up being what is known about and used.

Here is an example case of this story that has been played out like clockwork:

http://doselab.sourceforge.net/

This story has occurred many times. And it becomes the difference between pymedphys being kindling on the fire that makes a big flame for a short period of time and then gets burnt out, or something that has the staying power to build a slow burn for the long term.

[Matthew-Jennings]

[...] a significant issue is the closed source sold option always being the "Professional Version". Always being the version that can feel free to take all improvements within the open source version, and never have to return anything back.

Once again, who cares?. The only reason why anyone would opt for the "Professional", sold version is if the added cost is justified by features that are not present in pymedphys. The sold version has to be legitimately better than the free. "Taking all of the improvements" is almost irrelevant, because this is fundamentally not what people are paying for. In practice, they are only paying for what's not in pymedphys...

This story has occurred many times.

Really? In the medical physics arena? QATrack+, pylinac and pydicom seem fine to me...

[Matthew-Jennings]

Meaning that no matter what the Open Source version does, it will always be second rate, and can never actually be the best on the market.

Disagree. The open-source version is free. It has a competitive advantage. It is inherently better without trying, just because of that fact. The onus is on the sold version to be better to justify price.

[SimonBiggs]

I guess this part comes down to a big if. If pymedphys is the best on the market irrespective of price, then that gives credibility to the open source way of doing things, and it may draw in contributors.

It also may not, but that is a gamble I want to take. I want to see if this can stand, and bring in quality contributions, and actually be the best, irrespective of that whether it is free or not.

[Matthew-Jennings]

But you need not force other people to make their expansions of it open-source. And I really just do not buy your vague fear of pymedphys dying in the water when there are endless examples (especially outside of medical physics) where a more permissive license has worked. And in my opinion, has probably worked better. I honestly believe you limit both contributions and visibility by enforcing this. Especially when you remember that not all contributions are code.

[Matthew-Jennings]

Here is an example case of this story that has been played out like clockwork:

Do you know the full story here? Are you sure the makers weren't compensated for this? They may not have shared your particularly strong affinity for open-source. That may not have been the tragedy you seem to be interpreting it to be.

And I reiterate the success of the medical physics projects I've already mentioned - all of which have permissive licenses.

[SimonBiggs]

Just to also mention as an aside, every contributor owns the copyright to their own work. They can take their work and relicense it under any license they see fit. The AGPL cannot remove you're own right to share your own contributions under what ever license you see fit.

[Matthew-Jennings]

The AGPL cannot remove you're own right to share your own contributions under what ever license you see fit.

Does a copyright change revoke the AGPLv3 licenses of any copy of my code made prior to the license change? I suspect not...

Then there's the point that many contributions are made by multiple people without clear delineation of which portions were contributed by whom.

[SimonBiggs]

Once you've distributed under the AGPL, those contributions are always released under the AGPL to those whome you've released them to, but you can also release them under something else.

[SimonBiggs]

Once again, who cares?. The only reason why anyone would opt for the "Professional", sold version is if the added cost is justified by features that are not present in pymedphys. The sold version has to be legitimately better than the free. "Taking all of the improvements" is almost irrelevant, because this is fundamentally not what people are paying for. In practice, they are only paying for what's not in pymedphys..

I guess as an answer to that, I care, quite a lot... And if something isn't in pymedphys, and they want it in there, they can hire a programmer for cheaper than most medical software, and have that programmer build it for them, using pymedphys, and then also give back to pymedphys, and now what was not in pymedphys will be in there. And the resulting product will still be as flexible as ever, and the user who paid the programmer to write the code and add it to pymedphys will always have access to that code, to be able to take it further in the future.

[Matthew-Jennings]

I'm sorry, I was being a little coy. By "who cares?" I meant "why would you care?" I just don't understand this. You've outlined your fear of a commercial entity providing a closed-source almost-copied version of pymedphys. But that's not really specific enough. It's not getting to the nitty gritty details. What is it about a commercial entity providing a closed-source almost-copied version that is bad?

Is it some ideology that they should be sharing? That's a bit rough - I don't think there's any moral compulsion at all to share things freely. Insisting on the point that people should just share freely is condemning almost the entire human race. And promoting a near-communist economic model proven to be ineffective time and again.

Is it a desire to be recognised for your work? Recognition is still legally required by other licenses. AGPLv3 doesn't help here.

Is it a desire to be compensated for your work if someone else is? Remember that they'd only be getting compensated for the portion of work they do themselves.

Something else?

And if something isn't in pymedphys, and they want it in there, they can hire a programmer for cheaper than most medical software, and have that programmer build it for them, using pymedphys, and then also give back to pymedphys, and now what was not in pymedphys will be in there. And the resulting product will still be as flexible as ever, and the user who paid the programmer to write the code and add it to pymedphys will always have access to that code, to be able to take it further in the future.

So? That's completely fair enough, since they are still only really charging for what that extra programmer provided (which they paid for, invested in). You still seem to be missing the point that you cannot make money from a product that is free elsewhere!!

[SimonBiggs]

The fundamental property of the [GPL family of licenses] is a very simple "tit-for-tat" model: I'll give you my improvements, if you promise to give your improvements back.

It's a fundamentally fair licence

...

And the thing that then seemed to surprise people, is that that notion of "fairness" actually scales very well.

...

the whole "tit-for-tat" model isn't just fair on an individual scale, it's fair on a company scale, and it's fair on a global scale.

From Linus (https://www.bbc.com/news/technology-18419231)

It's not a moral obligation it's just the price I want people to pay to use the software that I/we write. I don't want monitary compensation, but I do want people to return the favour and give back the newly created code that has benefited from my/our code. If someone isn't willing to enter into that agreement, that is fine, they are under no moral obligation. They can put the work in themselves and create it themselves if they don't want to play by those rules. Nothing stopping them, and I wish them well. But don't use my/our code if they can't/won't pay the price for that code.

People have all sorts of licensing conditions on code, "only 5 users", my conditions are, take it, do what you like, have the source code even, but if you build on it, return the favour I/we have extended to you.

Acknowledgment is not sufficient, returning the favour is tit for tat. Returning the favour is fair.

If what they're building is orders of magnitude better than what we have, then that's fine if they don't want to give it away then don't enter the tit for tat agreement, don't use my/our code in that code base.

[Matthew-Jennings]

Okay, I think I'm catching what you're throwing.

The fairness point is... fair(ish - we can discuss why I say "ish" another time maybe)! But it is a nice model. I do agree with that.

I just don't think it's a practical model for pymedphys. I think I got carried away above, but the crux of my argument really is this:

"I am not the sole owner of the IP I generate at work"

Which raises the question:

"Am I allowed to use this code (at work, in work projects, etc.)?"

I'm concerned that, strictly, for code under AGPLv3, the answer to that question for most physicists is "no".

Even if I have no intention to sell pymedphys code or any other code I write that includes it, I do not have the legal right to remove that possibility from my employer. Nor any other developers, for that matter. And so the default, safe action is just to avoid using pymedphys code altogether and opt for alternatives or write my own.

It avoids a rigmarole of removing/replacing pymedphys code in the event my employer or other collaborators (or myself, since things can change with time) wish not to comply with AGPLv3. It could be rather drawn-out depending on how big and convoluted things get, and rather embarrassing since I would've basically forced AGPLv3 upon them (perhaps at their unawares) by using pymedphys code.

None of that is an issue for the MIT or other, more permissive licenses. It might all might sound ridiculous, but it basically boils down to my rights and responsibilities as an employee.

---

I know you have a vision of creating an open, collaborative development community within the international medical physics community, and a high-quality platform to support it. As you know, I have outlined that that is a secondary priority of mine, for reasons that I won't put here for the sake of brevity. But it is a priority. I do see it. I think we could broaden our ways of achieving it, but I do see it. And I really think the single most important things to achieve that are:

• visibility. Look at this cool thing I can use and contribute to! Heaps of other people are using it!
• quality. Look how well it's written. This is much better than what I could bash together by myself. It'd be great to be a part of this!

I believe that enforcing restrictions like "if you use this code, anything you share on top of it MUST be free and open-source" are in opposition to those two points. It's a (in my opinion, strong) disincentive to use the code. This decreases visibility and, by extension, quality. It detracts from your vision, it doesn't support it.

[SimonBiggs]

Even if I have no intention to sell pymedphys code or any other code I write that includes it, I do not have the legal right to remove that possibility from my employer. Nor any other developers, for that matter. And so the default, safe action is just to avoid using pymedphys code altogether and opt for alternatives or write my own.

It avoids a rigmarole of removing/replacing pymedphys code in the event my employer or other collaborators (or myself, since things can change with time) wish not to comply with AGPLv3. It could be rather drawn-out depending on how big and convoluted things get, and rather embarrassing since I would've basically forced AGPLv3 upon them (perhaps at their unawares) by using pymedphys code.

Let's say I/we refuse to budge on this, you could go to your employer and say, "I could spend about 40+ hours of work time recreating what is in this library here. But this person is providing it for free. They only have one condition, they have this 'tit for tat' clause. They say they gave us code for free, therefore any code we write that uses it, they want us to give back as free in the same way."

"Would you rather I spend 40+ hours recreating the work they've done, or are you okay with accepting their 'tit for tat' conditions?"

That way you're upfront, honest, and those decisions aren't presumed for them. I imagine the answer could go either way, but nevertheless the question is worth asking. I also wouldn't be surprised if it took one - two years to get an answer. But we're playing the long game here, and I want to play it right.

[SimonBiggs]

@msobolewski you probably need to be pinged on this discussion (given you and Cancer Care Associates are also copyright holders of significant portions of this code base). My opinions here aren't the only factors to be considered.

[SimonBiggs]

@kingrpaul you also have stake in this also, your opinions are welcome and valued.

[Matthew-Jennings]

Let's say I/we refuse to budge on this, you could go to your employer and say, "I could spend about 40+ hours of work time recreating what is in this library here. But this person is providing it for free. They only have one condition, they have this 'tit for tat' clause. They say they gave us code for free, therefore any code we write that uses it, they want us to give back as free in the same way."

"Would you rather I spend 40+ hours recreating the work they've done, or are you okay with accepting their 'tit for tat' conditions?"

You seem to be in the happy and rare situation that you have direct access to your employer/IP decision maker. In contrast, there are several degrees of separation between my employer and I, and my situation is a common one. I could be waiting several weeks just to have such a meeting, much less get an affirmative answer. Even then, an employer like yours that is close to the ground and can easily see the context and infer the benefits is more likely to answer in the affirmative.

Then there still remains the point that you will turn away users that are unhappy with AGPLv3. In my estimation, this is a majority of potential users that you seem to be just dismissing as unimportant. I think it is extremely important. I think it is a very poor trade off, even for you and your employer. I think AGPLv3 compliance poses a huge challenge to the visibility and marketability of pymedphys. I think this severely hampers your own vision (and probably that of your employer's). If marketing and visibility is what your institution wants to gain, maximising users is the answer. AGPLv3 benefits no employer, not even your own. As for you personally, if a thriving community is what you want to build, visibility, familiarity and quality are above all else.

I'm claiming that you and your employer will benefit from a net greater number of contributions by having a completely permissive license, because you'll get more users. I think it is a strong claim.

Faced with the limiting nature of the AGPLv3 license, its easy for a user to dismiss the resource. Faced with an open license, the user has no reason to dismiss the resource. Sure the user might not share freely back at that time, but they will become enmeshed, invested in pymedphys. This is really the key to get contributors. It's the golden ticket. They'll have read the docs, API, copied the code, maybe cloned the repo. They'll become familiar with pymedphys. And with that familiarity, they may contribute later. They'll more clearly see the benefits. They'll have clearer motivation to negotiate with their employer to provide open source material.

[Matthew-Jennings]

The trade-off of "40+ hours of work time" vs. "Can never profit from this" is a pretty uncompelling argument to an employer, by the way.

You're not just asking for free contributions given back to you. You're asking that for everyone. (Therein lies unfairness)

[kingrpaul]

I have been following this discussion, but cursorily. I do want to see pymedphys broadly open-source and have an interest in a growing contributor base (did a new member just join?) and the ultimate success and prestige of the project. You two seem to have the potential for institutional conflict that I do not believe I have; and more knowledge of, and stake in, the license details. I do not expect this project to lead to direct financial reward, though I wouldn't object if it did. I am keen to avoid liability.

" Plus, I genuinely have faith that most people aren't complete asses ... "

   Agreed, very much evidence to the contrary, notwithstanding.

"I think we should have strong cause to deviate from this apparent consensus."

This seems sensible, from where I sit. Without a good understanding, don't do what's atypical.

Side Note:
I would like to have a conversation, at some point, about "gamma analysis" as an approach. It has, at times, seemed to me that we, as a profession, are perhaps not doing this as well as it might be done.

[SimonBiggs]

@Centrus007 I think this one is worth a phone chat with @msobolewski and myself. Let us know when is a good time 😄 .

[Matthew-Jennings]

@SimonBiggs & @msobolewski, sounds good to me :D

I'm relatively free next week. Any time on Monday or Tuesday would be fine. Wednesday-Friday would need to dodge a few meetings, but are otherwise okay as well.

As a prelude, I think it's important for me to say that I do not believe this is a deal breaker for me personally. I know I've pushed pretty hard, but that's because I think it's a mistake generally. I think it's a dealbreaker for others (in fact this issue was triggered by conversations with colleagues). And I believe that is a highly undesirable outcome that is not worth the trade-off with the benefits AGPLv3 may provide.

But I do think rational minds can disagree on this depending on goals, priorities and perspectives on subjective points.

[kingrpaul]

Side Note: I know an engineer who has recently developed and is marketing a water tank beam scanner. There was talk of putting some GUI in front of pymedphys. If pymedphys were to complement this beam scanner, and if I were to suggest including it alongside the beam scanner's software, would the existing license prevent him from doing that?

[SimonBiggs]

@kingrpaul it certainly would not prevent him from doing that at all. But, when the scanner is released the user would need to have provided to them, maybe within the installation directory, the source code for both the version of pymedphys that was used as well as the source code for the beam scanner sofware, + instructions on how to build and install the source code.

So, the current license would require that the beam scanner software would also be required to be released open source. This would mean that not only would the users get a some nice hardware, they would also have access to the full source code for the software that runs it.

I know I'd be keen to have a beam scanner where the software that ran it was transparent. It would be quite awesome to be able to submit bug fixes to GitHub for my beam scanner :).

[SimonBiggs]

Any GUI would also need a note that declares the underlying software used, and the license that it is under. And there should be a note of where to find the source code.

These notes might sit quite nicely in and About > Licenses menu item.

[SimonBiggs]

Also, the consequence for not obeying the license is that, that person would be using our copyrighted work. It would be up to us to pursue the violation.

Personally, I would as much as possible not have it go to court, ideally never enter a court room ever. The idea would be to say, "here are the issues with your implementation, may you please fix it", if someone didn't want to comply then I would ask that remove the AGPLed code. If they didn't want to do that either, then that's when legality would be used.

So, please don't be worried about an honest mistake when trying to be compliant to the license.

Note, this stance that I outlined above is also held by the creators of the license. Their stance is along the lines of all license compliance work should go into helping code authors come into compliance either by correctly licensing their own code, or by removing the AGPLed code and not undergoing litigation of any kind.

[kingrpaul]

Probably better just to ask for the file format.

[SimonBiggs]

File format?

[kingrpaul]

Ask for the beam scanner file storage format, for simple import and export.

[SimonBiggs]

To partially allay concerns, here are a few examples of code bases that are under GPL copyleft licenses:

• Android
• Git
• PyQt and Qt
• Linux (and therefore many pieces of hardware such as the OS running the router that would connect your hospital to the internet, and possibly a not small portion of your Linac)
• MySQL
• Postgres
• MongoDB
• Notepad++
• GIMP
• FIJI (medical imaging ImageJ bundle)
• Orthanc
• EGSnrc
• R-Shiny

Using these libraries is certainly not illegal. And using them is certainly not rare in hospitals all around the world.

[kingrpaul]

Newly-installed Tomotherapy IDMS plan review workstation arrived with a 108-page license notification (to cover all the combinations) for open source software provided on the system, including Notepad++.

[Matthew-Jennings]

To partially allay concerns, here are a few examples of code bases that are under GPL copyleft licenses:

Fair enough. Although, with few exceptions (like PyQt), almost all of those examples are what I'd call "apps" rather than "libraries". They're far more targeted at "users" rather than "developers".

PyMedPhys, at least in its current form, is only targeted at developers. We have precious few (if any) CLIs or GUIs.*

Using these libraries is certainly not illegal. And using them is certainly not rare in hospitals all around the world.

I wonder about that. Is distributing a GUI built using PyQt illegal? What counts as "building on top of x-copyleft-project"? There could be many non-compliant institutions unaware of their non-compliance...

*Another "problem" I'd like to "fix", by the way ;P

[SimonBiggs]

PyQt is quite an exception to that rule though. I'll see if I can find a few more libraries. The gcc compiler is one I can think of off the top of the head.

…

On Wed., 6 Feb. 2019, 9:12 pm Matt Jennings ***@***.*** wrote: To partially allay concerns, here are a few examples of code bases that are under GPL copyleft licenses: Fair enough. Although, with few exceptions, almost all of those examples are what I'd call "apps" rather than "libraries". They're far more targeted at "users" rather than "developers". PyMedPhys, at least in its current form, *is only targeted at developers*. We have precious few (if any) CLIs or GUIs.* *Another "problem" I'd like to "fix", by the way ;P — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGQVe1bZaVyWDbbz8m0fCBoRXMTfWXfUks5vKqqRgaJpZM4aba4F> .

[SimonBiggs]

WordPress and Drupal are essentially "website creation libraries" they're
both GPL.

Other libraries/platforms:

• Ansible
• Deep Mind's lab -- https://github.com/deepmind/lab
• ggplot -- https://github.com/tidyverse/ggplot2

And I'm sure there's heaps more. And certainly for every GPL one there will
be a permissive one also, but the key here is that people make
libraries/platforms as GPL too. It certainly is not going against some
common wisdom or consensus.

Anyway :)

[SimonBiggs]

Here is one of the impacts of the WordPress platform being GPL, it forces all PHP WordPress derived themes to also be under that license. More information:

https://wordpress.org/news/2009/07/themes-are-gpl-too/

And here are two marketplaces where people make not small amounts of money selling these GPL themes:

• https://wordpress.org/themes/commercial/
• https://themeforest.net/collections/3516382-100-gpl-wordpress-themes

One such theme has been sold 100 000 times, it also has an advertised price of $59:

https://themeforest.net/item/jupiter-multipurpose-responsive-theme/5177775

[SimonBiggs]

I wonder about that. Is distributing a GUI built using PyQt illegal?

Not abiding by PyQt's licensing conditions when distributing code would be a copyright violation.

... it's certainly not illegal if you do abide by the license conditions.

[Matthew-Jennings]

Not abiding by PyQt's licensing conditions when distributing code would be a copyright violation.

... it's certainly not illegal if you do abide by the license conditions.

Well, sure, that's basically tautological. My question was: does distributing GUIs built using the PyQt library without the corresponding source code count as a breach of the licence conditions? I haven't read them, but if it's copyleft, I'd suspect so. If so, I suspect there would be very many copyright violations of PyQt5 through either:

• sheer unawareness of the licence conditions (we're not all lawyers, and it's not so crazy for one to assume that "freely visible code" is "freely distributable code (in non source code form)".
• the more sinister case: people knowingly take the risk and recognising that the risk of getting caught is very low.

[SimonBiggs]

Regarding PyQt here is Riverbank's take on it, if that is helpful:

https://www.riverbankcomputing.com/commercial/license-faq

[SimonBiggs]

Here is Oracle's take on releasing MySQL under a GPL license:

https://www.mysql.com/about/legal/licensing/oem/

Something of interest is their answer to question 5:

https://www.mysql.com/about/legal/licensing/oem/#5

They use the GPL, but they do slightly adjust it in a permissive way which makes using the library simpler:

https://oss.oracle.com/licenses/universal-foss-exception/

I hadn't heard of this before. I haven't yet thought through / researched the implementations of including an exception like that to simplify things...

[Matthew-Jennings]

I think I'm satisfied that AGPLv3 is the way to go (at least for now).

I think we can close this.

Though I think it is important that we determine (and then include in the docs) as clearly as possible exactly what counts as extension of PyMedPhys and what doesn't under copyleft. This is covered under #73

[SimonBiggs]

I think I'm satisfied that AGPLv3 is the way to go

Okay! :) thanks Matt

(at least for now).

Makes sense :).