[Buildroot] Package license constraints

[Buildroot] Package license constraints

[Grégory Romé]

Hello,

Can I add a proprietary package to buildroot which could be redistributed?

Generally, what are the license constraints?

Thanks,
Gr?gory

[Buildroot] Package license constraints

[Markus Heidelberg]

Gr?gory Rom?, 20.03.2009:
> Hello,
> 
> Can I add a proprietary package to buildroot which could be redistributed?

I think generally it's OK, otherwise we shouldn't allow building the
commercial license version of Qt, for example.

> Generally, what are the license constraints?

No idea.

Markus

[Buildroot] Package license constraints

[Thiago A. Corrêa]

Hi,

On Sat, Mar 21, 2009 at 3:06 PM, Markus Heidelberg
<markus.heidelberg@web.de> wrote:
> Gr?gory Rom?, 20.03.2009:
>> Hello,
>>
>> Can I add a proprietary package to buildroot which could be redistributed?
>
> I think generally it's OK, otherwise we shouldn't allow building the
> commercial license version of Qt, for example.

I guess it depends on what you want to push. Qt is GPL, LGPL and
Commercial. It already made sense to have it before, having the
commercial support was just a matter of a few config changes. On the
other hand, we don't have any thing on buildroot that *requires* Qt
commercial, because it's proprietary code or something like that.

In general, proprietary code isn't shared at all, unless it's dual
licensed. If you mean a binary package, them I guess the answer would
be pretty much "No".

Not that we are open source zealots, but rather that it would just be
impossible to crosscompile and have other platforms use it at all. We
also would not like to host your binary packages for you and on the
top of that, it could most likely be something that is not generic
enough for many users to take advantage of that package, etc.

But hey, if you could describe your package a little more, what it is,
what it does, and what are the licensing terms, then we could be more
specific than this "maybe/probably" answer :)
Also, then you would have much greater chance to get a reply from our
maintainer with a final answer.

>> Generally, what are the license constraints?
>
> No idea.
>

Same here, so far we never had that question raised AFAIK. It could be
complicated if your licensing terms would not permit us from
redistributing it in the first place since we keep a mirror of the
packages to ensure things will keep working for some time after
release. Please be more specific.

Kind Regards,
   Thiago A. Correa

[Buildroot] Package license constraints

[Grégory Romé]

On 03/22/2009 01:17 AM, Thiago A. Corr?a wrote:
> Hi,
>
> On Sat, Mar 21, 2009 at 3:06 PM, Markus Heidelberg
> <markus.heidelberg@web.de>  wrote:
>> Gr?gory Rom?, 20.03.2009:
>>> Hello,
>>>
>>> Can I add a proprietary package to buildroot which could be redistributed?
>> I think generally it's OK, otherwise we shouldn't allow building the
>> commercial license version of Qt, for example.
>
> I guess it depends on what you want to push. Qt is GPL, LGPL and
> Commercial. It already made sense to have it before, having the
> commercial support was just a matter of a few config changes. On the
> other hand, we don't have any thing on buildroot that *requires* Qt
> commercial, because it's proprietary code or something like that.
>
> In general, proprietary code isn't shared at all, unless it's dual
> licensed. If you mean a binary package, them I guess the answer would
> be pretty much "No".

My goal in this case is not to share a package, but to add a 'pure' 
binary package to the Buildroot I provide to my customer (to avoid two 
entry points, one for the open source components and one for the others).

Obviously, I'm very careful to respect the open source license!

>
> Not that we are open source zealots, but rather that it would just be
> impossible to crosscompile and have other platforms use it at all. We
> also would not like to host your binary packages for you and on the
> top of that, it could most likely be something that is not generic
> enough for many users to take advantage of that package, etc.

Sure.

>
> But hey, if you could describe your package a little more, what it is,
> what it does, and what are the licensing terms, then we could be more
> specific than this "maybe/probably" answer :)

A cryptographic library that we sale to our customers but we don't want 
to provide the source code (to protect the implementation).

> Also, then you would have much greater chance to get a reply from our
> maintainer with a final answer.
>
>>> Generally, what are the license constraints?
>> No idea.
>>
>
> Same here, so far we never had that question raised AFAIK. It could be
> complicated if your licensing terms would not permit us from
> redistributing it in the first place since we keep a mirror of the
> packages to ensure things will keep working for some time after
> release. Please be more specific.
>
> Kind Regards,
>     Thiago A. Correa


Thanks,
Gr?gory

[Buildroot] Package license constraints

[Daniel Mack]

On Mon, Mar 23, 2009 at 01:50:23PM +0100, Gr?gory Rom? wrote:
>> I guess it depends on what you want to push. Qt is GPL, LGPL and
>> Commercial. It already made sense to have it before, having the
>> commercial support was just a matter of a few config changes. On the
>> other hand, we don't have any thing on buildroot that *requires* Qt
>> commercial, because it's proprietary code or something like that.
>>
>> In general, proprietary code isn't shared at all, unless it's dual
>> licensed. If you mean a binary package, them I guess the answer would
>> be pretty much "No".
>
> My goal in this case is not to share a package, but to add a 'pure'  
> binary package to the Buildroot I provide to my customer (to avoid two  
> entry points, one for the open source components and one for the others).

Don't know if my oppinion matters here, but I would say that a package
like this would at least be of some use for others (not just your
customers). Proprietary drivers would be an example, if unavoidable.

>> But hey, if you could describe your package a little more, what it is,
>> what it does, and what are the licensing terms, then we could be more
>> specific than this "maybe/probably" answer :)
>
> A cryptographic library that we sale to our customers but we don't want  
> to provide the source code (to protect the implementation).

Closed source crypto sounds insane, IMO. It's not only that there are
tons of free cryptographic implementations out there, closed source code
like this is also not very trustworthy to anybody.

Don't take it personally, but I'd certainly vote NO for that. But I'm
not the maintainer, so I can't judge.

Daniel

[Buildroot] Package license constraints

[Thiago A. Corrêa]

Hi Gr?gory,

2009/3/23 Gr?gory Rom? <gregory.rome@maxim-ic.com>:
> On 03/22/2009 01:17 AM, Thiago A. Corr?a wrote:
>
> My goal in this case is not to share a package, but to add a 'pure' binary
> package to the Buildroot I provide to my customer (to avoid two entry
> points, one for the open source components and one for the others).
>
> Obviously, I'm very careful to respect the open source license!
>
[cut]
> A cryptographic library that we sale to our customers but we don't want to
> provide the source code (to protect the implementation).

Doesn't it depend on libs from the buildroot environment? Say, if we
decide to update uClibc or update one of the other toolchain packages,
wouldn't that break the binary package?

If you say yes to those last 2 questions then it sounds like the best
approach for you and your customers might be a fork, so if we change
things, it doesn't suddenly stop working for them. Then you would have
more control over things and you could merge our changes into your
tree as you review them, and hopefully, send back changes in your tree
that are generic enough to be usefull to others for inclusion into
upstream.

I guess the only reason to roll your own crypto library is to use a
crypto support inside one of your chips. Since it runs linux(as you
use buildroot), it would really be best if it were added to existing
crypto libraries, so existing apps could take advantage of that. This
would still actually only benefiting your customers directly and not
those of some other chip maker as the internal registers are likely
different anyway.
Of course, that is just my 2 cents, I don't really know what business
model you are trying to achieve.

Anyway, it doesn't look much practical to have a binary package added
to buildroot, mostly because of the dependencies.

Kind Regards,
   Thiago A. Correa