Change license to BSD for compatibility with Trac core

So I'm not sure if this ticket is asking for permission or if this is a good idea.

As far as permission....sure, I guess? I'm not a lawyer nor do I have intimate knowledge of the legal ramifications of this decision.

As far as whether its a good idea, I would say no. For a few reasons. For one, why this should be done isn't really outlined. I'm a big fan of keeping atomic functionality atomic. Bundling disparate things together just for distribution seems to be an anti-pattern. Is the reason for the sake of coherent development strategy? For making money? As a FOSS proponent and an IP opponent, I can get behind the former and not the latter.

Replying to k0s:

As far as whether its a good idea, I would say no. For a few reasons. For one, why this should be done isn't really outlined. I'm a big fan of keeping atomic functionality atomic. Bundling disparate things together just for distribution seems to be an anti-pattern. Is the reason for the sake of coherent development strategy? For making money? As a FOSS proponent and an IP opponent, I can get behind the former and not the latter.

I'm just exploring whether this is a good idea, and the licensing issue would be the first roadblock, so that's why I wanted to ask you about this. I would not proceed without your permission, and as the writer of the software, my understanding is that you are free to choose whatever licensing terms you would like. I intend to fully respect that right.

I don't intend to benefit financially and I'm just here to contribute to the FOSS community as I enhance and fix the tools that my company uses. I don't know much about licensing, but isn't the BSD license more free and open than any GPL license? In fact, this is something that I've been meaning to educate myself on. I read a recent ticket comment by osimons in which he stated, if I remember correctly, that he prefers not to contribute to GPL licensed plugins because of the restrictions of GPL licensing. My goal is to collaborate with others to develop software that is completely free and has no restrictions on use, so if GPL is indeed restrictive in this regard, I'd probably start to steer clear of those plugins. But like I said, I'm not educated about this stuff.

My reason for considering bundling these items together is to help resolve the jQuery UI conflicts. I outline this in comment:12:ticket:8964, which is why I hadn't provided much justification in this ticket. For example, the KeywordSuggestPlugin is using a recent version of jQuery UI and AutocompleteUsersPlugin is using an old jQuery plugin. If both AutocompleteUsersPlugin and KeywordSuggestPlugin are enabled, the KeywordSuggestPlugin breaks. There have been similar conflicts between DateFieldPlugin and WorkLogPlugin because they both use a datepicker objects. I'm trying to get all of these issues fixed so that I can use these components together.

One step that I think needs to happen is to get all of these plugins using the same version of jQuery UI. From a maintenance standpoint, I was thinking it might be easier if they were bundled together, but I'm not fixated on this yet. I'm just looking for opinions and feedback to help me think about the issue. Maybe there is a better way?

Replying to k0s:

As far as permission....sure, I guess? I'm not a lawyer nor do I have intimate knowledge of the legal ramifications of this decision.

Not a lawyer myself, but as a long-term Debian user and admin I felt urged to gained some fundamental insight. I've learned, that both are compatible licenses meaning you could re-use code under both and integrate into source under the other license. The so-called viral effect of the GPL still makes a difference to the legal effect: BSD code merges into GPL code rather silently, granted proper attribution to original author is retained. Not quite so with GPL inside the BSD or any other domain. It gradually turns surrounding code into GPL too, what is even the explicitly desired effect of this license.

To sum up BSD vs. GPL even shorter, it's about protecting versatility vs. protecting freedom of derived work. FOSS tends to support the latter, while the Trac community made a clear statement towards the former by moving to a BSD license years ago. And this spirit is the reason for osimons's and others position.

As far as whether its a good idea, I would say no. For a few reasons. For one, why this should be done isn't really outlined. I'm a big fan of keeping atomic functionality atomic. Bundling disparate things together just for distribution seems to be an anti-pattern. Is the reason for the sake of coherent development strategy? For making money?

The excursion into licenses above may suggest a strong linkage to that. Only I can't confirm that for any occasion rjollos and I have joined for maintaining Trac hacks. Working for free is not exactly altruistic, but more in the sense of not preventing to make money with results. In fact I don't know about anyone who's taking the extra workload of maintenance for maximizing profit. Anyhow, please take for granted, that the request is mostly towards improving code and maintenance for the plugins in question - a long-term engagement with a growing number of plugins for protecting and carrying on the work done so far.

As a FOSS proponent and an IP opponent, I can get behind the former and not the latter.

Sure, understand, and personally I'm with you there. But co-operations think different for various reasons. I acknowledge, that they happen to pay Trac developers to make their living with other stuff, essentially enabling them to contribute to further development at least in their spare time. Without this minimum, indirect support, plugin code would not only become more and more useless with every new Trac release, but Trac applications would possibly loose a lot of it's possibly use cases.

+1 for your open-minded style of discussion, asking questions before going into details and possibly answers. I purposefully avoid suggestions here, that tend to initiate religious wars about the subject rather than fruitful exchange of opinions and respectful argumentation. Respect and co-operate with authors and fellow developers, same as rjollos declared above.

Seeing I was mentioned, I suppose I better elaborate too - even though I have no particular interest in this particular bundling scenario.

In general, when all core features and core plugins are BSD, depending on GPL is just troublesome. And, personally I stay away because I'm wary of even lifting ideas that I get from reading GPL code. I need to be able to read and patch and improve all the code I use for my service, but I will not knowingly read or use GPL source code as I'm afraid that I even unknowingly can get entangled in murky licensing down the road.

We had a great discussion about this in the Bitten project that may be of interest, see bitten:ticket:453 Another painful GPL history is the Trac Mercurial plugin that is GPL licensed, and therefore cannot be shipped with Trac like the Subversion backend. On the other side, hvr changed GitPlugin from GPL->BSD for this particular reason - see https://github.com/hvr/trac-git-plugin/commit/d7a50e261b5aff5a404c016f9153b2ed7ef4298e (with comments at the bottom of the changeset, something Trac should support btw...)

So, in my opinion GPL in the Trac-sphere prevents reuse and precludes horizontal or vertical integration. It it fine for regular users, but does not work so well for the developer community. But even if I don't like it, I fully respect the wish of others to use GPL. Their code, their choice. No harm in asking, though ;-)

The comments in this ticket have me thinking more about possible scenarios. Suppose I do some work on a plugin, and it becomes refined enough that I wish to produce a patch for possible acceptance to the Trac core. If the code in the plugin is licensed as GPL, it seems that there might be a problem with integrating this to the Trac core. If that statement is accurate, then I will definitely start being more selective about which plugin I work on.

k0s, have you had a chance to review the comments in this ticket and decide if you are willing to switch the license to BSD?

So see http://trac-hacks.org/ticket/9768#comment:1 ;)

If you want permission to do this, sure, go ahead.

Thanks! I just want to be certain ;)

I think there is a COPYING file with the BSD license in one coderanger's plugin, so I'll probably just grab that and commit the change against this ticket.

#7429 had a comment that points to t:SeaChange/WhatDevelopersWant, which has some interesting comments on the license issue and potential for integration of plugins to the Trac core.

I was contacted today by the guys that are working on the Apache Bloodhound project, which is a fork of Trac, and as far as I understand it an Apache licensed open-source project with commercial backing. They were asking about packaging the plugin with their project, and suggested they might push some patches back to t-h.o. They also requested that the plugin be changed from GPL to BSD license, which I explained had already been approved.

Anyway, I'm not affiliated with that project other than having chatted with those guys from time to time, but I said that as far as I know you can use the plugin since it is (now) BSD licensed, and I'd be thrilled to have some patches sent back my way for maintaining this plugin in t-h.o, since it needs a lot of work for Trac 0.12 compatibility and other issues, and I haven't found time to maintain it lately.

I'll make the licensing changing now, to BSD 2-clause license, unless I hear a preference to one of the other specific BSD N-clause licenses.

(In [11369]) Refs #9768: Switch from GPL to BSD 2-clause license.

(In [11501]) Refs #9768: Renamed 0.11 directory to trunk.

(In [11502]) Refs #9768: Part of [11501].

(In [11503]) Fixes #9768: Changed license to BSD 3-Clause (same as Trac core). Tagged build with dev.

(In [11504]) Refs #9768: Part of [11503].