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 active development list.

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

The purpose of the license is very simple. It clarifies that the job of providing value-added, support, and other services for a software product is the job of the original developers and not others. If the original developers want to transfer 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 software developer to work on a software product just so some other company can try to make a living by running their website with 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 by programming. It's the goal of this license to ensure that my highly trained employees with MBAs and masters degrees have a 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's permission a developer can give the end user to use his/her software while retaining the exclusive right to provide services for hire on the product. The purpose of this license is to let the developer earn money for services. Is it a barrier for 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 books has this problem. It's a question of what agreement you have in place when you finally do discover the problem, and it'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 developer really 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 of living wage to the contributor because I know that I am always going to be the primary source for services related to the product. 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 of demand 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 a danger in having a product simply dissappear - the same problem we would have with cars if a particular car manufacturer dissappeared. We would not have that make of car available anymore. But, I maintain that as long as the original development 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 permission from that person to include their work. And, of course the contributor would be wise to negotiate some kind of wage 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 for my taste. This point is ackward for many I know, but as we release products and people see the quality is there this won'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 and employees. 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 -----