Message inline: 1. LEGAL RESEARCH. On Wed, July 4, 2007 2:09 am, MJ Ray wrote:
"Thomas Dukleth" <kohadevel@agogme.com> 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