Q: Can I relicence a BSD project to GPL, so as to host it on D.O CVS?
Hello,
I am working on a base-theme yui-grids-framework.
First of all: there is such a project on D.o. already, but that one is a) dead, and b) suffering from the same thing I want to solve.
YUI grids is dristributed under BSD. From my tiny bit of legal knowledge, I recall that BSD can be relicenced as GPL.
In that case, I can simply do so, and then upload the results to Drupal.org CVS.
However, first of all: third party code is discouraged in CVS. To avoid clutter, to avoid legal issues and so forth. This very project, however, is different in the way it uses the 3rd party code.
Rather then including a piece of PHP, or including a set of CSS files or anything like that, it will work mainly on, from and by these files. The INSTALL directives will most probably become longer and more complex then the whole rest of the projects code. Rather then providing a nice start-off theme for themers, we will have a large manual then.
My question therefore is:
Can I relicence this BSD code and put it onto the Drupal CVS?
Will this be frowned upon by the community?
Bèr



You cannot re/dual-license
You cannot re/dual-license something if you do not own its copyright. Otherwise, anybody would be able to relicense anything, so I'd be able to declare that Half-Life 2 is now public domain!
So unless you own or can somehow acquire the copyright to YUI, no, you cannot relicense it like this.
Garrett is correct about the
Garrett is correct about the relicense question. However, BSD is typically copasetic with GPL. However, Drupal infrastructure frowns on third party applications in its CVS repository. You can provide instruction and methods to download the BSD library that you need for your module.
More specifically, they
More specifically, they disallow any third-party code (or images, documentation, whatever) which is not also under a GPL license. This is why jQuery, which is dual-licensed under both the MIT and GPL licenses, can ship with Drupal.
Garrett is incorrect
You can re-license/sub-license something if you have a license to do so.
For example, the MIT license allows it. That's why http://drupal.org/project/htmlbox exists, though this is a fuzzy area that highlights the inconsistencies in the enforcement of Licensing policies.
The BSD license is not explicit about sub-licensing, but (IANAL) my understanding is that it is broad enough to encompass the GPL. So you could add GPL to your BSD-based reditribution, but you cannot remove the BSD notice from it.
Having additional licensing requirements (in this case, BSD's), I think, is frowned upon by the community. But if so, HTMLBox represents an exception, or else HTMLBox is probably not compliant with it's MIT license.
This gets into the idea of CopyLeft (GPL, MIT) vs non-CopyLeft licenses (BSD). You can add licensing restricitions to non-copyleft, but not vice versa.
$BSD .= $GPL //OK.
$GPL .= $BSD //NOT OK.
Drupal.org user profile
Portfolio: http://www.NinjitsuHosting.com/portfolio
Drupal Micro-blogging: http://twitter.com/matt2000
I agree that HTMLBox appears
I agree that HTMLBox appears to be an inconsistency with regards to application of the GPL rule.
Are we sure, though, that "sublicensing" implies the ability to change the type and rules of the license? Is this a common practice with MIT-licensed wares?
Re: Are we sure
I know that BSD is included in GPL projects. The newlib library has http://sourceware.org/newlib/COPYING.NEWLIB which includes several distinct licenses. The newlib library in turn is used by the Cygwin project which is GPL http://cygwin.com/licensing.html. I'm not as familiar with MIT though.
Not change (unless the
Not change (unless the licenses specifically says), but you can add to it. That's my understanding of sub-licensing, but really it's defined by the license itself.
I.e., if it says "You must include this notice", then you have to include the notice, presumably without change.
So MIT sub-licensing allows you to bring the project under GPL as long as you also retain the MIT notice. I don't know if HTML box does or not.
Drupal.org user profile
Portfolio: http://www.NinjitsuHosting.com/portfolio
Drupal Micro-blogging: http://twitter.com/matt2000
Exception needed
Redistributing BSD licensed code under the GPL is well-accepted as both legal and ethically kosher.
Drupal.org's CVS repository forbids the inclusion of 3rd party code regardless of its license. Exceptions may be made on a case-by-case basis by the infrastructure team if there is a specific reason for it. In the case of HTMLBox, an exception was made because HTMLBox itself needed to be hacked to pieces and heavily modified in order to be included in the module, so it was already a fork to begin with.
If you feel your project should be granted an exception, please open an issue in the infrastructure queue to discuss it. See: http://drupal.org/licensing/faq#q10
Thanks
The fact that it is
a) not entirely clear wether or not I could ship the code as GPL, (Garett seems to think I cannot, other seem to think I can, at the very least there is still a lot of confusion)
b) not allowed to ship 3rd party code into CVS, even if it is GPL,
made me decide to not host the project on D.o, but look for a Subversion-enabled project hosting site. This is not meant as critique, but simply a decision made on basis of "pragmatism". Any project host will do, for me, and I cannot afford long threads and discussions about whether or not I should be give an exception (I think I should not be granted that, in this case). So,
Thanks for your feedback.
Bèr
Which leads to a question
Which leads to a question of: If your code isn't hosted on d.o. can the project page be created anyway?
No
As a matter of policy Drupal.org does not permit project nodes for projects not hosted on Drupal.org. That's not a copyright thing, just a decision made by the infrastructure team.
So a catch 22 for Bèr then.
So a catch 22 for Bèr then. I suppose a good example of external project management interlaced with internal project management would be Ubercart. One thing Bèr can think about is hosting the code without the TPL and offer the complete set externally. That is the real rub; Bèr can't create a complete package from an internal project unless the TPL is added to the project; but TPL is off limits in the project CVS.
IMO, this TPL thing needs more attention because it hinders good will. MIT, BSD and PD are all used by GPL projects. There is no reason to make it a hardship for Drupal module contributors to use them. I guess that is the reason CiviCRM isn't supplying Drupal updates via the internal civicrm project page; you don't find a version for D5 but I know they offer it.
Not having a project page for Bèr's package will mean that Bèr's package is looked at as distrustfully. No one wants that to happen. AFAICT Bèr creates some good code.
What do you mean by TPL?
What do you mean by TPL?
Third Party License
Third Party License
To be clear, under my
To be clear, under my understanding, it's kosher to ship the code with a GPL project. However, the code will still be under the BSD license; it does not adopt the GPL license. It can't be relicensed. So the code cannot be shipped as GPL code, no, but it can be shipped with GPL code.
Earnie's question is intriguing. I'm guessing many people would object to that, especially if the project page said something like "To download this module, go to this other site (so I can skirt D.o's rules)."
I think the best path to take would be the one that others have taken when confronted with this problem; host the module you wrote at D.o, but prominently display on your project page and in your docs that folks have to go to Yahoo's site (or wherever) to download the non-GPL third-party code to make the module useful.
Interestingly, I did come across a license the other day which does appear to permit relicensing by others; the WTFPL - Do What The F&$% You Want To Public License (NSFW). I'm currently writing a module which includes a third-party jQuery extension which is covered by this license. Should I end up distributing the project (it's for a client, so I'll probably want to get their permission first), I'll exercise the license's provision to do what the f&%! I want to and relicense it as GPL to host on D.o. Will I get away with it? It might be a test case…
Test case?
There have already been test cases, and modules have been removed from CVS before. :-) We don't always catch it immediately, as we don't actively monitor ever project's source code (we have much better things to do with our time), but it usually gets noticed eventually.
Best thing to do is inquire about an exception. If the 3rd party code is not too large and/or is not being actively developed, it may be granted. I can't say. :-)
The whole module? Really?
The whole module? Really? Why not just the offending TPL?
Integrated
Because it's way too much work for our volunteer sysadmins to dig through the CVS history and prune out just certain files, some of which may have modifications and some not. :-)
TPL should reside within the project directory tree
http://groups.drupal.org/node/14734#comment-51433
As long as the license is one that FSF allows for GPL there should not be a problem. There shouldn't be any reason for a sysadmin to delete a project using GPL copesetic TPL. For the sake of goodwill this policy needs to change.
IMO you can relicense BSD
IMO you can relicense BSD code under GPL, as Larry explained.
You can host 3rd party code as part of your theme or module, if:
1) it is relicensable as GPL (see above)
2) it would be too high a burden for a downloader to obtain the code otherwise.
2) is true for example if the user would need to modify the elsewhere downloaded code. If in doubt, ask me.
This may be a little off subject...
What about projects that aren't modules or themes? I'm creating a project that would be similar to drush's cvs download, but wouldn't install in a module directory, it would just be a very useful script. Since it doesn't fit in the CVS module or theme scheme, I would think it hard to put it in drupal's CVS. Also would it be able to have a project page? Just looking to clarify the ides being discussed.
"Module"
I don't know that there is a structure for that right now, since they're so rare. I think the most common places for that right now would be to call it a module for CVS purposes and then note on the project page and/or readme file that it's just a script, or to just put it in your CVS sandbox. That's not a legal question, though, but one to take up with the infrastructure team in their issue queue.