[development] Drupal's CVS policies... including 'foriegn' codein TinyMCE module?

[John]

On May 25, 2007, at 12:29 AM, andy at spiders-lair.com wrote:

> As I see it, the commit of 3rd party libraries in Contrib generally  
> should not be allowed as:-
>
> a) It basically creates a duplicate code repository of code that  
> should be availble from a single authoritive source.
> b) Uses Drupal.Org resources to effectively host "someone elses work".
> c) It's potentially a security risk, especially if maintainership  
> is slack. Although problems aren't Drupal related directly it  
> presents a sloppy view of the project as a whole imho.


a.) We wouldn't be distributing the library by itself; it would be  
packaged with some higher-level code. Nowhere on d.o would it say "If  
you want this library, get it here!"
b.) As it relates to Drupal Core, contributed modules are ALREADY  
someone else's work. As it relates to Drupal as a whole,  including  
GPL code form other sources is the very spirit of open source (as  
Jeff just said.)
c.) If the maintainership is slack, the security risk is already  
there; the sloppy view of Drupal as a whole will already be there. It  
makes no difference if a 3rd party library is involved.  Also, as a  
counterpoint: a good maintainer will monitor updates to a 3rd party  
library. And the good maintainer will always be more secure than the  
average user.

I keep seeing the "security risk" reason repeated.  But it seems  
people are really talking about the /perceived/ security of Drupal as  
a whole and not the /actual/ security of the average user's  
installation.

Contrib modules are much more likely to get updated by the average  
user now that we have Update Status.  But forcing a user to download  
and install a separate library means that library will most likely  
never be updated again.

For /actual/ security, we need to allow 3rd party libs in Drupal's  
CVS (for the reason in c above).  As a compromise, we could make  
contrib authors apply for special 3rd party library inclusion into  
CVS as Derek suggested and to then trust them to keep that 3rd party  
library well maintained.  The CVS 3rd party lib application could be  
approved or denied based on the maintainers proven track record on  
previous modules.  So newbie developers would be denied and  
maintainers like JJeff would need co-maintainers before the start of  
the project. (I'm not picking on you, Jeff! I love your code!)

For /perceived/ security, maybe the best way to fix contrib from  
affecting Drupal core's good name is to put the distribution of  
contrib on a separate domain or sub-domain.  Like 3rd- 
party.drupal.org or unofficial.drupal.org...

Thoughts?
   - John