Re: Responsibilities of a module author

[renodino]

(For discussion purposes, I'm assuming "module authors" eq "CPAN contributors")

Its Thanksgiving weekend here in the USA. I suggest you immerse yourself in the spirit of the holiday and simply give thanks to all the CPAN contributors, minor, major, orphaning, or otherwise. After all, they've given you the source!. If you have an issue the author won't fix, then swallow hard, fixup a version for yourself and your friends, respect the author's copyright and/or license terms (if any), and move on.

CPAN is what it is. Accept it. If you don't like the fact that a module author doesn't snap to attention everytime you think you've found a bug, or want a new feature, TS. If you want immediate support for everything, you probably need to ditch Perl and head for VB and/or C#, and pony up the $$$/min for MSFT's 900 number. Even Linux doesn't have the kind of response you're demanding, unless you pony up $$$ for Red Hat/SUSE/etc. support contracts.

And be thankful CPAN isn't SourceForge...now there's a real cemetary! At least everything on CPAN usually has actual, "for real and truly" code, that worked sometime, somewhere (tho I have recently seen a few modules posted with major "THIS DOESN'T WORK YET" disclaimers - not just for minor features but for the whole bundle - which seems a bit out of scope for CPAN, but what the heck...)

As for offering remuneration, my experience indicates its pretty pointless. The amount offered is usually just a token relative to the effort. While I'm sure many CPAN contributors would like to get paid for their efforts, most are just scratching itches, or hoping for a little ego stroke, and/or maybe feel the need to give back to the community from which they've taken so much.

Awards ? IMHO, handing out a few chachkis to a select few contributors isn't likely to make a difference.

Ratings ? There's already some ratings on CPAN...but most people don't even bother with them. For that matter, many (most?) folks don't seem to use CPAN directly much anymore, but use PPM's from ActiveState (or elsewhere), so rating won't likely accomplish much except permitting a few cranky users to badmouth an author simply because the author rejected a patch.

As to the suggestion for a "community branch": it would likely violate any copyrights attached to the hijacked, er, "branched" code, so you'd need to get explicit author agreement or assignment of copyright. Of course, CPAN could decide to change the posting policies to require copyright assignment so a module could be "nationalized" whenever someone bitches about not getting their pet feature patched in. At which point, I suspect a lot of CPAN contributors will be clicking the PAUSE "Delete" link shortly thereafter...I know I will. The upside, of course, is all the extra free space that will be freed up on the CPAN servers and mirrors !

E.g., over the past year, some (very few) folks on the DBI maillists have 'turfed for some feature additions to DBI that many of us consider laughable. Under your "branching rule", the 'turfers just need to get a couple likeminded folks to complain about it, and voila! we get a "community branch" of DBI. Not a happy situation...

One possible solution might be to create a secondary classification akin to CORE, for modules which

• have explicitly assigned copyright from the author(s)
• are treated much the same as CORE modules
• but are not delivered within CORE

(kinda like the "javax" namespace in Java).

Asking module authors nicely for such permission to move their module into the "approved" list would likely meet with more cooperation than the "3 cranks complain and you're nationalized" rule, or enforcing a CPAN policy of "sure, you can post here, but once you do, we own it.".

Otherwise, in direct response to the OP Subject: Responsibilities of a module author:

• don't knowingly violate anyone else's copyright or license terms
• graciously accept the thanks of users who've found your contribution useful
• patiently listen to user's suggestions and bug reports, and help as best you can

The first is the law, and the last 2 are simply good manners. Imposing more on contributors is likely to send them to the exits, or off to SourceForge or elsewhere.

[BrowserUk]

Whilst I accept that my idea has no mileage, I would like to query one thing.

How does it "violate copyright", to branch a copy of artistic licenced code, or the various flavours of GPL licenced code?

I was not suggesting removing the authors copyright.

Only copying and modifying it and redistributing it, complete with all original laballing and packaging in place. Isn't that the essence of what these licences are intended to permit?

I'm not looking for an extended legal debate here, just confirmation or correction that my basic understanding is correct?

[renodino]

You may be right (IANAL), tho the notion of branching and redistributing wo/ an author's express consent seems a bit nefarious. Modifying for personal use, yes. Redist ? I don't know.

However, if by branching, you mean a complete rename, so that the branched version is completely distinguishable from the original, and the original author is given appropriate credit, but dispensed of all responsibility, I suppose branching may be an acceptable solution under the artistic license. I guess I see the difference as

Take BrowserUk's module XYZ, modify it, and repost it as XYZ with BrowserUk listed as primary developer, but wo/ BrowserUk's permission.

vs.

Take BrowserUk's module XYZ, modify it, rename it and post it as XYZPlus with renodino listed a primary developer, but credit given to BrowserUk for the initial development.

Perhaps the rules are more social contract than law; guess I need to go review the Artistic license to see what the relevant conditions are.

Update:

I stand corrected.

Upon review of the Artistic License, I discovered the following:

You may otherwise modify your copy of this Package in any way, provided that you insert a prominent notice in each changed file stating how and when you changed that file, and provided that you do at least ONE of the following:

a) place your modifications in the Public Domain or otherwise make them Freely Available, such as by posting said modifications to Usenet or an equivalent medium, or placing the modifications on a major archive site such as uunet.uu.net, or by allowing the Copyright Holder to include your modifications in the Standard Version of the Package.

So, having used the Artistic license on all my CPAN'd modules, I have given implicit permission for anyone to change anything in them, and redistribute as they please. Indeed, one might interpret that clause as requiring the modifier to publicly redistribute the updates.

Which I find appalling.

No, its not because I want absolute control. In fact, I originally used the GPL, but then took the time to really read it one day and realized it didn't do what I expected, namely, I did not want to require anyone using my modules to open source everything they used it with. That should be their choice; I'm offering my software as open source, and thats my choice. To paraphrase Yoda, "Give or give not, there is no GPL."

And I'm more than happy for someone to create a derivative work, so long as they use a different namespace and don't list me as primary developer.

My concern is liability. If you think the little indemnifier at the bottom of the Artistic license is all you need, I suggest you go have a chat with the folks at Sony BMG...they have plenty of indemnification printed on their CDs, but that won't stop TX and CA from grinding major bucks out of them for their recent DRM stunt.

"But I don't write malware/spyware/etc.". Great! However, by using the Artistic license, you've not only given permission to those who do write malware to pollute your code with it, but actually required them to redistribute it using your original namespace with your name as principal developer....just so long as they're kind enough to put a tiny disclaimer in some file 5 or 6 directory levels deep in the distribution. Please keep in mind that distributing, or even facilitating, malware is now a crime in many jurisdictions.

And of course, there's the whole issue of responsibility for bugs that are inadvertantly introduced by modifiers.

So I'll be busy this weekend, trying to find a license that provides a bit more protection, and updating my modules to reference it.

[tirwhan]

the notion of branching and redistributing wo/ an author's express consent seems a bit nefarious

Why? That's exactly what free software is about. If there's an application/library you like but which hasn't been updated for a while and you have the skills to fix it and thereby make it work for you because you have the code and the license allows it, great. If you can then redistribute the software along with your changes and thereby give the community the chance to profit from your work, so much the better.

This is not to say that I'm advocating wholesale forking of projects, it is usually much better to work with the original author and merge your changes back into his/her code. For one thing, you won't suddenly have to field the requests by users for yet more changes :-). But if the original author doesn't like what you're doing or is incommunicado for ages or you just simply don't get along, putting your version up somewhere for others to use is definitely the better option than letting your code smolder lonesome in your SCM.

[tilly]

You'd have to look long and wide to find a judge who would consider convicting you for having a malware author borrow code that is clearly not intended as malware.

You would not have to look far for an appeals court who would overturn such a stupid judgement.

To use the example that you brought up, the LAME folks have no worries about being sued for facilitating malware even though their software got used by Sony. (Of course there is the aditional issue of copyright violation there...)

[Anonymous Monk]

You're suggesting that CPAN have an official way to take-away module names from authors who aren't maintaining their modules like you (and 3 of your friends) think they should (different from abandoned modules).

Thats not something CPAN can do.

[BrowserUk]

No. That was not my intent, but I agree with you (and others that/msg'd me) that it could be read that way.

My intent was to suggest a mechanism whereby the users of a module could collaborate to fork a version of the module that would allow them to pool there efforts into producing and maintaining something that met their needs and requirements.

The intention was to avoid having 20 individually forked versions, whether on cpan or local production systems, whilst relieving the pressure on the original module author from having to either feel obligated to react to user pressure for new features and bug fixes, or abandon all control over the direction his code went in.

I felt that if a few, long term users expended their time and effort coming up with one or more patches that met their collective needs, and demonstrated both their commitment and collaboration to getting something that worked for more than a single application, the author my feel more inclined to see their point of view and incorporate those patches back into the original module. I did not envisage any mechanism for forcing him to do so.

[xdg]

Its Thanksgiving weekend here in the USA. I suggest you immerse yourself in the spirit of the holiday and simply give thanks to all the CPAN contributors, minor, major, orphaning, or otherwise. After all, they've given you the source!. If you have an issue the author won't fix, then swallow hard, fixup a version for yourself and your friends, respect the author's copyright and/or license terms (if any), and move on.

Please go back and re-read the quote that got me started on this meditation. Perhaps I got off track in the meditation itself, but the issue that I find frustrating is less about CPAN contributors not fixing things when they break but about not even bothering to maintain things when others in the community offer help.

You're absolutely right that the code is there and it can be forked off. But I don't think it helps the community (whatever that is) to proliferate module releases along the lines of Blah::Blah::Fixed. So... instead, I'm trying to spark a discussion what could be done short of that.

In response to some specific points, I was approaching this from the standpoint of things that might encourage me, as a CPAN contributor -- by positive or negative means -- to step up the priority to fix a bug, incorporate a patch, etc. at a time when I'm not actively using a module and have a shortage of tuits. It certainly wasn't a suggestion that any of it be "imposed".

On the money front, I'm not suggesting significant amounts like a shareware model -- if someone said "hey, if you could get that patch in there in the next week, I'd gladly buy you a drink at the next YAPC" that might well be enough for me. The idea is to explicitly recognize that asking someone to do something for you is an imposition in their busy lives -- and even a token offering can be enough to make them feel valued as opposed to put upon.

[renodino]

I actually got to thinking about this in light of BrowserUk's mention of a "community branch". Tho I disagree with the tenor of his suggestion (i.e., just taking the module over), I think theres a germ of an idea (which has probably already been discussed somewhere around here): namely a second tier of modules below CORE, but above "whatever's on CPAN". For the sake of discussion, I'll call them Certified Modules.

If I read your OP correctly, one of the major issues confronting developers is that organization's won't permit downloading just any old module. I know I've encountered that with a number of my customers. If it isn't CORE, then there better be a very good reason to install/upgrade it.

So if there were some add'l level of "trust" involved, i.e., a certification, then that issue might be eased. And part of the requirement for a Certified Module is that the module author has explicitly agreed to release the module to whoever administers certification for maintenance. One can imagine many other baseline requirements (e.g., it must use the normal build/test/install make process, it must have a test suite, it must explicitly specify which versions of perl and prereq modules, and on what OS's and/or platforms, it is certified for.

Of course, there's the little issue of funding... I doubt there's much of an opportunity for commercialization of the process, and it will cost money for all the h/w and s/w, not to mention staff to run this. But hey, if OSDL can survive, maybe there's room for another such org ?