01.07.07
Posted in FXGAS, development, evil, open source
at 02:44 am
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.
(source)
Since Drupal and its modules “make function calls to each other and share data structures”, GNU believes that Drupal modules have to be distributed under GPL or compatible. Then, they state that
All versions of the Open Software License have a term which requires that distributors to try to obtain explicit assent to the license. This means that distributing OSL software on ordinary FTP sites, sending patches to ordinary mailing lists, or storing the software in an ordinary version control system, is arguably a violation of the license and would subject you to possible termination of the license. Thus, the Open Software License makes it very difficult to develop software using the ordinary tools of Free Software development. For this reason, and because it is incompatible with the GPL, we recommend that no version of the OSL be used for any software.
Oh. And I recommend that you guys shut up and read this before talking smack about other licenses again:
There are benefits to the formation of contracts between licensors and their licensees,
including reliance on court cases that guide us in the interpretation of contract language, and the
opportunity to elect contract damages such as specific performance rather than just the monetary or
injunctive relief provided by copyright law. To encourage contract formation, OSL 3.0 requires that
downstream licensees who in turn distribute “must make a reasonable effort under the
circumstances to obtain the express assent of recipients to the terms of this License.” [§ 9] The
definition of “reasonable effort” is intentionally vague, because no open source license is allowed to
mandate any specific form of technology or any specific license acceptance procedure. Most open
source projects and commercial distributors already use appropriate procedures to obtain the
manifest assent of their licensees, so this OSL 3.0 requirement is not intended to require something
different than what now happens in ordinary software distribution practice.
If you want to know more about OSL and see where it differs from GPL, you can read a brief (16 pages) OSL 3.0 explanation by its author, Lawrence Rosen.
My problem is that not only if what GNU.org states is true, I would have to develop Drupal module under GPL license, but what is worse, also any games that would use my module (call its functions, share data structures) would be licensed under GPL. So, where is the freedom, when you’re forced to use license of your library’s platform? Because in my view, Drupal is a platform, my FXGAS will be library and game will just a separate program, using libraries. However, in GNU’s opinion, the game would be PART of the program of FXGAS and Drupal! Does it make sense?
I can’t help it, but no, I fail to see sense in that. Do you use Linux? Some of you do. And is EVERY software under Linux licensed under GNU/GPL? No, it isn’t! The programs probably use the libraries under many different licenses. They may depend on them more or less, but it doesn’t make them automatically derivative works – just by calling functions of each other!
You know what? I’ll stick with OSL. It rocks. And I’m thankful to its author, Lawrence Rosen for explaining my viewpoint few years back in his article Derivative Works. Thanks, Lawrence!
open source, fxgas, drupal, law, osl, gnu, gpl, fsf, rosen, lawrence
Permalink
01.13.06
Posted in FXweb CMS, development, open source, svn
at 12:57 am
Finally! Cca 2 months after first public announcement, sourceforge.net has opened beta testing of Subversion versioning system. And I’m proud to be among testers!
You can take a look at my repository – and check, if I’m not slacking ;) If it’s empty, it’s because they haven’t imported my svn dump yet, but that should be done within next day, I presume. Oh, the wind of freedom.
BTW, FXweb CMS will be released in nearest days. That is, within max. 4 days.
Tags: FXweb, open source, CMS, sf.net, svn, subversion
Permalink
12.21.05
Posted in FXweb CMS, open source, projects, webdev
at 12:06 am
I’m sure this question will pop up sooner or later from some of my friends or co-workers, so I’ll answer this way.
- Security: chance that someone will discover and report vulnerability raises with number of users. Open source = a lot of users.
- Developers: Anyone who modifies code has to release the changes – that means cost-free debugging and development. I know that this doesn’t mean that the project will just miraculously finish itself, but again – the more popular the project will be, the better chance of finding help.
- Bugs and ideas: Well, of course that only fraction of downloads will represent skilled developers willing to play with the code. But even regular users can help finding bugs and bringing new ideas, suggestions and comments to the project. Come to think about it, is there anything easier than complaining that something that you got for free, sucks? ;)
- Nothing lost: I don’t lose anything. Although it is technically and legally possible that someone will download, modify, install and do whatever he wants with FXweb and gets paid for it – but I really doubt that he will be in my vicinity and steal my clients somehow.
In other news, I’m learning JavaScript and will try to write some short tutorial soon and release FXweb CMS 0.0.2.
Tags: FXweb, open source, CMS, sf.net.
Permalink
11.23.05
Posted in FXweb CMS, projects
at 03:01 pm
I love using multidimensional arrays. It’s easy when you’re using PHP and have one mighty cool data type – mixed.
I’ve just finished tool for editing and reconstructing commands (objects) – that contain 3D array, which can contain another command object. Whew. I hope I’ll be able to release FXweb CMS 0.0.1 in nearest weeks.
Permalink
10.20.05
Posted in FXweb CMS, design, projects
at 05:09 pm
Oh my. I have to put it down, because I have total mess in my head. Plus I think that one is expert in given field when he can explain it to others.
So, the objective is to generate XML source from any given GPC data ($_GET, $_POST, $_COOKIE). I want to use templates, modules and elements for constructing the XML, site logic DB table for resolving GPC and some kind of ‘command’ object. So, what should do what?
Command object should be communication medium between anything and modules. It should contain array of commands that module (plug-in, see below) will understand.
Module (or plug-in, if you want) is… ehm… modular… module. It’s set of [un]installable files that provide coherent functionality – say, display a menu or site identity or whatever. This should be realised via elements – image, button, piece of text – piece of outputable data, as atomic as reasonable. Elements should be the only objects outputting XML, but I’m afraid it won’t be very practical.
And what are templates for? These are containers – set of sub-templates, module commands and maybe even elements (but I would advise against this behavior). This way, I can have some kind of default template – you know, the standard stuff – logo, menu, footer – and then just call module (or another template) that will provide main content.
OK, that was the easy part (or at least it may seem easy to come up with), the functional design. But I’m confused a bit about technical design. I know I could code something, but that’s just not enough. I don’t want to redesign my whole architecture and APIs later.
OK, let’s do simple and stupid functional decomposition:
- determine which main template we need
- call that template, all sub-templates, all modules (and elements, if any).
- and… that’s about it.
That sounded too simple (again). I didn’t even mentioned error checking, but that doesn’t matter now, I have a plan for that.
We need to have (sounds weird) defined default template. But how to determine if we need to use it, or some other?
At first, we’ll take a look into site logic DB table. If we found entry that matches our current GPC data, we’ll read command that’s there (or maybe cached file instead). That command will call everything needed – more modules or one complete template, or few templates and modules together – whatever.
When we don’t have anything in site logic, we could simply assume that user is manipulating GET data – and that would force us to put every single possible action into database. Or, modify code to check only part of GPC and generate rest (and I could think about this option). But it would be cooler if modules could recognise unallowed manipulation. So, we have to analyse that data.
How? That’s the question. $go ($_GET['go']) should tell us something about main content. $do should explain in one word what we’re gonna do. For example, $go = “shop” and $do = “top10″ should tell eShop module to output top10 products. If we’d need more data, they will have to be stored as serialised command object. Command object must have required attribute – name of the module/template/element we are calling. Now that explains a lot. But how will be processed? Will each module have to implement and interface to decompose message into tokens? Or will kernel include methods for translating the command? I don’t know yet. This is gonna be more complicated that I though it will be… but when it’s done, it will be well worth the time… I hope.
Permalink
10.15.05
Posted in FXweb CMS, PHP, design, projects, webdev
at 11:10 am
Ewww, awfully long title. But I don’t know how to express is by fewer words, so… on to the subject.
I’ve been coding new CMS in past few days, which won’t be released under any OSI-approved license, because it won’t be released at all. But I hope that the fragments of code and any gained skillz will make it to FXGAS, my open source project (which is codeless so far) someday.
My CMS can read static XML files and transform them via XSLT. Nothing special actually, that could be done in some 20 lines of code. Of course, that wouldn’t make it Content Management, nor System. It can analyse GPC data, look in the database and determine which XML to choose. This is all done by what I call ‘kernel’, or more specifically, class kernel. This is the only thing that’s instantiated by index.php and handles everything else. And, since I’ve used the name ‘kernel’, it should be able to load modules.
Now that was kinda problem. It wouldn’t be problem if I’d know what data modules need – but I don’t want to restrict them anyhow. I could have handled them all data, but that would unnecessarily increase memory usage. And nothing like calling public properties of instantiated kernel class didn’t work. Passing them by reference didn’t work either. Passing whole kernel by reference like $module->doStuff(&$this); didn’t work. And then…
I know I’m not very good at designing objects and stuff – I lack experience and time to read some of those nice books about design patterns. I didn’t want to use inheritance, because it just wasn’t suitable for my needs – PHP 5 doesn’t support multiple inheritance – and I don’t expect to have just one module. :)
So, when I finally realised that when I call preprocess modules with something like this:
// preprocess arrays stores names of pre-process module .php files
foreach ($this->
;preprocess
as $name) {
//strip .php from end and everything before last slash
$name = substr($name, strrpos($name, "/")+1
, -4
);
//run all modules from the list
$this->
;mod_pre
[] = new $name($this);
}
it gives the pre-process module just what I need – reference to the kernel! Awesome. No extra memory usage, no hassle with determining what data will module need. The only problem I see is that all properties had to be declared as public – and we ruin one of the cornerstones of OOP, encapsulation. But as long as we won’t let any rookie change important kernel properties we have no problem, I think.
So, now my baby CMS can call preprocess modules, which will replace in XSLT stylesheets with all transformations supplied by modules as well as in static XML content files with inclusion of all styles supplied by modules. Isn’t that great?
Permalink
