Re: [Koha-devel] copyright holder

[Thomas Dukleth]

Message inline:


1.  LEGAL RESEARCH.

On Wed, July 4, 2007 2:09 am, MJ Ray wrote:
> "Thomas Dukleth" <address@hidden> wrote: [...]
>> The hazard under United States copyright law is that any joint author
>> could relicense the work as a whole without consultation under any
>> license
>> with only the obligation to provide royalties to the other authors.
> This goes against what I've been told so often, so I hope you don't
> mind me getting a second opinion.

Please do obtain another opinion.  I could supply further references and
case law citations but maybe you want to find your own sources to be
certain of complete independence so that I will not have selected them for
you.  If you manage to find any US decision from recent decades which
contradicts the rule I identified, please be certain to Shepardize the
decision.

Remember that I make no particular claim about what category of multiple
author work Koha actually is.  I merely draw attention to some categories
which have problematic aspects.

2.  AGREEMENT.

I also trust Koha developers not to act without consultation and agreement
despite what might be allowed under US law.  However, given certain
problems under US law it is better to actually provide legal assurances as
well as actually acting respectfully of others.  This is a question of
being seen to act correctly in addition to acting correctly.

3.  COPYLEFT.

>
> [...]
>> The GPL frees us from worry about the derivative works problem as long
>> as
>> all dependencies allow licensing under the version of the GPL being used
>> in the project.
>>
>> Just released GPL 3 and AGPL 3 when it is released will allow even
>> broader
>> linking with software under other non-GPL licenses.  [...]
>
> This has the drawback of continuing the license soup.  In a way, I
> don't mind that, but I'm surprised that FSF are finally weakening the
> GPL's strong copyleft.  It's disappointing that it's weakened to allow
> the possible AGPL'ing of GPL'd software's output.
>

I do not interpret the FSF changes in GPL 3 as weakening the copyleft
nature of the GPL in comparison to GPL 2.

3.1.  FSF LICENSE DRAFT COMMENT SYSTEM.

I wish we could have discussed those issues in the GPL 3 comment system
where they would have informed the drafting of GPL 3.  Most people have
had problems with the FSF license draft comment system.  I have had my own
problems where I had to repost comments two times before the line breaks
would appear for a readable comment.  Sometimes I had to restart my web
browser to post any comment.  The XPath code also failed to highlight the
selected draft text for my last GPL 3 draft comment.

3.1.1.  AGPL 3 DISCUSSION.

I encourage you to take discussion of AGPL 3 at this time to the AGPL 3
draft comment system where it may inform the drafting of the AGPL.  The
current URL is http://gplv3.fsf.org/comment/agplv3-draft-1.html , however,
you should check to see if a new AGPL 3 discussiion draft has been
released.  AGPL 3 discussion draft 2, which has not been released yet,
should have reciprocal changes for section 13 paragraph 2 corresponding to
changes for section 13 from GPL 3 discussion draft 4 to the final released
text of GPL 3.

I recognise the problems of the FSF license drafts comment system but I
can help you work around them if you are willing to try.  Using Mozilla
based browsers; running the browser with JavaScript enabled by default;
restarting the browser before a comment session; avoiding successive blank
lines; and closing all double quotes before a blank line will help avoid
problems with the comment system in general and problems with line breaks
in particular.  If you still have problems, I could post your comments on
your behalf with your permission under my username  giving you attribution
or under another username giving you attribution.  I know that you have
valuable things to say about the issues which could lead to a better
license.

If you have trouble reading comments using the JavaScript comment system
or want a more reliable location for viewing comments, both parent and
child comments for AGPL discussion draft 1 appear in list form at
http://gplv3.fsf.org/comments/rt/readsay.html?Query=%20'CF.NoteUrl'%20LIKE%20'agplv3-draft-1'&Order=DESC
as they are posted.

If other means of commenting on the drafts do not work for you,
http://gplv3.fsf.org/comments/email.html has instructions for how to add
comments by email.  Child comments cannot be added by email which is a
significant limitation for using email.  Email comments may not appear
readily in the comment system either.

Discussion in terms of how to protect software freedom for all users while
minimising interference with software developer freedoms are most likely
to successfully influence FSF.  Certainly, other factors have a bearing on
what free software is created but are less likely to successfully
influence the FSF.

Every comment is read by Eben Moglen personally in addition to others at
FSF and associated working groups who read the comments and make further
recommendations.  The license drafts have changed in direct response to
comments in the comment system including my own.

The influence you would have over the drafting process by discussion on
the koha-devel list is minimal except to the extent that it may inform the
comments in the FSF license drafts comment system which others such as
myself make.

3.2.  NETWORK SERVICES.

>> I will have much more to say about the merits of GPL 3 and AGPL 3 for
>> both
>> users and developers at a later time.  [...]
>
> At that time, I will have much more to say about the drawbacks of
> applying licence terms to Koha's output in the way that AGPL does.  I
> feel that The Only Way drum is being banged a bit hard about this. In
> essence, if III or whoever wants to spend time studying and adapting
> Koha code (within the current copyleft terms) into their system, good
> luck to them.  While they're watching us, let's be watching the road
> ahead and blazing the trail, making the money!
>

I will qualify my presumption to "the only way I know" but I would be
pleased to know of others.  Any time I make a similarly narrow presumption
you should read it as being qualified as such by reasonable implication. 
In the distant past, I tended to explicitly qualify all my assertions,
however, such explicit qualifications obstructed the readability of
everything I wrote and made me seem indecisive when I was not indecisive.

I would also much prefer to spend my time developing code rather than
working on licensing issues.  I have raised some issues at this time
because related issues had already been raised by others in which I had
seen some mistaken understanding of copyright law.

3.2.1.  DISINTEGRATING THE ILS.

I actually want to encourage the disintegration of ILS modules to the
extent that it may be practical and useful.  Standardised data exchange
protocols could be used to communicate between modules.  Users should be
able to mix and match modules to use with whatever software suits
them.including proprietary software as long as the users freedom in free
software modules are preserved.

Paul Poulain and I have suggested elements of such disintegration
previously.  Opencataloger, a currently disintegrated record editor under
development, could be used as a possible example of such disintegration.

This suggestion does not give an advantage to proprietary software but
would allow libraries using proprietary software to use some parts of Koha
alongside their proprietary systems.  This may be analogous to how
GNU/Linux systems first gained a foothold in many corporate computing
environments as web servers and print servers.

3.2.2.  ALL USERS FREEDOMS VERSUS DEVELOPERS FREEDOMS.

The GPL is not generally concerned with allowing or protecting particular
business models. although, some business models have succeeded in the
context of the GPL and others have been disadvantaged in the market.  The
FSF goal is to protect all software users freedoms first and software
developers freedoms second.  I repeat that terms of argument which have
the most influence at FSF are how to best protect all users freedoms with
the minimum interference with developer freedoms.

However, FSF has compromised its principles in the GPL license slightly to
avoid a code fork by large business intersts.  Only interests opposed to
free software want to see a code fork of GPL software.  Certainly,
business factors are a significant in determining what free software is
developed.  In attempting to avoid a code fork over GPL software, FSF
hopes to serve the interest of all users better than if FSF had rigidly
held to its principles in all of the GPL 3 license terms.

I would like to confine my discussion of all users freedoms versus
developers freedoms to the FSF license drafts comment system as much as
possible at the current time.

In fairness to your assertion, I will address some business issues here
which I tend to avoid in discussions in the FSF license drafts comment
system.

3.2.3.  NETWORK SERVICES MARKETS.

At some future time, Koha is likely to include features which may interest
some well funded proprietary companies.  Within the supposed scope of
private modification, GPL software running on a network server may be
treated as if it is proprietary and combined with other proprietary code
to offer a network service to users.  Such a service would have no
obligations to respect the rights that the ultimate users or authors of
the GPL part would have had if the software had been conveyed for the
ultimate users to examine or run locally.  That may not be a problem for
you if you assert that it is not.

I do not necessarily have a concern about proprietary ILS software
companies.  My concern is about much larger organisations which have
monopolies or near monopolies in important markets.  The prospects of free
software gaining a sustaining base of users in some monopoly dominated
markets are generally proportionate to the distinctiveness of the features
the free software offers.

3.2.4.  USER TERMS OF EVALUATION.

Free software has succeeded in attracting large numbers of users mostly by
appealing to the terms under which users evaluate proprietary software. 
Users evaluate proprietary software in terms of marketing strength,
functionality, and cost.

Free software often fairs favourably in terms of features as compared to
proprietary software.  Features of free software may not be undeniably
better than comparable features of proprietary software. but free software
often has important features which are not available in proprietary
software.

In markets about which I am concerned, software running on a network
server often provides services to users without any direct charge for
offering the services.  Revenue for the primary no charge software
services in such a context usually comes from related incidental services
offered to all users.  In such markets, the primary services usually have
no charge and the incidental services have roughly comparable charges,
therefore, cost is not a significant differentiating factor for the users.
 New entrants offering network services in such markets have cost
disadvantages for offering their services to the users including lack of
the economies of scale for both the primary and incidental services which
the dominant monopolies have.

If organisations which have monopoly influence in some markets are able to
treat modified GPL software as if it is proprietary software merely by
operating services on a network server, then ultimate software users in
those markets are unlikely to obtain the benefits of free software as free
software.  In terms that most users understand how to value, there would
then be little differentiation between modified GPL software being
presented as proprietary and GPL software offered independently.  If
private modifications combine proprietary software with privately modified
GPL software all the features of both the proprietary and the GPL software
could be presented as proprietary to the ultimate users.  In terms that
most users understand how to value, the differentiation between modified
GPL software combined with proprietary software and presented as one
proprietary program and GPL software offered independently would be
adverse to GPL software.  If the GPL software offered independently has no
advantages which ultimate users recognise initially, then ultimate users
will not choose independently offered GPL software.  Ultimate users will
never learn to appreciate the other advantages of GPL software if they are
not first choosing GPL software in terms that they recognise.

3.2.4.1.  ULTIMATE USERS LOSE POTENTIAL FEATURES.

3.2.4.1.1.  DEFAULT MARKET CONDITIONS.

Consider a market dominated by three organisations offering their primary
services at no charge over a network server to ultimate users.  The
organisations derive revenue from related incidental services.

Organisation 1 includes features A, B, C, and D in its proprietary network
services.  Organisation 2 includes features A, B, C, and E in its
proprietary network services.  Organisation 3 includes features A, B, C,
and F in its proprietary network services.

Any of these proprietary features might be derivative works of GPL
software created as private modifications running on a network server with
no license obligations to the ultimate users of the software.  However, I
wish to identify another consequence in such a market.

3.2.4.1.2.  NEW ENTRANT.

New entrant organisation 4 includes features A, B, F, G, and H in its free
software network services for which it offers all source code to the
ultimate users over the network under the GPL license.  Organisation 4 has
insufficient capital for marketing to quickly attract a large base of
users but expects to attract more users over time and improve its existing
features while adding more features.

3.2.4.1.3.  MARKET CONDITIONS AFTER NEW ENTRANT.

The market dominating organisations may then adopt the features of
organisation 4 as modified derivative works combined with their other
features.  However, unlike organisation 4 the other organisations do not
inform the ultimate users that the organisations' software running over
the network for users is free software, do not provide any acknowledgement
to organisation 4, nor do they provide any access to the source code of
their modifications.  The market dominating organisations do not act any
differently than they had in the past with respect to GPL software.

Organisation 1 includes features A, B, C, D, and G in its proprietary
network services; but takes longer to develop feature G because it
develops feature G independently, using the model provided by organisation
4 but not as a derivative work of the organisation 4 source code. 
Organisation 2 includes features A, B, C, E, G, and H in its proprietary
network services. where features G and H are derivative works of
organisation 4 source code.  Organisation 3 includes features A, B, C, F,
G, and H in its proprietary network services, where features G and H are
derivative works of organisation 4 source code.  Organisation 4 includes
features A, B, G and H in its free software network services.

Organisation 4, as an undercapitalised new entrant in the market is unable
to obtain enough users to sustain development because it is no longer
offering any distinctive features to ultimate users.  Without users for
the primary services which are offered without charge, there will be few
users of the related incidental services from which revenue is derived. 
Organisation 4 would be unable to afford to improve its own existing
features A, B, G, and H and unable to take advantage of closed
modifications for features G and H made by the market dominating
organisations.  Organisation 4 would be unable to afford to develop
feature C and derive revenue from incidental services offered in relation
to feature C.  Organisation 4 would be unable to afford to develop planned
features I and J.

Ultimate users are unable to obtain the freedoms they would have had in
the GPL code if the modifications which organisations 2 and 3 made in
those features were conveyed.  Ultimate users may have options for
features A-H; however, they would not have improvements in those features
from organisation 4 nor additional features I and J.

3.2.4.1.4.  PRACTISES OF NEW ENTRANTS.

Conditions in many important markets are similar to the default conditions
which I described.  New entrants in such markets wishing to survive follow
the same closed proprietary code model of the other organisations
dominating the market.  Many of the organisations in such markets may
contribute something back to the GPL software projects from which they
create derivative works as proprietary private modifications which they
use to run network services for ultimate users.  However, such market
conditions discourage conveying high level business applications as free
software as distinct from lower level software underlying their high level
software.

A license which has an effect on modification in a network services
context may avoid the problems for free software in such markets.

3.2.5.  NEW FEATURES FOR KOHA.

I have an interest in the development of features which exist in no
library system and seldom exist in systems for other markets.  Such
features include support for semantic based browsing as distinct from
guessed searching without definite knowledge of the indexed terms.  My
interest is not necessarily in serving libraries directly but in the
ultimate users in other much larger information finding markets
independent of libraries.

I expect to be a good citizen of the Koha community and be able to
contribute high level code to Koha without the need to create a code
monopoly in order to sustain participating in those larger information
finding markets.  I hope to reduce the need to offer library support
services which do not scale as well as other more passive services, except
to the extent of supporting the work of others offering library support
services.

If at the time I introduce arguments in favour of some particular licenses
I fail to persuade everyone in the Koha community to change the Koha
license and there is no other solution available, I would then suffer the
inconvenience of committing code under a parallel license in parallel
files.  I hope at that time to either persuade successfully or to have
found another solution.

Please critique business issues here on the koha-devel list and take other
license related issues to the FSF license drafts comment system for the
present time.

4.  ASSIGNMENTS AND AUTHORS RIGHTS.

> [...]
>> The only way to resolve the problems of the category of multiple
>> authorship for software projects is to have copyright assignments to a
>> trusted entity with a grant back of rights for authors' own individual
>> contributions.
>
> It's The Only Way drum again :-( Couldn't we (for example) assign
> rights among ourselves by territory, with other cooperation
> agreements?  Not saying we will go that way, but Assign To Daddy
> doesn't seem the only obvious model.
>
> Also, I will check, but I thought most countries had unassignable
> rights which means that the authors will necessarily be involved in
> any copyright case anyway.
>

I will qualify my presumption as above.  Your suggestion is very
interesting and shows the kind of thinking we need to actually solve
problems.

Most countries do have unassignable rights or rights which survive
assignment.  Unfortunately, as I identified in my post; the US, UK, and NZ
reserve very little moral rights for software authors.  We should all hope
to have the moral rights for authors protected by legal systems more like
the French system.

> [...]

[...]

> It may be, but it is not yet one.  I would want to see Kohala have a
> form similar to a English Community Interest Company or secondary
> cooperative, so we know it can't trade in unfair competition with us
> on the reserves (our copyrights) which we'd give it.
>

My thoughts about assignment, which I am not yet ready to fully
articulate, include imposing a strict contract on the assignee limiting
the terms of assignment.  Such terms ought to reduce the risks in
assignment.

[...]

5.  OMISSIONS AND CORRECTIONS.

I apologise to those in Turkish, Argentine, and other legal systems which
I did not have time to include in my comparative analysis of copyright
law.  I would be pleased to include others at some future time and post
the document in some generally accessible and readable place, especially
if I have some assistance from others in obtaining English translations of
the relevant copyright laws.

I am always pleased to correct any errors of copyright law interpretation
I may have.


Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY  10003
USA
http://www.agogme.com
212-674-3783