1 |
Ed W wrote: |
2 |
>> It's not simple. You have to learn the requirements of each license |
3 |
>> and see if and how they allow themselves to be combined. There are |
4 |
>> businesses doing exactly that. If you want to DIY I think you just |
5 |
>> have to start by reading the licenses. You may or may not want an |
6 |
>> IP lawyer sitting beside you while doing it. |
7 |
> |
8 |
> This is the kind of unhelpful answer that I can find plenty of examples of |
9 |
> through google... |
10 |
> |
11 |
> Consider that all software comes with some kind of licence. Generally if |
12 |
> you ask a non opensource company about licensing costs then even the sales |
13 |
> droid can help you out. I do find it quite baffling that on average if you |
14 |
> question an opensource user then their answer on licensing is that one |
15 |
> should redirect the question to one of the most expensive and opaque |
16 |
> professions on earth... |
17 |
|
18 |
That's not what I wrote, I wrote that *you* should read the licenses. |
19 |
|
20 |
I wouldn't have mentioned an IP lawyer at all had it not been for the |
21 |
fact that I know that you are in the US. :) |
22 |
|
23 |
Lawyer or not depends on how much self education one is interested |
24 |
in. I've given open source law advice to customers and have had some |
25 |
contact guiding IP lawyers to better understanding. But it really is |
26 |
a big field, and you weren't clear on if you already had a good |
27 |
understanding of the requirements in the various licenses. |
28 |
|
29 |
|
30 |
> If your mate gave you that answer in the pub when you asked what |
31 |
> price for a beer you would immediately cotton on that they don't |
32 |
> really know and are bluffing... |
33 |
|
34 |
No bluff. |
35 |
|
36 |
|
37 |
> The bit people seem to miss is that legal documents are for forcing |
38 |
> arbitration in the event of dispute - in the meantime people are supposed |
39 |
> to rub along in a cooperative manner. That many OSS advocates seem to feel |
40 |
> that employing expensive lawyers is the only way to talk to them shows that |
41 |
> they are probably missing the bigger picture... |
42 |
|
43 |
Mh. A pretty picture, but the reason IP lawyers can live off open |
44 |
source alone is that there are people who do not and do not want to |
45 |
understand the licenses themselves. They may or may not desire to |
46 |
behave well. If they do want to behave well, they may want IP lawyers |
47 |
to not have to learn themselves, or because they don't trust |
48 |
themselves or their understanding of the legal system. If they don't |
49 |
want to behave well the IP lawyers will be working for the opposition |
50 |
and have a job hunting them down. :) |
51 |
|
52 |
I do not and have never advocated immediately talking to a lawyer |
53 |
over first trying to understand licenses oneself. |
54 |
|
55 |
That said, the legal systems of the world are such that it actually |
56 |
doesn't matter what the own understanding is, the only thing that |
57 |
matters is the opinions of the legal systems. And that's where the |
58 |
lawyers have experience. |
59 |
|
60 |
OTOH, I think that by now, there are enough documented cases that |
61 |
allow also developers themselves to understand the issues if they |
62 |
want to, and I very much encourage this. |
63 |
|
64 |
|
65 |
> On a more constructive note: I think I do understand the key terms of the |
66 |
> main software licences we use, from my understanding they are not all that |
67 |
> onerous. |
68 |
|
69 |
Sounds good. It is important to have gotten this right, since it is |
70 |
what drives everything else. |
71 |
|
72 |
|
73 |
> So can we perhaps move this topic onto tips, suggestions and |
74 |
> practical matters about moving forward? I'm not sure that one of |
75 |
> the most expensive type of lawyers is best employed talking |
76 |
> scripting tips? |
77 |
|
78 |
No, and I never said they were. |
79 |
|
80 |
|
81 |
>> If you have patches which use a different license than the package |
82 |
>> they modify then you have more work to do. Portage doesn't help here. |
83 |
>> A good start would be to add record of all patches applied by emerge. |
84 |
>> Indeed add it into the epatch command. |
85 |
> |
86 |
> OK, so this is what I asked the list. Please don't turn it back at me... |
87 |
> |
88 |
> Firstly can we not assume that the patches in gentoo *are* in compliance, |
89 |
> otherwise gentoo's various packaged binaries would cause Gentoo to be out |
90 |
> of compliance? |
91 |
|
92 |
Hm, this last sentence is inconsistent, but I guess it should be |
93 |
without the first "not" based on the rest you write. |
94 |
|
95 |
If you dare assume that all patches use the same license as the |
96 |
package they apply to, then I would say that it's actually easy |
97 |
to do an inventory of the packages and licenses your system uses. |
98 |
|
99 |
The package/license inventory is the first step. |
100 |
|
101 |
|
102 |
> So, back to the problem: one of the bigger challenges seems to be how to |
103 |
> actually capture the absolute list of patches applied? Any suggestions? |
104 |
|
105 |
I think you will have to extend portage. You can have a look at PMS |
106 |
(emerge app-doc/pms) to find what is currently possible. I think the |
107 |
A environment variable (Table 12.1 page 46) is the closest to what |
108 |
you want, but it does not seem to cover patches. |
109 |
|
110 |
|
111 |
> I already suggested creating my own "patch" utility which saves it's |
112 |
> input - seems ugly - other suggestions? |
113 |
|
114 |
I gave it already in the last mail; you should modify the epatch |
115 |
function to also do some bookkeeping. |
116 |
|
117 |
|
118 |
> I'm not using catalyst. |
119 |
|
120 |
Ok, then you have more manual work to do, because catalyst already |
121 |
does some of the things required by e.g. GPL for you, or at least it |
122 |
makes them easier to do. |
123 |
|
124 |
|
125 |
> Any tips from others on capturing, presenting, managing and |
126 |
> deploying GPL code? |
127 |
|
128 |
This is a little like asking "Any tips from others on building a car |
129 |
from scratch?" It's not a very practical question; it's much too |
130 |
broad. I think it would be good to focus on something specific. |
131 |
|
132 |
|
133 |
> Hoping for useful answers here rather than "talk to some really |
134 |
> expensive professional who knows nothing about programming". |
135 |
|
136 |
The programming involved is trivial IMO, although there are of course |
137 |
pricey commercial products for software inventory and license |
138 |
management out there. The difficult part is to understand the legal |
139 |
requirements that create technical requirements for your distribution |
140 |
of open source software. |
141 |
|
142 |
That process obviously has nothing to do with programming, and if you |
143 |
need legal advice it really is a good idea to talk to lawyers, not |
144 |
programmers. |
145 |
|
146 |
At the same time, I do advocate studying and discussing licenses. |
147 |
They are not magical, I actually find them pretty straightforward. |
148 |
|
149 |
|
150 |
> Gentoo seems very attractive for building embedded system - however, there |
151 |
> seem to be some missing steps to help with deployment. I thought that was |
152 |
> ontopic for this list? Any tips from others who are building things? |
153 |
|
154 |
I use catalyst, and I control what gets deployed with custom ebuilds |
155 |
and snapshots. The fewer packages in the final system the better; |
156 |
less stuff to track. |
157 |
|
158 |
|
159 |
//Peter |