1
jerryj
Re: Commisioned Modules
  • 2005/2/14 14:46

  • jerryj

  • Just popping in

  • Posts: 33

  • Since: 2001/12/20


Herko:

It wasn't my intent to discredit your experts, but just to remind you to always consider the source.

Unfortunately, I can see I'm not getting anywhere with this. You guys are only shooting yourselves in the foot with this interpretation. There are developers out there who would love to develop and sell commercial XOOPS modules, but will not because of how you have interpreted the GPL regarding interpreted languages (I of course read your whole post--3 or 4 times, actually).

I've considered starting up a company to develop and market commercial-grade XOOPS modules to the community at a reasonable price (i.e., $25-$100) and provide (1) ongoing support, (2) maintenance releases that coincide with XOOPS releases, and (3) upgrades with major XOOPS releases. But obviously with this stance, I can't do that.

Xoops is a great security, user, and content management framework on which commercial application developers could develop whole larger-scale applications, but that is not happening right now because of the GPL interpretation for modules.

So, that's all I have to say. Am I alone in my thinking here? Does anyone else agree with me?



2
jerryj
Re: Commisioned Modules
  • 2005/2/11 5:24

  • jerryj

  • Just popping in

  • Posts: 33

  • Since: 2001/12/20


Hi Mithrandir:

You misread my post. I said that XOOPS modules DO have to have the XOOPS core to run, in much the same way Linux applications have to have the Linux kernel to run.



3
jerryj
Re: Commisioned Modules
  • 2005/2/9 21:28

  • jerryj

  • Just popping in

  • Posts: 33

  • Since: 2001/12/20


Hey Herko:

I know you've done research on this and you've reveiwed this issue with some "experts" in the field. My guess is that your experts are individuals like yourselvs who have a "free software" world view that predisposes them to interpret this portion of the GNU license in such a restrictive manner.

I think your mistake is misinterpreting the term "module" on the GPL license to be equivalent to XOOPS modules. When in reality, what they're calling a "module" would be equivalent to a "library", "include", or "hack" in XOOPS (or most other CMS's).

I mentioned Mambo in my previous post. They have an FAQ item on their website here that specifically addresses this question. See question #10 on the link.

They also have a thread in their forum that talks about this very topic regarding Mambo you can visit by clicking here.

If you create a XOOPS module and then distribute XOOPS and the module together, then the module must be released as GPL. However, if the module is released and distributed separately and installed into XOOPS by the user, it is not subject to GPL and can be released under a commercial license. Here is an excerpt from the GPL preamble:

Quote:
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.


If you look at discussions regarding this "module" clause in the GPL, it usually centers around such items as linked libraries and derivative works. The spirit of the GPL is to make sure that derivative works from a GPL'ed piece of code are also GPL. Hacking the XOOPS core and reselling the hacked XOOPS core definitely IS a violation of the GPL license. However, XOOPS modules are NOT derivative works because they do not include the XOOPS core files, and have to have the Xooops core system to run. I know that's hard to understand and at first sounds contradictory, but think of XOOPS as a "website operating system". Modules are independent programs that use website operating system calls to accomplish their work, in much the same way as Linux programs make calls to the Linux kernel.

By your way of thinking, Herko, every program that runs on Linux would have to also be GPL because it can't run independently of Linux (Xoops) and makes calls to the Linux kernel (Xoops core).



4
jerryj
Re: Commisioned Modules
  • 2005/2/8 14:40

  • jerryj

  • Just popping in

  • Posts: 33

  • Since: 2001/12/20


I'm sure glad you guys have so many lawyers among you, otherwise people wouldn't be so confused.

Please read the following two points regarding the GNU Public License:

1.) If you develop a module for XOOPS or any other Open Source CMS, you ABSOLUTELY can charge for it.

2.) Further, you can license the module SEPARATELY from the Open Source CMS and protect your intellectual property. In other words, you do not have to allow other people to distribute your module for free as MadFish has incorrectly suggested.


What you cannot do is release the module and the GPL programs as one package and charge for the package.

If you want to see this model in action, go look at Mambo, http://www.mamboserver.com. Mambo is another excellent Open Source CMS licensed under GNU. It has SEVERAL third-party developers that develop and release commercial grade modules for that CMS and charge fees for them and offer upgrades and support. One of the most popular is Phil Taylor at http://www.phil-taylor.com .

PLEASE stop saying modules developed for XOOPS cannot be subject to intellectual property protection, because that is NOT TRUE.



5
jerryj
Re: Can this be done for Xoops?
  • 2004/1/15 15:52

  • jerryj

  • Just popping in

  • Posts: 33

  • Since: 2001/12/20


You guys should integrate this schedule or something simliar into the XOOPS core.



6
jerryj
Re: Is their any newsletter module in XOOPS ?
  • 2004/1/13 15:35

  • jerryj

  • Just popping in

  • Posts: 33

  • Since: 2001/12/20


Has the core development team considered adding module hooks for a newsletter much the same way as they have for searching?

For example, you currently have a search hook so that any module can be searched by the core XOOPS search function if the module developer codes to the hook.

In the same way, you should develop a "new items" hook that every module can code to to provide new items into the newsletter so that it can be automatically generated. Of course this would require updates to modules to use the hook, but it would be ultrakewl. Seems like it would be a logical step though given your superb core implementation.

I'm sure you all have thought of that already, but just wanted to throw it out.



7
jerryj
Re: Classifieds
  • 2003/11/15 4:35

  • jerryj

  • Just popping in

  • Posts: 33

  • Since: 2001/12/20


Well, actually, you can change it. You just can't share your changes with other people. So, you can customize it and make a XOOPS module out of it, but legally you can't distribute that module to anyone else.



8
jerryj
Re: XOOPS 2.1 Core development Roadmap
  • 2003/11/6 14:29

  • jerryj

  • Just popping in

  • Posts: 33

  • Since: 2001/12/20


Good post tom. I agree with your suggestions.



9
jerryj
Re: XOOPS 2.1 Core development Roadmap
  • 2003/11/5 20:05

  • jerryj

  • Just popping in

  • Posts: 33

  • Since: 2001/12/20


Hi All:

I'd like to throw out my suggestions for core enhancements as well. Some of these have been mentioned, some have not.

I'm very happy with XOOPS and you guys have done a great job. Here are just a few things that I think would help a lot of people in the XOOPS community (i.e., not just my personal "wishlist".)...

NEWSLETTER FUNCTIONALITY

This maybe should be separate from the "receive email from webmaster" checkbox, and may be a module, not sure. Here are a couple of quick ideas.

Automatcially pull "new" content snippets from modules via a hook into each module (similar to the current "search" functionality). For example, when you create a new newsletter, it should automatically pull some type of information on new downloads, links, articles (wf-sections?), gallery items, etc., that have been added since the last newsletter, and provide links to the full content on the site for those items. This would require building an API into the core to call modules to provide this information.

Provide ability to allow users to receive the newsletter without being a registered member of the site (but some users may not want this, so it should probably be a flag).

CROSS-MODULE LINK CHECKER

For all modules that have the ability to link to an external website, including downloads, web links, news, provide the functionality on the admin section to parse and check for valid and invalid links, and allow some action based on whether the link is good or bad. Gossamer Threads' "Links" program has had this for years, and XOOPS is in bad need of it.

For example, if it finds bad links in the Weblinks section, the admin should have the ability to block-delete bad links from the web links directory. Same for downloads (or this super-module you all keep talking about).

It should also parse the News and Articles (Sections, WF-Sections, etc.) for included [url= links and parse them and validate those links and notify the admin if they are not valid or need to be manually checked.

AUTOMATED DATABASE PURGING

Not sure if this is a module discussion or not, but some some database tables need to have some sort of purging mechanism set up for them, either from the admin menu, or more preferably, something you could schedule in cron or something.

News, forum posts, inactive users, etc., are candidates for this automated purging. For example, say I only want to keep one year's worth of forum posts in my forum. Right now there is no easy way to do that. This is going to get more critical as more and more XOOPS sites are on the net longer and grow to have larger userbases.

CREATE TRUE USER COMMUNICATION SYSTEM

I know this work is in progress, and it may be a module, but the system used to communicate between users right now needs a lot of work. Here are some ideas.

Beef up the PM system to be more of an email like system. Provide the ability to send a PM to multiple users, incorporate the buddy list into the PM functionality, allow users to save their favorite addresses into an address book etc.

What would be even one step beyond that would be to provide the functionality to check external POP3 email addresses using the PM system, as well as send mail through those POP3 mailboxes.

Another feature that would be a nice addition to the PM functionality but is not necessarily related to the above it to allow a user to specify in their profile that they be notified by email when they receive a PM.

I think these would be great additions to Xoops.



10
jerryj
Re: Making the news module appear without the front page material
  • 2003/10/13 2:36

  • jerryj

  • Just popping in

  • Posts: 33

  • Since: 2001/12/20


Yup, I mentioned this almost two years ago in this post.

It's confusing for the users.




TopTop
(1) 2 3 »



Login

Who's Online

116 user(s) are online (89 user(s) are browsing Support Forums)


Members: 0


Guests: 116


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Sep 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits