Serendipity Forums

Hi!

I've drafted some text here: http://www.s9y.org/217.html

Comments? Additions?

Regards,
Garvin

good idea!

some remarks:

documentation_XX.html file.

this is new, in't it?

By default, a s9y plugin is BSD licensed.

hm, if I have a look at http://spartacus.s9y.org/index.php?mode ... s_event_en most (all?) plugins are GPL.

Only use SQL statements that work in PostgreSQL, SQLite and MySQL.

We have already code that works only with Mysql - this code is even in the s9y-core (image moving )

I think we should not have sql-indipendant as a must but should - it has to be a must to declare such dependicies! And to have a if mysql-cause in the code

This could mean that I possibly can't use a plugin only because I'm using a database other than MySQL?
A plugin should work with and on every database.

hm, if I have a look at http://spartacus.s9y.org/index.php?mode ... s_event_en most (all?) plugins are GPL.

I specifically haven't put license files in my plugins because I wanted them to be BSD (or even less restrictive).

The website says they are GPL because it defaults to that if there is no propbag for "copyright" specified. I kind of feel that should change, but you run into a problem that I have been un-easy about for a while.

Unfortunately, a lot of the plugins I have worked on lately use other libraries that are licensed in other ways.

While I have kept the original license files in place on libraries (and tried to separate them out in directories), I have been reluctant to put a "$propbag->add('copyright', 'BSD License');" on anything that bundles libraries with other licenses.

I would like a little definition as far as how we handle that, even if it is to do something like It might be better to have the spartacus site default to something like "Please see bundled license (if available)" instead of "GPL". It might prevent code from being mis-licensed.

Also, I am kind of with Ruhe that SQL should make every attempt to be multi-platform. (The large plugins I have done have sacrificed a lot of speed in order to stay platform neutral. I've hopefully made up for it by caching responses with Cache/Lite.)

That being said, I know that that is not always possible when you are trying to implement specific features (the usergallery plugin has a mysql specific feature of showing related posts). I think Stephan is right that we need to make a clear distinction as to what features are supported on a specific platform.

If some feature of a plugin only works on one platform it should be easy for users to see that that platform is a requirement for the feature.

I have not made any such notes in the past, but a plugin documentation system makes it a lot easier to provide those types of notes.

Updated- I've used Stephan's name enough I shouldn't be forgetting it... Sorry about that Stephan!

Hi!

documentation_XX.html file.

this is new, in't it?

Yes!

hm, if I have a look at http://spartacus.s9y.org/index.php?mode ... s_event_en most (all?) plugins are GPL.

You're right. The spartacus plugin defines plugins with empty licensing as GPL. I've changed that to read "N/A (=GPL)" in the future.

Only use SQL statements that work in PostgreSQL, SQLite and MySQL.

We have already code that works only with Mysql - this code is even in the s9y-core (image moving )

Yes, but I mentioned that the code should fork if functionality only works in one of the database systems. Plugins should not FAIL if they are executed on foreign DBs, because some functionality does not exist in others, and it should still be usable if the plugin likes to.

I think we should not have sql-indipendant as a must but should - it has to be a must to declare such dependicies! And to have a if mysql-cause in the code

No, I really want to force plugin developers to use generic SQL. Lazy developers would otherwise use MySQL syntax where not really required.

Matt: Please change the 'license' propbag in that case for the plugins you've worked on? If external GPL libraries are BUNDLED, then you CANNOT make the Plugin 'BSD' code. GPL specifically forbids that. If GPL is involved, it is viral, and thus all depending code must be GPL compatible. BSD isn't.
Regards,
Garvin

garvinhicking wrote: Matt: Please change the 'license' propbag in that case for the plugins you've worked on?

I haven't used a propbag anywhere there is a conflict, so nothing needs to change. It might make sense to add a propbag in places, but I have been very careful not to relicense code. (In fact, a quick glance looks like none of the the additional plugins uses the "copyright" propbag setting.)

I am very aware of the problems of the different code licenses, and, while I deeply dislike the viral aspect of the GPL, I would never purposefully violate the GPL.

Also, I'm not one hundred percent sure I agree with

If external GPL libraries are BUNDLED, then you CANNOT make the Plugin 'BSD' code.

I believe that is easier, but I think the clearly labeling licensed components would allow us to split license by file or directory. But if you believe this is untenable to support and don't want to do this with the plugins, I'll abide by that (how ever much it hurts to see my code go GPL).

Ruhe wrote:This could mean that I possibly can't use a plugin only because I'm using a database other than MySQL?

yes, there can be plugins or functions of plugins which need mysql.

A plugin should work with and on every database.

No.

Or in better words:

SHOULD - yes
MUST - no!

if there is a feature which needs mysql, we have two ways: give this feature to no one or give it to mysql-user. Give it to no one would be the bad way in my opinion.

But of course: if there is an easy way for a feature with mysql and a hard (complex and cpu expensive) way without, we should use

mgroeninger wrote: Updated- I've used Stephan's name enough I shouldn't be forgetting it... Sorry about that Stephan!

Äh, OK, perhaps my english is not good enough: What do you mean?

stm999999999 wrote:Äh, OK, perhaps my english is not good enough: What do you mean?

*laugh* your english is fine... I originally just used your account name (stm999999999) to refer to you... when I re-read it I decided I really should call you by your real name, since I know what it is and all.

Sorry about the confusion.

*laugh* your english is fine...

Thanks! But tell this to my former english-teacher.

I originally just used your account name (stm999999999) to refer to you... when I re-read it I decided I really should call you by your real name, since I know what it is and all.

or name me stm9x9 like Garvin

Sorry about the confusion.

never mind