Hi there,

Ask a lawyer.

I might (have to). But clarification of the intentions by the maintainers and authors of Boost or the Boost Software License could give a much clearer picture. I see this definition as a very central point.

It is my understanding that derivative means a work based on something. Since your code uses shared_ptr it would then be "based on" shared_ptr.

But that is exactly where clarification is needed. My understanding of the phrase "derivative works" differs from yours, and I suspect that this will be the case for many people. I understand that it is an explicit goal of Boost developers to allow an almost entirely free (in the sense of free speech and free beer) usage of the library, INCLUDING commercial use. If, by simply using (or worse: deriving classes from) components of Boost the authors (who are possibly part of a company) would give away rights in their or their companies' code, very few commercial entities would ever produce software intended for public consumption, based on Boost. It is my understanding that this is one of the most central points where the GPL and the Boost Software License differ. The GPL automatically extends to code based on GPL'ed code. It is "viral" (I do not like that phrase), no matter whether the original, GPL'ed code itself was modified or not. The Boost Software License - at least this is how I understand it - is _not_ viral. But by not defining clearly, what "derivative works" means, this question is left open. Hence my proposal (posted to the Boost.documentation list - it has not appeared there yet) to add a corresponding section to the FAQ. But of course I am not a lawyer either. As per Scott's proposal, I will get myself a copy of Lawrence Rosen's book.

I also think you only need to list the copyright in the code if you give it out.

Well, many people and companies will want to be able to a) write commercial code (and possess all rights in the code) and b) hand out the source code without loosing any rights in their code (at least in code that makes no modifications to the original code). Please note that I'm not trying to argue against Boost or the Boost Software License. This is a great library! But if I loose substantial rights by using it, I at least want to know. Hence I believe that clarification of the term "derivative work" is needed. Best Regards, Ruediger

Ruediger Berlich wrote:

But that is exactly where clarification is needed. My understanding of the phrase "derivative works" differs from yours, and I suspect that this will be the case for many people.

Me too: I would read as "modification of", not "use of".

I understand that it is an explicit goal of Boost developers to allow an almost entirely free (in the sense of free speech and free beer) usage of the library, INCLUDING commercial use.

Yes, that was the motivation behind the licence.

If, by simply using (or worse: deriving classes from) components of Boost the authors (who are possibly part of a company) would give away rights in their or their companies' code, very few commercial entities would ever produce software intended for public consumption, based on Boost.

It is my understanding that this is one of the most central points where the GPL and the Boost Software License differ. The GPL automatically extends to code based on GPL'ed code. It is "viral" (I do not like that phrase), no matter whether the original, GPL'ed code itself was modified or not. The Boost Software License - at least this is how I understand it - is _not_ viral.

Exactly: that at least was the intent of the licence: of course IANAL, but it was drafted by one at least. John.

Here are two links which might shed some light on the meaning of "derivative work": http://www.rosenlaw.com/lj19.htm (Lawrence Rosen's page on derivative work). http://en.wikipedia.org/wiki/Derivative_work (see particularly at the end of the article) Best, Ruediger

Dear Peter, my question evolves from the following excerpt from the BSL: "Permission is hereby granted [...] to prepare derivative works [...] subject to the following: The copyright notices in the Software and this entire statement, including the above license grant, this restriction and the following disclaimer, must be included [...] (in) all derivative works of the Software, [...]". My interpretation of this is the following (and it is quite possible that to an English native speaker accustomed to legal speach this is an entirely stupid view ;-) If the definition of "derivative works" includes activities commonly understood as "usage" then, as per the above excerpt, basically any person just using Boost in an application has to a) include a copyright notice for the corresponding Boost library's author in the code (despite the fact that no modifications of that library's code took place) b) include the Boost license in his/her code. It would seem to me that this way a person who is just using Boost would sign away substantial rights in his/her own code. This in itself is not a bad thing, as long as the person using the code clearly knows that. So this is the point I'm trying to understand. If I simply _use_ Boost software in my code, which obligations do I have ? Please note that for me the term "usage" covers things like linking, #include'ing headers, instantiating Boost classes and benefitting from their services, deriving classes from Boost classes, overriding virtual functions in such derived classes, etc. . It does **not** cover modification of the original code, copying parts of the code into my own application (with the obvious exception of #include statements, #defines, etc). A short search on the Web revealed different interpretations of the term "derived work". The two fractions seem to be the FSF and the two URLs in my last posting (Wikipedia + Lawrence Rosen's page). Please also note that Lawrence Rosen says on his page about "derivative works": "This is a complex topic that courts and lawyers disagree about". But even if the legal meaning of "derivative works" *is* indeed well understood in US jurisdiction: Copyright laws differ in different countries. And Boost has both contributors and users from around the world. Plus, judging from the comments I've read on the Web, people who are not from the legal profession have difficulties with the phrase "derivative work". Hence, a section in the FAQ about the intention behind the BSL and how the initiators understood the term "derivative works" might help Boost get accepted by many more people. Have a nice evening, Ruediger Peter Dimov wrote:

Ruediger Berlich wrote:

...

Here are two links which might shed some light on the meaning of "derivative work":

http://www.rosenlaw.com/lj19.htm (Lawrence Rosen's page on derivative work).

http://en.wikipedia.org/wiki/Derivative_work (see particularly at the end of the article)

Why does the definition of "Derivative Work" matter to you (in the context of the BSL)?

Ruediger Berlich wrote:

Dear Peter,

my question evolves from the following excerpt from the BSL:

"Permission is hereby granted [...] to prepare derivative works [...] subject to the following: The copyright notices in the Software and this entire statement, including the above license grant, this restriction and the following disclaimer, must be included [...] (in) all derivative works of the Software, [...]".

My interpretation of this is the following (and it is quite possible that to an English native speaker accustomed to legal speach this is an entirely stupid view ;-)

If the definition of "derivative works" includes activities commonly understood as "usage" then, as per the above excerpt, basically any person just using Boost in an application has to a) include a copyright notice for the corresponding Boost library's author in the code (despite the fact that no modifications of that library's code took place) b) include the Boost license in his/her code.

... It would help if we use specific examples. Let's say that you have // foo.cpp // Copyright 2007 Joe Q. Author. All rights reserved. #include int main() { boost::shared_ptr<int> px( new int( 5 ) ); } Are you concerned that this foo.cpp may be considered a derivative work of boost/shared_ptr.hpp? My non-lawyer opinion is that it isn't, even if we use a Boost interface that is not already in TR1 and on its way to C++0x. Are you concerned that foo.o/.obj is a derivative work of shared_ptr.hpp? It may or may not be - this is a somewhat gray area because of the inlining - but the BSL specifically places no restrictions on derivative works in .obj form.

Felipe Magno de Almeida wrote:

If, hypotetically, I fix a bug in shared_ptr. What are my obligations when using it inside a closed-source project?

You aren't allowed to change the license of the modified shared_ptr.hpp; it must remain under the BSL. You have no other obligations. Of course you need to talk to a real lawyer if you want the question answered with certainty. ;-)

It would help if we use specific examples. Let's say that you have

// foo.cpp // Copyright 2007 Joe Q. Author. All rights reserved.

#include

int main() { boost::shared_ptr<int> px( new int( 5 ) ); }

Are you concerned that this foo.cpp may be considered a derivative work of boost/shared_ptr.hpp?

Yes, this is the case I'm talking about. My intention is to make my application, *including* its sources, available under a dual-licensing scheme, pretty much in the way Trolltech does it.

My non-lawyer opinion is that it isn't, even if we use a Boost interface that is not already in TR1 and on its way to C++0x.

That was also my original assumption when I did a quick cross-check of the licenses of third-party software involved in my application, and I still believe that the case you mention above is *not* derivative work. However, during research on the Web I have realised that there is a rather large variety of opinions about this topic. Indeed the very first answer to my post to this list showed a different opinion (see Noah's post). So some clarification (e.g. in the FAQ) might be needed, *particularly if library authors have a different understanding of this topic* . On the boost.devel list, David Abrahams strongly emphasizes the need for one license. That, I would think, requires an agreement amongst Boost authors of what the license entails. If two authors use the BSL for their code, and one defines "usage" as "derivative work" and the other doesn't, then they are not using the same license.

Are you concerned that foo.o/.obj is a derivative work of shared_ptr.hpp? It may or may not be - this is a somewhat gray area because of the inlining - but the BSL specifically places no restrictions on derivative works in .obj form.

Yes, I've seen that there is no restriction to derivative works in object form. BTW, IANAL. Best, Ruediger (and sorry for kicking off this thread ... ;-)

All,

Let's consider an analogy. If a writer uses words or phrases defined in a dictionary, does he need to acknowledge the copyright of that dictionary in his work? Of course not. If that were illegal, he would have to make up his own words and append a huge glossary to the end of his novel, which no one would then be bothered to read. IANAL, but that is exactly the same as is happening here. Microsoft, Boost, etc, provide definitions of functions, etc, for use, unmodified, in other code. Now, if were to take the code for iostream, change a few things and then market it as my own work, it would be a derivative work and a breach of copyright.

If we agree with this, then the next question is: what about example code ? Clearly the intention of the example code is to help the developer get on its way for using the library. But is it ok to copy/paste some of that code or does that automatically make the work derived ? For example, for a project, we started from the boost asio http server example, and extended this with various things to suit our needs, and put the result in a library ("wthttpd"). Can we now: 1) license "wthttpd" as GPL code ? (I assume not ?) 2) link this library "wthttpd" together with GPL code, and redistribute the resulting program as a GPL program, but put this library "wthttpd" as a whole under the boost license ? 3) distribute the whole program, including "wthttpd" under a proprietary license where the user is not given access to the source code (under the assumption that we are the copy right owner of all the GPL code involved) ? If not, how should we license this library "wthttpd" ? Regards, koen