On 12/31/2011 2:06 PM, Dirk Stöcker wrote:
> On Sat, 31 Dec 2011, Ian Wild wrote:
>> Assuming the Trac project wants to take Apache Bloodhound code, why is
>> shipping the Apache v2 license file and adding an appropriate
>> attribution in the form of a boilerplate to any file that contains
>> Apache licensed code 'impossible'?
>
> Ok. It is not "impossible". It is "undoable". A programmer is no lawyer
> and nobody I know doing software development in his free time wants to
> care for this. The result would be that after probably one year of
> copying code the license situation would be so confused, that nobody
> knows which files are licensed how. Again the result would be to switch
> everything to ALv2.
Even if more and more files would end up being ALv2 (only ALv2 for new
files, BSD + ALv2 for modified files?), the result as a whole could
still be licensed as BSD (as long as it's modified code, and it will
be as at the very least we will have "less" bundled plugins), and
provided we stick with the *terms* of the ALv2 license, i.e. carry the
LICENSE file somehow (contrib/LICENSE.Bloodhound?) and give proper
attributions that we used code from Apache (in a new NOTICE file).
But you're right, this might prove painful and could have been avoided
had they stuck to the same license as ours. For example, some people
pick only our wonderful plugin system in trac/core.py and a few other
files, other pick some of our utilities. So far it's simple for them,
we're a BSD project compatible with almost everything. What if now
they have to carefully look if what they take is BSD, BSD + ALv2 or
ALv2 only? Not impossible but harder than it is now. Of course, *we*
could switch to ALv2, but such a move is hard to justify beforehand,
and I think it will only happen if there's a really compelling reason
to do so.
Besides, even if the license would be the same, another concern is the
Apache policy related to contributor license agreements. I now wonder
if the Bloodhound project will even able to integrate our changes back
into their contributed and modified files (in a kind of "regularly
merge from upstream" workflow), as the changes contributed to Trac
typically won't be accompanied by a CLA [3] for Apache. Indeed, we
already have trouble getting our contributors to bother writing a
proper commit message, so let alone sign and send such paperwork ;-)
But they also never said they even *wanted* to do this, so far. If
they don't integrate our changes, then yes, the two code bases could
likely diverge after a while and it would prove difficult to stay
compatible.
So I'm not sure anymore. Perhaps my initial view that we could just
take their code (if it would be pertinent to do so based on its own
merit or for easing compatibility) was just misguided. Maybe the
split of licenses and policies regarding CLAs really doesn't make it
that realistic to share the code.
If that's the case, then we just won't take any modifications from
Bloodhound and we'll move on. This is of course fine by me, but it
would be better to have the answers to the questions above, in order
to know whether it's worth for us (as Trac maintainers) to spend some
time watching the Bloodhound project or not.
>
> I know the trouble I had with JOSM to find out whether the code is
> "GPLv2+" or "GPLv2 only", which is a major difference and this is only
> one license.
>
Right, the GPL is even a bit more complicated to deal with... Except
for one thing: once it's GPL, all derived work needs to be GPL as well
so with that license we wouldn't have had the kind of complications
we're now seeing here with the more "liberal" licenses ;-)
-- Christian
[1]
https://svn.apache.org/repos/asf/gump/trunk/python/gump/core/commandLine.py
[2] http://www.apache.org/licenses/LICENSE-2.0.txt
[3] http://www.apache.org/licenses/icla.txt
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to trac-dev@googlegroups.com.
To unsubscribe from this group, send email to
trac-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
