PDA

View Full Version : Official Open Src License Thread (Commercial License Part 2)



jack.slocum
14 Feb 2007, 1:10 PM
Hi Everyone,

I'm sorry for the delay on my response to your questions. This has been a very difficult decision for me because there are a lot of things to consider. On one hand, I love the community building around Ext and I have to love the work else I wouldn't be doing it day in/day out. :) On the flipside I have a family to support, 2 kids and with another due in early May. Savings can only last so long, and I am nearing that point. So I have to make a decision, and that is what the other thread (http://www.yui-ext.com/forum/viewtopic.php?t=2676) was for.

I do believe Ext could go to a commercial license and I'm sure plenty of people would buy licenses, and in the end there could be financial relief in that direction. If financial reward was what I was after, this would be a much easier decision.

I want this to work for everyone, so here is what I came up with.

- Ext continues to be open source, with a LGPL license. This allows for continued use in open source projects and free usage for everyone who wants use it (even commercial).

- For those companies that do need/want a commercial license, I will add an optional CDL license similar to the one offered by FCKEditor (http://www.fckeditor.net/license/commercial). The pricing will be similar. A CDL license will include 1/yr support.

- Introduce Ext Premium - $399/yr personal email support, premium support forum, priority bug fixes and SVN access (new up-to-date, organized SVN)

-Introduce a new method of sponsoring features. Input on this is appreciated. You are the people using it, what structure would enable you to sponsor new features?

- An enterprise support option. I will have more details on this soon. PortraitPainter was nice enough to volunteer to help guide me on getting this set up.

I understand everyone can't contribute financially. That's ok. There's other ways you can contribute. Take the Wiki, tutorials and examples. This is an area where I can use help. Robert Graff (rgraff) is putting together a team to help with it, please send him a PM and join. You can also just write something up and email it to me.

Best Regards to everyone and thank you for all your help in making such an important, and very difficult decision.

mmcmahon
14 Feb 2007, 1:40 PM
Sounds great Jack. It may sound odd, but if you could have a feature where we could generate a quote and voluntarily bump up the price (price + donation), I think a number of us would willingly get a P.O./cheque to you in excess of that $399 price as circumstances allow. I think the valuation would be somewhat variable in that way (above the $399 price of course), but I would have to be able to present a quote without the word 'donationl' on it. I wouldn't mind an additional "fair-pay" option for a quality product like yours.

PuritysDisciple
14 Feb 2007, 1:46 PM
Jack strikes again! Great news Jack!

jack.slocum
14 Feb 2007, 1:53 PM
mmcmahon, the current PayPal button now allows you to input any price and specifically avoids the word "Donation" for that reason. I can also send an "official" invoice if that makes it easier to get approved. :)

rmesser
14 Feb 2007, 2:58 PM
Sounds good Jack, I think you'll get a lot of takers both for the support deals and for other non-monetary contributions. In a prior post on the other thread I said I'd rather pay $2500 for support for a product with an open source license instead of $1299 for support for a non open source product, so next week when the new Ext comes out I'll put my money where my mouth is and put that through.

As far your question about how people can sponsor features -- I'd say just create a simple "sponsorship estimate request" form that people complete. Then you could reply with an opinion on feasibility and an estimate of how much it would take to create that feature (both in time and sponsorship money). Your time is very valuable and you don't want to get inundated with wacky feature requests, so you might also consider charging people some amount to investigate each request. If they aren't willing to pay then they can submit to the regular "feature request" forum but that would come with no guarantee of a response.

In any event thanks and I'll look forward to the new release.

griffiti93
14 Feb 2007, 3:02 PM
First class all the way, Jack!

Herm
14 Feb 2007, 3:43 PM
Extellent... :D

ilazarte
14 Feb 2007, 4:17 PM
Sounds like a winner Jack, congratulations :)

dfenwick
14 Feb 2007, 4:23 PM
Excellent news. I appreciate you weighing all the options.

MrKurt
14 Feb 2007, 6:46 PM
I've always been a fan of "bounties" for features, and a transparent system that talks about what's being considered. It would need to be moderated, but let users submit feature requests and put "donations" toward them.

I could imagine it working like this: I want a Task panel developed, and I'm willing to pay $300 for it. I'd submit it, go ahead and pay 10% or so up front (to keep me honest), then when it's chosen I'd get invoiced for the rest. If someone else happens to want the same thing, they could add $x of their own to the "bid".

You'd need to set a very clear set of expectations for people paying into this. For instance, bounties should probably be non-refundable if the feature is considered and scheduled for development.

The advantage to you is that I can throw $50 or $60 in on a feature that I don't really want to pay the full cost of development on, and when someone decides to spend $1k to get something built, my money just adds on to theirs. :) The advantage to me is that I can have some influence on new features without footing the entire bill for most of them.

MrKurt
14 Feb 2007, 6:50 PM
On the licensing itself, I'd suggest offering some kind of SLA to people who pay for license that sets some standard for turnaround on confirmed bugs. Companies get the warm fuzzies when they feel like they can get bug fixes in a hurry. You seem to fix them fast enough to pull something like that off.

manugoel2003
14 Feb 2007, 10:40 PM
Respect!!! I find the new plan very well thought out, and I respect your efforts to consider everyone's situation, which is not easy at all, but you always seem to find a solution that suits all.

If I understand it right we can use the full library (including the widgets and all) for free, even if our product is commercial, right? We can purchase phone and email support, but the current forum will be free to all and there will be another premium forum for people who purchase a premium account..... if this is so then it is just perfect.... I was just being asked to start searching for some other OS library of widgets which we can use, now I can happily tell them not to wander anywhere else, Jack's got everything worked out :D


The advantage to you is that I can throw $50 or $60 in on a feature that I don't really want to pay the full cost of development on, and when someone decides to spend $1k to get something built, my money just adds on to theirs. :) The advantage to me is that I can have some influence on new features without footing the entire bill for most of them.
I like this idea, coz we may be able to pool some money into an ongoing feature development rather than paying the full cost of development

mnugter
15 Feb 2007, 12:12 AM
This is a really great option. Now I can also keep using it privately. I will make a donation every time I use your library and make a profit :) Still waiting on my current project to get payed, when that's in, money for you too Jack :)

As for using it at work, I will just tell my boss a license is absolutely mandatory :)

gordon
15 Feb 2007, 1:00 AM
Nicely done Jack.

Gordon

San
15 Feb 2007, 1:11 AM
Hi Everyone,
- Introduce Ext Premium - $399/yr personal email support, premium support forum, priority bug fixes and SVN access (new up-to-date, organized SVN)



My 2c:

Charge enterprise customers more and don't lock/delay SVN

re: enterprise

Make an enterprise premium support contract that's a few $k or more with a 12/mo renewable contract. Most old school enterprises (wall st/chicago/etc) require support contracts for internal purchases. Making support contracts based on size of the company is aok. You're just trying to fly under the radar whatever is the budget approval price for each group (a few k can usually be signed for directly out of their allocated budget).

re: svn

I'm not sure if you mean the regular SVN is going to be 'stale' in some way. If SVN isn't live and up to date, you're going to kill the community of budding contributors. You always want more folks getting involved and in the flow. Again, think about encouraging a team of 150 contributors. SVN's appeal is that it's a vibrant place of life and chaos - let everyone who wants to add value join in.

re: other funding routes to explore

Dojo has a Foundation model where companies pay in to keep Dojo alive. This might be something to explore.

And thinking about it, have you had a chance to chat with the Yahoo folks? I'll bet sitting down with Yahoo might land revenue in your pocket (or a job working remotely if you'd like one), and perhaps enough to keep Ext free. I can probably find someone at the big Y's strategy group to talk to if you don't have a contact already.

dfenwick
15 Feb 2007, 1:38 AM
My 2c:

Charge enterprise customers more and don't lock/delay SVN

.
.
.

And thinking about it, have you had a chance to chat with the Yahoo folks? I'll bet sitting down with Yahoo might land revenue in your pocket (or a job working remotely if you'd like one), and perhaps enough to keep Ext free. I can probably find someone at the big Y's strategy group to talk to if you don't have a contact already.

From my experience, most enterprise customers don't really want the latest and greatest, particularly if they're a wall street kind of firm. They want stability. I agree with you about SVN access for developers. It needs to be read-only until a developer has proven they can adhere to the coding guidelines and produce something that doesn't crash the build. There are a lot of large development companies that don't allow their own employees access to the code tree until they feel the employee is ready to commit changes. This can take up to 6 months in some places. Oh, and having broken a build tree in the past for a large nameless company, I can attest to the fact that people DO get pretty nasty about it.

On the job front, I think Jack has recently accepted at least a participation role, if not a job role, with RSS Pieces. News story at http://www.rsspieces.com/2006/12/04/rss-pieces-welcomes-jack-slocum

jack.slocum
15 Feb 2007, 3:09 AM
Herm -
Can I trademark that? ;)

rmesser -
As for the support, just let me know if there is anyway I can help. :)

rmesser and MrKurt
I like both suggestions. Natural Docs has the "bounties" for features and it seems to do ok. The request for a quote is nice too, as I think it will fit better in corporate environments.

MrKurt -
Is there anywhere you you can point me to an SLA that looks reasonable to adopt/derive from? I have no problem commiting to a response time (obviously time-to-patch depends on the bug).

Manu-
Yes, yes, yes and yes. :)

San -
I haven't come up with the enterprise support agreement yet. There will be one though. If you have any specific ideas please share.

I'm not sure if you mean the regular SVN is going to be 'stale' in some way.

SVN access will be for Ext Premium and hosted on the Ext website (not google code). For those who can't afford the Premium, contributors (docs, tutorials, forums, website - in any way) will also get access.

The SVN acess will continue to be read-only for now. There are a few people with write-access, and they have been helping with things like documentation and CSS sprites. I still prefer most core code to go through me as it keep the code clean (1 code style) and gives me a chance to put it through the ringers. :)

dfenwick -
I've never even heard of RSS pieces. :shock: I will have to send them an email and find out what is up with that.

jack.slocum
15 Feb 2007, 3:13 AM
Ah, I know who they are. I discussed doing some short-term consulting with the founder a while back but it never happened.

n.karthikeyan
15 Feb 2007, 9:38 AM
Great News Jack. Thanks for doing this

MrKurt
15 Feb 2007, 9:49 AM
You should probably be careful about letting people contribute code/images/whatever that will fall under your dual license, unless you have some sort of agreement (ie: I release all this IP to Jack Slocum, Inc) that gives you completely control over it. Dealing with community contributions on code that can be sold under closed licenses can be a real pain in the ass.

All you need is some disgruntled contributor to start making legal noise down the road to scare licensees off.

As far as the SLA goes, I know I've seen one or two related ones before, but I can't find one at the moment. I'll keep digging and see what I come up with.

The thing about SLAs is they're largely pretty useless, and the reparations they guaranty aren't ever going to be enough to make up for the potential problems something could cause. The important part is that one exists for a developer to wave around in front of management.

I'd probably structure it in a couple of different sections. The first would cover promised response times to support and bug requests. For people who pay enough, you might want to ensure that they get a response to just about anything within a few hours, for instance. It wouldn't necessarily have to be you responding, just some kind of response. The second would cover actual bug fixes and patch delivery. It could be a little vague and say "in most instances, bug fixes will be delivered within 5 business days. Some issues might require longer blocks of time, and you will be informed right away if that's the case". The third part should cover reparations, namely what happens if a bug causes actual problems. Generally this would involve a refund of some of the yearly maintenance fee, although it's rarely enough to matter.

You don't necessarily need to have anything written by a lawyer, although for peace of mind you might want to run whatever it is by one. The thing about contracts, though, is that as long as they're relatively clear and understandable, they'll hold up. That means the fewer exceptions and special cases, the better. If it's short and talks about a few specific things, there's less room for interpretation and less problems.

Damn I talk a lot.

mwarden
15 Feb 2007, 10:52 AM
You should probably be careful about letting people contribute code/images/whatever that will fall under your dual license, unless you have some sort of agreement (ie: I release all this IP to Jack Slocum, Inc) that gives you completely control over it. Dealing with community contributions on code that can be sold under closed licenses can be a real pain in the ass.

That's a good point. I also briefly wondered whether there would be any issue with using the YUI name for commercial purposes.

I would think not, but I'm not sure.

justheatingup
16 Feb 2007, 6:49 PM
Jack, I suggest contacting someone at the Apache foundation for some guidance. You can reach jim @ www.jimjag.com He's a great guy and would be an asset to you.

tedHusted
23 Feb 2007, 9:06 AM
Jack, I suggest contacting someone at the Apache foundation for some guidance. You can reach jim @ www.jimjag.com He's a great guy and would be an asset to you.

I'm not Jim Jagielski, but I am an ASF Member.

As to IP contributions, the ASF is careful to obtain a Contributors Licence Agreement from every comitter or major contributor to document an individual's intent to contribute code or documentation. The Dojo Foundation does the same thing. It's not unusual for large corporations to review the code and actually ask if we have CLAs from all the contributors.

Not having a clear providence to the code can cause problems later. I know teams that would like to change their license, but don't feel that they can, because there were many early contributions from individuals who can no longer be contacted. (Don't think that's a problem here, yet.)

One side effect of choosing the LGPL is that the various ASF web application frameworks, like Struts, and Wicket, and Tapestry, will not be able to bake YUI-EXT into our distributions. (We've been trying to obtain permission to use Hibernate with ASF projects for years, but the LGPL blocks us from doing so.) Right now, both Struts and Tapestry utilize Dojo behind our own tags. Of course, that doesn't prevent developers from using YUI or YUI-EXT with their own applications.

For my day job, we're still evaluating both YUI/YUI-EXT and Dojo. I can still use YUI-EXT with my day job, regardless, but I won't be able to apply any YUI-EXT knowledge to my work with Apache Struts.

-Ted.

Joche
1 Mar 2007, 7:13 PM
Ok, without being a lawyer and without having english as my first language I'm off on the licensing details. I bet someone will compile a license FAQ sooner or later, but until then I'm in the need of an answer on this very specific question:

We have plans on using the latest YUI-EXT or Ext or whatever the version 1.0 is named on a clients intranet. This will be a closed application used at the clients side, we can't give the code back to any community.

In relation to the situation above:
a) Can we do this at all?
b) What license must our software use?
c) How much should we pay for the Ext library?
d) Is this sum (in c) relevant for all instances where we use the Ext library, or do we need a license per server/client/user?[/i]

stekolla
26 Mar 2007, 11:35 AM
I have a question regarding a license issue that I had not noticed until this morning.

The copy of license.txt that is distributed with all of the Ext 1.0 Alpha versions contains the following portion.



The JavaScript code distributed with Ext is licensed under an LGPL open source
license version 2.1.

http://www.gnu.org/licenses/lgpl.html


However, the source files do not reference this license document. They reference http://www.extjs.com/license.txt, which contains the following portion.



The JavaScript code distributed with Ext is licensed under an LGPL open source
license version 2.1 with the one modification below titled "PROHIBITED USES".

http://www.gnu.org/licenses/lgpl.html

PROHIBITED USES
You may not, without prior written consent, redistribute
the Software or Modifications other than including its parts or as a whole
into your own product, which must have substantially different functionality
than the Software or Modifications and must not allow any third party to use
the included parts of the Software or Modifications for the software
development purposes. You are explicitly not allowed redistributing the
Software or Modifications as part of the product, which can be described as a
development toolkit or library and which is intended for use by software
developers and not end-users. You are not allowed to redistribute any part of
the Software documentation.
You may not: a) use any part of the Software or Modifications or your
knowledge of the Software to create a product with the same or substantially
the same functionality as the Software; b) transfer, rent, lease, or
sublicense the Software or Modifications; c) change or remove the copyright
notice from any of the files included into the original Software or
Modifications.


Therefore, my main question is which version is it supposed to be?

The latter version seems to completely go against the LGPL, restricting redistribution and modification of the library, so I'm hoping that this is an oversight and that it should be as the former is.

KimH
28 Mar 2007, 2:00 AM
Hi Jack,

I can't find head or tail of all the threads involving license questions... :?


- Ext continues to be open source, with a LGPL license. This allows for continued use in open source projects and free usage for everyone who wants use it (even commercial).

- For those companies that do need/want a commercial license, I will add an optional CDL license similar to the one offered by FCKEditor (http://www.fckeditor.net/license/commercial). The pricing will be similar. A CDL license will include 1/yr support.
I do not understand the first statement "... (even commercial)"... so can a commercial application be sold to a customer wichout paying license fees to Ext?

I guess .... and hope .... that all the unanswered questions will be put in crystal clear text on April 1st.... :wink:


- Introduce Ext Premium - $399/yr personal email support, premium support forum, priority bug fixes and SVN access (new up-to-date, organized SVN)
I'm one of those really looking forward to this..... and the invoice :wink: which is required!

amackay11
2 Apr 2007, 12:08 PM
...
We have plans on using the latest YUI-EXT or Ext or whatever the version 1.0 is named on a clients intranet. This will be a closed application used at the clients side, we can't give the code back to any community.

In relation to the situation above:
a) Can we do this at all?
b) What license must our software use?
c) How much should we pay for the Ext library?
d) Is this sum (in c) relevant for all instances where we use the Ext library, or do we need a license per server/client/user? [/i]

My interpretation of the Ext Beta license is that unless you use Ext for educational, academic or for Open Source projects, a commercial license is required. I do some corporate intranet development in an office where 'Ajax' is considered a brand of detergent. My only hope of getting some money to buy toolkits/frameworks is if I can deliver an application or decent prototype and show what can be done. Since I need to pay for Ext up front, it looks like I'll have to invest my time in another toolkit :(

brian.moeskau
2 Apr 2007, 1:17 PM
Not sure where your interpretation came from. :-/


Ext is licensed under the terms of the Open Source LGPL license. You may want to use our open source license if you:

* Want to use Ext in an open source project that precludes using non-open source software
* Plan to use Ext in a personal, educational or non-profit manner
* Are using Ext in a commercial application, the LGPL works for you and you do not wish to support the project


Wouldn't your situation be covered under the third bullet? As long as you adhere to the terms of the LGPL, you can use it in an intranet no problem.

JeffHowden
2 Apr 2007, 1:37 PM
My interpretation of the Ext Beta license is that unless you use Ext for educational, academic or for Open Source projects, a commercial license is required.

May I suggest that maybe your interpretation of the license is not correct?


Since I need to pay for Ext up front, it looks like I'll have to invest my time in another toolkit :(

I don't think anybody is saying you have to pay for it upfront, especially if all you're doing is prototyping something.

amackay11
2 Apr 2007, 2:52 PM
May I suggest that maybe your interpretation of the license is not correct?


Yes you may! Sorry....I missed bullet three under Open Source on my first read. Thanks for clarifying. I hope to wow my boss and contribute some $$$.

ccustine
17 Apr 2007, 8:27 AM
Echoing what Ted Husted said above, no Apache projects (or ASL licensed projects) will be able to distribute this library, effectively ruling it out. I started a UI for an established Apache project using yui-ext but I will have to do something different because of the move to LGPL. Love this project, but I can't help but be dissappointed in the choice of LGPL as your open source license.

justheatingup
17 Apr 2007, 12:34 PM
I'm not Jim Jagielski, but I am an ASF Member.

As to IP contributions, the ASF is careful to obtain a Contributors Licence Agreement from every comitter or major contributor to document an individual's intent to contribute code or documentation. The Dojo Foundation does the same thing. It's not unusual for large corporations to review the code and actually ask if we have CLAs from all the contributors.

Not having a clear providence to the code can cause problems later. I know teams that would like to change their license, but don't feel that they can, because there were many early contributions from individuals who can no longer be contacted. (Don't think that's a problem here, yet.)

One side effect of choosing the LGPL is that the various ASF web application frameworks, like Struts, and Wicket, and Tapestry, will not be able to bake YUI-EXT into our distributions. (We've been trying to obtain permission to use Hibernate with ASF projects for years, but the LGPL blocks us from doing so.) Right now, both Struts and Tapestry utilize Dojo behind our own tags. Of course, that doesn't prevent developers from using YUI or YUI-EXT with their own applications.

For my day job, we're still evaluating both YUI/YUI-EXT and Dojo. I can still use YUI-EXT with my day job, regardless, but I won't be able to apply any YUI-EXT knowledge to my work with Apache Struts.

-Ted.

Can you elaborate a bit more as to the issues with Struts?

justheatingup
17 Apr 2007, 12:42 PM
Echoing what Ted Husted said above, no Apache projects (or ASL licensed projects) will be able to distribute this library, effectively ruling it out. I started a UI for an established Apache project using yui-ext but I will have to do something different because of the move to LGPL. Love this project, but I can't help but be dissappointed in the choice of LGPL as your open source license.

I think it was a very tough choice for them to make. Short of having a Apache/BSD type license, I think most will be content to see LGPL.

Wolfgang
19 Apr 2007, 6:23 AM
Echoing what Ted Husted said above, no Apache projects (or ASL licensed projects) will be able to distribute this library, effectively ruling it out. I started a UI for an established Apache project using yui-ext but I will have to do something different because of the move to LGPL. Love this project, but I can't help but be dissappointed in the choice of LGPL as your open source license.

Would that also be the case with a commercial EXT Licence?