On 26/08/12 06:42, Joe Pfeiffer wrote:
> Ron Waters writes:
>> On Wed, Aug 22, 2012 at 04:30:06PM -0700, Valient Gough wrote:
>>> Hi,
>>>
>>> I hadn't been spending much time on encfs over the last few years, ever 
>>> since
>>> full-disk encryption became fast enough that it was the norm for all my 
>>> systems
>>> (including cell phones!).  However I've become aware of an increased used 
>>> as a
>>> wrapper on top of cloud storage systems.
>>>
>>> Client-side encryption is good for users, by making cloud data less 
>>> accessible
>>> to misuse.  There are now multiple public storage clouds and a number of
>>> middleware components for syncing user data to those clouds.  I believe it 
>>> is
>>> beneficial to users to have inter-operable middleware, so it is in the best
>>> interest of users to make it easier for middleware to incorporate encfs.  
>>> With
>>> that in mind, I'm planning to ease the licensing requirements for encfs.
>>>
>>> My plan is to modify the license for an upcoming release.  Files making up
>>> libencfs would be re-licensed under LGPL (was GPL).  The main programs 
>>> (encfs,
>>> encfsctl) would remain GPL.
>>>
>>> The idea is that this would make it easier to incorporate libencfs into
>>> commercial middleware, while still maintaining what I consider the primary
>>> benefit -- that modifications such as a port to a new architecture would be
>>> released as open source.
>>>
>>> Comments / concerns?
>>
>> This sounds great!
>>
>> One thing I was wondering about was how would developers be able to use
>> libencfs without reading the main programs source code or taking
>> examples from these (which are still licensed under GPL).
>>
>> Given that libencfs by itself isn't documented, the only practical way
>> to incorporate libencfs into commercial projects without violating GPL
>> would be to read libencfs's code and do some guesswork on how it was
>> meant to be used.
>>
>> One option is of course to write documentation for libencfs. However,
>> this may involve quite an effort.
>>
>> Perhaps the main programs could be licensed under a more lenient license
>> than GPL as well? This would allow others to wrap libencfs with wrappers
>> which could borrow code from the main programs, and export functionality
>> to closed source modules. These wrappers might need to be licensed under
>> an open source license, depending on the license chosen for the main
>> programs. If the license is lenient enough, libencfs could even be used
>> directly without any wrappers.
>
> Well, the "right" thing to do would be to document libencfs!
>
> Aside from that, it's far from clear to me that the GPL requires
> clean-room techniques (ie, "without reading the main program's source
> code").
> http://h2o.law.harvard.edu/viewThread.do?postId=53


It is very clear to me that the GPL does not require that. Anyone can 
see the source of the GPL main program and use it as documentation 
without forcing any code written based on that knowledge to be covered 
under the GPL!


Robert

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Encfs-users mailing list
Encfs-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/encfs-users

Reply via email to