9 ms·

This is exciting. A compelling FOSS alternative to Atlassian Confluence was sorely needed. Mediawiki has some UX and RBAC challenges that makes it difficult to

This is exciting. A compelling FOSS alternative to Atlassian Confluence was sorely needed. Mediawiki has some UX and RBAC challenges that makes it difficult to scale to large organizations.

oneplane 6y ago
Since it's AGPL it will probably never end up in the same commercial use cases as Confluence does. Google has some motivations written down from their lawyer department: https://opensource.google/docs/using/agpl-policy/ https://opensource.google/docs/using/agpl-policy/ It boils down to 'not worth the risk, do not use'.
- bachmeier 6y ago
  That's not relevant for using wiki.js.
- edp 6y ago
  OT, as the sole copyright owner of a web application I wrote, can I license it under the AGPL for the general public, and license it under different terms for clients who would prefer not to use AGPL software (and possibly pay for it) ? is dual licensing allowed by the AGPL ?
  - tkfu 6y ago
    If you're the sole copyright owner, you can offer as many different licenses as you want, and no copyleft license can interfere with that.
  - dualscyther 6y ago
    Yes, you can licence it however you want because you are the copyright holder. See mongodb. IANAL. Licences are to restrict those who do not hold copyright.
    - teddyh 6y ago
      > Licences are to restrict those who do not hold copyright. On the contrary, licenses gives permission to those who do not hold copyright. Without any license, only the copyright holder has any rights to copy or modify the work in any way (except for fair use). A license gives permissions to non-copyright holders to do things which would otherwise be illegal under copyright law. A license can never restrict what anyone would otherwise be allowed to do, since it is not a contract.
  - bachmeier 6y ago
    That's not how licensing works. If you write the software, you can release it under any license(s) you want. The license states the terms under which you'll let others use the software.
    - edp 6y ago
      That's what I thought but wasn't sure. Thank you (and sibling comments) for your comment.
  - teddyh 6y ago
    Yes. But keep in mind that the copyright of any contributions you might get will be held by the author of that contribution, not by you. The contributor might license that contribution under the AGPL only, and thereby put a stop to your little scheme. You would have to either get a license from the contributor to your dual licensing scheme, or simply require all contributors to sign the copyright over to you, which is most commonly done in a so-called Contributor Licensing Agreement (CLA). However, CLAs are rightly disparaged for being unfair, in that it lets you, and only you, profit and monopolize what might become a community effort. A requirement of a CLA will most certainly discourage many, if not most, potential contributors from contributing.
    - edp 6y ago
      I knew about this, that's why I said "sole copyright owner". The goal is to put the code out there and restrict other from modifying it without publishing their changes to their users. But I want to keep the option of licensing it differently for specific (b2b) clients. It's a not a true open source / free software in spirit as I don't plan to accept outside contributions.
      - teddyh 6y ago
        You seem to be assuming that you are the only person who will ever contribute meaningfully to the software. But if, as you probably also hope, the software is widespead and successful, there will most probably arise at least one popular third-party extension/modification. And you will not be able to incorporate this addition into the product which you distribute to your b2b customers; this will make your version of the software inferior to the free version.
        Rotten194 6y ago
        The other option is that could simply pay community members some fair portion of the b2b revenue in exchange for signing the CLA. If you're the primary contributor, it's fair to take most of the revenue for yourself, but revenue sharing with major contributors from the community is also fair. Could be difficult tax-wise though? IDK.
- richrichardsson 6y ago
  Is the suggestion here that, say I was in the business of selling proprietary software, by running Wiki.js and making it accessible to the public that the copyleft license would then apply to my proprietary software?
  - dspillett 6y ago
    If you package it with your software, then that might be the case unless you had negotiated other licencing terms first. Simply hosting it with your information in would not have any such effect, but many commercial entities avoid anything xGPL just-in-case. In this case perhaps because they see a time that they might later want to package and distribute documentation that is in the wiki without converting it to something else first. There is an extra concern with AGPL that does not exist with GPL specifically because of its key difference. AGPL applies to hosting the software and making it available not just distributing a compiled form. Some interpret this as meaning that if it is hosted on the same server, or in the same site, as other software then that other software becomes AGPL licensed too. I doubt anyone would enforce this interpretation but the possibility is enough to put off those who create proprietary software. > making it accessible to the public that the copyleft license would then apply to my proprietary software? Not just the public. Anyone you give access to, so for non-public hosted proprietary software you could be beholden to giving them access to the code under the AGPL in situations where AGPL applies. This will be a complete blocked for many creators of proprietary, or other non-*GPL licensed, software. [if the above makes me sound against AGPL rest assured that I am not - I in fact might end up using it at least initially (at least until I decide upon which of the more proprietary-friendly options to use) for some near-future projects]
    - mushufasa 6y ago
      So for complete clarification: If I hosted a wiki.js, say on a subdomain, unrelated to a commercial application's code at all, but lined to it (e.g. the "docs" section of navigation) would I need to disclose a) the source code of the wiki.js subdomain only, and any modifications we make to it b) the source code of wiki.js and the other proprietary app BOTH ?
omegote 6y ago
"Some"? The fact that you have to manually access the database backend in order to change a password is a joke, among many.
- kemayo 6y ago
  There's a bunch of ways which don't involve manual database access? https://www.mediawiki.org/wiki/Manual:Resetting_passwords https://www.mediawiki.org/wiki/Manual:Resetting_passwords
- bawolff 6y ago
  If its your own password you can change from the web interface. If it is someone else's password you can send a password reset email from the web interface. To actually set someone else's password to a specific value does require running a command line script (not the same as going into db). In my view that is a reasonable security-convinence trade off. In any case, i would assume a large org would use a single-sign-on extension and not mediawiki's native user management, which would make MW's password management moot. Disclaimer: am mediawiki developer
ta20200710 6y ago
> large organizations Interestingly Amazon just finished a multi-year effort to migrate off MediaWiki internally to comply with an infosec mandate that PHP is banned company wide.
- mekster 6y ago
  Why is PHP banned?
- antoineMoPa 6y ago
  Source?
  - spurgu 6y ago
    Quick search gives me an HN comment from 2014, without any sources either... https://news.ycombinator.com/item?id=7440811 https://news.ycombinator.com/item?id=7440811

This is exciting. A compelling FOSS alternative to Atlassian Confluence was sorely needed. Mediawiki has some UX and RBAC challenges that makes it difficult to scale to large organizations.

oneplane 6y ago

Since it's AGPL it will probably never end up in the same commercial use cases as Confluence does. Google has some motivations written down from their lawyer department: https://opensource.google/docs/using/agpl-policy/ https://opensource.google/docs/using/agpl-policy/ It boils down to 'not worth the risk, do not use'.

bachmeier 6y ago
That's not relevant for using wiki.js.
edp 6y ago
OT, as the sole copyright owner of a web application I wrote, can I license it under the AGPL for the general public, and license it under different terms for clients who would prefer not to use AGPL software (and possibly pay for it) ? is dual licensing allowed by the AGPL ?
- tkfu 6y ago
  If you're the sole copyright owner, you can offer as many different licenses as you want, and no copyleft license can interfere with that.
- dualscyther 6y ago
  Yes, you can licence it however you want because you are the copyright holder. See mongodb. IANAL. Licences are to restrict those who do not hold copyright.
  - teddyh 6y ago
    > Licences are to restrict those who do not hold copyright. On the contrary, licenses gives permission to those who do not hold copyright. Without any license, only the copyright holder has any rights to copy or modify the work in any way (except for fair use). A license gives permissions to non-copyright holders to do things which would otherwise be illegal under copyright law. A license can never restrict what anyone would otherwise be allowed to do, since it is not a contract.
- bachmeier 6y ago
  That's not how licensing works. If you write the software, you can release it under any license(s) you want. The license states the terms under which you'll let others use the software.
  - edp 6y ago
    That's what I thought but wasn't sure. Thank you (and sibling comments) for your comment.
- teddyh 6y ago
  Yes. But keep in mind that the copyright of any contributions you might get will be held by the author of that contribution, not by you. The contributor might license that contribution under the AGPL only, and thereby put a stop to your little scheme. You would have to either get a license from the contributor to your dual licensing scheme, or simply require all contributors to sign the copyright over to you, which is most commonly done in a so-called Contributor Licensing Agreement (CLA). However, CLAs are rightly disparaged for being unfair, in that it lets you, and only you, profit and monopolize what might become a community effort. A requirement of a CLA will most certainly discourage many, if not most, potential contributors from contributing.
  - edp 6y ago
    I knew about this, that's why I said "sole copyright owner". The goal is to put the code out there and restrict other from modifying it without publishing their changes to their users. But I want to keep the option of licensing it differently for specific (b2b) clients. It's a not a true open source / free software in spirit as I don't plan to accept outside contributions.
    - teddyh 6y ago
      You seem to be assuming that you are the only person who will ever contribute meaningfully to the software. But if, as you probably also hope, the software is widespead and successful, there will most probably arise at least one popular third-party extension/modification. And you will not be able to incorporate this addition into the product which you distribute to your b2b customers; this will make your version of the software inferior to the free version.
      - Rotten194 6y ago
        The other option is that could simply pay community members some fair portion of the b2b revenue in exchange for signing the CLA. If you're the primary contributor, it's fair to take most of the revenue for yourself, but revenue sharing with major contributors from the community is also fair. Could be difficult tax-wise though? IDK.
richrichardsson 6y ago
Is the suggestion here that, say I was in the business of selling proprietary software, by running Wiki.js and making it accessible to the public that the copyleft license would then apply to my proprietary software?
- dspillett 6y ago
  If you package it with your software, then that might be the case unless you had negotiated other licencing terms first. Simply hosting it with your information in would not have any such effect, but many commercial entities avoid anything xGPL just-in-case. In this case perhaps because they see a time that they might later want to package and distribute documentation that is in the wiki without converting it to something else first. There is an extra concern with AGPL that does not exist with GPL specifically because of its key difference. AGPL applies to hosting the software and making it available not just distributing a compiled form. Some interpret this as meaning that if it is hosted on the same server, or in the same site, as other software then that other software becomes AGPL licensed too. I doubt anyone would enforce this interpretation but the possibility is enough to put off those who create proprietary software. > making it accessible to the public that the copyleft license would then apply to my proprietary software? Not just the public. Anyone you give access to, so for non-public hosted proprietary software you could be beholden to giving them access to the code under the AGPL in situations where AGPL applies. This will be a complete blocked for many creators of proprietary, or other non-*GPL licensed, software. [if the above makes me sound against AGPL rest assured that I am not - I in fact might end up using it at least initially (at least until I decide upon which of the more proprietary-friendly options to use) for some near-future projects]
  - mushufasa 6y ago
    So for complete clarification: If I hosted a wiki.js, say on a subdomain, unrelated to a commercial application's code at all, but lined to it (e.g. the "docs" section of navigation) would I need to disclose a) the source code of the wiki.js subdomain only, and any modifications we make to it b) the source code of wiki.js and the other proprietary app BOTH ?

omegote 6y ago

"Some"? The fact that you have to manually access the database backend in order to change a password is a joke, among many.

kemayo 6y ago
There's a bunch of ways which don't involve manual database access? https://www.mediawiki.org/wiki/Manual:Resetting_passwords https://www.mediawiki.org/wiki/Manual:Resetting_passwords
bawolff 6y ago
If its your own password you can change from the web interface. If it is someone else's password you can send a password reset email from the web interface. To actually set someone else's password to a specific value does require running a command line script (not the same as going into db). In my view that is a reasonable security-convinence trade off. In any case, i would assume a large org would use a single-sign-on extension and not mediawiki's native user management, which would make MW's password management moot. Disclaimer: am mediawiki developer

ta20200710 6y ago

> large organizations Interestingly Amazon just finished a multi-year effort to migrate off MediaWiki internally to comply with an infosec mandate that PHP is banned company wide.

mekster 6y ago
Why is PHP banned?
antoineMoPa 6y ago
Source?
- spurgu 6y ago
  Quick search gives me an HN comment from 2014, without any sources either... https://news.ycombinator.com/item?id=7440811 https://news.ycombinator.com/item?id=7440811