Ed W wrote:
>> It's not simple. You have to learn the requirements of each license
>> and see if and how they allow themselves to be combined. There are
>> businesses doing exactly that. If you want to DIY I think you just
>> have to start by reading the licenses. You may or may not want an
>> IP lawyer sitting beside you while doing it.
> This is the kind of unhelpful answer that I can find plenty of examples of
> through google...
> Consider that all software comes with some kind of licence. Generally if
> you ask a non opensource company about licensing costs then even the sales
> droid can help you out. I do find it quite baffling that on average if you
> question an opensource user then their answer on licensing is that one
> should redirect the question to one of the most expensive and opaque
> professions on earth...
That's not what I wrote, I wrote that *you* should read the licenses.
I wouldn't have mentioned an IP lawyer at all had it not been for the
fact that I know that you are in the US. :)
Lawyer or not depends on how much self education one is interested
in. I've given open source law advice to customers and have had some
contact guiding IP lawyers to better understanding. But it really is
a big field, and you weren't clear on if you already had a good
understanding of the requirements in the various licenses.
> If your mate gave you that answer in the pub when you asked what
> price for a beer you would immediately cotton on that they don't
> really know and are bluffing...
> The bit people seem to miss is that legal documents are for forcing
> arbitration in the event of dispute - in the meantime people are supposed
> to rub along in a cooperative manner. That many OSS advocates seem to feel
> that employing expensive lawyers is the only way to talk to them shows that
> they are probably missing the bigger picture...
Mh. A pretty picture, but the reason IP lawyers can live off open
source alone is that there are people who do not and do not want to
understand the licenses themselves. They may or may not desire to
behave well. If they do want to behave well, they may want IP lawyers
to not have to learn themselves, or because they don't trust
themselves or their understanding of the legal system. If they don't
want to behave well the IP lawyers will be working for the opposition
and have a job hunting them down. :)
I do not and have never advocated immediately talking to a lawyer
over first trying to understand licenses oneself.
That said, the legal systems of the world are such that it actually
doesn't matter what the own understanding is, the only thing that
matters is the opinions of the legal systems. And that's where the
lawyers have experience.
OTOH, I think that by now, there are enough documented cases that
allow also developers themselves to understand the issues if they
want to, and I very much encourage this.
> On a more constructive note: I think I do understand the key terms of the
> main software licences we use, from my understanding they are not all that
Sounds good. It is important to have gotten this right, since it is
what drives everything else.
> So can we perhaps move this topic onto tips, suggestions and
> practical matters about moving forward? I'm not sure that one of
> the most expensive type of lawyers is best employed talking
> scripting tips?
No, and I never said they were.
>> If you have patches which use a different license than the package
>> they modify then you have more work to do. Portage doesn't help here.
>> A good start would be to add record of all patches applied by emerge.
>> Indeed add it into the epatch command.
> OK, so this is what I asked the list. Please don't turn it back at me...
> Firstly can we not assume that the patches in gentoo *are* in compliance,
> otherwise gentoo's various packaged binaries would cause Gentoo to be out
> of compliance?
Hm, this last sentence is inconsistent, but I guess it should be
without the first "not" based on the rest you write.
If you dare assume that all patches use the same license as the
package they apply to, then I would say that it's actually easy
to do an inventory of the packages and licenses your system uses.
The package/license inventory is the first step.
> So, back to the problem: one of the bigger challenges seems to be how to
> actually capture the absolute list of patches applied? Any suggestions?
I think you will have to extend portage. You can have a look at PMS
(emerge app-doc/pms) to find what is currently possible. I think the
A environment variable (Table 12.1 page 46) is the closest to what
you want, but it does not seem to cover patches.
> I already suggested creating my own "patch" utility which saves it's
> input - seems ugly - other suggestions?
I gave it already in the last mail; you should modify the epatch
function to also do some bookkeeping.
> I'm not using catalyst.
Ok, then you have more manual work to do, because catalyst already
does some of the things required by e.g. GPL for you, or at least it
makes them easier to do.
> Any tips from others on capturing, presenting, managing and
> deploying GPL code?
This is a little like asking "Any tips from others on building a car
from scratch?" It's not a very practical question; it's much too
broad. I think it would be good to focus on something specific.
> Hoping for useful answers here rather than "talk to some really
> expensive professional who knows nothing about programming".
The programming involved is trivial IMO, although there are of course
pricey commercial products for software inventory and license
management out there. The difficult part is to understand the legal
requirements that create technical requirements for your distribution
of open source software.
That process obviously has nothing to do with programming, and if you
need legal advice it really is a good idea to talk to lawyers, not
At the same time, I do advocate studying and discussing licenses.
They are not magical, I actually find them pretty straightforward.
> Gentoo seems very attractive for building embedded system - however, there
> seem to be some missing steps to help with deployment. I thought that was
> ontopic for this list? Any tips from others who are building things?
I use catalyst, and I control what gets deployed with custom ebuilds
and snapshots. The fewer packages in the final system the better;
less stuff to track.