Google Groups

would-be copyright assignment in README.md is a barrier to entry to ERPNext


Bradley M. Kuhn Nov 19, 2013 12:33 PM
Posted in group: ERPNext Developer Forum
My employer recently started a project to build non-profit accounting
software for non-profit organizations (see
https://sfconservancy.org/campaign/ for details).  As a first phase of
this project, we're evaluating every Open Source and Free Software
accounting package we can find (see
http://npoacct.sfconservancy.org/ExistingProjects/ ).

Thus, while I note that this thread about ERPNext's copyright policy
ended back on July 17th, and my comments are coming very late, I only
looked in detail at this issue on last Friday, so I'm commenting on this
thread now.

My colleague and I were evaluating ERPNext, and we encountered this
policy found at:
     https://github.com/webnotes/erpnext#copyright-for-contributors
which reads:
>> Unless otherwise asserted in the code files, Web Notes will own the
>> copyright of all contributions too. That means Web Notes holds the
>> rights to change the license in the future or offer Commercial
>> Licenses.

This seems to me as if it's some sort of implicit CLA and/or ©AA, but a
unilateral statement of like this -- particularly one that doesn't
define what it means for something to be a "contribution" -- seems
unlikely to automatically "cause" someone to *assign* their copyrights
merely by failing to put a copyright notice on a file.  I'd suspect this
doesn't hold up under legal analysis.

I'd like to point out that this policy is problematic not only because
it may not be valid under copyright rules in most countries, but also
because the policy that it seeks to implement is IMO problematic for
various reasons.

The key issue is that it treats the community as unequal under the GPL.
The GPL is valuable because it creates equal rights for all in the
codebase.  However, if Web Notes reserves the rights to have more power
over the codebase than everyone else by reserving the right to
proprietary relicense, that policy creates community inequity.

Moreover, if Web Notes does fix the policy such that copyright
assignment for most contributions does become mandatory, any USA
501(c)(3) on-profit organization (like the one I work for) probably has
to avoid contributing upstream to the ERPNext codebase entirely, at
least for contributions where Web Notes makes copyright assignment
mandatory.

That's because a 501(c)(3) non-profit charity can't simply "give away"
assets like copyrights to a for-profit company, due to various rules by
the IRS in the USA.  Thus, it wouldn't be possible for potential
non-profit contributors like myself to contribute to the main codebase,
*even if* we wanted to give up our rights under GPL entirely (which we
don't want to do, in any event).

The options that leaves us is to fork ERPNext under GPL (which of course
we don't have the resources to do), or to look at other codebases that
we can participate in without copyright assignment.  We're likely to do
the latter at this point, but I wanted to raise this issue to (a)
possibly help clarify and correct this policy, and/or (b) to register
for the record that this policy was the reason we had to give up on
considering adoption of the ERPNext codebase.


Meanwhile, I noticed a few things in that thread back in July that I
thought it might be useful to comment on, also for the record.

Dale Scott said in July:
>>> 2. License. The key here is that the license is granted by the
>>> copyright owners. If the copyright owners are ambiguous, the license
>>> is ambiguous.

While the first sentence is correct, I don't see how it leads to the
conclusion in the second sentence.  I think the point Dale was perhaps
trying to make (which I *would* agree with) is that projects need to be
sure that all copyright holders have agreed to submit their changes
under the license of the project (in ERPNext's case, the GPL).
Ironically, the existing policy in README.md makes the situation *worse*
on this point (IMO), because that policy is tries to create a copyright
assignment agreement implicitly, based on ambiguous conditions.

Did you perhaps consider using something like Linux's DCO, wherein
developers add Signed-Off-By to their commits to indicate they have
permission to contribute the change under the license of the project?
That is a good way to deal with that ambiguity.

Meanwhile, on a semi-related issue, Rushabh wrote on July 13th:
> I personally like GPL, but in practice unless you are a big foundation
> there is nothing you can really do if someone violates the GPL and
> does not maintain the same license in the derivatives

I truly don't understand what Rushabh's point here.  Consistently, for a
decade and a half, I've been involved with and/or in charge of more GPL
enforcement than any other person on the planet in history.  I've never
worked anywhere "big" -- indeed, I've worked only for tiny non-profit
organizations for most of my career.  Thus, Rushabh's point is
completely incongruent with my direct, practical (, and quite
substantial) experience with GPL enforcement.  It's true that GPL
enforcement requires work, and it's often quite boring and tedious work,
but it's also not very difficult, either.

I wonder, given Rushabh's comment: did ERPNext have a GPL violation that
was unresolved?  Is there anything I can do to help on that?
--
   -- bkuhn