Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Asserting Rights as Granted Under AGPL Section 7 #1
I've consulted with Richard Stallman of the FSF and GNU Project, original architect of the GPL family of licenses. Initially, I was merely alerting him that your use of the AGPL was doing his licenses and his work a grave disservice.
However, he has pointed out that the AGPL explicitly permits the wholesale removal of additional license terms that are not compatible with the AGPL. He explicitly suggested that I simply remove those terms. I have revised the license, and in this fork I have removed those conflicting terms, according to that right which you granted when you licensed under the GPL.
The terms which I removed are:
I now implore you to do the same to the master repository. I am happy to offer a pull request to that effect, but I will not sign a contributor license agreement for my edits, if any are relevant.
You do not need to shackle your customers to extract money from them. Just offer a valuable service and make your service worth paying for. The AGPL is an excellent commercial license; if you can't think of anything else valuable to offer, then at the very least, many customers will pay for alternative licensing. But, I expect you are both intelligent enough to offer more than that. :)
I'd like to thank you for providing this license, because PDF manipulation was a much-needed addition to Go's list of superpowers. I don't currently see that I will use it, but I'm glad to have it available to the Go community.
Actionable things I would like us to discuss:
PS: I will CC the above to Richard Stallman, as he has taken an interest in this and wishes to be kept appraised of it. However, he will not take part in this discussion on a platform such as Github!
Thanks for your insightful analysis of our licensing model. You have many good points, but some which we do not agree with and warrant some discussion.
1. Commercial / noncommercial use
We agree that this should be changed. Any work which open sources the code and releases to the community can use the AGPL licensed UniDoc library as per the AGPL license (no matter whether commercial or not).
Secondly, you listed
I am not sure what you are referring to... Are you referring to the following?
I would like to point out that there are examples of other software with a similar clause, see for example http://stackoverflow.com/questions/36351302/itextsharp-net-pdf-unable-to-change-pdf-producer
We are clearly not trying to assert any copyrights on the PDFs or document content that is outputted, simply that the Producer line that is outputted by our library is not modified or removed.
3. Indemnification of FoxyUtils for breaches of copyright / license terms by the immediate developer ..
I am afraid I don't quite understand what the problem with this is. According to Section 7(a) the limiting liability disclaimer can be different than Sections 15 or 16.
Would be great if you can clarify that!
Regarding the naming, I think that is entirely up to you and I am sure will depend on what kind of additions and modifications you are planning to make.
We look forward to see what you will be developing and adding to UniDoc. We have plans to add more features to it and are working on the next version. We would definitely love to see some community driven efforts. We clearly don't expect developers to give their work up for free and if there is mutual interest we would look at collaborations or potentially purchasing the rights to code for inclusion in UniDoc.
Note that we have updated the license, hopefully making it more clear:
Hi @gunnsth - I'm glad to see the "noncommercial" part removed and clarified to mean "AGPL unless you buy a nonfree license". That means, as intended by the AGPL, that commercial users can continue to use the code provided they abide by the terms of the AGPL. If the meaning of your original license terms was unclear, then I'm sorry for misunderstanding.
Thankfully the revised terms only appear to contain one of the areas I consider inappropriate (and incompatible with the AGPL: that a watermark be incorporated into final PDFs. While you would be welcome, under the AGPL, to include code to this effect, the AGPL makes it clear that you cannot prevent users or coders from removing this "feature" as they desire it. For my part, if I used Unidoc to build a thing and credit would not be a problem for the final product, then I would see little need to remove a watermark from the PDF metadata, for example; but the AGPL makes it clear that I cannot be forced to incorporate a watermark in this way, upon files produced by the software.
What the AGPL does tentatively allow for is the requirement that certain notices be retained in the source code, for example attributing the original AGPL-licensed source code to you. Indeed, for legal reasons it's pretty important that the copyright owners be logged and credited, so that they can be requested to stand up for their work later if a court case arises. So, under the AGPL, you would be fully entitled (as I understand it, and IANAL) to require incorporation of copyright attribution notices in the Unidoc source tree. But this provision of the AGPL would not entitle you to attach attributions to files that you did not possess the copyright to, namely the products of Unidoc.
I hope the above makes sense; it's late here. And, thank you for engaging in this discussion. I believe that this was a misunderstanding, and I'm glad to see that Unidoc is indeed open source in spirit and not only in license.
We are happy to make the license more clear, hopefully it will help and encourage people to use UniDoc. Thank you for initiating the discussion, it is clear that it was needed.
Regarding the "Producer" line or "watermark" as you call it: It appears to me to be in a grey area. I am by no means a lawyer, but I think some precedence has been set with similar effect. The Java PDF library iText for example has this kind of a requirement in their license under 7(b).
After some consideration, we think that having this additional requirement is not a good idea, especially if for example one fork changes its name, or version, it makes no sense to require the Producer line to be always the same. The original intention was to ensure that UniDoc would get its credit and that others could not pretend to be using their own work. But of course I think the AGPL itself handles that for us and requires such users to disclose their source code where there should be a reference to UniDoc as well.
As a result, we are planning to remove this clause and will be updating the LICENSE shortly.
Would be happy to hear your comments on this.
Sorry for the big time-lag, the last two weeks have been an odyssey of various illnesses in my immediate family.
Re-reading the new license files, I feel that they are now within the normal bounds of AGPL licensing, and I'm really happy to see you folks turning around a positive change like this in so little time. Thank you sincerely.
Also, glad to see the issues tab being activated on Github!
I feel that unidoc is a project I can advocate to others now, and one that I'm more comfortable using for my own projects, also.