Fwd: Re: [Ossi] New Open Source License: Single Supplier Open Source License

I'm forwarding this message onto this list because this is where the thread belongs.  I apologise for posting to the
activedevelopment list. 

----- Begin Forwarded Message -----
Date: 2004.01.25 14:27
Subject: Re: [Ossi] New Open Source License: Single Supplier Open Source License[rschi@rsmba.biz]
From: Richard Schilling <rschilling@nationalinformatics.net>


The purpose of the license is very simple.  It clarifies that the job of providing value-added, support, and other
servicesfor a software product is the job of the original developers and not others.  If the original developers want
totransfer that right then they can.  It's the original developers' job to provide service, training, support, custom
development,and value added services like web hosting using their product.  It is not acceptable in my view for a
softwaredeveloper to work on a software product just so some other company can try to make a living by running their
websitewith that software.  It is the responsibility, however, of the software developer to make sure that the
training,services, and value-added whatever are provided in a quality way.   

It is not the goal of this license to allow a high school student to use a developer's software product to earn money
byprogramming.  It's the goal of this license to ensure that my highly trained employees with MBAs and masters degrees
havea means to be paid for their time on a project, and to protect that means indefinitely. 


On 2004.01.25 11:05 Robert Munro wrote:
>
> A non-contractual software license rests on the rights of the copyright
> holder, but Open Source copyleft licenses operate by granting of rights
> not by imposing contract terms like submitting back changes and servicer
> restrictions, sole-source distribution requirements and control of code.
>

I think this is a source of confusion for many who read this license, Robert.  This license is not a copyleft license.
It'spermission a developer can give the end user to use his/her software while retaining the exclusive right to provide
servicesfor hire on the product.  The purpose of this license is to let the developer earn money for services.  Is it a
barrierfor other companies who want to provide services on that developer's product?  You bet. 


> Some features of the proposal are also unenforceable just as a matter of
> practicality.  If the users have the source code, how do you propose to
> restrict who will work on that?  Obviously you can't, not in real life.

Obviously if the product is distributed illegally but secretly there's no way to detect the violation.  Any seller of
bookshas this problem.  It's a question of what agreement you have in place when you finally do discover the problem,
andit's a question of making it publically and contractually clear what the developer wants. 


> In fact, such a servicer restriction (#4) would operate counter to users
> compliance with point #3, that "any" modifications have to be submitted
> back to the developer.  If a user has a non-approved programmer resolve
> a bug, do you actually expect them to admit it by submitting code back?

I would suggest that any potential contributor work directly with the initial developer to resolve any issues.  If the
developerreally wants help then he/she should be expected to allow the contributor to license their work in a similar
fashion. For example, if I write software under this license, and I need help, I am going to be able to offer some kind
ofliving wage to the contributor because I know that I am always going to be the primary source for services related to
theproduct.  Everyone on the development team gets paid. 

Can the project stall if no one wants to pay me and my contributors for our time?  Sure you bet - that's called a lack
ofdemand and it means we'll invest our time into something else. 

>
> Open Source users contribute code back to active projects because that's
> less work than reintegrating their local modifications after an upgrade,
> and for other reasons such as pride of authorship and genuine altruism.
> They also have security of knowing that a valuable Open Source software
> product likely won't disappear if the vendor company folds or otherwise
> ceases maintaining and improving the software.  The proposal kills this,
> in points #4 thru #6.  Those would also tend to cripple users incentive
> to contribute to the software, since they could not be assured continued
> access to the evolving product.  What happens if you go out of business?

If I go out of business I can transfer the rights of the license to someone else or sell them.  You're right, there is
adanger in having a product simply dissappear - the same problem we would have with cars if a particular car
manufacturerdissappeared.  We would not have that make of car available anymore.  But, I maintain that as long as the
originaldevelopment team can get paid for their time this is much less likely to happen. 

>
> These observations don't include the apparent conflict between points #4
> through #6 and #8 with #7, that all contributors retain their copyrights
> to their own code.  Your proposal would take away most of their rights,
> so it's a little disingenuous to claim that they'd somehow retain those.


Not at all.  You can retain copyright to your work and still negotiate a license for someone to use your work.  For
example,if a person wants to contribute something to my original work, I don't need his/her copyrights.  What I need is
permissionfrom that person to include their work.  And, of course the contributor would be wise to negotiate some kind
ofwage for his/her time in making the contribution. 

>
> Point #8 is simply unnecessary.  One of the major problems popular Open
> Source projects have is the overloading of main distribution servers at
> significant upgrades.  Unauthorized, corrupted mirrors are almost never
> encountered.  Users most typically have to be begged to use FTP mirrors.
>

Allowing a high school student to download my code, change it and put it on their server is not enough quality control
formy taste.  This point is ackward for many I know, but as we release products and people see the quality is there
thiswon't be an issue. 

> I'd respectfully suggest that you think about what you really want your
> alternative license to accomplish, what rights in copyright you control
> and can license (as opposed to specifying under software contract terms)
> to your users, and rely more on user incentives inherent in Open Source.
>
> Since the GPL permits dual-licensing, you might look into that approach.
>

Thanks for the suggestion - we do constantly review the existing licenses to determine what is best for our customers
andemployees.  Dual licensing under the GPL presents too many complications and expense for use to manage it
efficiently.

Richard Schilling




----- End Forwarded Message -----
----- End Forwarded Message -----