Live data from Hacker News

Libxml2 Enterprise Edition (AGPL, from the previous maintainer)

codeberg.org

11–19 of 19 posts

Re: Libxml2 Enterprise Edition (AGPL, from the previous maintainer)

#11

> Sorry, we don't accept code contributions and direct you to the original libxml2 project. This has me puzzled to the point of being dumbfounded: If libxml2-ee has fixed many security and other flaws in libxml2, then what's the point of directing people back to a project that is relatively flawed? Licencing it as AGPL is also interesting, since the original was MIT, though I'm not sure they've worked out all of the…

Presumably, this is (or will be) dual-licensed to enterprise customers who want the bug fixes but don't want to publish their code in accordance with the AGPL. Dual-licensing is much simpler for the author if he doesn't accept contributions.

Re: Libxml2 Enterprise Edition (AGPL, from the previous maintainer)

#12

> Sorry, we don't accept code contributions and direct you to the original libxml2 project. This has me puzzled to the point of being dumbfounded: If libxml2-ee has fixed many security and other flaws in libxml2, then what's the point of directing people back to a project that is relatively flawed? Licencing it as AGPL is also interesting, since the original was MIT, though I'm not sure they've worked out all of the…

You can't just take an MIT/X11 licence, remove it, and relicense it as it's an explicit violation of the MIT/X11 licence. This however only applies to the original code, so any new addition can be under whatever licence you want, including a more restrictive one. That doesn't change your obligation to reproduce the previous copyright notice as instructed by the licence you got the code under

Correct, not many folks understand this.

Re: Libxml2 Enterprise Edition (AGPL, from the previous maintainer)

#13
post #3

Earlier quoted context omitted.

When has "enterprise edition" ever been the sign of parody projects?

I remember at least this one: https://github.com/Hello-World-EE/Java-Hello-World-Enterpris...

Since I've dealt with "EE" Java in a previous life, that's actually pretty tame as far as parodies go.

I hate the fact I can say that. :-/

Re: Libxml2 Enterprise Edition (AGPL, from the previous maintainer)

#14

> Sorry, we don't accept code contributions and direct you to the original libxml2 project. This has me puzzled to the point of being dumbfounded: If libxml2-ee has fixed many security and other flaws in libxml2, then what's the point of directing people back to a project that is relatively flawed? Licencing it as AGPL is also interesting, since the original was MIT, though I'm not sure they've worked out all of the…

You can't just take an MIT/X11 licence, remove it, and relicense it as it's an explicit violation of the MIT/X11 licence. This however only applies to the original code, so any new addition can be under whatever licence you want, including a more restrictive one. That doesn't change your obligation to reproduce the previous copyright notice as instructed by the licence you got the code under

In practice, how would you differentiate old code from new code when changes start to flow in?

Re: Libxml2 Enterprise Edition (AGPL, from the previous maintainer)

#15

> Sorry, we don't accept code contributions and direct you to the original libxml2 project. This has me puzzled to the point of being dumbfounded: If libxml2-ee has fixed many security and other flaws in libxml2, then what's the point of directing people back to a project that is relatively flawed? Licencing it as AGPL is also interesting, since the original was MIT, though I'm not sure they've worked out all of the…

You can't just take an MIT/X11 licence, remove it, and relicense it as it's an explicit violation of the MIT/X11 licence. This however only applies to the original code, so any new addition can be under whatever licence you want, including a more restrictive one. That doesn't change your obligation to reproduce the previous copyright notice as instructed by the licence you got the code under

I get what Nick is trying to do (allow F/OSS to continue receiving security fixes while requiring commercial users to pay), even forwarded his call for help or other support last year. I'm not sure though relicensing MIT code under AGPL is legally sound if your additions are just bug fixes.

Re: Libxml2 Enterprise Edition (AGPL, from the previous maintainer)

#16
post #14

Earlier quoted context omitted.

You can't just take an MIT/X11 licence, remove it, and relicense it as it's an explicit violation of the MIT/X11 licence. This however only applies to the original code, so any new addition can be under whatever licence you want, including a more restrictive one. That doesn't change your obligation to reproduce the previous copyright notice as instructed by the licence you got the code under

In practice, how would you differentiate old code from new code when changes start to flow in?

Everything after is AGPL unless stated otherwise.

Re: Libxml2 Enterprise Edition (AGPL, from the previous maintainer)

#17

Earlier quoted context omitted.

You can't just take an MIT/X11 licence, remove it, and relicense it as it's an explicit violation of the MIT/X11 licence. This however only applies to the original code, so any new addition can be under whatever licence you want, including a more restrictive one. That doesn't change your obligation to reproduce the previous copyright notice as instructed by the licence you got the code under

I get what Nick is trying to do (allow F/OSS to continue receiving security fixes while requiring commercial users to pay), even forwarded his call for help or other support last year. I'm not sure though relicensing MIT code under AGPL is legally sound if your additions are just bug fixes.

> I'm not sure though relicensing MIT code under AGPL is legally sound if your additions are just bug fixes.

It is: the original unmodified code is still MIT, but the bits you wrote and thus you hold the copyright for are AGPL. The combination of your bits + old bits is AGPL; some judge may argue your derived work isn't derived enough if you just change a few characters though. Still, I may argue that fixing a bug, no matter how trivial, requires you to perform a creative task, which almost definitely is by itself to be considered enough to go above the threshold required by a derived work.

Re: Libxml2 Enterprise Edition (AGPL, from the previous maintainer)

#19

Earlier quoted context omitted.

I get what Nick is trying to do (allow F/OSS to continue receiving security fixes while requiring commercial users to pay), even forwarded his call for help or other support last year. I'm not sure though relicensing MIT code under AGPL is legally sound if your additions are just bug fixes.

> I'm not sure though relicensing MIT code under AGPL is legally sound if your additions are just bug fixes. It is: the original unmodified code is still MIT, but the bits you wrote and thus you hold the copyright for are AGPL. The combination of your bits + old bits is AGPL; some judge may argue your derived work isn't derived enough if you just change a few characters though. Still, I may argue that fixing a bug, n…

It really doesn't matter until one tries to enforce an AGPL provision. If you do, that's where as you say will be arguments whether one added something substantial enough; basically the AGPL terms can really only be enforced on those additions.
Post reply on HN