-----BEGIN PGP SIGNED MESSAGE-----
Well, I think this type of license defies the general idea of an Open Source
License. A single supplier open source license would be a closed license with
source handed to the customer (mostly under a non-disclosure term).
A single supplier open source license simply is no open source, since nobody
could benefit from the source - thus it's not "open". Is it even legally ok
to read code licensed like this ? It might influence the implementation of a
What is the idea behind handing source to anybody where the source may not be
used in any way ? The only benefit I can see would be under a special
agreement to the customer in case the "single supplier" goes out of business.
Then the customer could be granted rights to develop/use the product on an
ongoing basis for his business. But this is nothing that needs an open source
license - it just needs an agreement with the customer (and handing out the
source of course)
Also - if it's not acceptable for a developer to work on a software product
that is open source, then don't. But please also tell those developers to not
use any open source tools/languages/operating systems - since it might be
unacceptable for the community to give anything to those developers.....
Although nobody really requires you to contribute to any open source project -
it is considered nice and fair to return some of the favors by contributing
back (at least a little contribution, error testing, whatever - nobody asks
you to do full time development on that project)
You could still open source part of the project and keep the rest closed. For
example reportlab (reportlab.com) used this scheme quite successfully: The
open sourced the pdf generating library, but didn't open the XML description
language and parser which uses the library. Doing so promotes their product -
everyone can play with the library, but if you need it in large scale you
most likely go back to reportlab and buy the addon's and services.
On Sunday 25 January 2004 03:10 pm, Richard Schilling wrote:
> 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
> 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
> > 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 -----
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
Open Source Solutions 4U, LLC 2570 Fleetwood Drive
Phone: +1 650 872 2425 San Bruno, CA 94066
Cell: +1 650 302 2405 United States
Fax: +1 650 872 2417
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
-----END PGP SIGNATURE-----
In response to
pgsql-general by date
|Next:||From: Shachar Shemesh||Date: 2004-01-26 00:20:16|
|Subject: Re: Fwd: Re: [Ossi] New Open Source License: Single Supplier|
|Previous:||From: Richard Schilling||Date: 2004-01-25 23:10:40|
|Subject: Fwd: Re: [Ossi] New Open Source License: Single Supplier Open Source License|