linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Massimo Maggi <me@massimo-maggi.eu>
To: linux-fsdevel@vger.kernel.org
Subject: Re: Posix ACL on non-GPL modules.
Date: Sat, 12 Oct 2013 14:51:38 +0200	[thread overview]
Message-ID: <525945DA.6040908@massimo-maggi.eu> (raw)
In-Reply-To: <20131012081444.GA16821@infradead.org>

On 12/10/2013 10:14, Christoph Hellwig wrote:
> attempts to bypas the license we put on the code and vilationg our copyrights.

I seriously appreciate the clear description of what you were thinking
when reading my message.
I will also be clear: My intention is to fully respect developer's
decisions to protect APIs and (obviously) respect laws.
Original author's decision in this regard is clear:
posix_acl_init,posix_acl_alloc,posix_acl_valid,posix_acl_equiv_mode,posix_acl_from_mode,posix_acl_chmod,
posix_acl_create are explicitly exported for modules with _ANY_ license.
Therefore I'm authorized to use them in a CDDL-licensed module.
There is one function, posix_acl_release, whose use is clearly related
to posix_acl_alloc, which does not have a clearly expressed export
policy, as it is an inline function written in a header file. Through
multiple macro expansions, it calls a GPL-only symbol. Being an inline
function, the linker won't allow that.
Do you agree with me that this is a quite weak to express the decision
to not allow the use of Posix ACL's functions in non-GPL modules?
This is the reason why I tought this might be an oversight.
If original authors think that Posix ACL APIs should not be used from
non-GPL modules, I suggest you to export also:
posix_acl_init
posix_acl_alloc
posix_acl_valid
posix_acl_equiv_mode
posix_acl_from_mode
posix_acl_chmod
posix_acl_create

as GPL-only symbols. Currently, they are available to modules with any
license. Your intent of protecting Filesystem APIs will be clear to
anyone and will be respected without any more questions on this mailing
list.
This is an inconsistency that IMHO should be fixed. Fixing it in a more
liberal way or in a more strict way is up to the original authors.
Sorry for the long message, but I felt misunderstood and wanted to make
my point clear.
Regards,
Massimo Maggi


  reply	other threads:[~2013-10-12 12:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-11 23:30 Posix ACL on non-GPL modules Massimo Maggi
2013-10-12  8:14 ` Christoph Hellwig
2013-10-12 12:51   ` Massimo Maggi [this message]
     [not found]   ` <CAOPrR7qkkBbYi2esgwbN3-OrkPeP=W9OG59ArUSqLf67ia8DSg@mail.gmail.com>
2013-10-12 14:48     ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=525945DA.6040908@massimo-maggi.eu \
    --to=me@massimo-maggi.eu \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).