Tags:
create new tag
, view all tags
Below discussions started in OpenSourceDistributionVsForkModel.

-- PeterThoeny - 12 Dec 2003

I am currently developing products at work which use open source software. The GPL is a huge pain. It really prohibits development. The best way to grow a user base and a developer base is to allow complete freedom of the codebase, and GPL really limits that. Companies just do not want to work on GPL code, and for good reason. (Why spend R&D dollars when the product must be given away?)

I've always felt on the fence about the GPL, but confronting these issues at work on a daily basis really drives it home.

Anyway, I vote for this: change the example plugin license to be BSD. I even feel funny writing plugins, because I want the code to be freely usable. That means usable in commercial products, too. I don't mind if someone uses my unbilled-effort in a commercial product--I already billed the time (as free!).

I did change the license on one of my plugins to bsd (I think it was the quick calendar plugin). However, it's not right to delete the current GPL from the example plugin and replace it with the bsd license. That is why I suggest that core do this in the distribution.

-- JonathanCline - 10 Dec 2003

Jonathan - why do you have a problem with supplying code to whomever you supply the product to? ina commercial sense this is much better for the paying customer - they can fix / extend it anytime they like. and its soo my cheaper then putting th source in escrow. Similarly, if your company pays for the deveopment, and uses it inhouse only, they don't need to pass on the code to anyone.. another fine thing.

  • I believe any business book should explain why. Look under 'barrier to entry'. Are you telling me you would spend $1,500,000 of your own money to fund a small team of highly paid professionals for a year and then give away their effort? Go ahead and try it, you'll learn, like the dot coms did. -- JonathanCline - 11 Dec 2003

I still think you missunderstand the GPL. If you spend $1,500,000 to fund an inhouse team to produce software, and then sell it as small shrink wrap software, then GPL would be a possible problem. But as most software is written on a contract basis for one customer, who generally wants the source in return for paying your company money, GPL is a non-issue. The only people who you have to give the source to are the ones who have paid for it anyway.

this "Barrier to entry' is a general missunderstanding of the way that software works. people seem to think that the best way to make money off software is to sell shrinkwrap, but this is a very small, difficult area of the market. selling integration, customisation or even programming services is generally more effective.

  • Most software is not written for one customer. The key to return on software is writing it once and then re-using it. You can not guarantee those returns if you write it and give away the product. The other day I browsed over to see the author of rzsz is still selling his code (on a low-cost buyout model currently). This is revenue which he will retire on. He worked hard to implement this code and develop the protocols it uses and now he can be rewarded for his work. I won't argue this further, except to say that by giving a product away, you are destroying new development effort, not encouraging it. R&D will not be spent without the possibility of return. There are many, many software businesses which spend initial R&D and then thrive on the product for ten years or more on the same software or only minor, low cost upgrades to it (ever hear of Hughes? Raytheon? IBM?) -- JonathanCline - 12 Dec 2003

  • And this is where you've chosen some really bad examples. most of the software that the 3 intergration firms that you listed have sold were customisations with source. thats why EDS and other big contractors (which those 3 are) can come in and do the maintainence contracts on them. The stuff you are refering to is the smallest portion of the market - most of us work on customisations and integration for those that are convinced that their needs are special, and they get the source as part of the contract. These things are not talked about in the same way as OS's and similar things..... The governement contracts are the same - they want something they see as special and are willing to pay for us integrators to write them code and supply it.
-- SvenDowideit - 12 Dec 2003

I (as a business) would only spend $1,500,000 on software if i knew that it would generate some large multiple of that in revinues. in which case the license would not be an issue, time to market would be.

  • I think you are forgetting, in the hype of techie world, that the majority of customers do not adopt a product until years into it's lifetime. That means by focusing your revenue model to claim the time-to-market crowd, you are missing the other 85-95% of the paying customers. That's unfortunate. -- JonathanCline - 12 Dec 2003

-- SvenDowideit - 10 Dec 2003

I can certainly understand concerns with the GPL; moving the core TWiki code away from this would be very difficult (given so many people hold Copyright). I would think we could release the Plugin example under more than one license, but does this could get very confusing; having said that the example is really just showing you how to use the API so there's not really much of an issue. Given the author owns the copyright to the Plugin I would think you could release under whatever license you like. You could put all you code in a file that is called from a file derived from the Plugin if you want to be really clear. I know there are restrictions of how you can join to GPL code, given the TWiki "library" (core) code is under GPL (not LGPL), is it legal to call from non-GPL code?

-- JohnTalintyre - 10 Dec 2003

Linus just wrote about this in response to a similar q on KernelModules - so long as the code in the module is not mostly dependant on the module interface, it can be argued as not being derivative. some of our simpler plugings would be considered dervatice workes, but if you seperate out your funtionality, and then activate it from the PluginsAPI that could be licensed differently. (yes - the author would need to make an effort for this to be ok though)

-- SvenDowideit - 10 Dec 2003

"I can certainly understand concerns with the GPL; moving the core TWiki code away from this would be very difficult (given so many people hold Copyright)."

I fail to see the validity of this. If changing the license is a priority, it only takes a couple months to get everyone's buy-in. Thus, that is no barrier to changing the license.

-- JonathanCline - 12 Dec 2003

I don't actually think chaning the license is a priority, although I accept there are concerns. I'm not so sure that getting everyone's buy-in is so easy; you only need one person to say no and you can't do it. A similar point is made at http://www.gnu.org/licenses/gpl-faq.html#AssignCopyright, although this refers to legal enforcement rather than changing the license.

-- JohnTalintyre - 12 Dec 2003

Just one minor point. A company I used to work for has draconian rules about releasing IP, that include jumping through the eyes of needles and orbiting remote stars before you can get permission to release anything. In addition, their standard employment contract means that anything developed by an employee at any time during their employment is the property of the company, and subject to those rules. This means that if there is the faintest sniff of profit from something developed by an employee, or risk to the company name if it doesn't work, the company will clamp down and make it impossible to release. And "guilty until proven innocent" is the standard modus operandi.

Because TWiki is GPL, it is easy to argue that it is in the terms of the license that anything you release built on TWiki / to work with TWiki has to be free. As long as you make the usual statements about uselessness for purpose and no warranty, the lawyers quickly lose interest. If TWiki were not GPL, it would be much harder.

-- CrawfordCurrie - 12 Dec 2003

Currie, that's an interesting angle I hadn't thought of.

-- JohnTalintyre - 12 Dec 2003

Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r5 - 2003-12-12 - JohnTalintyre
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.