On Monday, January 2, 2012 6:03:05 PM UTC-5, Christian Boos wrote: > > 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?), > Right: all current files would remain BSD, and would be modified under that license. New files created by committers at the ASF would fall under ALv2, and be noted as such in their header. We would be attaching a LICENSE file with the ALv2, and a NOTICE file that notes that portions are available under the BSD license (under whatever copyright). The ASF will leave any existing copyright notices in the file headers. It may prepend a small notice above that to refer people to the overall package license and NOTICE file; I don't know the plan right now. It isn't too hard to keep track of licensing on a per-file basis, as you simply look in the header. 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). > That sounds just right. Apache Bloodhound is released as a whole under the ALv2, and incorporates some work under the BSD. If Trac chooses to incorporate code from Bloodhound, then it would be released (as a whole) under the BSD license with portions under the ALv2. The licenses are bidirectionally compatible. You *cannot* "relicense" (as I've seen mentioned else-thread) any of the code. You must distribute it under the terms of its existing license, but those terms are extremely liberal for both licenses. 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* > Well, the ALv2 is philosophically just like BSD, so this isn't a complicated decision for consumers of a Trac (w/ Bloodhound code) release. The material difference is that the ALv2 has been modernized in its reference to copyright, trademark, and patent law. I can provide details if anybody is curious, but I think that is mostly immaterial to the discussion at hand. Suffice to say, the two licenses operate mostly the same, and are fully-aligned in their permission philosophy. But the first sentence is the sticking point for the ASF, as code developed and released by the ASF must fall under the ALv2. We don't have a choice on that point. > 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. > Your users would get the same style of license, so it wouldn't be a big deal from their standpoint. But it is certainly some work for you. > 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 > The CLA that Apache committers sign says they have the "right" to commit the patch to version control. Whether that right is based on those provided by the BSD license, or that the committer has authored their own work... they can still make the commit. In short: the ASF won't have any problems carrying upstream changes into its codebase. >... I've rejiggered the subject line for this message to call out the licensing stuff. I'd be more than happy to followup with any questions or concerns that people may have. For reasons good or bad, I happen to know all too much about this stuff :-P Cheers, -g -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To view this discussion on the web visit https://groups.google.com/d/msg/trac-dev/-/tPk7fKAY3gIJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
